1537666 - In markup view, add back/forward buttons for returning to previously-selected elements

Status: ASSIGNED

(DevTools :: Inspector, enhancement, P3)

Description

[Victoria Wang [:victoria]]

While navigating through unfamiliar HTML and modifying certain elements' styles in the Inspector, I found that I kept getting lost when I wanted to go back to previous elements, in order to change those elements' CSS again.

A way to start addressing this is to add a highlight/left border effect on HTML elements that are affected by changed CSS. This would have to be subtle so that it doesn't overwhelm in the case where every element is affected by some style change. Ideally it would match the Rules change indicator - maybe something like a thin dotted green left border.

Comment 1

[Patrick Brosset <:pbro>]

I think there are 2 groups of elements here:

1. The elements that you selected in the markup-view and might want to select again in the future
2. The elements that are impacted by the CSS changes you made

These are different groups because while you might have selected only 2 elements, maybe the CSS changes you made impacted 1000 elements in the page.
My impression is that you want to be able to quickly navigate back to elements from group 1, not navigate through elements from group 2.
First because there may be many more in group 2, making navigation harder, and secondly because a lot of them you have never selected and might not actually be interested in.

Would a more traditional navigation system solve your need? Specifically back and forward buttons. The inspector would just remember the elements you visit in a stack, and offer buttons to navigate through this stack. Much like a browser allows navigation through your browsing history.

Comment 2

[Victoria Wang [:victoria]]

Yes, you make great points, and I really like the idea of adding back and forward buttons!

Ideas: https://mozilla.invisionapp.com/share/89R5ABKN5ZC#/screens

1. Put it in the top bar because that's usually where that kind of nav goes, and it would be super prominent, and we have lots of space there.

2. Put it next to the breadcrumbs, which automatically gives it more context, since the breadcrumbs also navigate between elements.

[out of scope ideas ahead!]

3. I've always wanted to get rid of the markup top bar in its current form and replace it with cmd-F to open the find. It just takes up so much space, esp compared to chrome, and now that we're making all the top bars 28px, this is bugging me a bit more.

4. I know we have plans to do badge filtering like in Console, which was to be located in the top bar. I think other options are possible, such as top-right floating section. I feel the doctype and html lines can share their horizontal space a bit ;D

Comment 3

[Victoria Wang [:victoria]]

Sounds like #2 is the way to go! As Patrick mentioned: "If we’re getting rid of the toolbar on the long run, better not put more stuff in it now"

I just realized a UX complication - we current use these caret icons for when the breadcrumbs are too long. We could use the Firefox-style back/forward icons to differentiate, and maybe add a little more visual separation beyond that. I'll put this on my todo list.

Comment 4

[Florens Verschelde :fvsch]

Attachment: debugger-search-bar.png

The debugger search has "previous/next result" buttons in its search bar (when searching in the current file). They use angles pointing up (previous) and down (next). Maybe we could follow that?

Comment 5

[Victoria Wang [:victoria]]

Oh wow, good point. Then it matches Firefox prev/next as well. That totally makes more sense than the heavyweight browser icons. Thanks Florens!

Comment 6

[Victoria Wang [:victoria]]

Here's how this could look. Pretty busy with the scroll - probably still more refinement that could be done there.

https://mozilla.invisionapp.com/share/67R9PAVYTUN

Comment 7

[Martin Balfanz [:mbalfanz]]

Hm, I'm against using up/down arrows. I find them very misleading in this case. We’re looking at a tree structure in the markup view that can be navigated in arbitrary order (e.g. with the element picker). Those arrows suggest to me that I would navigate it up and down (previous/next), not backward and forward. And in reality, the previous selected element can be below the current one (=> pressing arrow up would navigate the view down).

Left/right on the other hand is a known backward/forward navigation pattern, learned for example on the general browser toolbar.

Comment 8

[Florens Verschelde :fvsch]

