642241 - Experiment with better UI presentation methods in GCLI

Status: RESOLVED FIXED

(DevTools :: Console, defect, P2)

Description

[Joe Walker [:jwalker]]

The current CLI plus dialog is very staid and boring, we should experiment with some fancier methods of allowing input.

Joe has a ton of ideas.

Comment 1

[Joe Walker [:jwalker]]

There is no reason why the input line has to be displayed as an <input type=file> we could use an hidden input with a custom div for display.

Ideas:
- display passwords using ***** or even a chroma-hash http://mattt.github.com/Chroma-Hash/
- display long arguments with elision when not being edited
- use colors to denote different parts of the input (see attached png)

Comment 2

[Joe Walker [:jwalker]]

Attachment: potential gcli view

Comment 3

[Joe Walker [:jwalker]]

Attachment: original graffle file

Comment 4

[Joe Walker [:jwalker]]

Attachment: svg export

Comment 5

[Joe Walker [:jwalker]]

Moving GCLI bugs to Developer Tools: Console. Filter on 'baked beans are off'.

Comment 6

[Joe Walker [:jwalker]]

Triage. Filter on PEGASUS.

Comment 7

[Joe Walker [:jwalker]]

Triage. Filter on PEGASUS.

Comment 8

[Joe Walker [:jwalker]]

Attachment: upload 2

Comment 9

[Joe Walker [:jwalker]]

Attachment: bbml file from which the png was taken

Comment 10

[Kevin Dangoor]

FWIW, I agree with everything in attachment 591405 [details] (comment 8). That looks like a nice refinement of the current command line interaction.

Comment 11

[Joe Walker [:jwalker]]

The section 'Typing a Mandatory Parameter' calls for UX elements to help parameter entry in some cases.

Currently we have helpers for:

string -> <input>
number -> <input type=number max=? min=? step=?>
boolean -> <checkbox>
selection -> <select>
javascript -> <input> + <select>

The important question to as is - When might someone want to reach for the mouse above typing? I think there are 2 answers:
1. When they don't know what to type
2. When there is lots to type from few options

A mythical command to tweak the size of an element might be an example of (1).
> tweak width #id 512

It would common for the number to be expressed in a users mind not as an absolute number but relative to the current (i.e. 2px more than it is now). In this case a slider might be better

The current edit command allows users to pick from a list of CSS sheets in the current page, by URL. The URLs all have similar long prefixes. The correct URL can be more quickly selected from a <select> than typed.

Of the current 5 helpers, select and javascript (which are very similar) seem to be worth retaining.

Comment 12

[Paul Rouget [:paul]]

Comment on attachment 591405 [details]
upload 2

* About the prompt. There are 2 prompts: js (console) and command (gcli). We need to make sure the differences are clear. I think a big colored arrow with "command" or "javascript" written could work (different colors). But I suggest to not take any decision at the moment (layout vs. design).

* Without Input: which problem are you trying to solve? When you say "initially", do you mean "for the first run ever"?

I would avoid showing a popup when the user is not typing anything. This is quite "heavy".

Instead, I would have a very explicit placeholder for "gcli beginners":
> Type 'help' or 'list' to begin.
After a while (once `list` and `help` have been typed once), I would hide this placeholder (a little clear/closed button could be added to immediately remove this placeholder).

* Typing a command:

I think these completion mechanisms are awesome. But we should be careful to do not show too many results. I think we will need to experiment with the implementations to see how it feels. If possible, we should also consider basing the behavior of the gcli on existing known mechanisms (shell?).

Fuzzy matching should not be `on` by default. I use that in Vim. If you don't understand what a FuzzySearch is, it is very very disturbing.

Help matching can be interesting. But it might be a little unexpected. What about showing such result only if prefix matching doesn't return anything?

Matching something that is IN the command but is not the prefix is interesting, and I would activate it only on ctrl-r (like for a shell). We also need a "history" matching (triggered via ctrl-r as well).

* Typing a mandatory parameter

