Closed Bug 991810 Opened 10 years ago Closed 10 years ago

Move the inspector button to the top left

Categories

(DevTools :: Framework, defect)

30 Branch
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 32

People

(Reporter: canuckistani, Assigned: bgrins)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 5 obsolete files)

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.
More radically - we could consider swapping all the buttons on the left to the right and v-v.
(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.
(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.
(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?
Flags: needinfo?(dhenein)
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?
Flags: needinfo?(dhenein)
Attached image toolbox-linux.png
The top tab bar is organized a bit differently already on Linux (and Windows)
What about the options cogwheel ?
(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.
(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.
(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.
Blocks: 983600
(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.
> 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.
(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?
Flags: needinfo?(dhenein)
(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.
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
(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.
Attached image inspect-button-left.png (obsolete) —
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
Attached image inspect-button-left.gif (obsolete) —
Animated gif of UI in comment 19
Attached image inspect-button-left-options-panel.gif (obsolete) —
Shows what the options panel functionality could be like
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/bgrinstead@mozilla.com-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?
Flags: needinfo?(dhenein)
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.
Won't osx dev. now complain about muscle memory wrt control buttons ?
(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.
Attached image inspect-left.gif
Another gif - this time with the ui polished a bit more, and showing various dock states
Assignee: nobody → bgrinstead
Attachment #8418263 - Attachment is obsolete: true
Attachment #8418265 - Attachment is obsolete: true
Attachment #8418287 - Attachment is obsolete: true
Status: NEW → ASSIGNED
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?
Flags: needinfo?(jwalker)
Flags: needinfo?(dhenein)
(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?
Flags: needinfo?(dhenein)
(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.
(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.
(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
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.
Flags: needinfo?(jwalker)
Attached patch inspect-left.patch (obsolete) — Splinter Review
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.
Attachment #8427294 - Flags: review?(vporof)
(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 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?
Attachment #8427294 - Flags: review?(vporof) → review+
(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
Attachment #8427294 - Attachment is obsolete: true
Attachment #8419494 - Attachment is obsolete: true
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/6940c3eb040e
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 32
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.
(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
Depends on: 1017512
Depends on: 1017897
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.