Curtis Bartley’s Blog

Note: Since I was getting lots of comment spam I've closed comments here.  If you have any comments or suggestions, feel free to file them on the Firebug Issues page or drop us a line in the Firebug discussion group in the Tabs on Top thread.

The Firebug tabs-on-top UI refactoring has finally landed in Firebug 1.4 alpha.  You can download it as firebug-1.4.0a17.xpi (or later) from http://getfirebug.com/releases/firebug/1.4.  This change is pretty close to the one I described and prototyped in February (see Improving the Firebug UI) and which in turn follows my original proposal from late last year (see Firebug UI: Tabs on the Top).  These blog posts describe the reasoning behind the change so I won't rehash it in full.

The old layout had a toolbar at the top of the Firebug UI, and a tabbed "panel bar" below it.  Sometimes a tabbed "side panel bar" would show up to the right of the main panel bar.  This change essentially takes the toolbar and the side panel bar (when it appears) and puts them inside the active panel.  This puts the panel tabs at the top of the Firebug UI (hence the name "tabs-on-top") and panel specific controls underneath.  Several controls that are not panel-specific (the main Firebug menu, the search box, and the detach window and close window buttons) have been moved to the tab strip, so they are effectively in the same location as before the change.  The idea is that UI elements that are specific to a panel look like they are inside that panel.  This description probably makes the change sound more complicated that it really is.  A screenshot will better communicate how it looks.

Firebug UI with the tabs-on-top layout.  The Net panel is selected.

Even the screenshot is a poor substitute for actually downloading the extension and trying it out, so let me encourage you to do that.

There are still some outstanding issues, before this change can really be called complete.

• The location of the main panel Options menu is less than ideal.  I think the right thing to do here is to merge the panel options with the menus on the panel tabs, but I haven't had time to prototype it yet.
• The Inspect button really belongs on the top toolbar.  I've held off on relocating it because I think it will look too much like the label of a panel tab.  There are a couple of options here.  We could change the styling to make it look more like a button.  We could replace the label with an icon, or we could change the tab styling so even unselected tabs show a tab outline.  Probably any of these solutions would work, we just need to figure out what the best one is.
• The position of the debugger buttons can jump drastically under some conditions.  Normally the debugger buttons only appear when the Script panel is active.  However, if JavaScript execution is paused, the debugger buttons always appear, regardless of the tab.  With the new layout this means their position can jump if you switch to another tab which doesn't have a side panel bar.  I think it might make sense to move them to the left side of the toolbar, which will eliminate this problem.  This seems like it might be a fairly controversial change, so we really need to explore it separately.
  

Refactoring the Firebug UI

My main project for the last few weeks has been doing some Firebug UI work that I’ve been thinking about for a while.  Since I’ve just been moving UI elements around (to make the layout more logical), I’ve been referring to this effort as “UI refactoring”.

So here’s the deal.  It’s not enough that I think this redesign is an improvement, or even that the Firebug working group has been supportive.  We need to know what you, the Firebug user, think.

Before I get started, I should let you know that I’ve been working on the Firebug 1.4 branch, which is still undergoing active development.  The changes I’m proposing are fairly simple in the sense that they are really only a reorganization of existing UI elements.  However, if you have not yet seen 1.4, be aware that there are other significant UI changes, notably John J. Barton’s work on the activation UI, kpdecker’s multi-file search capability, and Hans Hillen’s work on accessibility.

What’s wrong with the current Firebug UI?

The basic UI layout for Firebug today consists of a toolbar across the top, a main “panel bar” underneath, and an optional “side panel bar” to the right.  Each panel bar consists of a set of tabbed panels, only one of which is visible at a time.

 

This is a simple design, and seems pretty logical.  There’s a problem, however.  The contents of the toolbar can change substantially depending on which panel is selected in the main panel bar.  For some panels this is maybe not such a big deal.  At the other extreme, consider the Net panel.  When the Net Panel is selected, it adds seven buttons to the toolbar which control what information is displayed inside the Net panel’s content area.

