1355080 - The eyedropper command is never used

Status: RESOLVED INCOMPLETE

(DevTools Graveyard :: Graphic Commandline and Toolbar, enhancement, P2)

Description

[Patrick Brosset <:pbro>]

The eyedropper can be started from 4 different places, and we have 4 telemetry probes for each of those:

1. As a GCLI command: "DEVTOOLS_EYEDROPPER_OPENED_COUNT"
2. From the developer menu: "DEVTOOLS_MENU_EYEDROPPER_OPENED_COUNT"
3. From the colorpicker tooltip (in the rule-view): "DEVTOOLS_PICKER_EYEDROPPER_OPENED_COUNT"
4. From the inspector toolbar: "DEVTOOLS_TOOLBAR_EYEDROPPER_OPENED_COUNT"

I was looking at telemetry data for Firefox release 52 and found the following numbers:

1. 23 samples
2. ~4200 samples
3. ~1900 samples
4. No data, because the histogram is not declared, see bug 1352115

These numbers suggest that the gcli command is never used, and we could get rid of it.

Now, the twist is that the developer menu actually calls this command behind the scenes, with a specific argument so the telemetry gets recorded in a different place.

We're starting to understand a bit more how gcli get used in general with the new DEVTOOLS_GCLI_COMMANDS_KEYED probe and there are good chances that very few commands actually get used and that we might want to get rid of gcli as it is now, and just make these few commands available differently.

So, knowing this and the fact that the eyedropper command doesn't get used at all, it might be good to change how the menu starts this tool and just remove the command.

Comment 1

[Joe Walker [:jwalker]]

I think we should re-ask the question - should we kill the whole developer toolbar. Previously the argument against killing it has been that we want to make something of it, and that keeping it alive until then is good. If we make something of it, and usage increases, then an eyedropper command could be useful.

Killing commands individually when they're not used is likely to be lots of work compared to just killing the whole thing. So either we should take of and nuke it from space, or leave it basically alone until we make something of it.

Comment 2

[Tim Nguyen :ntim]

(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #1)
> I think we should re-ask the question - should we kill the whole developer
> toolbar. Previously the argument against killing it has been that we want to
> make something of it, and that keeping it alive until then is good. If we
> make something of it, and usage increases, then an eyedropper command could
> be useful.

The only reason people use the developer toolbar is because there's no easier way to access some commands:
- People who use the screenshot command don't have an easier way to access the command without opening the toolbox
(you have to open the toolbox, make sure the screenshot command is enabled and click it)
- Same thing could be said about most commands
- GCLI also offers some exclusive features that haven't made their way in the toolbox: security tool, css coverage, @media emulation, inject command, ...

I think the dev toolbar should be killed and its functionality should be integrated in the toolbox.

Comment 3

[Joe Walker [:jwalker]]

> I think the dev toolbar should be killed and its functionality should be integrated in the toolbox.

I'm arguing that removing commands one-by-one as we find that they're not used, isn't a great strategy. We should either:

1. Decide that we're not doing commands, and so kill the developer toolbar, gcli, all the commands, and integrate the functionality elsewhere, or,
2. We should decide that we do want to do commands at some point in the future, not kill commands just because they're low usage, and at some point integrate gcli into the console.

Doing something in-between is death by a thousand cuts, rather than death because it deserves to die.

Comment 4

[Bryan Clark (DevTools PM) [:clarkbw]]

I agree.  I think the eyedropper is a great start but given the numbers in general we might as well take on the broader question.

Are we going to invest more in the GCLI in general?

I think our answer to this is no.

Are we going to invest more in commands but move them somewhere else like the console?

Possibly?  I'm not sure but I'd prioritize making these commands more available via the UI first.

Are we going to stop investing in the the GCLI altogether and move the valuable commands elsewhere?

I think this is our priority unless there's a future with the GCLI I'm unaware of.  (and I'm asking this question honestly)


Furthering the stop GCLI route.  I suggest we evaluate the high usage commands and figure out a path forward for those.  We should likely then look into the unique command (like the security tool) which may not get high usage but that doesn't equate to their value as much as the way they are naturally used.  What's left over can likely be converted into a list of things we're interested in but not investing in, hopefully we see them again as WebExtensions.

Comment 5

[Joe Walker [:jwalker]]

The vision of GCLI was (and I still there there's something in this):

Command lines are beloved because they're fast and composable in interesting ways. But they're opaque, so they're hard to get into.

The opacity problem is hard because the interface between shell and command is basically a single API function "invoke with list of string params". There is so much more we could do if the command could tell the shell how it worked, but that API is basically unfixable in unix because of the size of the eco-system.

With a new CLI however, we could solve the opacity problem.

Jeff had a vision of a GCLI that ran in a normal shell window to talk to Firefox (possible with Node), and for GCLI in Firefox to be able to fire off shell commands.


That said, we're no nearer realizing any of this vision, so maybe now's the time to cut and run.

Comment 6

[Bryan Clark (DevTools PM) [:clarkbw]]

That all makes sense to me.  I don't know if we should continue down that path, probably needs lots of product / ux thought.

Comment 7

[Firefox Bug Husbandry Bot]

Per bug 1491875, this component has been closed, and the affected code is being removed from Firefox. Closing this bug as incomplete.