Closed Bug 1076932 Opened 9 years ago Closed 3 years ago
Don't show "inspect element" unless devtools are already toggled
I think we could declutter our right-click menu just a bit by only showing the "inspect element" option to people who have given us a clear signal they're interested in inspecting elements. As it is, it's kind of a scary thing to mis-click.
CC'ing psackl, for some UX love.
That makes sense. This item is useful to a very very tiny portion of our users. But many devtools users use it to start the devtools. What we could probably do is to show the menuitem only if the user used the devtools at least once.
That is the primary way lots of people open our DevTools... and how they get discovered. Just sayin'
Paul's idea is solid, I think. In terms of discoverability, the current experience is kind of like discovering a real toolbox by having a passerby empty one into your lap accidentally.
Perhaps we should leave it as-is for at least the Nightly / Aurora channels? I think some developers could be confused by this not being present, and then "suddenly" appearing later.
(In reply to J. Ryan Stinnett [:jryans] from comment #5) > Perhaps we should leave it as-is for at least the Nightly / Aurora channels? > > I think some developers could be confused by this not being present, and > then "suddenly" appearing later. We can make it so that people who used the devtools in the past still see the menuitem. I know it's ugly, but if any devtools.toolbox.* pref is not the default value, then the user had interacted with the devtools at some point in the past. What we could do is: By default: devtools.enableInspectContextMenu is *not* in prefs.js - when context menu opens: - if devtools.enableInspectContextMenu is true - show contextMenu - if devtools.enableInspectContextMenu is false - don't show contextMenu - if devtools.enableInspectContextMenu is undefined - if devtools.toolbox.footer.height is default value - set devtools.enableInspectContextMenu to false, don't show contextMenu - else - set devtools.enableInspectContextMenu to true, show contextMenu - when toolbox opens: - set devtools.enableInspectContextMenu to true How does that sound?
All other browsers have this in the context menu by default. Safari used to hide it but added it to the context menu because people wanted it there.
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #7) > All other browsers have this in the context menu by default. Safari used to > hide it but added it to the context menu because people wanted it there. That doesn't mean we should not hide it by default.
I think we should get some telemetry on how the tools are opened before making a change here. The more I think about this, it feels like a bad idea, but we need data to be sure. Removing ways to access the tools when we are trying so hard to make them more usable and more discoverable seems like a bad idea.
People that would be annoyed by the button use release. And there's no telemetry there. So we can't really get data. And because we never really heard about any complain, I'm not sure we should take the risk of making our tools less discoverable.
(In reply to Mike Hoye [:mhoye] from comment #0) > I think we could declutter our right-click menu just a bit by only showing > the "inspect element" option to people who have given us a clear signal > they're interested in inspecting elements. > > As it is, it's kind of a scary thing to mis-click. Things you should have in your pocket to convince us this is something we should do on release channel: * from Beta populations, data collected via telemetry that counts how many times that menu command is used, ideally with some correlation with how long the toolbox remains open afterwards. The idea here is that Beta populations are more representative of release. I don't consider measurements of this from Nightly / Aurora currently to be meaningful. You're in luck, we're going to add something a lot like this to bug 1046234. If you want data prior to December, you should request beta uplift of the telemetry changes ( I don't need uplift personally ) to get these measures into 34. * SUMO reports complaining about non-developers accidentally hitting this item and being confused / terrified. I personally haven't heard reports from SUMO along these lines? If we get to the point where we feel this is a real issue for release channel users, we then need to ensure that people using release channel can discover and enable this menu item. For developers this menu item is the key entry point into the tools, and I'm loathe to remove it in the absence of an actual problem for users.
Removing the items seems quite harsh for all the reasons posted in the comments here. One thing we probably could do instead is improving the first-time experience of dev tools, including an easy »Whoah, I don't want that!« option that then hides the menu entry. That way we could keep the visibility and yet provide a safety net for users who don't know what is going on there.
(In reply to Philipp Sackl [:phlsa] from comment #12) > Removing the items seems quite harsh for all the reasons posted in the > comments here. > > One thing we probably could do instead is improving the first-time > experience of dev tools, including an easy »Whoah, I don't want that!« > option that then hides the menu entry. That way we could keep the visibility > and yet provide a safety net for users who don't know what is going on there. That's bug 953166 - and I agree. Dev Edition will have a first run experience that will be quite minimal at first but that I hope to expand so that it's meaningfully helpful for first-time users of future versions. We'll need to make sure that any first run experience for the toolbox itself is in sync with first run experience for the dev browser - I could see a lot of repetition.
Depends on: 1106262
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.