We’re looking at a tree structure in the markup view that can be navigated in arbitrary order (e.g. with the element picker)

Good point, I had misunderstood the brief. :D
Left/right arrows would be better than, using the same arrow design as Firefox's navigation bar (https://design.firefox.com/icons/viewer/#back) but maybe smaller.

Pretty busy with the scroll

Agreed. I don't see a better option right now. Maybe we could get away with it if we get more aggressive with how we show DOM nodes in the breadcrumbs? I think Chrome is often omitting the classes and just showing stuff like "body > div > div > main > div > section > header > h2", which makes it easier to see the ancestors of the current node and go back up one or a few levels (that's my two use cases for the breadcrumbs: get a summary of the ancestors and go back up 1-3 levels if I picked an element too deep in the tree, e.g. a <span> when I wanted its parent <button>).

Comment 9

[Victoria Wang [:victoria]]

Hm, I'm against using up/down arrows. I find them very misleading in this case.

Oh, wow... yes, now that I'm actually imagining clicking on these arrows, up/down does seem really strange 😅

Side note: Xcode has a somewhat similar feature (navigates between previous files) that also has left/right arrows.

Maybe we could get away with it if we get more aggressive with how we show DOM nodes in the breadcrumbs? I think Chrome is often omitting the classes and just showing stuff like "body > div > div > main > div > section > header > h2",

Wow, Chrome's is complicated. When resizing the window, they start truncating specific parts of the breadcrumbs from left to right, first removing the element, then the class only showing id. I'm not seeing the only-elements thing you mentioned. I think I do like seeing the class/id names over the elements (though removing the element doesn't save much room).

One thing we could do is a << menu that works opposite of the regular overflow menu, truncating from the left. Updated the mockup with this idea:

https://mozilla.invisionapp.com/share/67R9PAVYTUN#/screens

Comment 10

[Victoria Wang [:victoria]]

So Martin agrees with the above overflow idea with the << menu :D. I removed the scroll example.

I think this is ready for development. Gabe, let me know if there are concerns.

Hover/active states for all the buttons/links in the breadcrumbs bar should match the new Copy all Changes button spec: https://mozilla.invisionapp.com/share/Z3F7OGCTK#/344940269_Feb_2019_M2 (This will be added to the DevTools design system later)

Comment 11

[Florens Verschelde :fvsch]

Perhaps we should split the breadcrumbs update to a separate bug.

Heads up: I'm changing a bit of the bottom toolbar and breadcrumbs CSS in bug 1535956. I can remove some of those changes from the patch if it makes things easier.

Comment 12

[Patrick Brosset <:pbro>]

Attachment: back-forward-buttons.diff

:mbalfanz and I discussed about this bug just now and decided that the back/forward navigation buttons weren't entirely solving the need described by Victoria originally.
The user need as expressed here is jumping back to nodes where modifications have been done.
A simple back/forward mechanism would just take you back to previously selected nodes. Not exactly the same.

Now, I spent some time last week checking if the back/forward nav would be easy to do, and it is. So before I forget, let me attach my work-in-progress patch so if we do decide, in the future, that something like this is useful still, then perhaps we can start from here.

Comment 13

[Victoria Wang [:victoria]]

To summarize/clarify the comments I made in Slack on May 2nd:

My use case was to find an element which 1. I had recently selected, and 2. for which I had changed the CSS inside Rules.

The two ideas that came out of this were:

1. A navigational feature to step through previously selected elements, as shown in the mockup.

2. Highlight indicator on changed nodes. (We would only highlight the element that was selected when a user changed a rule, to cut down on the amount of things that would be highlighted. I think a gutter icon could be the best way to do the highlight.)

These two features complement each other, but it seems the highlight indicator is more directly useful.

These features aren't replaced by the (also-useful) Jump Back from Changes Panel idea, because I think it's spatially and contextually easier to stay in the markup in some situations, especially for very recently made selections/changes (like what Martin has said about undoing a selection).