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

RESOLVED FIXED in Firefox 17

Status

()

Firefox
Developer Tools: Console
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jwalker, Unassigned)

Tracking

Trunk
Firefox 17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux-wanted])

Attachments

(2 attachments)

Picks up the work that got dropped off from bug 720641
Created attachment 614518 [details]
GCLI UI Design Overview - i01
Created attachment 614521 [details]
GCLI UI Mockups - i01
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.
(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.
Blocks: 745773

Updated

5 years ago
Depends on: 749626

Updated

5 years ago
No longer depends on: 720641

Updated

5 years ago
Depends on: 720641
Target Milestone: Firefox 15 → Firefox 16
Depends on: 760445
Depends on: 760446

Updated

5 years ago
Depends on: 764555
Using as a meta bug for UI issues with developer toolbar.
Summary: Update the look of the developer toolbar and GCLI → [meta] [devtb] Update the look of the developer toolbar and GCLI
No longer blocks: 745773
Target Milestone: Firefox 16 → Firefox 17
Old meta bug that's not particularly helpful to have kept around.
Triage.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
No longer depends on: 760445
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.