Bug 76917 – Web Inspector: "Dock to right" shouldn't be in the settings dialog

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Nico Weber]

I read that the inspector now supports docking to the right, and it took me forever to figure out how to do it. I tried to just drag it over, option-clicking on the "dock" button, long clicking on the dock button, right-clicking on the dock button.

Putting this into the settings dialog feels like bad UI to me. (Unrelated mini-ran: The settings dialog is already starting to look for a dumping ground of decisions that shouldn't be exposed to the user.)

[Pavel Feldman]

Where would you expect to see it?

[Nico Weber]

I tried dragging the docked devtools titlebar to the right, option-clicking on the "dock" button at the bottom left corner of the devtools, long clicking on the dock button, right-clicking on the dock button.

[Timothy Hatcher]

I expect the option key as well. Holding option should change the button glyph before you press it to show it will do something different.

[Pavel Feldman]

(In reply to comment #3)
> I expect the option key as well. Holding option should change the button glyph before you press it to show it will do something different.

I like this one, but I think it is also not discoverable.

[Nico Weber]

(In reply to comment #4)
> (In reply to comment #3)
> > I expect the option key as well. Holding option should change the button glyph before you press it to show it will do something different.
> 
> I like this one, but I think it is also not discoverable.

It's no worse than the current behavior, and keeps the settings menu slightly less cluttered. But up to you :-)

[Nikita Vasilyev]

Created attachment 139612 [details]
Context menu mockup

(In reply to comment #3)
> I expect the option key as well. Holding option should change the button glyph before you press it to show it will do something different.

+1. Adobe Photoshop uses it a lot and I like it. Context menu is also a viable option, I think we can have both.

[Nikita Vasilyev]

Created attachment 139613 [details]
Three (radio) buttons

One more option.

Props:
— dead-easy to discover
— One click to switch the mode

Cons:
— Clutters a bottom bar

[Alexander Pavlov (apavlov)]

*** Bug 88559 has been marked as a duplicate of this bug. ***

[Alexander Pavlov (apavlov)]

Bug 88559 requests a shortcut for toggling the Inspector docking side.

[sam]

*** Bug 88559 has been marked as a duplicate of this bug. ***

[Nikita Vasilyev]

> (In reply to comment #3)
> > I expect the option key as well. Holding option should change the button glyph before you press it to show it will do something different.
> 
> I like this one, but I think it is also not discoverable.

At least it makes switching between dock to right and dock to bottom much quicker.

I’d love to have a feedback. I’m eager to implement my first mockup as soon as we agree on it.

[Pavel Feldman]

I have a wip patch that implements behavior in comments 2-5. Will attach once I am back from vacations. (Tomorrow). I did not upload it initially because Chrome loses focus upon toggling dock side and it is especially noticable when using such action.

[sam]

*** Bug 79923 has been marked as a duplicate of this bug. ***

[Nikita Vasilyev]

Any progress here?

[Pavel Feldman]

(In reply to comment #14)
> Any progress here?

I am facing another limitation here: when focus is elsewhere, pressing Cmd while hovering over the button can't be tracked. So it sounds like we need a different UX solution here. What was yours?

[Nikita Vasilyev]

(In reply to comment #15)
> (In reply to comment #14)
> > Any progress here?
> 
> I am facing another limitation here: when focus is elsewhere, pressing Cmd while hovering over the button can't be tracked. So it sounds like we need a different UX solution here. What was yours?

We can track Cmd on click:

addEventListener("click", function(event)
{
    event.metaKey
}

When focus is elsewhere pressing Cmd won’t change the icon but I think it’s okay.

[Pavel Feldman]

> When focus is elsewhere pressing Cmd won’t change the icon but I think it’s okay.

I don't really think it is. The whole point of the meta thing is its discoverability... I am thinking of implementing a long click that would change it to dock-to-side. Wdyt?

[Pavel Feldman]

(In reply to comment #17)
> > When focus is elsewhere pressing Cmd won’t change the icon but I think it’s okay.
> 
> I don't really think it is. The whole point of the meta thing is its discoverability... I am thinking of implementing a long click that would change it to dock-to-side. Wdyt?

I.e. you hold mouse down and dock to side icon pops up above the dock one in 0.5 sec...

[Nikita Vasilyev]

(In reply to comment #18)
> (In reply to comment #17)
> > > When focus is elsewhere pressing Cmd won’t change the icon but I think it’s okay.
> > 
> > I don't really think it is. The whole point of the meta thing is its discoverability... I am thinking of implementing a long click that would change it to dock-to-side. Wdyt?
> 
> I.e. you hold mouse down and dock to side icon pops up above the dock one in 0.5 sec...

I haven’t used much click-and-hold on a desktop so I need to use it for some time to share an opinion. Worth trying anyway.

[Pavel Feldman]

Created attachment 150753 [details]
Patch

[Pavel Feldman]

Created attachment 150754 [details]
[IMAGE] with patch applied

[Pavel Feldman]

Created attachment 150755 [details]
[IMAGE] with patch applied

[Nikita Vasilyev]

Looks good overall. I have a small suggestion though:

I’ve been using it for a few minutes and I’ve noticed that I click on the icon then instantly move mouse cursor a bit higher expecting the new extended icon to show up. But it doesn’t. Wouldn’t it be better to show the extended icon right after a click yet make it invisible? We could make it visible (possibly, with a nice transition) after an half of a second.

[Pavel Feldman]

(In reply to comment #23)
> Looks good overall. I have a small suggestion though:
> 
> I’ve been using it for a few minutes and I’ve noticed that I click on the icon then instantly move mouse cursor a bit higher expecting the new extended icon to show up. But it doesn’t. Wouldn’t it be better to show the extended icon right after a click yet make it invisible? We could make it visible (possibly, with a nice transition) after an half of a second.

It would flicker for existing dock/undock users then. Lets land it as is and see if this makes users happy.

[Vsevolod Vlasov]

Comment on attachment 150753 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150753&action=review

> Source/WebCore/inspector/front-end/StatusBarButton.js:230
> +            if (e.which !== 1)

I would remove this check and remove button options if right mouse button was released as well.

[Pavel Feldman]

Committed r121843: <http://trac.webkit.org/changeset/121843>

[Nikita Vasilyev]

(In reply to comment #24)
> (In reply to comment #23)
> > Looks good overall. I have a small suggestion though:
> > 
> > I’ve been using it for a few minutes and I’ve noticed that I click on the icon then instantly move mouse cursor a bit higher expecting the new extended icon to show up. But it doesn’t. Wouldn’t it be better to show the extended icon right after a click yet make it invisible? We could make it visible (possibly, with a nice transition) after an half of a second.
> 
> It would flicker for existing dock/undock users then. Lets land it as is and see if this makes users happy.

This is what I meant http://www.screenr.com/20Z8

[Pavel Feldman]

> This is what I meant http://www.screenr.com/20Z8

Reduced timeout to 200ms. Is this better? The idea is that the button acts as the PS tool chooser or a long press mobile button. I think people will figure it out. Note that we assume that people toggle between bottom / right mode less often than dock / undock the pane. If we learn that this is not the case, we'll need to tweak the defaults / behavior.