Closed Bug 1127871 Opened 9 years ago Closed 9 years ago

(compat-mdn-tables) [Compat Tables] Circulate Draft #2 for feedback

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: shobson, Unassigned)

References

Details

Attachments

(3 files)

Screen Shot 2015-03-06 at 8.04.24.png
65.90 KB, image/png
Details
On desktop safari, extra empty column moves icons to the right
49.07 KB, image/png
Details
On iPhone, table + detail dropdown is hard to use
111.23 KB, image/png
Details 
Circulate draft #2 for feedback from the team and do some user testing on it.
Depends on: 1127868
Blocks: 1127872
Note that it is not integrated with the API yet, the code has been written by hand.

Potential enhancements:
- row and column highlighting on hover and focus
- encourage user contributions when support is unknown
- on small screen, collapse tables with more than 2 rows so that tapping feature name expands support information

Known bugs:
- copy/paste from expanded history is buggy
- can't click links in expanded history
- can't read tooltips for icons when cell has more than 2 icons and wraps to new line
Convert icons in <span> to <abbr> so there's tool tips.
Comment 3 and this are both from :sheppy

Text in first column is sometimes clipped.
This is crazy beautiful. It needs a touch of design love here and there, and tooltips to explain the icons in the headers... but otherwise, it's just some little things like the text in the first column being clipped at times at the right edge of the cell.

Nice job!
A discussion in dev-mdc list suggests I need to include Android Browser in the display data as well.
I'm really impressed by the UX of this Stephanie. The different breakpoints all make sense, the icons look good, the way the notes expand in and out is really great, it is really elegantly keyboard accessible. I love it.

A few points: 

1. There are some cases in which you'll need three entries per browser vendor, for example in The Firefox column you'll need, Desktop, Android and Firefox OS. Can you mock this up so we can see if it works ok?
2. In the narrow screen view, I don't think you need to show the browser vendor icon on every line. Just show it once for each set.
3. I'd show a check icon in the green "supported" squares, in the same way that you show a cross for not supported - don't just convey the info by colour alone, anywhere.
4. There are some cases in which we'll want to have an extended notes section at the bototm of the compat table, e.g. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API#Browser_compatibility. Does this need any special design consideration?
I think the color quickly communicates the support for a feature, as well as points out where the data is sparse.  I've worked with a red-green color blind coworker, who beat into me that color isn't sufficient for yes/no data.

I like the concept of "click to get more info", and it is clear to which items have more information.  I'm not sure about the difference between crossing arrows, dog-earred pages, and -x-, but it's clear the next step is to interact to learn more.

I'm not sure about the display of this additional information.  It feels constrained by the table format. Maybe a summary is exposed within in the table view, with a further click to a detail view to let the information breathe.

On an iPhone, it's difficult to browse the information.  There's a lot of left-and-right scrolling to see all the entries, and then the detail is set to the width of the table, not the screen, so it's more scrolling to read the note.  I think that's already on your list of potential enhancements.

https://www.dropbox.com/s/obs7d7o6rqlcdug/draft2-iphone.png?dl=0

There's an issue on desktop Safari - the first icon section is blank, and then all others are off by one, so that the first icon under Firefox is for Chrome on Android.  Probably a simple fix, but a more complex design will require cross-browser fixes.

https://www.dropbox.com/s/oetyol7biudtnka/draft2-safari.png?dl=0

It's bold, and feels like a real upgrade.  Keep going!
Eeek, we have major bugs in iOS Safari. Dammit. 

John, I've attached a screen shot of how it's *supposed* to display.
Yep, that's what I was hoping to see.  Glad it's a bug rather than by design.

Also, thanks for reminding me about attachments.  I'll attach dropbox images for future reference.
Bugs in webkit should be resolved :)
Yes, works very nicely on desktop and iPhone Safari.  I was worried about long detail lists, but there is enough space on the edges to scroll past, and the transition between details works smoothly.
It looks great. Just one comment really, which maybe Chris in comment 7 had already: it looks like it tends to assume that browsers are organized by vendors, where each vendor might have one desktop and one mobile version. How solid do we expect that assumption to be (for example, is it challenged by Firefox OS, Microsoft "Spartan" ...), and how heavily does the design depend on that assumption?
I'll mock up a table with ALL THE BROWSERS :)
I've uploaded a page with some of the suggested changes here:
http://stephaniehobson.github.io/browsercompat/3/

> 3. I'd show a check icon in the green "supported" squares, in the same way that you show a cross for not supported - don't just convey the info by colour alone, anywhere.

> I've worked with a red-green color blind coworker, who beat into me that color isn't sufficient for yes/no data.