For me, using these buttons, with this placement, feels even weirder than the screenshot looks.  They would feel much more natural if they were adjacent to the content area that they affect.

Furthermore, the side panel bar is only visible when either the HTML tab or the Script tab is selected.  And, of course, it’s a different set of panels that show up in the side panel bar depending on whether it’s the HTML panel, or the Script panel.  Logically, you could think of the HTML panel as having a smaller panel bar embedded inside it which in turn contains several sub-panels specific to the HTML view.  You can think of the Script panel similarly.  The other panels simply don’t have any sub-panels they need to display.

Basically, the problem is that clicking a tab changes not only the main panel below the tab strip, but also the toolbar above it, and oftentimes the side panel bar to the right as well.  You click on a tab, and the whole UI mutates around it.  Even though the current UI layout makes superficial sense, I contend that the toolbar – or at least a big chunk of it – belongs inside the main panel bar.  I also think you can make an argument that the side panel bar, when it appears, should look like it’s inside the currently selected panel.

Another way to think of it: The tabs – Console, HTML, CSS, Script, DOM, and Net – should appear at the top of the Firebug UI where the panel-specific toolbar elements appear now.  Since these main panels are the major organizing principle of the Firebug UI, it makes sense that they should be more prominent.

I’m clearly not the first person to come to this conclusion since Firebug Issue 222 makes a similar argument.

This is the layout I have working now.  I’ve been referring to this as the “tabs-on-top” layout.

In this design, not all of the toolbar has been relocated.  The main Firebug menu that hangs off the Firebug button is in the top-left just as it always has, and the search elements and Firebug window control elements are still at the top right.  Although the side panel bar doesn’t really appear to be inside the main panel, it does at least appear subservient. 

There are some smaller changes as well.  Notably the tabs are now “stand-up” style –

, rather than “hanging” style – .

The handling of the main panel Options button and the Inspect button still leave something to be desired.  Nevertheless, I think this is a more logical layout, although you probably have to use it to really appreciate the improvement.

What now?

As I mentioned above, you really need to try the out the new layout to see if it’s really does work better.  To that end, I’ve attached an experimental version of the Firebug extension to the post, so you can download it and try it out.  I’ve tested it fairly thoroughly on Windows and to a lesser extent on Mac and Linux.  Also, since it’s built on top of the 1.4 branch, which is still under active development, you probably won’t want to leave it installed for too long.  However, it should be good enough for you to take it for a test drive.

 

In a previous post I explored the idea of moving Firebug's main panel bar tabs to the bottom of the UI.  One of my teammates pointed out that a common scenario in Firebug is to select a tab and then immediately click in the toolbar to make a panel specific adjustment.  For example, it's common to click on the Script tab and then to click the files drop down to select a specific JavaScript file.  With the current arrangement, the toolbar and the panel tabs are close together regardless of Firebug's window size.  If Firebug's window is opened to a large size, for example showing 40 or 50 lines of source code, then this two step usage scenario is going to be rather inconvenient for the user.

If this is a common scenario (and I suspect that it is), then this argues for a tabs-on-top design, which is what I'm going to look at in this post. 

There's a link to the prototype at the end of the post if you want to try it out.  In the meantime, here's a screenshot.


A screenshot of the Firebug UI with panel tabs at the top.  The Script panel is selected.

One of my goals with the previous tabs-on-the-bottom design was to reduce the "busyness" of having the toolbar and main panel tabs right next to each other.  This design doesn't do much to address the busyness angle, but it still seems cleaner than the current Firebug layout.  For example, in this design the tab strip for the main panel bar is at the top of Firebug's UI, and all it has on it is tabs, and the tabs are largely static -- the selected tab can change, but that's it.  It's a much simpler UI element than the toolbar.

