703092 - Element locking feature is not a visible / obvious

Status: RESOLVED DUPLICATE of bug 717916

(DevTools :: General, defect)

Description

[Håkan Waara]

In the new devtools the "locking" on an element on and off is not a very visible feature.  I had no idea about until I read bug 691844.

Idea: maybe show a little clickable lock icon near the clicked node that would lock down on it?

Comment 1

[Håkan Waara]

Sorry, that reference should be bug 691884

Comment 2

[Paul Rouget [:paul]]

(In reply to Håkan Waara from comment #0) 
> Idea: maybe show a little clickable lock icon near the clicked node that
> would lock down on it?

In the infobar (the floating bar with the id + classes)?

Comment 3

[Paul Rouget [:paul]]

Attachment: screenshot - unlocked

Comment 4

[Paul Rouget [:paul]]

Attachment: screenshot - locked

Comment 5

[Paul Rouget [:paul]]

So the problem is that we don't really make the difference between the "unlocked" and "locked" mode (see attached screenshots).

Questions:

1) Do we really want to make it obvious that a node is locked or not?
2) Should we change the look of the selection (we already make it a bit brighter), and/or change the look of the infobar? Or add an icon/marker somewhere?
3) If we add an icon/marker somewhere, should it be clickable to unlock the node and start the inspection?

Comment 6

[Håkan Waara]

I think that right now it just feels very random whether something is locked or not. There's no user-visible way for controlling it, so I definitely think there should be a button or toggle near the node for changing it.

IMHO the look of the selection is secondary, because the understanding of that distinction comes *after* you know how to toggle the feature.

Comment 7

[Håkan Waara]

Or you could go the way of firebug and always lock by default, and let a button on the toolbar toggle it. Maybe that is the way to go if people rarely use unlocking/locking and just decide on a default.

Comment 8

[Paul Rouget [:paul]]

(In reply to Håkan Waara from comment #6)
> I think that right now it just feels very random whether something is locked
> or not. There's no user-visible way for controlling it, so I definitely
> think there should be a button or toggle near the node for changing it.

There is the "inspect" button.
 
> IMHO the look of the selection is secondary, because the understanding of
> that distinction comes *after* you know how to toggle the feature.
>
> Or you could go the way of firebug and always lock by default, and let a
> button on the toolbar toggle it. Maybe that is the way to go if people
> rarely use unlocking/locking and just decide on a default.

By default, it is locked. And there is the "inspect" button to toggle it.

"locking" is the opposite of "inspecting".

Comment 9

[Joe Walker [:jwalker]]

I think there is an obvious visual distinction between locked mode and unlocked mode - it's whether the highlighted element follows the cursor or not.

The problem is perhaps in the terminology: locked/unlocked. We talk about a node being locked, but in reality it's the highlight square that's locked, and perhaps even the notion of locking is not perfect, although a better term doesn't spring to mind.
However I don't think we should be hugely hung up about the terminology because it is not user visible.

Perhaps this would help the user interaction - in locked mode if you could change to unlocked mode by clicking outside of the highlighted node, the transitions would be more natural.

Comment 10

[Rob Campbell [:rc] (:robcee)]

I wonder if a lighter shade on the highlighter when unlocked would provide a bit of additional distinction between the new modes?

I don't think we need to do a whole lot here, but maybe some additional differentiation could help. I do think people will become used to checking the state of the Inspect button to check if they're inspecting or not.

Comment 11

[Joe Walker [:jwalker]]

(In reply to Rob Campbell [:rc] (robcee) from comment #10)
> I wonder if a lighter shade on the highlighter when unlocked would provide a
> bit of additional distinction between the new modes?
> 
> I don't think we need to do a whole lot here, but maybe some additional
> differentiation could help. I do think people will become used to checking
> the state of the Inspect button to check if they're inspecting or not.

Let me try to re-spin what I was saying:

Let's not focus on visual changes, because there will always be people that don't notice, instead, lets make it trivial to get into the mode you want.
i.e. Make it so that you could click anywhere, and the mode would change.

"*click* now the white square is following me. *click* now it isn't. Ahh, I get it."

I think that education through action works better than education that relies on someone noticing some potentially out of the way visual change.

Comment 12

[Håkan Waara]

I agree that making nodes/boxes/document clickable makes the UX much simpler and more discoverable than using a button somewhere in the toolbar.

(Semi-offtopic, but in general I think the currently the new devtool relies too much on a dozen clicks in the toolbar to get to a useful state of the tool; with firebug 1 click on "inspect" gives me instant access to the HTML tree etc.)

Comment 13

[Dave Camp (:dcamp)]

(In reply to Joe Walker from comment #11)

> I think that education through action works better than education that
> relies on someone noticing some potentially out of the way visual change.

Agreed, but an immediate and local visual change would be nice.  Same way I could learn that clicking on a button has an effect, but it's nice to see the button depress too.

Comment 14

[Paul Rouget [:paul]]

This is going to be fixed when we will get the Inspect button (bug 717916) and the Node Menu (bug 717919) to the infobar once locked.