Last Comment Bug 599498 - Web Console CSS aesthetics
: Web Console CSS aesthetics
Status: RESOLVED FIXED
: dev-doc-complete, meta, polish
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 574103 601667 601671 601672 605621 611440 611851
Blocks: 580502 devtools4b8 608135 684561
  Show dependency treegraph
 
Reported: 2010-09-24 14:16 PDT by Dave Herman [:dherman]
Modified: 2012-02-02 07:43 PST (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
Colorized Category Mockup (17.00 KB, image/png)
2010-10-04 08:19 PDT, Rob Campbell [:rc] (:robcee)
no flags Details
Mockup that integrates ideas from the separate bugs (61.80 KB, image/png)
2010-10-05 12:21 PDT, Kevin Dangoor
no flags Details
Screenshot. (45.65 KB, image/png)
2010-10-05 18:43 PDT, Patrick Walton (:pcwalton)
no flags Details
Mockup: color and shape used in a timeline bar (1.05 MB, image/png)
2010-10-05 19:54 PDT, Alex Faaborg [:faaborg] (Firefox UX)
no flags Details
Mockup i2 (965.24 KB, image/png)
2010-10-06 14:32 PDT, Alex Faaborg [:faaborg] (Firefox UX)
no flags Details
Mockup i3 (996.44 KB, image/png)
2010-10-06 16:29 PDT, Alex Faaborg [:faaborg] (Firefox UX)
no flags Details
First stab at some icons (1000 bytes, image/png)
2010-10-06 19:15 PDT, Patrick Walton (:pcwalton)
no flags Details

Description Dave Herman [:dherman] 2010-09-24 14:16:48 PDT
The current web console needs some designer love. :) Colors, font styling, and more modern fonts are the first and probably easiest thing I noticed that could use improvement. But the checkboxes might benefit from icons or more fashionably-styled elements (I'm cribbing a bit from Chrome here, perhaps).

Another thing that could stand to be a little less clunky is the auto-complete style. It's pretty blinky and distracting. Chrome's approach on this one is worth looking at, too.

I'm not making more specific suggestions because IANA designer and I don't mean to bikeshed -- just wanted to call attention to the need.

Dave
Comment 1 Kevin Dangoor 2010-09-30 10:04:00 PDT
cc'ing limi here for feedback.
Comment 2 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-30 11:59:21 PDT
Limi's OOTO for basically October. I'll take this, I guess. Kevin, wanna quickly meet up on IRC or by phone to chat about the priorities and so I can catch up on any existing design work that's been done?
Comment 3 Kevin Dangoor 2010-10-01 09:49:13 PDT
We don't really have existing design work to point to. The work that has gone in so far has had limi's sign off on it and we generally worked from the mockup in bug 559481, with a few changes along the way.

limi has expressed to me that he's not in favor of icons for things that are not easily represented by pictures that everyone understands. Otherwise, input on polish items for the UI is certainly welcome here.
Comment 4 Patrick Walton (:pcwalton) 2010-10-01 11:10:55 PDT
I'll take these one by one:

(In reply to comment #0)
> Colors

I'm currently thinking that only the categories ought to be color-coded in the output messages, and the messages themselves should be black on white, to make the colors look less jarring and retro.

> font styling, and more modern fonts

I erred on the side of caution and just used the XUL monospace font, to minimize friction with the rest of the product (and to allow the user to customize it in the prefs). If we want to move to Monaco or something else, then I'd personally be fine with that, but I'd want the UX team to sign off on it, because it'll come at the cost of customization and consistency.

> But the checkboxes might benefit from icons or more
> fashionably-styled elements (I'm cribbing a bit from Chrome here, perhaps).

We agonized over this one. Originally, they looked sorta like a platform filter bar, but the fundamental problem with that was that only checkbox-like UI elements convey the fact that the categories can be toggled on and off *individually*. Aza was in favor of little on/off sliders, like the iPhone checkboxes [1] except vertical, but Limi didn't like the idea from a platform integration perspective. So we compromised on checkboxes, pending a better solution.

At the very least I'd like to have the checkboxes that we have in the Find bar on the Mac (notice that they look different, and IMO blend in better with toolbars/filter bars).

Based on feedback from the UX team, we came to the conclusion that icons are a bad idea. The original mockup in bug 559481 had icons for Errors/Warnings/Info/Log, but they were nixed, because there's no good way to represent "Log" in particular.

I think WebKit misuses icons in its developer tools. I can't tell what the icons in this screenshot [2] represent.

> Another thing that could stand to be a little less clunky is the auto-complete
> style. It's pretty blinky and distracting. Chrome's approach on this one is
> worth looking at, too.

This one I hadn't thought about, but I agree that WebKit's approach looks nicer. The primary issue here is technical: we use a XUL textbox, which doesn't allow rich text as far as I know. Joe spent some time with Bespin's autocomplete finding a good solution for exactly this problem: I've filed bug 601183 for this and cc'd him.

> I'm not making more specific suggestions because IANA designer and I don't mean
> to bikeshed -- just wanted to call attention to the need.

Actually, I think more specific suggestions are exactly what are needed here. I'm certainly very aware of the need to make the console prettier (see bug 559481, the mockups therein, and the giant list of squashed bugs in its dependency tree).

[1]: http://www.tobypitman.com/wp-content/uploads/2010/06/iphone-checkboxes.png
[2]: http://imgur.com/XQ0MQ.png
Comment 5 Dave Herman [:dherman] 2010-10-01 15:20:54 PDT
> > Colors
> 
> I'm currently thinking that only the categories ought to be color-coded in the
> output messages, and the messages themselves should be black on white, to make
> the colors look less jarring and retro.

Yes, that sounds good.

> > font styling, and more modern fonts
> 
> I erred on the side of caution and just used the XUL monospace font, to
> minimize friction with the rest of the product (and to allow the user to
> customize it in the prefs). If we want to move to Monaco or something else,
> then I'd personally be fine with that, but I'd want the UX team to sign off on
> it, because it'll come at the cost of customization and consistency.

On the Mac, Chrome's use of Menlo looks modern to me, even more modern than Monaco. On Windows, I'm not 100% positive, but I think Lucida Console might be the monospace-du-jour.

> > But the checkboxes might benefit from icons or more
> > fashionably-styled elements (I'm cribbing a bit from Chrome here, perhaps).
> 
> We agonized over this one. Originally, they looked sorta like a platform filter
> bar, but the fundamental problem with that was that only checkbox-like UI
> elements convey the fact that the categories can be toggled on and off
> *individually*. Aza was in favor of little on/off sliders, like the iPhone
> checkboxes [1] except vertical, but Limi didn't like the idea from a platform
> integration perspective. So we compromised on checkboxes, pending a better
> solution.
> 
> At the very least I'd like to have the checkboxes that we have in the Find bar
> on the Mac (notice that they look different, and IMO blend in better with
> toolbars/filter bars).

I agree that might look better. Maybe simpler just to give the checkboxes different background colors, like in the screenshot of WebKit that you attached? Since we have many checkboxes, maybe just two subtly different colors, one for each of the two sets?

> Based on feedback from the UX team, we came to the conclusion that icons are a
> bad idea. The original mockup in bug 559481 had icons for
> Errors/Warnings/Info/Log, but they were nixed, because there's no good way to
> represent "Log" in particular.

Just a thought: something reminiscent of a ship's log? http://www.google.com/images?q=ship's+log

> I think WebKit misuses icons in its developer tools. I can't tell what the
> icons in this screenshot [2] represent.

Fair enough.

> Actually, I think more specific suggestions are exactly what are needed here.
> I'm certainly very aware of the need to make the console prettier (see bug
> 559481, the mockups therein, and the giant list of squashed bugs in its
> dependency tree).

For my money, changing the fonts as above and a little bit of color would go a long way. I like Chrome's color choices, which look something like:

- black for current edited text
- light blue for previously edited text
- dark blue for console output
- red for error messages
- gray for previous prompts
- light blue for current prompt

That's not exactly right, since different output seems to have different colors. Really just a couple such visual distinctions would be helpful.

Also, the use of underline for output looks really bad to my eye.

Dave
Comment 6 Patrick Walton (:pcwalton) 2010-10-01 15:31:04 PDT
(In reply to comment #5)
> On the Mac, Chrome's use of Menlo looks modern to me, even more modern than
> Monaco. On Windows, I'm not 100% positive, but I think Lucida Console might be
> the monospace-du-jour.

In that case, I feel like we should change the default Firefox monospace fonts.

> I agree that might look better. Maybe simpler just to give the checkboxes
> different background colors, like in the screenshot of WebKit that you
> attached? Since we have many checkboxes, maybe just two subtly different
> colors, one for each of the two sets?

Or color the checkboxes identically to the messages.

> Just a thought: something reminiscent of a ship's log?
> http://www.google.com/images?q=ship's+log

Mmm, seems too subtle to me, especially at such small sizes. Apple's Console icon is great, but I don't think it'd work at the small sizes we need.

> Also, the use of underline for output looks really bad to my eye.

Me too. I'd like to change it, but we need some way to indicate that the output is clickable (what you're seeing is actually the link style). I was thinking a light gray dashed bottom border might be less jarring.
Comment 7 David Dahl :ddahl 2010-10-01 16:16:39 PDT
(In reply to comment #6)
> (In reply to comment #5)
> > On the Mac, Chrome's use of Menlo looks modern to me, even more modern than
> > Monaco. On Windows, I'm not 100% positive, but I think Lucida Console might be
> > the monospace-du-jour.
> 
> In that case, I feel like we should change the default Firefox monospace fonts.


see bug 574103
Comment 8 Dave Herman [:dherman] 2010-10-01 23:07:59 PDT
> > On the Mac, Chrome's use of Menlo looks modern to me, even more modern than
> > Monaco. On Windows, I'm not 100% positive, but I think Lucida Console might be
> > the monospace-du-jour.
> 
> In that case, I feel like we should change the default Firefox monospace fonts.

I don't think web content necessarily needs to have the same defaults as browser UI widgets. Being more conservative about changing defaults for web content and more progressive about UI controls seems like a tenable position to me. But changing the default to something more modern throughout sounds reasonable too.

> Me too. I'd like to change it, but we need some way to indicate that the output
> is clickable (what you're seeing is actually the link style). I was thinking a
> light gray dashed bottom border might be less jarring.

Dashes might be too busy. Adding a light underline only on hover is sometimes nice, so that at most one REPL output is underlined at any point. But I still wouldn't be surprised if underlines looked jarring for multi-line values such as functions. Maybe dotted would work. Actually, just the fact of the cursor changing on hover is often enough to make it pretty discoverable that something is a link, though, and heavyweight styling like underlines is a magic feather.

Dave
Comment 9 Kevin Dangoor 2010-10-02 04:59:19 PDT
(In reply to comment #8)
> Dashes might be too busy. Adding a light underline only on hover is sometimes
> nice, so that at most one REPL output is underlined at any point. But I still
> wouldn't be surprised if underlines looked jarring for multi-line values such
> as functions. Maybe dotted would work. Actually, just the fact of the cursor
> changing on hover is often enough to make it pretty discoverable that something
> is a link, though, and heavyweight styling like underlines is a magic feather.

You might be right. We might be able to get away with doing something on hover. Originally, the Network output didn't have underlines (though I think the cursor did change), and it was not discoverable at all. Making the output look link-like on hover (underlining, possible color change) may be enough. That's something to play with.
Comment 10 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-03 20:19:11 PDT
Limi is out of the office for awhile getting married, so I can help out here with the UX side of things.

>> In that case, I feel like we should change the default Firefox monospace fonts.

>see bug 574103

Also some information in bug 468169.


>We might be able to get away with doing something on hover.

I think providing the hyperlink styling on hover (underline, blue) sounds like a reasonable compromise between readability and allowing users to discover that the text is interactive.

Regarding the check boxes, if they were represented as push buttons all we need to do is keep them visually separate from each other and they should convey the capability of multiple selection (as opposed to a literal radio style button where pushing one in causes the others to deactivate).

I agree that text will be more descriptive than icons for a lot of these values, we don't want the user to have to rely on tooltips as they use the interface.  Additionally, we are seeing a strong shift away from toolbar icons in favor of text on Windows (for the same set of reasons).

I'll try to follow up soon with some details on visually styling the toolbar on various platforms.
Comment 11 Rob Campbell [:rc] (:robcee) 2010-10-04 08:17:26 PDT
30 minutes of bikeshedding lost due to an errant misclick on a link. The world will never know the true depths of my bikeshed.

anyway, colors:
Fewer is better.

Maybe a single blob of color *next* to the category.

Maybe a colored background around the category text. See mockup attached.
Comment 12 Rob Campbell [:rc] (:robcee) 2010-10-04 08:19:31 PDT
Created attachment 480623 [details]
Colorized Category Mockup

Showing three possible styles for colorized categories.
Comment 13 Rob Campbell [:rc] (:robcee) 2010-10-04 08:53:29 PDT
I kind of like example 2, "color blob". I think it would look the best of the three in a bunch of console output, give some indication of grouping (they're all going to be lined up vertically) and lets you glance to see if there are a large number of a particular type in a section of console output without having to read everything.
Comment 14 Mihai Sucan [:msucan] 2010-10-04 09:57:48 PDT
Here's a proposal for the Web Console output styling:

    before http://img.i7m.de/show/ydhan.png

and after  http://img.i7m.de/show/pedsr.png


Ideas:

- no need to repeat the "Network" label so many times. GET/POST followed by URL is very much clear for anyone.

I would remove the Exception label as well, but that might be too daring. :)

- no need to repeat timing information more than once per minute. let's keep things visually clean. other consoles from other browsers don't even show any timing info in their output. we are overdoing it with seconds and milliseconds.

- no need to make network messages entirely blue and underlined. let's pick a nicer color and underline only the [http status and timing].

- align jsterm input and output.

- make a clearer distinction between jsterm input and output.

- added a 10 circled ... just like chrome console does. We currently repeat the same message over and over. I suggest we do what the chrome console does: only show how many times the message has been repeated.

Any comments are welcome.
Comment 15 David Dahl :ddahl 2010-10-04 10:36:51 PDT
The other thing to keep in mind here is that we need to open the urls of the js and css parsing errors in a "view source" window - so that is one more use case of styling a clickable log node
Comment 16 Kevin Dangoor 2010-10-04 11:42:41 PDT
I've opened additional bugs (see the depends on) to track the individual pieces of this. Mockups and ideas for the overall view are fine in this bug, but the actual work/patches will end up in the other bugs.
Comment 17 Kevin Dangoor 2010-10-05 12:21:45 PDT
Created attachment 481002 [details]
Mockup that integrates ideas from the separate bugs

We've talked about a bunch of separate things and I wanted to collect them all together for additional feedback. This mockup pulls it together.
Comment 18 Patrick Walton (:pcwalton) 2010-10-05 12:24:17 PDT
(In reply to comment #17)
> Created attachment 481002 [details]
> Mockup that integrates ideas from the separate bugs
> 
> We've talked about a bunch of separate things and I wanted to collect them all
> together for additional feedback. This mockup pulls it together.

Thoughts:

* I'm not sure the check box nature of the filter bar buttons is very discoverable here. It looks like you can select *one* of Net/CSS/JS/Errors/Warnings/Info/Log, not toggle them individually.
* How about different colors for Errors/Warnings/Info/Log?
* "Clear" looks off balance, but I don't know where to put it...
* How about timestamps on the right?
Comment 19 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-05 17:42:16 PDT
Selected items should appear depressed, and since we start with multiple items selected, it should be initially self describing that more than one can be selected at a time.

When the user is visually scanning the contents of the console, are they more likely to be looking for a type of message (Net/CSS/JS) or the level of the message (Error/Warning/Info/Log)?

Color is more effective than shape in that it is a selective visual variable, which means that you can see all of the items in a particular color with a single broad glance, and you don't have to do a linear visual search inspecting each item individually (example here, where it is easier for instance to find all of the green letters than it is to find all of the N's http://people.mozilla.com/~faaborg/files/daf/cogSciColorSelect.png )

However, using color to represent both the type of message and the severity is likely going to end up being too chaotic, so I recommend that we only use color for the type of information the user is more likely going to want to visually filter on, and then a glyph shape for the other type of information.
Comment 20 Patrick Walton (:pcwalton) 2010-10-05 17:45:50 PDT
(In reply to comment #19)
> Selected items should appear depressed, and since we start with multiple items
> selected, it should be initially self describing that more than one can be
> selected at a time.

Good enough for me.

> When the user is visually scanning the contents of the console, are they more
> likely to be looking for a type of message (Net/CSS/JS) or the level of the
> message (Error/Warning/Info/Log)?

Actually, all of those are types. The latter four are user-defined errors that the user can produce from his or her code using the console.foo() API.

> Color is more effective than shape in that it is a selective visual variable,
> which means that you can see all of the items in a particular color with a
> single broad glance, and you don't have to do a linear visual search inspecting
> each item individually (example here, where it is easier for instance to find
> all of the green letters than it is to find all of the N's
> http://people.mozilla.com/~faaborg/files/daf/cogSciColorSelect.png )
> 
> However, using color to represent both the type of message and the severity is
> likely going to end up being too chaotic, so I recommend that we only use color
> for the type of information the user is more likely going to want to visually
> filter on, and then a glyph shape for the other type of information.

They're both the same type of information, really.
Comment 21 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-05 18:02:44 PDT
>Actually, all of those are types. The latter four are user-defined errors that
>the user can produce from his or her code using the console.foo() API.

Ok, makes sense.  In that case I think we should probably give the later 4 the same color (so the higher level set of types is NET/JS/CSS/You), and the sub types of error/warning/info/log can just be represented with a glyph.  I think it is generally more likely that the user is going to start by thinking "I'm looking for one of the things I sent to console.foo" as opposed to starting with "I'm only looking for errors" or "I'm only looking for info."  Does that seem reasonable?
Comment 22 Patrick Walton (:pcwalton) 2010-10-05 18:07:17 PDT
(In reply to comment #21)
> >Actually, all of those are types. The latter four are user-defined errors that
> >the user can produce from his or her code using the console.foo() API.
> 
> Ok, makes sense.  In that case I think we should probably give the later 4 the
> same color (so the higher level set of types is NET/JS/CSS/You), and the sub
> types of error/warning/info/log can just be represented with a glyph.  I think
> it is generally more likely that the user is going to start by thinking "I'm
> looking for one of the things I sent to console.foo" as opposed to starting
> with "I'm only looking for errors" or "I'm only looking for info."  Does that
> seem reasonable?

Sounds good to me. Perhaps we should follow up by removing the "Page" category as well, and joining the "Errors/Warnings/Info/Log" buttons together so that they're visually a single group (cf. Find Previous and Find Next in the Find bar). What do you think?
Comment 23 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-05 18:11:17 PDT
I'm not seeing a page category in this mockup: https://bug599498.bugzilla.mozilla.org/attachment.cgi?id=481002

Is page the combination of Network/CSS/JS?

>and joining the "Errors/Warnings/Info/Log" buttons together so that
>they're visually a single group 

providing some form of separator, either an etched line or some white space between them should be enough to establish two groups.  If we literally join the buttons then it will look like they only support single selection per group.
Comment 24 Patrick Walton (:pcwalton) 2010-10-05 18:14:09 PDT
(In reply to comment #23)
> I'm not seeing a page category in this mockup:
> https://bug599498.bugzilla.mozilla.org/attachment.cgi?id=481002
> 
> Is page the combination of Network/CSS/JS?

Right. The current Web Console looks like this:

Page: [ ] Net [ ] CSS [ ] JS     Console: [ ] Errors [ ] Warnings [ ] Info [ ] Log

> >and joining the "Errors/Warnings/Info/Log" buttons together so that
> >they're visually a single group 
> 
> providing some form of separator, either an etched line or some white space
> between them should be enough to establish two groups.  If we literally join
> the buttons then it will look like they only support single selection per
> group.

As long as the interface doesn't look too busy with so many rounded buttons.
Comment 25 Patrick Walton (:pcwalton) 2010-10-05 18:43:55 PDT
Created attachment 481123 [details]
Screenshot.

Hacking around with CSS for a couple of hours I came up with the attached screenshot. Still need to add the "Close" button back.

Up in the air as to whether to remove "Page:"; I'm slightly in favor to compensate for the addition of "Close".
Comment 26 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-05 18:49:50 PDT
Looks good, I'm working on a similar design for windows and trying out an idea I had for color bars.
Comment 27 Kevin Dangoor 2010-10-05 19:15:51 PDT
(In reply to comment #25)
> Created attachment 481123 [details]
> Screenshot.
> 
> Hacking around with CSS for a couple of hours I came up with the attached
> screenshot. Still need to add the "Close" button back.
> 
> Up in the air as to whether to remove "Page:"; I'm slightly in favor to
> compensate for the addition of "Close".

Nice. I like the look of that, and agree with removing "Page:".
Comment 28 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-05 19:54:39 PDT
Created attachment 481132 [details]
Mockup: color and shape used in a timeline bar

This mockup shows a continuous timeline bar that changes color based on the message types (network, javascript, css, user). If a user created message appears, the bar increases in width to draw attention to the message, and then visually falls back from color to shape to indicate the level (warning, error, info, log).  Assuming that users first filter on message source, this should reduce visual scan time as they attempt to locate a particular message.

Note that the there are very small breaks in the continuous timeline bar when the overall message type changes.
Comment 29 Kevin Dangoor 2010-10-06 06:23:07 PDT
(In reply to comment #18)
> * How about timestamps on the right?

I meant to comment on this one: on the one hand, the timestamps are visually a bit intrusive. On the other, when you want to know the timing of something having those there on the left where they can be seen and copied easily is key. Having an option to toggle the timestamps might be nice but, for now, just de-emphasizing them seems good.
Comment 30 Kevin Dangoor 2010-10-06 06:38:43 PDT
(In reply to comment #28)
> Created attachment 481132 [details]
> Mockup: color and shape used in a timeline bar
> 
> This mockup shows a continuous timeline bar that changes color based on the
> message types (network, javascript, css, user). If a user created message
> appears, the bar increases in width to draw attention to the message, and then
> visually falls back from color to shape to indicate the level (warning, error,
> info, log).  Assuming that users first filter on message source, this should
> reduce visual scan time as they attempt to locate a particular message.
> 
> Note that the there are very small breaks in the continuous timeline bar when
> the overall message type changes.

I can't comment on what it takes to implement this mockup, but it looks good!
Comment 31 Rob Campbell [:rc] (:robcee) 2010-10-06 07:44:46 PDT
Patrick was looking at implementing the color blobs category idea from my mockup above. It should be possible to move the blobs into a color bar which I think makes for a nice, continuous identifier stream.

For the times on the left, I'd kind of like to implement a "zoomable" timeline. As a user hovers over a line, the time at left grows compared to the other times with some nice css-animation. Might be hard to do without having the line-spacing jump around though.

I am liking the look of the proposed toolbars a lot!
Comment 32 Patrick Walton (:pcwalton) 2010-10-06 08:10:35 PDT
Looks good. Shouldn't be hard to implement.

I'm wondering how user-evaluated expressions and their results should look in the timeline. Perhaps a different shade of gray?
Comment 33 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-06 14:32:20 PDT
Created attachment 481347 [details]
Mockup i2

A few small changes:

-Remembered to add clear and filter
-Trying moving the close button to the toolbar, in the entry field it looks like it might clear that text instead of acting on the entire console
-Changed the font to Consolas
-Trying out grey text for messages sent by the developer to the console API, not sure if I like it or not
Comment 34 Patrick Walton (:pcwalton) 2010-10-06 15:28:34 PDT
(In reply to comment #33)
> Created attachment 481347 [details]
> Mockup i2
> 
> A few small changes:
> 
> -Remembered to add clear and filter
> -Trying moving the close button to the toolbar, in the entry field it looks
> like it might clear that text instead of acting on the entire console
> -Changed the font to Consolas
> -Trying out grey text for messages sent by the developer to the console API,
> not sure if I like it or not

A few things:
* How about making the timeline pieces all the same width? Currently the icons stick out a bit.
* The icons (and buttons) for "Warnings" and "Errors" look swapped.
* Correct me if I'm wrong, but what I think you're proposing is for the timeline bar for new messages to be colored and then fade to gray, leaving only the symbol to distinguish them. In that case, and assuming that errors, warnings, and info are red, orange, and blue respectively, we have warnings/CSS as the same color, and errors/JS as the same color.
Comment 35 Patrick Walton (:pcwalton) 2010-10-06 15:29:46 PDT
(In reply to comment #34)
> > -Trying out grey text for messages sent by the developer to the console API,
> > not sure if I like it or not

I think it's a little too subtle. If we use gray, IMO it should be reserved for echoing the user's input back to her.
Comment 36 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-06 16:06:43 PDT
>* How about making the timeline pieces all the same width? Currently the icons
>stick out a bit.

yeah, this was intentional but I agree it isn't working that well. I'll attach another idea.

>* The icons (and buttons) for "Warnings" and "Errors" look swapped.

yeah I accidentally swapped them in the mockup, sorry about that

>* Correct me if I'm wrong, but what I think you're proposing is for the
>timeline bar for new messages to be colored and then fade to gray, leaving only
>the symbol to distinguish them. In that case, and assuming that errors,
>warnings, and info are red, orange, and blue respectively, we have warnings/CSS
>as the same color, and errors/JS as the same color.

Not exactly, I was proposing that messages that originated from the page were given a color (JS=blue, CSS=orange, network=black), and that messages that originated from the developer with a call to the console api would appear in grey and use shape for their distinction.  I'm not more familiar with how this actually works, where unchecking errors actually filters out CSS errors.
Comment 37 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-06 16:29:15 PDT
Created attachment 481368 [details]
Mockup i3

This version draws a clearer distinction between message source and message level.  Color is used to represent source, and shape is used to represent level.  The user has has more direct control over the levels shown for each source.
Comment 38 Patrick Walton (:pcwalton) 2010-10-06 16:32:27 PDT
(In reply to comment #37)
> Created attachment 481368 [details]
> Mockup i3
> 
> This version draws a clearer distinction between message source and message
> level.  Color is used to represent source, and shape is used to represent
> level.  The user has has more direct control over the levels shown for each
> source.

That looks a lot better to me. The only thing is that there's only one level for Network, CSS, and JS. Those three are basically levels unto themselves.

(Also, "Web Developer" is a string, but string freeze shouldn't stop us from doing the right thing from a UX perspective IMO.)
Comment 39 David Dahl :ddahl 2010-10-06 16:39:06 PDT
(In reply to comment #37)
> Created attachment 481368 [details]
> Mockup i3
> 
A very clean look. A menu for CSS and JS with 'Warning' and 'Error' toggle-able will cover the bases. Network is more or less binary (for now)
Comment 40 Patrick Walton (:pcwalton) 2010-10-06 16:43:32 PDT
(In reply to comment #39)
> (In reply to comment #37)
> > Created attachment 481368 [details] [details]
> > Mockup i3
> > 
> A very clean look. A menu for CSS and JS with 'Warning' and 'Error' toggle-able
> will cover the bases. Network is more or less binary (for now)

We only have one level for both CSS and JS though. JS == exceptions, CSS == CSS parser errors.

I don't think we should be giving the impression that there are some CSS warnings to turn on, or some JS warnings to turn on, when we don't support either concept in the console.
Comment 41 Patrick Walton (:pcwalton) 2010-10-06 16:48:39 PDT
Also, at the risk of bikeshedding, how about a more neutral color (purple?) to represent the CSS category? Red/orange/yellow/green all tend to convey severity, I think.
Comment 42 Dave Herman [:dherman] 2010-10-06 16:50:40 PDT
If only JS has multiple levels, the drop-downs may be overkill and make it unnecessarily annoying to toggle multiple levels. Is there a strong rationale against the adjacent buttons? They don't seem like they take up all that much real estate, and they avoid the toggle-vs-dropdown ambiguity on click.

Dave
Comment 43 Dave Herman [:dherman] 2010-10-06 16:51:17 PDT
> If only JS has multiple levels...

Rrrgh, I meant "If only Web Developer has multiple levels".

Dave
Comment 44 David Dahl :ddahl 2010-10-06 17:33:31 PDT
We need to support JS: warn, JS: error, JS: strict

and CSS: warn and error

So there is another couple of bugs to file.
Comment 45 Patrick Walton (:pcwalton) 2010-10-06 17:35:57 PDT
(In reply to comment #44)
> We need to support JS: warn, JS: error, JS: strict
> 
> and CSS: warn and error
> 
> So there is another couple of bugs to file.

Which should be beta7 blockers if they're going to hit Firefox 4, right? These would be new features.

This is the first time I've heard about this.
Comment 46 David Dahl :ddahl 2010-10-06 18:00:43 PDT
(In reply to comment #45)
> (In reply to comment #44)
> > We need to support JS: warn, JS: error, JS: strict
> > 
> > and CSS: warn and error
> > 
> > So there is another couple of bugs to file.
> 
> Which should be beta7 blockers if they're going to hit Firefox 4, right? These
> would be new features.
> 
> This is the first time I've heard about this.

It is something that fell through the cracks that just needs documenting right now. Not a blocker.
Comment 47 Patrick Walton (:pcwalton) 2010-10-06 18:16:57 PDT
So from a quick glance through MXR it looks like the CSS engine only reports warnings, not errors [1], so it doesn't look like we'll need to handle CSS errors. Also, it looks like the "strict" flag on nsIScriptError isn't used anywhere in Mozilla [2], so we don't need to handle strict warnings either.

It would be good to have JS errors and JS warnings though, since it looks like both of these can be emitted in Mozilla. So there *is* one more button to add: "JS Warnings". Not a beta7 blocker though, since we already have the string (phew!) :)

So the UI should look something like:
  [Net]  [CSS]  JS: [Errors|Warnings]  Web Developer: [Errors|Warnings|Info|Log]

Or:
  [Net]  [CSS]  [JS|v]      [Web Developer|v]
                x Errors    x Errors
                x Warnings  x Warnings
                            x Info
                            x Log

I'm actually in favor of the former, but the latter would work too.

[1]: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.cpp#419
[2]: http://mxr.mozilla.org/mozilla-central/search?string=strictFlag&filter=[Ss]trictFlag
Comment 48 Patrick Walton (:pcwalton) 2010-10-06 19:15:58 PDT
Created attachment 481407 [details]
First stab at some icons

I took a quick stab at designing the icons for this one.
Comment 49 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-06 22:41:18 PDT
>If only JS has multiple levels, the drop-downs may be overkill and make it
>unnecessarily annoying to toggle multiple levels. Is there a strong rationale
>against the adjacent buttons?

We can't really use directly adjacent buttons if any of them are using a split button design so that they can contain a drop down with sub-items.  Even if we don't have different levels of messages from some of these sources, this design would allow us to expand to have that functionality later.
Comment 50 Kevin Dangoor 2010-10-07 04:20:54 PDT
One question about the behavior of this design: will clicking, for example, the "Web Developer" button just pull down the menu or will it toggle all Web Developer messages at once?

BTW, bug 601177 highlights the confusing nature of the current design and the desire to be able to filter JS Warnings and Errors separately.

By the way, we can also identify Network errors and info by looking at the HTTP status (4xx or 5xx is an error)
Comment 51 Mike Beltzner [:beltzner, not reading bugmail] 2010-10-07 07:22:00 PDT
Stephen should take a look at this as well, just to make sure it passes his muster. The button styles here look new-ish, but overall it's a huge improvement; thanks, Alex!
Comment 52 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-08 14:12:23 PDT
>Stephen should take a look at this as well

Yeah we should have Stephen create final icons.  Stephen should also choose colors for JS and CSS, I just picked some at random for showing contrast but I agree that they shouldn't have any semantic meaning (avoiding red, green, orange, yellow, etc.)  Perhaps blue and purple or something.

For the icons I recommend that we only display icons for warning (triangle) and error (x) states.  If every level were to get an icon, the icons wouldn't provide any more relative information than the colored timeline bar itself.  By making that column sparse it becomes easier to visually target a particular level of message, by focusing on the presence or absence of an icon.
Comment 53 Patrick Walton (:pcwalton) 2010-10-08 14:19:32 PDT
(In reply to comment #52)
> >Stephen should take a look at this as well
> 
> Yeah we should have Stephen create final icons.  Stephen should also choose
> colors for JS and CSS, I just picked some at random for showing contrast but I
> agree that they shouldn't have any semantic meaning (avoiding red, green,
> orange, yellow, etc.)  Perhaps blue and purple or something.
> 
> For the icons I recommend that we only display icons for warning (triangle) and
> error (x) states.  If every level were to get an icon, the icons wouldn't
> provide any more relative information than the colored timeline bar itself.  By
> making that column sparse it becomes easier to visually target a particular
> level of message, by focusing on the presence or absence of an icon.

I think giving "info" an icon would be good, actually; "console.info()" is so seldom used that it's worth giving it an icon to tell it apart.
Comment 54 Alex Faaborg [:faaborg] (Firefox UX) 2010-10-08 14:22:03 PDT
Makes sense, we should try to distribute the icons across the message levels so there the mixture provides value.  For instance, if every nearly single CSS error is a warning, then we shouldn't use the warning icons for those.
Comment 55 Eric Shepherd [:sheppy] 2010-10-22 09:11:00 PDT
This will impact screenshots on devmo, so tagging as doc needed so I can track it.
Comment 56 Johnathan Nightingale [:johnath] 2010-11-01 12:04:56 PDT
Early is better for this one. Like, is beta8 possible?

The bar here is that we need to be at least as attractive as Chrome's console. Do you both feel these mocks satisfy that bar, Alex/Kevin?
Comment 57 Alex Faaborg [:faaborg] (Firefox UX) 2010-11-01 17:19:57 PDT
>The bar here is that we need to be at least as attractive as Chrome's console.
>Do you both feel these mocks satisfy that bar, Alex/Kevin?

Chrome's console brings OS X Aqua UI to Windows, so that isn't necessarily the highest polish bar for us to clear.  We might want to use some different color values for the message channels, otherwise we're just re-using our toolbar graphics here.
Comment 58 Kevin Dangoor 2010-11-02 09:51:35 PDT
I'll note that the most complete current screenshot I've seen is this one:

https://bugzilla.mozilla.org/attachment.cgi?id=487101

which includes the work of restyling the output area.
Comment 59 Patrick Walton (:pcwalton) 2010-11-18 16:38:54 PST
Just a note to the drivers that this may not need blocking2.0:betaN+ anymore, as it's become a rather large metabug. The two big components of this that need to land to ship Firefox 4 (IMO) are bug 601667 (toolbar styling) and bug 605621 (output area styling), and both are marked blocking2.0+.
Comment 60 Shawn Wilsher :sdwilsh 2010-12-15 10:09:52 PST
We don't block on meta bugs.  This appears to be handled in bug 605621, which I've just marked as blocking beta N.
Comment 61 Kevin Dangoor 2012-01-13 07:59:27 PST
This bug was for finishing up the initial styling of the console (in firefox 4). It's a meta bug and all of its dependencies are done.

Note You need to log in before you can comment on or make changes to this bug.