Bug 76917 - Web Inspector: "Dock to right" shouldn't be in the settings dialog
Summary: Web Inspector: "Dock to right" shouldn't be in the settings dialog
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nikita Vasilyev
URL:
Keywords:
: 79923 88559 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-24 08:28 PST by Nico Weber
Modified: 2012-07-04 06:56 PDT (History)
12 users (show)

See Also:


Attachments
Context menu mockup (11.42 KB, image/png)
2012-05-01 05:20 PDT, Nikita Vasilyev
no flags Details
Three (radio) buttons (1.54 KB, image/png)
2012-05-01 05:27 PDT, Nikita Vasilyev
no flags Details
Patch (22.59 KB, patch)
2012-07-04 03:09 PDT, Pavel Feldman
vsevik: review+
Details | Formatted Diff | Diff
[IMAGE] with patch applied (865 bytes, image/png)
2012-07-04 03:09 PDT, Pavel Feldman
no flags Details
[IMAGE] with patch applied (1023 bytes, image/png)
2012-07-04 03:10 PDT, Pavel Feldman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Weber 2012-01-24 08:28:51 PST
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.)
Comment 1 Pavel Feldman 2012-01-24 08:52:05 PST
Where would you expect to see it?
Comment 2 Nico Weber 2012-01-24 09:02:43 PST
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.
Comment 3 Timothy Hatcher 2012-01-24 09:39:49 PST
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.
Comment 4 Pavel Feldman 2012-01-25 01:44:26 PST
(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.
Comment 5 Nico Weber 2012-01-25 08:18:30 PST
(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 :-)
Comment 6 Nikita Vasilyev 2012-05-01 05:20:48 PDT
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.
Comment 7 Nikita Vasilyev 2012-05-01 05:27:11 PDT
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
Comment 8 Alexander Pavlov (apavlov) 2012-06-08 00:59:22 PDT
*** Bug 88559 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Pavlov (apavlov) 2012-06-08 01:00:18 PDT
Bug 88559 requests a shortcut for toggling the Inspector docking side.
Comment 10 sam 2012-06-08 04:34:45 PDT
*** Bug 88559 has been marked as a duplicate of this bug. ***
Comment 11 Nikita Vasilyev 2012-06-08 04:51:26 PDT
> (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.
Comment 12 Pavel Feldman 2012-06-08 04:53:36 PDT
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.
Comment 13 sam 2012-06-08 05:31:25 PDT
*** Bug 79923 has been marked as a duplicate of this bug. ***
Comment 14 Nikita Vasilyev 2012-07-03 07:43:53 PDT
Any progress here?
Comment 15 Pavel Feldman 2012-07-03 08:32:40 PDT
(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?
Comment 16 Nikita Vasilyev 2012-07-03 08:41:23 PDT
(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.
Comment 17 Pavel Feldman 2012-07-03 08:53:48 PDT
> 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?
Comment 18 Pavel Feldman 2012-07-03 08:55:12 PDT
(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...
Comment 19 Nikita Vasilyev 2012-07-03 09:04:13 PDT
(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.
Comment 20 Pavel Feldman 2012-07-04 03:09:04 PDT
Created attachment 150753 [details]
Patch
Comment 21 Pavel Feldman 2012-07-04 03:09:49 PDT
Created attachment 150754 [details]
[IMAGE] with patch applied
Comment 22 Pavel Feldman 2012-07-04 03:10:08 PDT
Created attachment 150755 [details]
[IMAGE] with patch applied
Comment 23 Nikita Vasilyev 2012-07-04 03:57:26 PDT
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.
Comment 24 Pavel Feldman 2012-07-04 05:22:43 PDT
(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.
Comment 25 Vsevolod Vlasov 2012-07-04 05:25:48 PDT
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.
Comment 26 Pavel Feldman 2012-07-04 05:54:06 PDT
Committed r121843: <http://trac.webkit.org/changeset/121843>
Comment 27 Nikita Vasilyev 2012-07-04 06:34:05 PDT
(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
Comment 28 Pavel Feldman 2012-07-04 06:56:53 PDT
> 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.