Related tweet: https://twitter.com/fvsch/status/663658769419751424

I believe that: 1) BLACK text color should NOT be used for array lengths on DARK theme 2) Changing theme color should be applied immediately, not after reload (that's how it works currently) Tell me if I should file these as blocking bugs.

(Sorry for the attachment spam, didn't find a way to add them all at once.)

I’m going to list the issues I can see using the JSON viewer on Nightly (Firefox 45), if it can help. ## Reach: JSON viewer on text/plain responses Many JSON URLs out there have no Content-Type header in the response or respond falsely with Content-Type:text/plain. Here’s one example: https://raw.githubusercontent.com/npm/npm/master/package.json Maybe there’s an opportunity for using the JSON viewer on URLs that end in “.json” when the Content-Type is null or text/plain. ## General UI polish / fixes - The Save buttons (in the JSON and Raw Data tabs) don’t seem to work. - In the JSON tab, the Filter input box has square corners and italic text, vs. the filter/search input boxes in the DevTools which have rounded corners and regular text (at least on OSX). - In the Headers tab, the headings have a [-] icon but can’t be collapsed (not that collapsing would be that useful here). - Right-to-left support needs some tweaks. Main bug: in the JSON tab, the toolbar buttons disappear behind the search box. ## Readability/UX: zoom level tied to hostname If users zoom the JSON viewer page, this preference impacts all pages for the hostname from which the JSON data is served. In development situations, this means that a developer working on a website might end up zooming the website’s HTML pages (perhaps in other tabs) because they zoomed the JSON viewer. This also means that if users zoom the JSON viewer to a level that is comfortable for them, this setting will not be applied to JSON views for other hostnames. Let’s review how other Firefox tools manage this. View Source: keeps a different zoom level info for each URL. It doesn’t impact web views, or other View Source views for other URLs on the same hostname or on different hostnames. Developer Tools: zoom level is specific to the DevTools pane (devtools.toolbox.zoomValue). I suggest making the zoom level either follow devtools.toolbox.zoomValue, or make it specific to the JSON viewer (maybe a devtools.jsonview.zoomValue), not impacting web pages, and shared between all instances of the JSON viewer (I don’t see the value of per-URL zoom level preferences). ## Readability: problematic typographic choices By default the text is hard to read, since it’s displayed as 11px Courier on OSX or 11px Courier New on Windows. The combination of the small font-size and a font with a small x-height hurts readability big time. Let’s break it down: Size: the JSON viewer doesn’t follow user preferences for monospace font-size (hard 11px). This is unlike the View Source view (uses the user’s preference, 13px by default), but similar to what the DevTools tend to do (11px by default, no user preference except for the global zoom). If the JSON viewer will use the same (small) font-size as the DevTools, perhaps it should use the DevTools zoom level too? So that if a user finds 11px too small in the DevTools and has zoomed it, this will be matched in the JSON viewer. Font family: currently the JSON viewer CSS uses "font-family:monospace;", but sadly 11px Courier/Courier New is a no-go, and Firefox seems stuck with Courier New/Courier by default for monospace web content on Windows and OSX (those OSes are using more modern and more readable monospace fonts, mostly Menlo and Consolas I think, but I guess the point is to not "break" the visual style and spacing of sites relying on the small Courier/Courier New). So, if the JSON viewer is not going to follow the user’s preferences for monospace font-family *and* font-size, it should imitate the DevTools better and try to pick a more readable font. (The Inspector uses a --monospace-font-family custom property, I guess with one stylesheet per platform. On OSX it's set to Menlo.) Finally, some of the text is sans-serif, which is alright for headings in the Headers tab, but perhaps not so great for keys in the main JSON view. In any case, the font-family used is: "Lucida Grande, Tahoma, sans-serif" (same on OSX and Windows). It would be nice if this text could use the main system font (or main UI font used by Firefox). Apparently using "font:message-box" gets you the system font, and it's the technique used all over the place in Firefox UI (DevTools, preferences). (I'm attaching a screenshot of the Headers tab with the OSX system font + Menlo for the values + small spacing tweaks + font-size bumped to just 12px. I’d say it looks nicer.) ## JSON tab - contrast issues in the Dark theme Using the Dark theme, the base blue is too dark or too dull. Comparing similar colors: - In the JSON viewer: #5E88B0 - In the DevTools inspector: #46AFE3 Other text (e.g. array lenths) is dark gray on dark blue or something like that. The orange seems close enough. ## JSON tab - usability - one-line object summaries can lead to information overload Object values are represented in compact form on the same line as the key, something like that: object_key { child_1: "some value", child_2: "other value", child_3: 42, more… } Possibly with nested compact representations: object_key { child_1: { gand_child_1: "some value", grand_child_2: "something else" }, child_2: "other value", child_3: 42, more… } When you have a lot of lines like this visible, this can lead to information overload, and a representation of data that is very hard to parse mentally into something meaningful. See the two attached screenshots for examples of very dense representations of data. Note that it can also be incoherent to have object summaries but not array summaries. They’re both expandable, but array summaries are just "[length]". One solution, which I’ve mocked up quickly in "proposal-compact-expanded.png" (attached), is to limit object summaries to a count of properties. ## JSON tab - duplicate information when expanding an object When an object is expanded, the object summary is still displayed, resulting in an unclear visual feedback, unclear hierarchy and duplicate information. In the attached "duplicate-information.png" screenshot, the information "needsflag:false" is visible 3 times, but it’s only one data point. ## JSON tab - misleading representation of empty arrays Empty arrays are represented as: key_name [0] (or "key_name: [0]" in object summaries) This, and the syntax coloring used (the zero is green, like a number literal in the Console) suggests that the value for key_name is an array with one value, the number 0. Yet the value is an *empty* array. It should probably be represented as "key_name: []". For the record, empty objects are: "key_name { }". ## JSON tab - readability - too much punctuation removed? Except in the object summaries, this punctuation is removed: - commas - colons - curly brackets (for expanded objects) - square brackets (for expanded arrays) I understand doing away with the commas, and relying on new lines only. But I would reinstate the colons to not be too far from JSON syntax (which users already know). Right now when users are faced with: some_key "hello…goodbye" other 4 it can be a bit hard to parse, and the colons (or another visual separator, but why invent a new one unrelated to the actual syntax?) would help: some_key: "hello…goodbye" other: 4 For the brackets, I find it puzzling to have them in the object and array summaries but not having them wrap the expanded data. This does not convey "full content of an object" to me: some_key { annie: "are you okay", are_you_okay: "annie" } annie "are you okay" are_you_okay "annie" Similarly for an array (though the lack of repetition makes it not as bad): some_key [4] 0 "annie" 1 "are you okay" 2 "are you okay" 4 "annie" Since we already have the brackets anyway that indicate the type, why not go the full way and wrap the expanded values in the brackets? (See "proposal-compact-expanded.png".) ## JSON tab - usability - line expanding lacks visual cues For expanding an object/array, there are visual feedback cues when hovering the key and the [+]/[-] indicators beside it (the key turns blue and is underlined). But the full line is actually reactive, and there is no visual feedback to show it. Also, making the full line clickable, up to the right edge of the page, means that there can be a lot of blank space that does something for hard-to-identify reasons when it's clicked. It might be better to: - limit reactive zones to where there is some text under or near the cursor; - give visual feedback on hover for the whole zone that is reactive. ## JSON tab - visual - expand[ed] indicators feel a bit old The [+] and [-] indicators on the left of keys with expandable values (objects, arrays) feels like something from older Windows OSes. Maybe use the triangle used in the DevTools inspector's dom tree? ## JSON tab - accessibility - no keyboard access? When I use the Tab key in the JSON tab nothing reacts visually. I can’t tell if something gets the focus. Since all elements are DIV and SPANs, and document.activeElement seems to always point to the body when I try to Tab my way through this page, I suspect keyboard navigation is not supported at all for now. I’m also wondering about screen reader access. Was there some preliminary research done on how a collapsible, hierarchical structure might be surfaced efficiently to screen readers? ## JSON tab - usability - filter box has limited value, can be frustrating When exploring structured data, one will often have a lot of data with objects several levels deep and key/value pairs that look like e.g.: "relevant_info:4". Searching for "relevant_info" will select all or most entries. Searching for "4" will yield a lot of false positives if the user intended to select all entries that had a value of "4" for "relevant_info". There are situations where just searching keys and values for a string will be useful. But also many others where it will be unusable and frustrating. Two ideas for data exploration: 1. Filter by key:value pairs. Maybe with a special syntax in the filter field (like "relevant_info:=4", "relevant_info:<4", "relevant_info:text") or a dedicated, more discoverable UI. 2. Filter (or maybe query, with a separated result view?) by path. For instance if we have data that looks like this: [ …, 102: { x:"y", meta:{…}, … }, … ] We might use "[102]" to isolate "102: { x:"y", meta:{…}, … }". And we might use "[102][meta]" to isolate "meta:{…}". Terminal featuritis, I know. :D ## JSON tab - usability - copying a single text value Text values longer than N characters are shortened, and expanded on click. For instance I have a value that looks like this: "https://msdn.microsoft.c.../mt146826(v=vs.94).aspx" and clicking it expands it as: "https://msdn.microsoft.com/en-us/library/mt146826(v=vs.94).aspx" Once expanded, I want to select and copy it. I click at the start of the text, drag to the right, release the click to end the selection… and the text gets shortened and kills my selection. The solution seems to be to start clicking outside of the text value, so that one doesn't trigger a click-that-toggles-the-value. Doable but hard to figure out. Aaand that’s about it. :)

Thanks for the detailed feedback. ni'ing and cc'ing Honza to ensure he sees this. Honza: let me know if you want to discuss and prioritize the feedback, or just put a meeting on my schedule as early as 8AM PT.

Adding this: when refreshing the page, the JSON viewer always shows the first tab ("JSON"). If the user was on the second or third tab, that navigation is lost.

(ah, I accidentally removed the flag, setting again, will reply asap) Honza

I am marking this bug as 'meta'. Some parts already fixed/wip (bug 1230544, bug 1230583) the other are discussed/analysed. Thanks fordetailed report Florent! Honza

Ok, I'm going through all this to double check it. (In reply to Florent Verschelde from comment #7) > I’m going to list the issues I can see using the JSON viewer on Nightly > (Firefox 45), if it can help. > > ## Reach: JSON viewer on text/plain responses > > Many JSON URLs out there have no Content-Type header in the response or > respond falsely with Content-Type:text/plain. Here’s one example: > https://raw.githubusercontent.com/npm/npm/master/package.json > > Maybe there’s an opportunity for using the JSON viewer on URLs that end in > “.json” when the Content-Type is null or text/plain. There was an attempted fix in bug 1230544 but it was backed out with bug 1235118 I believe because it wasn't checking that the Content-Type was plaintext. So a lot of URLs like https://github.com/BYK/superset/blame/master/package.json became broken because they end in .json. I think we can take another stab at this. > ## General UI polish / fixes > > - The Save buttons (in the JSON and Raw Data tabs) don’t seem to work. Filed bug 1244265 but it looks like bug 1230583 if it gets going again. > - In the JSON tab, the Filter input box has square corners and italic text, > vs. the filter/search input boxes in the DevTools which have rounded corners > and regular text (at least on OSX). bug 1230583 is also taking this on. > - In the Headers tab, the headings have a [-] icon but can’t be collapsed > (not that collapsing would be that useful here). filed bug 1244268 but it looks like bug 1230583 was also taking this on. > - Right-to-left support needs some tweaks. Main bug: in the JSON tab, the > toolbar buttons disappear behind the search box. bug 1230583 is also taking this on as well. > ## Readability/UX: zoom level tied to hostname > > If users zoom the JSON viewer page, this preference impacts all pages for > the hostname from which the JSON data is served. > > In development situations, this means that a developer working on a website > might end up zooming the website’s HTML pages (perhaps in other tabs) > because they zoomed the JSON viewer. > > This also means that if users zoom the JSON viewer to a level that is > comfortable for them, this setting will not be applied to JSON views for > other hostnames. > > Let’s review how other Firefox tools manage this. > > View Source: keeps a different zoom level info for each URL. It doesn’t > impact web views, or other View Source views for other URLs on the same > hostname or on different hostnames. > > Developer Tools: zoom level is specific to the DevTools pane > (devtools.toolbox.zoomValue). > > I suggest making the zoom level either follow devtools.toolbox.zoomValue, or > make it specific to the JSON viewer (maybe a devtools.jsonview.zoomValue), > not impacting web pages, and shared between all instances of the JSON viewer > (I don’t see the value of per-URL zoom level preferences). investigating in bug 1244763 > ## Readability: problematic typographic choices > > By default the text is hard to read, since it’s displayed as 11px Courier on > OSX or 11px Courier New on Windows. The combination of the small font-size > and a font with a small x-height hurts readability big time. > > Let’s break it down: > > Size: the JSON viewer doesn’t follow user preferences for monospace > font-size (hard 11px). This is unlike the View Source view (uses the user’s > preference, 13px by default), but similar to what the DevTools tend to do > (11px by default, no user preference except for the global zoom). > > If the JSON viewer will use the same (small) font-size as the DevTools, > perhaps it should use the DevTools zoom level too? So that if a user finds > 11px too small in the DevTools and has zoomed it, this will be matched in > the JSON viewer. > > Font family: currently the JSON viewer CSS uses "font-family:monospace;", > but sadly 11px Courier/Courier New is a no-go, and Firefox seems stuck with > Courier New/Courier by default for monospace web content on Windows and OSX > (those OSes are using more modern and more readable monospace fonts, mostly > Menlo and Consolas I think, but I guess the point is to not "break" the > visual style and spacing of sites relying on the small Courier/Courier New). > > So, if the JSON viewer is not going to follow the user’s preferences for > monospace font-family *and* font-size, it should imitate the DevTools better > and try to pick a more readable font. (The Inspector uses a > --monospace-font-family custom property, I guess with one stylesheet per > platform. On OSX it's set to Menlo.) > > Finally, some of the text is sans-serif, which is alright for headings in > the Headers tab, but perhaps not so great for keys in the main JSON view. In > any case, the font-family used is: "Lucida Grande, Tahoma, sans-serif" (same > on OSX and Windows). It would be nice if this text could use the main system > font (or main UI font used by Firefox). Apparently using "font:message-box" > gets you the system font, and it's the technique used all over the place in > Firefox UI (DevTools, preferences). > > (I'm attaching a screenshot of the Headers tab with the OSX system font + > Menlo for the values + small spacing tweaks + font-size bumped to just 12px. > I’d say it looks nicer.) Font sizing and family issues filed in bug 1244910 > ## JSON tab - contrast issues in the Dark theme > > Using the Dark theme, the base blue is too dark or too dull. Comparing > similar colors: > - In the JSON viewer: #5E88B0 > - In the DevTools inspector: #46AFE3 > > Other text (e.g. array lenths) is dark gray on dark blue or something like > that. > > The orange seems close enough. I believe this was handled by bug 1232613 > ## JSON tab - usability - one-line object summaries can lead to information > overload > > Object values are represented in compact form on the same line as the key, > something like that: > > object_key { child_1: "some value", child_2: "other value", child_3: 42, > more… } > > Possibly with nested compact representations: > > object_key { child_1: { gand_child_1: "some value", grand_child_2: > "something else" }, child_2: "other value", child_3: 42, more… } > > When you have a lot of lines like this visible, this can lead to information > overload, and a representation of data that is very hard to parse mentally > into something meaningful. > > See the two attached screenshots for examples of very dense representations > of data. > > Note that it can also be incoherent to have object summaries but not array > summaries. They’re both expandable, but array summaries are just "[length]". > One solution, which I’ve mocked up quickly in > "proposal-compact-expanded.png" (attached), is to limit object summaries to > a count of properties. Agreed on the overload, not sure what the right solution is here. > ## JSON tab - duplicate information when expanding an object > > When an object is expanded, the object summary is still displayed, resulting > in an unclear visual feedback, unclear hierarchy and duplicate information. > > In the attached "duplicate-information.png" screenshot, the information > "needsflag:false" is visible 3 times, but it’s only one data point. Filed bug 1244912 to hide the duplicate information > ## JSON tab - misleading representation of empty arrays > > Empty arrays are represented as: > > key_name [0] > > (or "key_name: [0]" in object summaries) > > This, and the syntax coloring used (the zero is green, like a number literal > in the Console) suggests that the value for key_name is an array with one > value, the number 0. Yet the value is an *empty* array. > > It should probably be represented as "key_name: []". > > For the record, empty objects are: "key_name { }". Filed bug 1244916 for hiding the zero > ## JSON tab - readability - too much punctuation removed? > > Except in the object summaries, this punctuation is removed: > > - commas > - colons > - curly brackets (for expanded objects) > - square brackets (for expanded arrays) > > I understand doing away with the commas, and relying on new lines only. But > I would reinstate the colons to not be too far from JSON syntax (which users > already know). Right now when users are faced with: > > some_key "hello…goodbye" > other 4 > > it can be a bit hard to parse, and the colons (or another visual separator, > but why invent a new one unrelated to the actual syntax?) would help: > > some_key: "hello…goodbye" > other: 4 > > For the brackets, I find it puzzling to have them in the object and array > summaries but not having them wrap the expanded data. This does not convey > "full content of an object" to me: > > some_key { annie: "are you okay", are_you_okay: "annie" } > annie "are you okay" > are_you_okay "annie" > > Similarly for an array (though the lack of repetition makes it not as bad): > > some_key [4] > 0 "annie" > 1 "are you okay" > 2 "are you okay" > 4 "annie" At first I didn't agree, but I think you're right now that I look at the object summaries. Either we need to fix those to lose the colon, which I think would be odd or we need to be consistent and have the colon visible. Filed bug 1244919 > Since we already have the brackets anyway that indicate the type, why not go > the full way and wrap the expanded values in the brackets? (See > "proposal-compact-expanded.png".) I don't think we currently have the brackets, except that the object summary isn't hidden and therefore the brackets are always visible there. I do agree that we should have the corresponding brackets shown. Filed bug 1244920 > ## JSON tab - usability - line expanding lacks visual cues > > For expanding an object/array, there are visual feedback cues when hovering > the key and the [+]/[-] indicators beside it (the key turns blue and is > underlined). > > But the full line is actually reactive, and there is no visual feedback to > show it. > > Also, making the full line clickable, up to the right edge of the page, > means that there can be a lot of blank space that does something for > hard-to-identify reasons when it's clicked. > > It might be better to: > - limit reactive zones to where there is some text under or near the cursor; > - give visual feedback on hover for the whole zone that is reactive. I believe this has been fixed in bug 1232613 > ## JSON tab - visual - expand[ed] indicators feel a bit old > > The [+] and [-] indicators on the left of keys with expandable values > (objects, arrays) feels like something from older Windows OSes. Maybe use > the triangle used in the DevTools inspector's dom tree? I know this has been fixed in bug 1232613 > ## JSON tab - accessibility - no keyboard access? > > When I use the Tab key in the JSON tab nothing reacts visually. I can’t tell > if something gets the focus. Since all elements are DIV and SPANs, and > document.activeElement seems to always point to the body when I try to Tab > my way through this page, I suspect keyboard navigation is not supported at > all for now. I don't believe it is but I'll flag this with our accessibility folks to see what they think. > I’m also wondering about screen reader access. Was there some preliminary > research done on how a collapsible, hierarchical structure might be surfaced > efficiently to screen readers? I don't believe so but we can start looking into this. > ## JSON tab - usability - filter box has limited value, can be frustrating > > When exploring structured data, one will often have a lot of data with > objects several levels deep and key/value pairs that look like e.g.: > "relevant_info:4". > > Searching for "relevant_info" will select all or most entries. Searching for > "4" will yield a lot of false positives if the user intended to select all > entries that had a value of "4" for "relevant_info". > > There are situations where just searching keys and values for a string will > be useful. But also many others where it will be unusable and frustrating. > > Two ideas for data exploration: > > 1. Filter by key:value pairs. Maybe with a special syntax in the filter > field (like "relevant_info:=4", "relevant_info:<4", "relevant_info:text") or > a dedicated, more discoverable UI. > > 2. Filter (or maybe query, with a separated result view?) by path. For > instance if we have data that looks like this: > > [ > …, > 102: { x:"y", meta:{…}, … }, > … > ] > > We might use "[102]" to isolate "102: { x:"y", meta:{…}, … }". > And we might use "[102][meta]" to isolate "meta:{…}". > > Terminal featuritis, I know. :D We have some of this in other panels like the debugger and inspector so I think we can borrow some similarly appropriate syntax. > ## JSON tab - usability - copying a single text value > > Text values longer than N characters are shortened, and expanded on click. > For instance I have a value that looks like this: > > "https://msdn.microsoft.c.../mt146826(v=vs.94).aspx" > > and clicking it expands it as: > > "https://msdn.microsoft.com/en-us/library/mt146826(v=vs.94).aspx" > > Once expanded, I want to select and copy it. I click at the start of the > text, drag to the right, release the click to end the selection… and the > text gets shortened and kills my selection. > > The solution seems to be to start clicking outside of the text value, so > that one doesn't trigger a click-that-toggles-the-value. Doable but hard to > figure out. I believe this was handled in bug 1232634 > Aaand that’s about it. :) Aand, that should be all filed in bugs now. Thank you so much! I need to prioritize all these bugs I've filed bug this was super useful.

>> Note that it can also be incoherent to have object summaries but not array >> summaries. They’re both expandable, but array summaries are just "[length]". >> One solution, which I’ve mocked up quickly in >> "proposal-compact-expanded.png" (attached), is to limit object summaries to >> a count of properties. > Agreed on the overload, not sure what the right solution is here. Lets come back to this after the other bugs have been fixed. >> ## JSON tab - accessibility - no keyboard access? ... > I don't believe it is but I'll flag this with our accessibility folks to see what they think. I filed bug 1255828 for keyboard navigation and we'll get the a11y people to help with the input there. >> Terminal featuritis, I know. :D > We have some of this in other panels like the debugger and inspector so I think we can borrow some similarly appropriate syntax. I'm going to start filing some bugs about the search inputs in general that should cover this. Going forward we should be using more widget based inputs so we can share the same set of features across all the inputs we have. This is like a meta / breakdown bug so I'm marking this as fixed now that almost all the issues have separate bugs to track them.