Closed Bug 599498 Opened 14 years ago Closed 12 years ago

Web Console CSS aesthetics

Categories

(DevTools :: General, defect)

defect
Not set
normal

Tracking

(blocking2.0 -)

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: dherman, Unassigned)

References

Details

(Keywords: dev-doc-complete, meta, polish)

Attachments

(7 files)

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
Version: 3.6 Branch → Trunk
cc'ing limi here for feedback.
Blocks: devtools4b8
Keywords: polish
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?
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.
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
> > 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
(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.
(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
> > 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
(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.
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.
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.
Showing three possible styles for colorized categories.
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.
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.
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
Depends on: 601667
Depends on: 574103
Depends on: 601671
Depends on: 601672
Depends on: 601675
Depends on: 601183
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.
Depends on: 601681
No longer depends on: 601183, 601675, 601681
OS: Mac OS X → All
Hardware: x86 → All
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.
(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?
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.
(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.
>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?
(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?
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.
(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.
Attached image 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".
Looks good, I'm working on a similar design for windows and trying out an idea I had for color bars.
(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:".
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.
(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.
(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!
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!
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?
Attached image 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
(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.
(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.
>* 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.
Attached image 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.
(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.)
(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)
(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.
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.
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
> If only JS has multiple levels...

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

Dave
We need to support JS: warn, JS: error, JS: strict

and CSS: warn and error

So there is another couple of bugs to file.
(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.
(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.
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
I took a quick stab at designing the icons for this one.
>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.
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)
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!
>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.
(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.
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.
blocking2.0: --- → ?
Blocks: 604618
Depends on: 605621
This will impact screenshots on devmo, so tagging as doc needed so I can track it.
Keywords: dev-doc-needed
Blocks: 608135
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?
blocking2.0: ? → betaN+
>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.
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.
Depends on: 611440
Depends on: 611851
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+.
Assignee: nobody → pwalton
Status: NEW → ASSIGNED
No longer blocks: 604618
We don't block on meta bugs.  This appears to be handled in bug 605621, which I've just marked as blocking beta N.
blocking2.0: betaN+ → -
Assignee: pwalton → nobody
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Keywords: meta
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: