991810 - Move the inspector button to the top left

Status: RESOLVED FIXED

(DevTools :: Framework, defect)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Firebug ( and chrome ) both place the inspector icon at the top left of their toolboxes. We should do the same so as to be less surprising to users of other tools.

Comment 1

[Joe Walker [:jwalker]]

More radically - we could consider swapping all the buttons on the left to the right and v-v.

Comment 2

[Girish Sharma [:Optimizer]]

(In reply to Joe Walker [:jwalker] from comment #1)
> More radically - we could consider swapping all the buttons on the left to
> the right and v-v.

I think that there is a general perception of importance and frequency of use as you go from left to right. Thus moving all the buttons to left will be a bit too much , imo.

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Girish Sharma [:Optimizer] from comment #2)
> (In reply to Joe Walker [:jwalker] from comment #1)
> > More radically - we could consider swapping all the buttons on the left to
> > the right and v-v.
> 
> I think that there is a general perception of importance and frequency of
> use as you go from left to right. Thus moving all the buttons to left will
> be a bit too much , imo.

I somewhat agree. Firebug has always been very inspection-oriented and the inspect button has 'special' prominence:

http://note.io/1dVL4Nq

Chrome on the other hand is not great using the 'magnifying glass', I associate it too strongly with 'search' as opposed to 'inspect':

http://note.io/1pWmNaf

We're different again, and seem to almost deliberately do things opposite from chrome:

http://note.io/1pWmT1l

I would happily swap our gear / toolbox control buttons over to the right to get the inspect / split console / responsive design view buttons on the right. I would go further and say that the inspect button should be particularly prominent, a la Firebug.

Apologies is this seem prescriptive, I am doing so with the aim to be less surprising to people and I don't think it's useful to try to re-word 'let's confrim to chrome and firebug in this way' to more generic language.

Comment 4

[Joe Walker [:jwalker]]

(In reply to Jeff Griffiths (:canuckistani) from comment #3)
> ...
> I would happily swap our gear / toolbox control buttons over to the right to
> get the inspect / split console / responsive design view buttons on the
> right.

I read this as: "I would happily swap our gear / toolbox control buttons over to the right to get the inspect / split console / responsive design view buttons on the *left*". Is that correct?

The gear 'button' isn't a button really - it's a panel like console, etc, just one without a name. So I think it needs to be adjacent to the other panels. Not to say that it can't be on the RHS though.

So to be really specific, and to setup a straw-man, the order would be:

Inspect | Split console | Responsive | Console, Inspector, etc, Options | <gap> | Side | Popout | Close

Questions:

* Split console could be seen as being a window control. Should it be on the right (like chrome)?
* Options could seem like it is 'hanging' maybe it should be on the right?

Darrin, what do you think?

Comment 5

[Darrin Henein [:darrin]]

My instant, reactive thought is this:

inspect button | Inspector, Console, etc. | <--------> split console, responsive, etc. | window controls

This put the inspect button in a prominent position (and i would order Inspector first so they are connected mentally) and still leaves a flexilbe area for command buttons (responsive, etc) so adding/removing from there doesn't alter layout. Window controls are lighter to begin with and can be further separated by a line.

Thoughts?

Comment 6

[Brian Grinstead [:bgrins]]

Attachment: toolbox-linux.png

The top tab bar is organized a bit differently already on Linux (and Windows)

Comment 7

[Girish Sharma [:Optimizer]]

What about the options cogwheel ?

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Girish Sharma [:Optimizer] from comment #7)
> What about the options cogwheel ?

Ignoring implementation details and just focusing on the UI the possible ways I would think of doing it are:

1) inspect button | inspector, etc | options cog  <--------> split console, responsive, etc. | window controls

2) inspect button | options cog | inspector, etc  <--------> split console, responsive, etc. | window controls

3) inspect button | inspector, etc  <--------> split console, responsive, etc. | options cog | window controls