The toolbar is placed such that it appears to be inside the currently selected panel, which seems logical since so many of the toolbar controls are dependent on which panel that is.  In this particular variation, the toolbar extends all the way across the window, so I call it the "long toolbar" version.  One negative of this design is that the side panel looses a line of vertical real estate.

There's another advantage of having the tabs on top.  In Firebug, the major functional units correspond to individual panels in the main panel bar.  In the tabs-on-top layout, the tabs for these panels is the most obvious thing you see.  I think that's probably a good thing.


Moving the Search Box


A mockup with the Search Box and window controls moved from the toolbar to the tab strip.

One possible variation on the tabs-on-top layout is to move the Search Box and adjacent window buttons from the toolbar to the right end of the tab strip.  Since the Search Box and window buttons don't change with the active panel, it makes sense to pull them "out" of the panel.  This clutters up the tab strip a little bit, but as long as there's some reasonable amount of blank space between the rightmost tab and the search box, it doesn't really seem to hurt that much.  One advantage is that it substantially reduces the clutter on the toolbar and another is that it frees up a lot of space for the "object path", which, unfortunately, you can't see in this screenshot.  (In the Script panel the object path is the call stack in horizontal layout.  In the HTML panel, the object path is the HTML containment hierarchy.)


The short toolbar version.



With the Search Box and window controls on the tab strip, we can also do a "short toolbar" layout as mentioned above.  In this layout, the toolbar is only as long as the left sub-panel.  The side panel bar (containing the Watch, Stack, and Breakpoints panels) now tops out just below the tab strip, reclaiming that line of vertical real estate that we'd lost in the first two layouts.  Of course the short toolbar reduces area available to the object path by quite a bit.

Conclusion

I think putting the tabs on top and above the toolbar makes for a much nicer UI.  Although I think my earlier tabs-on-the-bottom UI offered some advantage by completely separating the toolbar and the tab strip, I think the tabs-on-top design offers some clear advantages.

• The tabs are the major organizational principle in the Firebug UI and putting them on top makes them stand out as the most prominent UI element. 
  
• The toolbar appears like it belongs to the current tab page, almost like you're tabbing between different toolbars as well as different panels.  This seems logical since the toolbar changes with the panel anyway (The ever present Firebug-icon-menu and Inspect button do muddy the water a bit, though).
• Selecting a tab and then selecting something on the toolbar (e.g. selecting the Script tab and then selecting a JavaScript file from the drop down) is still convenient.  It feels a little more natural to select something on the tab strip and then move down one line to carry out the next step.  In the current UI with the toolbar on top, the flow is up rather than down.

I haven't tested it in a prototype yet, but after looking at the mockups, I think moving the search box and window controls to the right end of the tab strip is a good idea.  I'm less certain about whether the long toolbar or the short toolbar is the best approach, although I feel like the short toolbar wins on simple aesthetics.

Try it out
A link to the Firebug "tabs-on-top" prototype extension is at the bottom of this post.  The standard disclaimer applies.  It's prototype code built on 1.3 pre-release code, so although it's OK to play around with, you probably don't want to leave it installed.

One of my biggest complaints about Firebug is the way its tabbed UI works.  Firebug organizes its features into six major functional units: Console, HTML, CSS, Script, DOM, and Net.  Each unit gets a "panel" and these panels are organized in a tabbed display called a "panel bar".  There's also a smaller panel bar that sometimes appears to the right of the main panel bar depending on which primary panel is selected.  The main Firebug toolbar appears just above the panel bars.  Below is a screenshot from Firebug and an annotated version of the same screenshot.



A screenshot from Firebug 1.2.1.  The Script panel is currently selected.




The same screenshot as above with the major UI components labeled.

One of the things I don't like about the current UI is just how busy it looks.  The toolbar is already pretty complex, and it's stacked right on top of the tabs for the two panel bars.  That's not the biggest problem however.  Take a look at this next screenshot.



