This could include:

• "Esc" should collapse all open features
• Show/hide all panel toggle

Showing all may not be practical, but hide certainly is.

Something like:

[ green dot ] \t low compatibility risk \t what this means for web dev \t what this means for vendors

[ red dot ] \t high compatibility risk \t what this means for web dev \t what this means for vendors

Hit the tab button a few times until you're in the newly focusable feature list (thank you for fixing that!).

Once you're there, there's no indication that you're anywhere at all. A focus ring would be nice (I assume you're overriding 'outline'?). Or a different colour/background whatever. I'm not a UX guy. :)

Thanks!

-mike

non-intrusive links at the top of the list to select an alternate ordering e.g.

• last updated
• category
• alphabetical
• overall color

Other may be added.

Currently they only take into account how web developers and other vendors feel.

We also need to add a color status dot for the spec/standard

Because of the way these labels are generated, it's possibly that a feature is incorrectly categorized under a version. The labels are turned on for the very first feature of a milestone, but filtering changes this list.

In the example, template is chrome 26, but it's labeled under 27

ie sorting based on compatibility risk

In other words, if the left nav looks like:

30: canary
30: dev

Then remove the "canary" line.

I want to see all the features that are behind a flag in chrome right now. How do I do that?

Replace "Canary/Dev", "Beta", and "Stable" with "Enabled by default"

Confusing because for example, how can Lazy Layout be green for Web Developers, but there's "no public discussion" ?

Right now when you click on M29, the first feature that landed in M29 appears at the top of the list. But it's hard to tell where the last M29 feature is and the M28 features start.

It'd be good to break up the list like this:

...
--- 29 ----
Feature name1
Feature name2
--- 28 ----
Feature name3
...

The spreadsheet is a cluttered mess, but the one thing it has over this replacement is that it's easy to visualize the citizenship of the whole project at a glance, because you can see so many green/red cells and if you squint you get a good overall feel--kind of like how a sparkline can help you understand general trends even if the specific data points are too small to understand.

We should figure out how to add an aggregate view to the new dashboard.

the way html5please does.

Lower priority than #17

e.g. we should know the milestone the feature landed and the milestone that it was deprecate.

"Chromium Dashboard: a status of what we're up to" sounds strange to my eyes. :)

How about cutting it to "what we're up to"?

For example, in the "Web Animations/Graphics" title at the top of a chip, I would like to click "Graphics" and get a filtered list of all of the Graphics features.

Try in Safari: http://v2dash.cr-status.appspot.com/features

I'm seeing a few weird rendering bugs in Safari.

Issues:

1. the filtering search box doesn't work. The filtered feature count updates, but the list is not re-rendered properly.
2. toggling a feature opens it, where the rest of the template is activated (e.g. it's under <template if="{{open}}">. Safari refuses to render that content when open == true.
3. "In development" should be selected on the left nav when the page loads.

...everything is working correctly in Webkit Nightly and FF.

Also, when the inspector is open everything renders fine. Weird!

It needs a colored dot like web dev and other browser vendor opinions.

Currently, features are sorted by desktop launch milestones. They should instead be sorted by "most recent milestone on any platform."

For example, datalist support was added to Chrome for Android in M33: http://www.chromestatus.com/features/6090950820495360

The "datalist" feature should appear in the list of features for M33, not M20.

WDYT?

e.g. experimental status.

Tabbing through the document should eventually land me on the clickable feature list. It currently doesn't, as each item is just a flat <div>. I'd suggest adding "tabindex='0'" to each element that you expect folks to interact with (or changing them to use something which is natively focusable, like <a> or <button>).

As a second step, it would be good to ensure that they're interactwithable (yes, that's a word now) via the keyboard. :)

Thanks!

-mike

Right now, the feature view is only expanded if you click on the feature's name or category. Clicking anywhere on the box should open it.

To close the box, the right behavior is less clear to me. The current behavior seems fine, but users could be confused that clicking on the description twice doesn't open and then close the box. For that reason, I think we should make the "close box" click target bigger too.

It should be easy to deep link to a feature's entry on the dashboard.

From https://code.google.com/p/support/wiki/IssueTracker#Issue_entry :

The following fields can be pre-populated with a value supplied in the URL. Using links with these query parameters present allows you to guide end-users to enter an issue that is tailored to a specific need. Usually defining a template and specifying just a template value is better than specifying other values in a URL. The user must still review, edit, and submit the form.

Form field | URL query parameter | Values
Template | template | Name of a defined template in this project
Summary | summary | Initial summary string
Description | comment | Prompt text to show in issue description area
Status | status | Initial status value
Owner | owner | Username of initial issue owner
CC | cc | List of users to CC
Labels | labels | Comma-separated list of initial label values
Branch | branch | Initial branch path to use for code review requests

template : OWP Launch Tracking
summary : {feature description}
comment : defined here
status : Started
owner : {first owner email address}
cc : {other owner email addresses}
labels : I think this will be filled in by the template
branch : n/a

Example:
https://code.google.com/p/chromium/issues/entry?template=OWP%20Launch%20Tracking&summary={{feature.summary}}&status=Started&[email protected]&comment=body%20of%20intent%20template

What these look like in the wild is something like:
https://code.google.com/p/chromium/issues/detail?id=243345

Otherwise users have to manually scroll the version list. Some are offscreen.

Possible places to add it in the UI: below the version numbers or next to "Add a new feature"

There's been a few ideas around a more rich visualization. Also filtering and viewing the standardization side or the implementation side.

If anyone is interested, here would be a good place to throw out some ideas of what we could do and how to do it.

I think we should try to make the colors easier to understand by adding corresponding text.

Current colors:

Example of color with text on html5please.com:

I'm not sure exactly what the UI should look like.

So we gatther the data, even before it's available on the 'view' front end.

The best ordering would correspond to the column on the left (ie so "started" features appear first), but we might do alphabetical because it's easier to implement.

Investigate styling the size of the "citizenship" indicator by how big the footprint/visibility is.

Currently, the launch bug link is positioned immediately below the "Implementation Status" header. This is confusing because it reads as "Implementation Status: Launch Bug."

It should be moved to the end of the list, so that the actual implementation status appears first in the list, and reads as, for example: "Implementation Status: Started."

Android and desktop land features at different times. We need to distinguish.

Chromium Dashboard users should be able to 1) sign up for emails or 2) subscribe to RSS feeds for changes to:

• P0: Everything on the dashboard (analogous to email notifications on the current spreadsheet)
• P1: Specific entries (e.g. someone might only care about Shadow DOM)
• P2: Categories (e.g. someone might only care about Web Components)

Right now the search box moves when the number of web platform features changes:

Web Platform Features (100) [ Search Box ]
Web Platform Features (10) [ Search Box ]
Web Platform Features (1) [ Search Box ]

Ideally, the search box's position would remain fixed.

In v2, when you create a new record in the Admin view, it doesn't show up in the list view until you edit or create ANOTHER record.

If you flush memcache manually and refresh, the record shows up even without creating or modifying another record.

Items on the left (under "Builds") are not really builds, but a mix of implementation status and builds, which can be confusing. For example, users might expect clicking on "28 Stable" to show all features in Stable, but it only shows new features in that build. I think this could be expressed better. See specific proposal below.

I think http://html5please.com/ does this well.

Implement smooth scrolling when https://twitter.com/ebidel/status/364825118171602944 lands.

this.featureLiList[idx].scrollIntoView(true, {x: blah,y: blah, behavior: 'smooth'});