For some reason, having a moving options cog always on the right of panels (#1) just seems weird to me.  #2 would also be easy to implement - it would keep the inspect button close to, but not directly next to the inspector.  For #3, I think the options panel is different enough from the rest of the panels from usage that it would be possible to move it away from them - but this would not be as simple a change.

Comment 10

[Girish Sharma [:Optimizer]]

(In reply to Brian Grinstead [:bgrins] from comment #9)
> (In reply to Girish Sharma [:Optimizer] from comment #7)
> > What about the options cogwheel ?
> 
> Ignoring implementation details and just focusing on the UI the possible
> ways I would think of doing it are:
> 
> 1) inspect button | inspector, etc | options cog  <--------> split console,
> responsive, etc. | window controls
> 
> 2) inspect button | options cog | inspector, etc  <--------> split console,
> responsive, etc. | window controls
> 
> 3) inspect button | inspector, etc  <--------> split console, responsive,
> etc. | options cog | window controls
> 
> For some reason, having a moving options cog always on the right of panels
> (#1) just seems weird to me.  #2 would also be easy to implement - it would
> keep the inspect button close to, but not directly next to the inspector. 
> For #3, I think the options panel is different enough from the rest of the
> panels from usage that it would be possible to move it away from them - but
> this would not be as simple a change.

+1 for 3. Implementation is pretty straight forward.

Comment 11

[Joe Walker [:jwalker]]

(In reply to Girish Sharma [:Optimizer] from comment #10)
> (In reply to Brian Grinstead [:bgrins] from comment #9)
> > (In reply to Girish Sharma [:Optimizer] from comment #7)
> > ...
> > 3) inspect button | inspector, etc  <--------> split console, responsive,
> > etc. | options cog | window controls
> > 
> > For some reason, having a moving options cog always on the right of panels
> > (#1) just seems weird to me.  #2 would also be easy to implement - it would
> > keep the inspect button close to, but not directly next to the inspector. 
> > For #3, I think the options panel is different enough from the rest of the
> > panels from usage that it would be possible to move it away from them - but
> > this would not be as simple a change.
> 
> +1 for 3. Implementation is pretty straight forward.

The options tool would need to not be a tool any more, and we'd have to hide all the tools when the options 'panel' was showing. Right?

I'm unclear why #1 is weird?

For reference, the bug to re-order the tools is bug 983600.

Comment 12

[Girish Sharma [:Optimizer]]

(In reply to Joe Walker [:jwalker] from comment #11)
> (In reply to Girish Sharma [:Optimizer] from comment #10)
> > (In reply to Brian Grinstead [:bgrins] from comment #9)
> > > (In reply to Girish Sharma [:Optimizer] from comment #7)
> > > ...
> > > 3) inspect button | inspector, etc  <--------> split console, responsive,
> > > etc. | options cog | window controls
> > > 
> > > For some reason, having a moving options cog always on the right of panels
> > > (#1) just seems weird to me.  #2 would also be easy to implement - it would
> > > keep the inspect button close to, but not directly next to the inspector. 
> > > For #3, I think the options panel is different enough from the rest of the
> > > panels from usage that it would be possible to move it away from them - but
> > > this would not be as simple a change.
> > 
> > +1 for 3. Implementation is pretty straight forward.
> 
> The options tool would need to not be a tool any more, and we'd have to hide
> all the tools when the options 'panel' was showing. Right?

It can still remain a tool, with a little special casing for not building the tab, but reusing it from the tabbar.

Comment 13

[Brian Grinstead [:bgrins]]

> The options tool would need to not be a tool any more, and we'd have to hide
> all the tools when the options 'panel' was showing. Right?
> 
> I'm unclear why #1 is weird?

It just seems weird to me that the options cog would move around based on which tabs are visible.  That makes it seem more like just one of the other tools, and it is a lot different than the other tools.  The other tools are used for debugging the current page, and the options panel is used for setting preferences to be used within the tools themselves.  That's why I think it should be anchored in some location rather than being tacked onto the end of the list.

Comment 14

[Joe Walker [:jwalker]]

(In reply to Brian Grinstead [:bgrins] from comment #13)
> > The options tool would need to not be a tool any more, and we'd have to hide
> > all the tools when the options 'panel' was showing. Right?
> > 
> > I'm unclear why #1 is weird?
> 
> It just seems weird to me that the options cog would move around based on
> which tabs are visible.  That makes it seem more like just one of the other
> tools, and it is a lot different than the other tools.  The other tools are
> used for debugging the current page, and the options panel is used for
> setting preferences to be used within the tools themselves.  That's why I
> think it should be anchored in some location rather than being tacked onto
> the end of the list.

OK. My perspective was that since it replaced the main area like the other tools, it was represented along the top in roughly the same way as the other tools.
I guess I don't much like the way the Chrome options panel is disconnected, which is another way of saying a similar thing.

What do you think, Darrin?

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to Joe Walker [:jwalker] from comment #14)
> (In reply to Brian Grinstead [:bgrins] from comment #13)
> > > The options tool would need to not be a tool any more, and we'd have to hide
> > > all the tools when the options 'panel' was showing. Right?
> > > 
> > > I'm unclear why #1 is weird?
> > 
> > It just seems weird to me that the options cog would move around based on
> > which tabs are visible.  That makes it seem more like just one of the other
> > tools, and it is a lot different than the other tools.  The other tools are
> > used for debugging the current page, and the options panel is used for
> > setting preferences to be used within the tools themselves.  That's why I
> > think it should be anchored in some location rather than being tacked onto
> > the end of the list.
> 
> OK. My perspective was that since it replaced the main area like the other
> tools, it was represented along the top in roughly the same way as the other
> tools.
> I guess I don't much like the way the Chrome options panel is disconnected,
> which is another way of saying a similar thing.
> 
> What do you think, Darrin?

FWIW, I like how it replaces the content main area also and would expect it would still do so even if the button moved.  An overlay could be a possibility too, but I'm not a huge fan of that either since it takes away a bit more space and is harder to dismiss.

Comment 16

[Joe Walker [:jwalker]]

So re-thinking what irks me - I think what I didn't like was the thought that in between the options panel and the network panel (or whatever is on the RHS) are things that are not panels. So we could do this:

4) inspect button | inspector, etc <--------> options cog | split console, responsive, etc. | window controls

Comment 17

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Joe Walker [:jwalker] from comment #16)
> So re-thinking what irks me - I think what I didn't like was the thought
> that in between the options panel and the network panel (or whatever is on
> the RHS) are things that are not panels. So we could do this:
> 
> 4) inspect button | inspector, etc <--------> options cog | split console,
> responsive, etc. | window controls

I had come to this conclusion by the time I read down this far. +1 for #4.

Comment 19

[Brian Grinstead [:bgrins]]

Attachment: inspect-button-left.png

This is a WIP I was playing with that moves the button to the left.  Changes:

1) Gets rid of the special case in OSX where the close button / docking is on left and moves them to right side like other platforms
2) Moves Inspector tab to the left of the console
3) Moves the 'pick an element' command button to the far left
4) Moves the options panel tab to the right, but still left of docking/close

Comment 20

[Brian Grinstead [:bgrins]]

Attachment: inspect-button-left.gif

Animated gif of UI in comment 19

Comment 21

[Brian Grinstead [:bgrins]]

Attachment: inspect-button-left-options-panel.gif

Shows what the options panel functionality could be like

Comment 22

[Brian Grinstead [:bgrins]]

Darrin, you can download a binary to play with the select element button on the left at: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a1ef14971c49/try-macosx64-debug/.  Can you give this look and let me know what you think with regards to the select element button and options cog positioning?

Comment 23

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Attachment: Firefox_Nightly_First_Run_Page_and_991810_–_Move_the_inspector_button_to_the_top_left.png

Tried the build ( love getting try builds! ) and it works for me, except the one edge case we discussed in the content meeting today, which is that the GCLI bar has a close button on the left still.

Comment 24

[Girish Sharma [:Optimizer]]

Won't osx dev. now complain about muscle memory wrt control buttons ?

Comment 25

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Girish Sharma [:Optimizer] from comment #24)
> Won't osx dev. now complain about muscle memory wrt control buttons ?

Discussed this with Joe, I think the right thing to do might be to ( ON OS X ONLY ) place the toolbox close button *ONLY* at the top left to be consistent with other UI in Firefox and the platform. The window controls still go to the right tho.

Comment 26

[Brian Grinstead [:bgrins]]

Attachment: inspect-left.gif

Another gif - this time with the ui polished a bit more, and showing various dock states

Comment 27

[Jeff Griffiths (:canuckistani) (:⚡︎)]

It looks good and I really want to wrap this issue up. As mentioned in comment 25, it looks like the most consistent thing to do for us is put the close toolbox 'x' a the top left on OS X. Joe, Darrin, what say you?

Comment 28

[Darrin Henein [:darrin]]

(In reply to Jeff Griffiths (:canuckistani) from comment #27)
> It looks good and I really want to wrap this issue up. As mentioned in
> comment 25, it looks like the most consistent thing to do for us is put the
> close toolbox 'x' a the top left on OS X. Joe, Darrin, what say you?

I'm hesitant to separate the close 'x' from the rest of the window controls... also it would become perilously close to the new inspector button, no? Other than the OSX system windows having close in the top left, is there another reason?

Comment 29

[Brian Grinstead [:bgrins]]

(In reply to Jeff Griffiths (:canuckistani) from comment #27)
> It looks good and I really want to wrap this issue up. As mentioned in
> comment 25, it looks like the most consistent thing to do for us is put the
> close toolbox 'x' a the top left on OS X. Joe, Darrin, what say you?

I'm OK with deferring on this decision, but IMO it would be nice to keep the close button on the right on all platforms, sort of like Firebug does.  This way the 'inspect an element' button is always the left-most thing, and has a nice big hit area without the worry of closing the toolbox.

Comment 30

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Brian Grinstead [:bgrins] from comment #29)

> I'm OK with deferring on this decision, but IMO it would be nice to keep the
> close button on the right on all platforms, sort of like Firebug does.  This
> way the 'inspect an element' button is always the left-most thing, and has a
> nice big hit area without the worry of closing the toolbox.

Joe pointed out that all the other horizontal bars have the 'x' on the left on OS X ( the developer bar, various notification boxes )

I'm torn, if we put everything to the right but the inspector button we're in line with Firebug / Chrome, but different from the rest of the UI. 

If we think it is better to be consistent with other tools though ( which I think is my preferences ) we should move the close button to the extreme right on all platforms.

Comment 31

[Brian Grinstead [:bgrins]]

(In reply to Jeff Griffiths (:canuckistani) from comment #30)
> (In reply to Brian Grinstead [:bgrins] from comment #29)
> 
> > I'm OK with deferring on this decision, but IMO it would be nice to keep the
> > close button on the right on all platforms, sort of like Firebug does.  This
> > way the 'inspect an element' button is always the left-most thing, and has a
> > nice big hit area without the worry of closing the toolbox.
> 
> Joe pointed out that all the other horizontal bars have the 'x' on the left
> on OS X ( the developer bar, various notification boxes )
> 
> I'm torn, if we put everything to the right but the inspector button we're
> in line with Firebug / Chrome, but different from the rest of the UI. 
> 
> If we think it is better to be consistent with other tools though ( which I
> think is my preferences ) we should move the close button to the extreme
> right on all platforms.

There is at least one other case where the close button is on the right (notifications for paused debugger and some sort of error in the style editor): https://i.imgur.com/0xlHCL1.png

Comment 32

[Joe Walker [:jwalker]]

So I'm happy if we say "devtools buttons go on the right", as a general UX principle.

Also having seen Brian's demos where the settings button is separated from the other 'tool' buttons (i.e. option 3 from comment 9), I'm less of the opinion that it's weird.

Comment 33

[Brian Grinstead [:bgrins]]

Attachment: inspect-left.patch

Victor, can you take a look at these changes?  Basically, I've special cased the options panel button to move it to a different parent, but it is treated in the toolbox deck just the same as the others.  I've also tried to refactor the CSS a bit to accommodate the new layout.

Darrin/Jeff - I've pushed to try if you care to try it out (binaries will be available there when build finishes): https://tbpl.mozilla.org/?tree=Try&rev=25732d2265ec.

Comment 34

[Brian Grinstead [:bgrins]]

(In reply to Joe Walker [:jwalker] from comment #32)
> So I'm happy if we say "devtools buttons go on the right", as a general UX
> principle.

I can follow up with a change to Developer Toolbar.  Are there any other close buttons in the UI?

Comment 35

[Victor Porof [:vporof][:vp]]

Comment on attachment 8427294 [details] [diff] [review]
inspect-left.patch

Review of attachment 8427294 [details] [diff] [review]:
-----------------------------------------------------------------

Changes LGTM. Not sure about the toolbox controls placement on OS X, but it looks like this was argued upon a few comments above so I'll stay out of it :)

::: browser/devtools/framework/toolbox.js
@@ +698,5 @@
>        deck.appendChild(vbox);
>      } else {
> +      // If there is no tab yet, or the ordinal to be added is the largest one.
> +      if (tabs.childNodes.length == 0 ||
> +          +tabs.lastChild.getAttribute("ordinal") <= toolDefinition.ordinal) {

No need to force coercion with + here, since <= does it automatically.

::: browser/themes/shared/devtools/toolbars.inc.css
@@ +754,5 @@
>  .devtools-tab:not([selected])[highlighted] > .default-icon {
>    visibility: collapse;
>  }
>  
> +/* The options tab is special - it doesn't live with the other tabs */

I would say that it doesn't *look* like the other tabs, but lives in the same place, doesn't it?

Comment 36

[Brian Grinstead [:bgrins]]

(In reply to Victor Porof [:vporof][:vp] from comment #35)  
> > +/* The options tab is special - it doesn't live with the other tabs */
> 
> I would say that it doesn't *look* like the other tabs, but lives in the
> same place, doesn't it?

It has a different parent element (toolbox-option-container vs toolbox-tabs), though they both live inside of .devtools-tabbar.  I've updated the comment to clarify

Comment 37

[Brian Grinstead [:bgrins]]

Attachment: inspect-left.patch

Comment 38

[Brian Grinstead [:bgrins]]

Interdiff: https://bugzilla.mozilla.org/attachment.cgi?oldid=8427294&action=interdiff&newid=8429479&headers=1, pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=6c4f8763f16d

Comment 39

[Brian Grinstead [:bgrins]]

https://hg.mozilla.org/integration/fx-team/rev/6940c3eb040e

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6940c3eb040e

Comment 42

[Tim Nguyen :ntim]

Hate this change :( Feels unnatural to have a command button moved out from the other ones, same for the options tab. Btw, it caused a theme regression.

Comment 43

[Tim Nguyen :ntim]

(In reply to Tim Nguyen [:ntim] from comment #42)
> Hate this change :( Feels unnatural to have a command button moved out from
> the other ones, same for the options tab. Btw, it caused a theme regression.

Filed bug 1017512