John and Chris, I couldn't find a good pattern to put behind the green :( A check mark felt wrong because it is obscured by the writing and ends up looking like the reverse of the \ through "partial". I'm going to count on the absence of pattern to relay the information to returning users.

For new users and high-contrast users I've added an icon with a tool tip to serve as a legend. The icon appears by default for @media screen and (-ms-high-contrast) and on :hover/:focus/.open for other users. If javascript is disabled the colour/patterns now display in the legend as well.

Is this solution headed in the right direction? I have a couple of colour bind users who I can have test it out once it's stable.
Flags: needinfo?(john)
Flags: needinfo?(cmills)
I've uploaded a page with some of the suggested changes here:
http://stephaniehobson.github.io/browsercompat/3/

> 1. There are some cases in which you'll need three entries per browser vendor, for example in The Firefox column you'll need, Desktop, Android and Firefox OS. Can you mock this up so we can see if it works ok?

Will and Chris, I've added a table showing at the end of the file showing how we'd display a vendor that had more than a desktop and mobile version. The table also serves to show how we can add more browsers if need be. I think 13 is the maximum number of browsers this design can handle. 

I have ideas for how we can allow the user to control which browsers display but it gets more complicated when one considers we will also want to have some control over what displays (for example we would want this page: https://developer.mozilla.org/en-US/docs/Web/API/BluetoothManager to show FxOS by default, if it had a table). I'm going to have to work on that part of the design after the default display is done.

Does this look extensible enough for our purposes?
Flags: needinfo?(wbamberg)
I've uploaded a page with some of the suggested changes here:
http://stephaniehobson.github.io/browsercompat/3/

> 2. In the narrow screen view, I don't think you need to show the browser vendor icon on every line. Just show it once for each set.

Change made :) It's impossible to centre the icons vertically or remove the lines between the browsers with the technique I've used to add the icons to every row. Is the association clear enough?
> - copy/paste from expanded history is buggy
> - can't click links in expanded history

I had to switch to a close button to enable these behaviours. It's not as slick but it makes the interaction much more explicit.

> - can't read tooltips for icons when cell has more than 2 icons and wraps to new line

Fixed. Also added cursor:help to all our icons.
> 4. There are some cases in which we'll want to have an extended notes section at the bototm of the compat table

Chris, it's no problem to add more text on the page after the compatibility table is inserted. It would be editable on MDN instead of via the API. The feeling I got from the compat data API team is that footnotes should be short. If we need to add a paragraph break it's probably content better maintained in MDN.
> tooltips to explain the icons in the headers... 

Added!
(In reply to Stephanie Hobson [:shobson] from comment #17)

> 
> John and Chris, I couldn't find a good pattern to put behind the green :( A
> check mark felt wrong because it is obscured by the writing and ends up
> looking like the reverse of the \ through "partial". I'm going to count on
> the absence of pattern to relay the information to returning users.
> 
> For new users and high-contrast users I've added an icon with a tool tip to
> serve as a legend. The icon appears by default for @media screen and
> (-ms-high-contrast) and on :hover/:focus/.open for other users. If
> javascript is disabled the colour/patterns now display in the legend as well.
> 
> Is this solution headed in the right direction? I have a couple of colour
> bind users who I can have test it out once it's stable.

Yeah, looking at this a bit more, I don't think you need a check mark, as it is fairly obvious it IS supported, if it is showing "Yes" or a browser version.

Yes, I think this is going in the right direction.
Flags: needinfo?(cmills)
(In reply to Stephanie Hobson [:shobson] from comment #18)
> I've uploaded a page with some of the suggested changes here:
> http://stephaniehobson.github.io/browsercompat/3/
> 
> > 1. There are some cases in which you'll need three entries per browser vendor, for example in The Firefox column you'll need, Desktop, Android and Firefox OS. Can you mock this up so we can see if it works ok?
> 
> Will and Chris, I've added a table showing at the end of the file showing
> how we'd display a vendor that had more than a desktop and mobile version.
> The table also serves to show how we can add more browsers if need be. I
> think 13 is the maximum number of browsers this design can handle. 
> 
> I have ideas for how we can allow the user to control which browsers display
> but it gets more complicated when one considers we will also want to have
> some control over what displays (for example we would want this page:
> https://developer.mozilla.org/en-US/docs/Web/API/BluetoothManager to show
> FxOS by default, if it had a table). I'm going to have to work on that part
> of the design after the default display is done.
> 
> Does this look extensible enough for our purposes?

This is also looking pretty good.
I agree w/ cmills, I think the text makes supported / not supported clear.  I've reached out to my friend, and I'll see if he agrees.
Flags: needinfo?(john)
I asked my friend, and he found it clear.  I think it is ready for wider feedback.
Looks good to me.
Feedback rolled up into stephaniehobson.github.io/browsercompat/3/
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(wbamberg)
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: