UI/UX brief

[eduardoboucas]

1. Main area

A table with browsers as columns and versions as rows. Roughly similar to what caniuse displays. This is where the user will get a general view of which browsers are fully compatible with their site, as well as which ones need work and how much.

Browser versions are colour-coded to indicate the amount of issues present for that particular version. In addition to the colour coding, we could also indicate in each cell the exact number of issues found. Something like this:

1.1. Questions

1. Is colour coding enough, or should we also add the number of issues to each cell?

2. How granular would the colour coding be? In the current prototype, there are only three colours:

   • Green: No issues

   • Yellow: Up to 3 issues

   • Red: 3 issues or more

     Is this enough, or should we look into dynamically generating the colours based on the exact number of issues, so that a browser version with 13 issues could have a slightly darker hue of red than another one with 12?

2. Sidebar

Currently, when users click on a specific browser version, any issues associated will appear on the sidebar. A header indicates the browser and version being inspected, as well as the number of issues. Each issue is then displayed as a row in a table, ordered by the number of occurrences from greatest to lowest.

Currently, issues are simply CSS properties, but eventually they can be anything from "flex CSS property" to "JS arrow functions".

Additionally, a list of radio buttons allows users to choose whether they want to see all the browser versions available or just the 10 more recent. Not sure if this should live in the sidebar, or if it should exist at all.

2.1. Questions

1. How do we expand on a specific issue? For example, if I see that the animation property I'm using is not supported by iOS Safari 8.4, I want to be able to expand on that and see more information, such as:
   • Which stylesheets are using it;
   • Where in those stylesheets the property is (file, line and column, with source map support);
   • Any additional information that can help me overcome the problem, such as a vendor prefix or polyfill. In this specific case, I would want to know that all I need is to add the -webkit prefix.

3. Others?

There are other things we'll need to configure that have not yet been built and I'm not sure where they should live.

1. Users can choose which stylesheets are going to be included in the compatibility report. I envision a list with the URL of each stylesheet with a checkbox next to it, so that the user can toggle it on and off. Not sure what we do about stylesheets embedded with <style> tags – as in how do we identify them in the list?

2. Choose what to analyse: CSS, JavaScript or both.

3. Flag an issue as resolved. The tool will do its best to be smart about flagging issues – for example, it will not warn about lack of support for rem units if it detects a px fallback in the same rule. However, there will be times where it fails to detect fallbacks, so it'd be nice if users could flag these situations – in a future version, it might even be possible for the tool to learn from these actions.

[captainbrosset]

My 2 cents.

Re: color coding:

Is this enough, or should we look into dynamically generating the colours based on the exact number of issues, so that a browser version with 13 issues could have a slightly darker hue of red than another one with 12?

I don't think a very granular color coding based on the number of issues is going to help much.
The thing is, maybe you have 20 errors and it's fine, it degrades nicely. Or maybe you have 1 error only and it's totally broken.
If the tool could color code based on how "broken" the site would be, then it might be more useful.
But I'm not sure this would be possible to do without false positives. So I'd stick with the simple green/yellow/red approach.

Re: sidebar

It might help to show a cell in the browser matrix as selected when you click on it. Like a border or outline.

I would move the options (number of browser versions) to a cog icon or something. Outside of the sidebar. So the sidebar can be fully used to display issue. This is going to be the most important area of your tool. When you think of it, the matrix is only here to navigate, once you've clicked on a browser, all you want to see is the issues, where they appear, why, and how to solve them. All of this information will be in the sidebar. So it makes to use as much space as you can for this.

Re: stylesheet config

Users can choose which stylesheets are going to be included in the compatibility report. I envision a list with the URL of each stylesheet with a checkbox next to it, so that the user can toggle it on and off. Not sure what we do about stylesheets embedded with <style> tags – as in how do we identify them in the list?

For displaying stylesheets in the list, I would advise to mimic what the Style Editor panel does. So it's easier for people to switch from one to the other and mentally map things together (obviously it would be better to offer links from one to the other, but that's not yet feasible for WebExtensions). So inline styesheets for instance are displayed as <inline style sheet #1>.

However, another approach comes to mind: instead of selecting which stylesheets you want to include in the report, maybe you always include them all but offer the possibility for users to silence any number of errors in the report. Maybe they know it's fine and they don't want to see it anymore in there.

Choose what to analyse: CSS, JavaScript or both.

Sounds like you need a toolbar similar to the webconsole, with filters. If you add that, then that would be a good place to put all of your settings too, behind drop-downs.

Flag an issue as resolved.

Haha, great. Exactly what I meant with silencing errors. That sounds really good to me.

[eduardoboucas]

@captainbrosset That's really useful, thank you!

I've done quite a lot of work on this recently and ended up instinctively incorporating most of the feedback you just gave me. I abandoned the idea of fine-grained colour coding and made substantial changes to how the sidebar works and how issues are displayed.

I've updated the Discourse thread last night with a new set of screenshots that illustrate the workflow. When you've had a chance to see them, I'd love to hear your thoughts.

Thanks again.