A screenshot from Firebug 1.2.1.  The HTML panel is currently selected.

In this screenshot, the HTML panel has been selected.  Look carefully at the toolbar, and compare it with the first screenshot above where the Script panel was selected.  The Inspect button and the find textbox are the same, but everything in between has changed.  Now look at the side panel bar.  That's right, it's completely different.  Changing panels in the main panel bar essentially causes the whole Firebug UI to change, not just the main panel.

I think you can make a case that the toolbar and the side panel bar belong inside the current panel since they are so dependent on which panel that is.  The argument is stronger for the side panel bar since it is completely dependent on the main panel bar.  The argument is weaker for the toolbar since the toolbar doesn't completely change, but I think you can still make a case there.

Tabs on the bottom

So I have two problems that I'd like to solve.  I'd like to make the user interface less "busy", especially with regard to the toolbar.  I'd also like to promote the illusion that both the toolbar and the side panel bar are inside the currently selected main panel, since both those UI elements are so dependent on which panel that is.

I've built an experimental variant of Firebug to test out an alternative UI that I think addresses these issues.

To address the busyness issue I've moved the main panel tabs from the top of the panel bar to the bottom.  This also helps differentiate the main panel bar from the side panel bar, where I've retained the tabs on the top.  I think this helps a little bit with the illusion that the side panel bar is actually inside the main panel since the two panel bars now look different.  Then I've tweaked the UI so that the main panel bar tabs appear to extend all the way across the window and all the way around both panels and the toolbar.  This effect is perhaps more subtle than I'd like, but it still feels like an improvement.

Below is a screenshot of this alternative UI.



A screenshot from an experimental version of Firebug with the main panel bar tabs on the bottom.

It might also be useful to evaluate the design where the main panel bar tabs are moved above the toolbar.  This won't do anything for the busyness issue but it might make a stronger statement that the toolbar is dependent upon the currently selected panel.  (Firebug issue 222 suggests making exactly this change.)

Take it for a spin
I've attached the XPI file for my experimental Firebug build so you can try it out yourself.  That will give you a much better feel for the proposed change than just looking at static screenshots.  The experimental build is probably a little bit buggy, both due to my changes and the fact that it's built on Firebug 1.3 pre-release code.  It should be OK to take for a test-drive, but you probably don't want to leave it installed for a prolonged period of time.

Firebug crams a lot of disparate UI into a relatively small amount of screen real estate, and consequently it can't help but be noisy and confusing.  However, I think there's some obvious areas for improvement, and I wanted to document some of the problems I've been noticing as I go along, and maybe propose some solutions while I'm at it.

First up: Is it a button or is it a menu?

One of the most notable aspects of the Firebug UI is that it wants to stick menus all over the place, including on some of the tabs.  Firebug is not very consistent about how it does this, and so the user is left wondering: Is it a menu, or just a button?  For example, in the screenshot below, you can see two Firebug bug icons -- one on the right end of the Firefox status bar at the bottom of the window and another one (slightly larger but otherwise identical) as the first control on the Firebug toolbar.  The small icon behaves as a simple button -- it toggles Firebug on and off.  The larger icon actually triggers a menu.

Next on the toolbar is the Inspect button, which always appears in the location, regardless of the current tab.  The Inspect button triggers a mode where you can click on elements in an HTML page and have them show up in Firebug.  Continuing to the right, the "all" button actually controls a menu, and there's a helpful arrow next to it to indicate that there's a menu there.  Next is the button that's labeled "slideshow.html".  It's also a menu, only this time there's no helpful arrow to indicate that.

One simple improvement that can be made here is to consistently use the arrow next to all menu items.  I'd also consider replacing the Inspect label with an icon, and the Firebug icon with just "Firebug", so the button is an icon, and the menu has a label.  This sounds more natural to me, although in terms of actual usability, I don't know if it would make a big difference.

This is just scratching the surface, but it seemed like a good place to start.