I don't think we should forbid the user to type an invalid command. That would be against the user expectations and the natural way to use a cli. Showing an error once the command is validated might be better.

Looking at the mockups, it looks a bit "encumbered".

Important thing: I think the dialog should be optional. `on` by default, but the user should be able to disable it.

I don't think we should embed rich UIs in the dialog. This goes against the nature of a cli.
A rich UI (slider, comboboxes, …) would have been interesting if the command was executed everytime the value was changed. You click, you expect changes. But in this configuration (command line), this doesn't make sense.

The dialog should be discrete, and should not encumber the UI and distract the user.

* Typing a Second Mandatory Parameter

This sounds "too much". Do we really need to allow the user to click on the second parameter? This introduces problems (what if no default values) where there're no really advantages.

----------------

Overall comment: I feel like this is going a little too far. It feels "too much".

To make every-things discoverable, to make sure it's not possible to type anything wrong and to ensure you can always use the mouse, this mockups makes the command line very cluttered.

Comment 13

[Joe Walker [:jwalker]]

(In reply to Paul Rouget [:paul] from comment #12)
> Comment on attachment 591405 [details]
> upload 2
> 
> * About the prompt. There are 2 prompts: js (console) and command (gcli). We
> need to make sure the differences are clear. I think a big colored arrow
> with "command" or "javascript" written could work (different colors). But I
> suggest to not take any decision at the moment (layout vs. design).

Agreed - as I say under 'Minor changes'

> * Without Input: which problem are you trying to solve? When you say
> "initially", do you mean "for the first run ever"?

Either. Any time when you're about to type a command, and an may not know exactly the command to type.

> I would avoid showing a popup when the user is not typing anything. This is
> quite "heavy".

Agreed. This current feature of GCLI is expected to continue.

> Instead, I would have a very explicit placeholder for "gcli beginners":
> > Type 'help' or 'list' to begin.

I've been pondering various options for the first-run experience. I don't want to have instructions that people need to read to get what's going on, but I do think we need to set expectations of JS vs. command line.

> After a while (once `list` and `help` have been typed once), I would hide
> this placeholder (a little clear/closed button could be added to immediately
> remove this placeholder).

I'm not sure what you want to display in this placeholder?

> * Typing a command:
> 
> I think these completion mechanisms are awesome. But we should be careful to
> do not show too many results. I think we will need to experiment with the
> implementations to see how it feels. If possible, we should also consider
> basing the behavior of the gcli on existing known mechanisms (shell?).
> 
> Fuzzy matching should not be `on` by default. I use that in Vim. If you
> don't understand what a FuzzySearch is, it is very very disturbing.
> 
> Help matching can be interesting. But it might be a little unexpected. What
> about showing such result only if prefix matching doesn't return anything?

The idea with the matching is to show less than 7 potential matches, much less when we're fairly confident that we know what the user wants.
I was expecting fuzzy matching and help matching to only be of use when prefix matching doesn't find anything, but I agree we'll need to take a look to see how it works.

> Matching something that is IN the command but is not the prefix is
> interesting, and I would activate it only on ctrl-r (like for a shell). We
> also need a "history" matching (triggered via ctrl-r as well).

Bug 681340 is for history matching.

> * Typing a mandatory parameter
> 
> I don't think we should forbid the user to type an invalid command. That
> would be against the user expectations and the natural way to use a cli.
> Showing an error once the command is validated might be better.

We don't prevent the user from typing an invalid command - GCLI lets you mash on the keyboard all you like, but it doesn't let you press return (or at least it ignores it) until it is at least not obviously wrong. Validation is an as-you-type thing.

> Looking at the mockups, it looks a bit "encumbered".
> 
> Important thing: I think the dialog should be optional. `on` by default, but
> the user should be able to disable it.
> 
> I don't think we should embed rich UIs in the dialog. This goes against the
> nature of a cli.
> A rich UI (slider, comboboxes, …) would have been interesting if the command
> was executed everytime the value was changed. You click, you expect changes.
> But in this configuration (command line), this doesn't make sense.

I noted in comment 12 some of the reasons for rich UIs in the dialog. I think we're not going to get away with them for the selection/javascript case.
Also there's nothing to stop us previewing the effect on the page if we want.

I'm not against an option to turn the dialog off, but I'd like to see it working before implementing it.

> The dialog should be discrete, and should not encumber the UI and distract
> the user.
> 
> * Typing a Second Mandatory Parameter
> 
> This sounds "too much". Do we really need to allow the user to click on the
> second parameter? This introduces problems (what if no default values) where
> there're no really advantages.

I think we have no choice - users will try to click there expecting it to do something. However this isn't a top priority bug (in fact I forgot to raise it) Bug 720971 makes sure there will always be a default parameter.

Comment 14

[Kevin Dangoor]

(In reply to Joe Walker from comment #13)
> I noted in comment 12 some of the reasons for rich UIs in the dialog. I
> think we're not going to get away with them for the selection/javascript
> case.
> Also there's nothing to stop us previewing the effect on the page if we want.
> 
> I'm not against an option to turn the dialog off, but I'd like to see it
> working before implementing it.

This is how I feel about most of your proposals here. I don't know what the relative cost (in development time) of the various features here are, but it seems like you've got a lot of the infrastructure already for this.

While I can imagine some of these interactions (and the mockups do help with that), until we have a bunch of commands and a good opportunity to use them I couldn't personally say that I think the dialogs will be annoying.

A color picker is an example of something I'd reach for the mouse to use in some cases, rather than just guessing at color numbers.

> 
> > The dialog should be discrete, and should not encumber the UI and distract
> > the user.
> > 
> > * Typing a Second Mandatory Parameter
> > 
> > This sounds "too much". Do we really need to allow the user to click on the
> > second parameter? This introduces problems (what if no default values) where
> > there're no really advantages.
> 
> I think we have no choice - users will try to click there expecting it to do
> something. However this isn't a top priority bug (in fact I forgot to raise
> it) Bug 720971 makes sure there will always be a default parameter.

It could always just say "you need to enter the <repository> first" (or whatever the first parameter is).

Comment 15

[Paul Rouget [:paul]]

> (In reply to Joe Walker from comment #13)
> > I noted in comment 12 some of the reasons for rich UIs in the dialog. I
> > think we're not going to get away with them for the selection/javascript
> > case.
> > Also there's nothing to stop us previewing the effect on the page if we want.

(comment 11)

I understand that having such a dialog can help for some commands.
But how many commands will require a rich UI?

I don't want to see a dialog every single time I type something, especially
if I get fluent enough with the command line, and if the majority of the commands
don't need any complex selector.

I also feel like if a command needs such a rich UI, it should not be a command in the first
place.

In your examples:

> A mythical command to tweak the size of an element might be an example of (1).
> > tweak width #id 512
> 
> It would common for the number to be expressed in a users mind not as an absolute number but relative to the current (i.e. 2px more than it is now). In this case a slider might be better

In this case, this should happen in the Layout View. If you're will to use your mouse to tweak the size of an element, just use the rule view.

And if you really want to use the command line:
> tweak width #id {$0.style.width + 2}

> The current edit command allows users to pick from a list of CSS sheets in the current page, by URL. The URLs all have similar long prefixes. The correct URL can be more quickly selected from a <select> than typed.

Pressing <tab> should autocomplete the common prefix, like in a shell.

I feel like we are introducing complex UI and complex code to respond to extreme use cases that can be addressed by good-enough solutions (JS and completion).

(In reply to Kevin Dangoor from comment #14)
> > I'm not against an option to turn the dialog off, but I'd like to see it
> > working before implementing it.
> 
> This is how I feel about most of your proposals here. I don't know what the
> relative cost (in development time) of the various features here are, but it
> seems like you've got a lot of the infrastructure already for this.
> 
> While I can imagine some of these interactions (and the mockups do help with
> that), until we have a bunch of commands and a good opportunity to use them
> I couldn't personally say that I think the dialogs will be annoying.

Can we do it the other way around? We first implement a perfect simple command line with prefix-completion and history support, and then we iterate?

Comment 16

[Joe Walker [:jwalker]]

(In reply to Paul Rouget [:paul] from comment #15)
> > (In reply to Joe Walker from comment #13)
> > > I noted in comment 12 some of the reasons for rich UIs in the dialog. I
> > > think we're not going to get away with them for the selection/javascript
> > > case.
> > > Also there's nothing to stop us previewing the effect on the page if we want.
> 
> (comment 11)
> 
> I understand that having such a dialog can help for some commands.
> But how many commands will require a rich UI?
> 
> I don't want to see a dialog every single time I type something, especially
> if I get fluent enough with the command line, and if the majority of the
> commands don't need any complex selector.
> 
> I also feel like if a command needs such a rich UI, it should not be a
> command in the first place.

These dialogs only come up with a small delay, so if you type fast, you might not see them at all, and one of the things I've pondered is increasing this delay - so you only get help if you look lost.

Also I think we should expect duplication between the command line and the rest of the UI. GUIs are visually discoverable and mousable. Command lines are fast, keyboardable and don't get so cluttered with extra features, so there are benefits of both.

> I feel like we are introducing complex UI and complex code to respond to
> extreme use cases that can be addressed by good-enough solutions (JS and
> completion).

So we're agreed that there are cases where we need rich parameter completion. Commands are have more to them than JS because we are typing parameters to commands more. Also, we have a system that can give help. Why would we throw the help away for everyone, especially if there is an off switch for experts?

> (In reply to Kevin Dangoor from comment #14)
> > > I'm not against an option to turn the dialog off, but I'd like to see it
> > > working before implementing it.
> > 
> > This is how I feel about most of your proposals here. I don't know what the
> > relative cost (in development time) of the various features here are, but it
> > seems like you've got a lot of the infrastructure already for this.
> > 
> > While I can imagine some of these interactions (and the mockups do help with
> > that), until we have a bunch of commands and a good opportunity to use them
> > I couldn't personally say that I think the dialogs will be annoying.
> 
> Can we do it the other way around? We first implement a perfect simple
> command line with prefix-completion and history support, and then we iterate?

It sounds like harder work to me.

Comment 17

[Kevin Dangoor]

(In reply to Paul Rouget [:paul] from comment #15)
> (In reply to Kevin Dangoor from comment #14)
> > > I'm not against an option to turn the dialog off, but I'd like to see it
> > > working before implementing it.
> > 
> > This is how I feel about most of your proposals here. I don't know what the
> > relative cost (in development time) of the various features here are, but it
> > seems like you've got a lot of the infrastructure already for this.
> > 
> > While I can imagine some of these interactions (and the mockups do help with
> > that), until we have a bunch of commands and a good opportunity to use them
> > I couldn't personally say that I think the dialogs will be annoying.
> 
> Can we do it the other way around? We first implement a perfect simple
> command line with prefix-completion and history support, and then we iterate?

I was under the impression that most of the dialog building code is already there, which influences my thinking that we should give that a try.

I am complete agreement with you about making something useful available and iterating. From the recent gcli-in-nightly experiment, the biggest hurdle to usefulness was commands. Once we start having commands like "tweak", it will be easier to see ways in which those commands can be more discoverable and usable.

Comment 18

[Joe Walker [:jwalker]]

Something we are going to have to consider is that not all command output is synchronous. Indeed it's possible for us to have multiple outstanding commands.

This isn't theoretical - some debugger commands run asynchronously and produce output now.
Now the debugger runs asynchronously *not* because things are generally going to take significant time (at least until we're doing remote debugging) so we can probably get away with ignoring this issue for FF13, but we're going to have to consider it.

Comment 19

[Stephen Horlander [:shorlander]]

Still trying to assemble my thoughts on this. It's a lot to absorb :)

Comment 20

[Joe Walker [:jwalker]]

GCLI Triage.
Fixed with the closing of bug 720641
Also there are other UX bugs still open.