search

firefox-devtools / ux

Firefox DevTools UX Community
Mozilla Public License 2.0
103 stars 21 forks source link

Polish Headers Side Panel #116

Open janodvarko opened 4 years ago

janodvarko commented 4 years ago

The Headers side panel (in the Network panel) would deserve some UI/X clean-up (this might be done as part of the Accordion refactoring see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1613884

There are currently three expandable sections: 1) Response Headers 2) Request Headers 3) Request headers from upload stream

We could:

WDYT? @digitarald @bomsy @fvsch

image

Open Questions

Decisions

digitarald commented 4 years ago

There is both UI work to better align the space in this panel and UX for the information hierarchy.

From user feedback "network header tab is confusing", "a lot of information in a very compressed space – should be redone", "easy selecting and copy-pasting of request/response headers (for example: right-click header name and have the option to copy the name, value or name and value)."

Constraints that I'd like to throw in:

Questions:

fvsch commented 4 years ago

Would it make sense to move away from tabs to one accordion holding more/all sections?

Many sections have sub-sections, so we'd end up with like 10 accordion items which is a bit much. And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)

I notice that the Debugger when for a standard checkbox (in the Event Listener Breakpoints accordion header). We could use that, or make a smaller toggle control (the current one is rather big) and use it in Debugger too.

Personally for Headers I'd be happier with a single "Raw Headers" toggle (next to "Filter Headers") that affects all sections.

Maybe: States for pending request, streamed request/response

Yes please! It's hard to figure out that a request is pending just by looking at the table row, and you're left wondering if something is broken when the details are blank.

digitarald commented 4 years ago

And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Agreed, beyond WS, preview, formatted payloads and timings work better with more space. Security could link to the cert viewer or inline it.

To simplify the tabs, Cookies and Params could be rolled into the main panel. They often end up empty as well.

Related, Honza and I discussed why WS' Messages could not be shown in Response.

digitarald commented 4 years ago

A related UX bug, improving the summary view for cached resources: https://bugzilla.mozilla.org/show_bug.cgi?id=1338065

bomsy commented 4 years ago

Also to add to the list of suggestions from honza above

fvsch commented 4 years ago

Can we move the filter headers to the top to be consistent with the other panels?

A small toolbar with "Filter Headers" and a toggle for "Raw Headers" would be great. It'd be consistent with the Messages tab, or with what we have in the Inspector for Computed styles, for instance:

Screen Shot 2020-02-21 at 13 49 38

One difficulty is that those controls wouldn't affect the first block of information with the URL, Status, HTTP version etc. That could make the top placement a bit awkward.

janodvarko commented 4 years ago

Great, I really like these ideas (search box within a toolbar at the top) Created a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1617167

Honza

digitarald commented 4 years ago

Great, I really these ideas (search box within a toolbar at the top)

I shared @fvsch's concern on how it doesn't search through the first part.

Maybe we can find a consistent toolbar that allows filter/copy/pretty-raw-toggle?

digitarald commented 4 years ago

I found Paw last week and found its UI for inspection nice and clean:

Splits data in Info, Request (Headers, Formatted, Raw) and Response (Headers, Formatted, Raw)

image

Prev/Next buttons in toolbar are nice affordance for navigating between ordered requests (often in REST and page load):

image

Summarized request/response meta data links to the Request/Response tabs:

image

Raw tab shows full HTTP (with basic highlighting for headers):

image

Share button to export & upload to online viewer:

image
janodvarko commented 4 years ago

I found Paw last week and found its UI for inspection nice and clean:

I can't open the Paw link (or is it suppose to be a link?)

digitarald commented 4 years ago

I can't open the Paw link (or is it suppose to be a link?)

Fixed. It is on paw.cloud :).

digitarald commented 4 years ago

Updating priority as @bomsy will be starting on this soon.

digitarald commented 4 years ago

@violasong fyi, we had some discussion today for some mock ups I made: https://www.figma.com/file/cf8pMDTvi64HWzRhQWdMnO/DevTools-Network-Details-Pane?node-id=32%3A2

violasong commented 4 years ago

I'm working on a mockup but here are some initial thoughts:

Could we hide the Cookies/Params/etc tabs if they're empty, or could this be confusing?

Paw is a great find! Nice example of Mac native patterns.

For copying, there are a couple things we could try:

Some little consistency issues that could be fixed:

States for pending request, streamed request/response

Curious about this, but need to learn more. What does this look like in other places?

violasong commented 4 years ago

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

violasong commented 4 years ago

I noticed Safari does this nice color coding. Does categorizing it this way make sense?

image image
violasong commented 4 years ago

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

digitarald commented 4 years ago

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

I think I know what you mean. With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

States for pending request, streamed request/response

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

digitarald commented 4 years ago

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

