744906 - [meta] [devtb] Update the look of the developer toolbar and GCLI

Status: RESOLVED FIXED

(DevTools :: Console, defect, P1)

Description

[Joe Walker [:jwalker]]

Picks up the work that got dropped off from bug 720641

Comment 1

[Joe Walker [:jwalker]]

Attachment: GCLI UI Design Overview - i01

Comment 2

[Joe Walker [:jwalker]]

Attachment: GCLI UI Mockups - i01

Comment 3

[Joe Walker [:jwalker]]

This is shorlander's, from bug 720641 comment 32:

(In reply to Joe Walker from comment #18)
> Can you give me an example of >> for overflow?
> My reasoning behind >> was that it was like the > we already used, but "more
> so", and it worked simply anywhere, allowing a change of color and
> background using only CSS, which unless you know of cool tricks that I
> don't, you can't do with graphics. (I know you can change one of
> color/background using transparency, but both, independently?)

We use it for toolbar overflow: http://cl.ly/1t1W312V2s172x3b1v01

Although we use a single tailless arrow for scroll left/right also so maybe it doesn't matter that much.

Where would we be reusing it so that we need to change the style that often?


> I agree that it's not massively discoverable, but on the other hand:
> - it is 'the standard'
> - we do tell people about it in the opening blurb that shows every time
> until they say they've read it
> - it's not a requirement for using GCLI. The obvious thing to do if you're
> not sure is to type help, which we also support (and I guess we could add F1
> instruction in there too)
> - the help shows automatically when we think people need it. so this is just
> for when people say they want help, and we've not guessed

Fair enough, just a thought :)


> The location of the (?) clashes somewhat with the (tick) marker that we
> previously discussed to show that a command worked but had no output. How do
> you see those interacting?

They could align next to each other without much issue assuming we end up needing an indicator like that.


> I agree that moving the hints as you type would be really annoying, but the
> hints change depending on which parameter the cursor is in so I think it
> makes sense to connect the hint to the parameter in some way.

Right, let me think about that some more. I have a few things I was trying, I will post those.


> One thing I would like to do is to get away from monospace fonts. I don't
> see any good reason for them other than implementation detail (which is/was
> the issue, we might be able to fix that now). Can we get away from that?
> It's certainly not needed in the hint/output area, and possibly not in the
> input any more, although that will require some experimentation.

This has the makings of a larger and more contentious debate ;)

There is no reason we couldn't use the system font here. I think the concern is what kind of font people expect from a command line. Especially in a situation where you might be entering code into it.

I do think we should use a consistent font for both the input and the output/help panels.


> What's the 'undefined' for in the final example?

I actually meant to ask you that ;) It is what showed up in my GCLI output with your patches.

Comment 4

[Joe Walker [:jwalker]]

(In reply to Joe Walker from comment #3)
> This is shorlander's, from bug 720641 comment 32:
> 
> (In reply to Joe Walker from comment #18)
> > Can you give me an example of >> for overflow?
> > My reasoning behind >> was that it was like the > we already used, but "more
> > so", and it worked simply anywhere, allowing a change of color and
> > background using only CSS, which unless you know of cool tricks that I
> > don't, you can't do with graphics. (I know you can change one of
> > color/background using transparency, but both, independently?)
> 
> We use it for toolbar overflow: http://cl.ly/1t1W312V2s172x3b1v01
> 
> Although we use a single tailless arrow for scroll left/right also so maybe
> it doesn't matter that much.
> 
> Where would we be reusing it so that we need to change the style that often?

In the tab view of GCLI, we currently use it as a prefix on executed commands with 3 colors, red: error, green: ok, blue, incomplete.

For example:
  http://mozilla.github.com/gcli/
  » echo hi
  » sleep 1000
  (I'm not sure there is a command that can fail there)

Also I would like to add some colors to the prompt to indicate what state the current command is in: red: error, orange: incomplete, blue: ready to press return.

I guess this is just 4 graphics, given a transparent background - not a huge hassle.


> > The location of the (?) clashes somewhat with the (tick) marker that we
> > previously discussed to show that a command worked but had no output. How do
> > you see those interacting?
> 
> They could align next to each other without much issue assuming we end up
> needing an indicator like that.

I suggest we see how it works without a (?), and we can add one in if we need one.


> > I agree that moving the hints as you type would be really annoying, but the
> > hints change depending on which parameter the cursor is in so I think it
> > makes sense to connect the hint to the parameter in some way.
> 
> Right, let me think about that some more. I have a few things I was trying,
> I will post those.

Thanks.


> > One thing I would like to do is to get away from monospace fonts. I don't
> > see any good reason for them other than implementation detail (which is/was
> > the issue, we might be able to fix that now). Can we get away from that?
> > It's certainly not needed in the hint/output area, and possibly not in the
> > input any more, although that will require some experimentation.
> 
> This has the makings of a larger and more contentious debate ;)
> 
> There is no reason we couldn't use the system font here. I think the concern
> is what kind of font people expect from a command line. Especially in a
> situation where you might be entering code into it.
> 
> I do think we should use a consistent font for both the input and the
> output/help panels.

Right now, we've even removed the ability to enter Javascript, so you can't enter code at all!
I would like to add that back in, but only once we've established the idea that we can have a command line separate from an JS prompt.
I would also like to have the input area be hidden and represented on-screen by nicer markup. The idea is to be able to:
- display text inside {} in a monospace font, variable width outside
- display long arguments elided when not being edited
- display passwords obfusticated in some way
- etc.

> > What's the 'undefined' for in the final example?
> 
> I actually meant to ask you that ;) It is what showed up in my GCLI output
> with your patches.

I hope that's gone now.
Please tell me if you find it again.

Comment 5

[Joe Walker [:jwalker]]

Using as a meta bug for UI issues with developer toolbar.

Comment 6

[Joe Walker [:jwalker]]

Old meta bug that's not particularly helpful to have kept around.
Triage.