As usual, I don't understand Safari's color/icon choices ;) . But as long as things are readable and copy-able we are good. It feels similar to Paw's information hierarchy, which highlights key aspects in slightly bolder form and then just lists out the rest.

violasong commented 4 years ago

With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

digitarald commented 4 years ago

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

This reminds of of an idea I liked UX table, Row to Details. It compresses additional details into the remaining row.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

Using phases from Resource Timing to map out which data gets available over time:

  1. requestStart: Request headers available (for many failed/blocked requests, this is we ever have)
  2. multipart/form-data requests (only important for file uploads): Chunked data are being added as they are sent
  3. responseStart: Response headers available
  4. responseStart to responseEnd: Response data chunks (and additional headers) available as they are received
  5. responsEnd: All data available

@janodvarko did I miss a state?

violasong commented 4 years ago

Content for the summarized section

* Single-line summaries for
  * Request: Method + Host + Path → Link to _Request_ tab
  * Response: HTTP Code → Link to _Request_ tab
  * HTTP/TLS Version → Link to _Security_
  * Size / Transferred Size + Time to Load → Link to _Timing_
  * Blocked Cookies? → Link to _Cookies_
  * Referrer Policy

Some questions about this:

At first I was thinking of a menu-like UI like this

image

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

image
janodvarko commented 4 years ago

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

@janodvarko did I miss a state?

I think that we can see it a bit more precisely as follows: (but, the impact on the UI might be minimal)

More info in HAR spec: http://janodvarko.cz/blog/har-12-spec/#timings

One more note. Request HTTP status is using a styled number in the first column image

We can reuse the same style in the Headers panel.

Honza

digitarald commented 4 years ago

Related, I just checked out Safari's Network details pane which has some related ideas to grouping and labels (It is a bit hidden in Sources, which seems a nice touch, to have that information available in other panels; but kind of hard to discover):

image image
digitarald commented 4 years ago

@violasong looks great.

@bomsy looking at Victoria's work, it doesn't seem like we'd want to use the tree component for that. Or do you see that we should customize it to present data like that?

What do you mean by "Link to Request tab"? (Different from the Request Headers section?)

Sorry, the Params payload tab, which should be called Request for consistency.

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

Do we still want to show Address?

It would be important to know which server is resolved for some requests. See my analysis for Safari – maybe it fits with additional URL data.

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

I like the option as well. Maybe they could appear on hover to reduce UI density?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

violasong commented 4 years ago

I like the option as well. Maybe they could appear on hover to reduce UI density?

That seems good, although maybe we want something there to encourage users to use the more contextual UI instead of looking through the tabs?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

That subtler look could work if we keep the labels short to allow for more spacing, like this:

image

It wouldn't match the request/response headers though.

(Figma for all mockups so far)

  • Blocked Cookies? → Link to Cookies

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

What should show up in the summary for Blocked Cookies?

violasong commented 4 years ago

Ideas:

Expand arrow on the URL opens to show query string params

Some syntax coloring on the URL (this doesn't look great, but maybe something similar could work

image
violasong commented 4 years ago

Idea:

More separation for warning/error messages in Header Summary

image

Or should we just put it at the top?

image
violasong commented 4 years ago

Idea: In header sections, show info (MDN link) and copy button on hover

image
violasong commented 4 years ago

Idea: All the above, with Response headers in blue sans-serif 12px labels + black monospace 11px values.

image
violasong commented 4 years ago

Same as above, except with gray labels.

image
janodvarko commented 4 years ago

Thanks Victoria for the mockups, it looks really great!

Questions:

Honza

digitarald commented 4 years ago

Idea: All the above, with Response headers in blue sans-serif 12px labels + black monospace 11px values.

@violasong the smaller font seems also good to save space for longer output. Blue is also good since the summary section already has a grid layout to differentiate visually.

It just occurred to me that you mentioned another example for this, how the Debugger sizes those lines. Is that sizing/spacing aligned? It seems like it:

image

The tracking protection notification message at the top is nice. We could use this concept for other messages as well (more info about request error state, etc)

What other errors did you have in mind, @janodvarko?

An alternative to the error could be adding a line with a warning in-line with the tracking category.

Referrer:         no-referrer-its-referer
Content Blocking: Tracking Content
                  🛡 Be aware that cookies or content for this URL could be blocked. (?)`

WDYT, @violasong ?

Color syntax for collapsed URL - awesome idea!

@violasong I like the idea. It does make it a bit more readable. I am not sure which parts we should highlight; as use cases vary on what's important to users. Have you seen an example of that anywhere else?

What's supposed to be in the Resend dropdown? I can think of "Edit and Resend" and "Resend", is that it?

Yes, that was my proposal, making sure we are exposing more options from the context meny in the toolbar. @violasong another idea would be an "Edit" button and a "Resend" button; where Edit implies that it would be send again anyways. So we avoid the dropdown.

What's suppoed to be in the Block dropdown?

"Block URL" is very blunt atm. I proposed this as we can expose more options. "Block Domain" and "Block Path" could be added here. To simplify, it is probably easier to use the blocking icon from the network toolbar and avoid the dropdown. If users want to fine-tune, the blocking sidepanel will open automatically anyways and they can edit the URL down to what they need.

janodvarko commented 4 years ago

What other errors did you have in mind, @janodvarko?

I like the idea to use the notification box as a generic way to show any error/warning/info that's worth of user attention.

Honza

violasong commented 4 years ago

Updated color syntax for collapsed URL:

image

Changed magenta to gray which I think works better, and added in the filter bar.

@violasong I like the idea. It does make it a bit more readable. I am not sure which parts we should highlight; as use cases vary on what's important to users. Have you seen an example of that anywhere else?

I don't think I've seen this elsewhere, though the grayed out https:// is like Firefox's URL bar. The idea I had is that the blue parts correlate to the blue keys when expanded.

violasong commented 4 years ago

Expandable URL - to show URL params. We can also play with showing individual URL parts (domain, path, etc.)

So something like this?

image
violasong commented 4 years ago

Mockup with:

image
digitarald commented 4 years ago

@violasong looks really nice! Makes me want to click around and play with it.

One thing I am not sure about is the shortened labels ("Blocking" is less descriptive than "Content Blocking") and other languages will vary in length as well. What's the strategy to make this responsive and overflow in sensible ways?

Harald's last suggestion for error message. This de-emphasizes the error and makes it more a part of the summary rather than an extra section. Sounds like that's what we want?

A more typically-sized URL with no params, shown in the style of the query param examples

Should this URL be limited in lines, using line-clamp?

FYI, the parts of the URL that we should show are all listed in https://developer.mozilla.org/en-US/docs/Web/API/URL .

Smaller toggle for switching to raw

Perfect size!

Just to get consensus (I am a fan of hover menus), is the idea from https://github.com/firefox-devtools/ux/issues/116#issuecomment-610742996 accepted? @bomsy @janodvarko

violasong commented 4 years ago

One thing I am not sure about is the shortened labels ("Blocking" is less descriptive than "Content Blocking") and other languages will vary in length as well. What's the strategy to make this responsive and overflow in sensible ways?

Ah, I see. I'll look at this some more. Here's one thing we can do with the alignment, though we don't do this anywhere else.

image

Should this URL be limited in lines, using line-clamp?

I thought we were saying that the full URL is important here, as this is the only place to see the whole thing (besides the query string, but that's an extra step and kind of different).

digitarald commented 4 years ago

I thought we were saying that the full URL is important here, as this is the only place to see the whole thing (besides the query string, but that's an extra step and kind of different).

Right, makes sense. Might also work if we expand it to a full URL when the user expands this section. If we do a proper line-break (not like now), 1000+ character URLs will take up a lot of space.

(Example of word-wrap in VS Code and in our current URL preview: image)

bomsy commented 4 years ago

Just to get consensus (I am a fan of hover menus), is the idea from #116 (comment) accepted?

@digitarald I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

violasong commented 4 years ago

Might also work if we expand it to a full URL when the user expands this section. If we do a proper line-break (not like now), 1000+ character URLs will take up a lot of space.

I see what you mean, there needs to be some level of truncation at some point :D

This could work, though the expanded query string part could end up being pretty massive

image
digitarald commented 4 years ago

@digitarald I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

Maybe @violasong has ideas how some icons are always on and don't need hover. Otherwise we could show errors like we do them inline in the general section?

digitarald commented 4 years ago

This could work, though the expanded query string part could end up being pretty massive

As it's expanded optionally, that seems acceptable.

violasong commented 4 years ago

I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

Good point. I realized I also didn't work out how the hovering would work on a long row.

One quick idea: buttons float on top on hover, like in Copy Rules:

image
violasong commented 4 years ago

Hm, right after posting this I realized it's probably too much fanciness as it obscures basic copy paste, like if someone just wanted to grab the time part of that timestamp.

So the other option is there's just an area on the right side saved for the icons, and the text would wrap before getting there.

digitarald commented 4 years ago

One quick idea: buttons float on top on hover, like in Copy Rules:

I like that. One caveat to test during implementation is how hover-enabled buttons interact with selecting text portions.

fvsch commented 4 years ago

For the URL params when there are many:

This could work, though the expanded query string part could end up being pretty massive

One option is to truncate and, rather than expand, add a button that sends the user to the "Params" tab where we already parse and display the URL parameters.

digitarald commented 4 years ago

@violasong One aspect to think about is long header names and how to align the values:

image
digitarald commented 4 years ago

Just for reference, leaving this example for a super-long URLs that makes the URL preview take over the whole above the fold space for the panel; so we can test it against the new bug:

image