Improving the Firebug UI

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.

 

Upvote Upvoted 0
18 responses
Sounds more sensible to me, at least. I'll give it a try.
— Simon
Ok, I don't like the positioning of the Options menu. 'Inspect' is (for me, at least) the single most heavily used feature in Firebug, and I think the button for it should be left-most.

In contrast, 'Options' is something I hardly ever use, and would prefer to see it put somewhere out of the way of the primary tools - right now, it's being given too much prominence.

— Simon
@Simon:

I agree about the Options menu. In fact, we've already got an "Options" problem in the UI (unrelated to my changes): We've got three different Options menu in the UI visible at the same time.

We've discussed putting the panel options on the drop-down menus that are on the panel tabs themselves. Those menus are used for the activation UI right now (enable, disable, etc.) and John J. Barton's still working on the new Activation UI, so it seemed prudent to wait before trying out that idea.

I definitely think that the Inspect button should be the first one in the toolbar. It might make sense to pull it up to the top bar next the the Firebug menu/icon again. For that to work well, I think we might want an icon for it rather than a label, something like a flashlight icon maybe. Sticking a labeled button next to the tab labels seems like it would be confusing.

— Curtis Bartley
Playing with it, the Inspect button really is global, isn't it - no matter what tab you're on, using it will switch you to the HTML tab. So yeah, the button itself probably should be global - place it next to the tabs, rather than on them.

Not sure replacing the label with an icon is right though. You're right that it needs to look visually distinct from the tabs, but making it into an icon will also make it smaller, and I don't think that's appropriate for what I consider to be the most heavily used button in all of Firebug. Maybe a button with both icon *and* text?

As for a labeled button next to the tabs being confusing, I think that's partly due to the lack of any visual cues on both buttons and tabs. The currently selected tab has usual tab decorations around it, but buttons and other tabs are just plain text until you hover over them. Menus too, actually - Options looks somewhat like Inspect and Clear, but shows up as a link when you hover it.

— Simon
@simon: All good feedback. Thanks!
— Curtis Bartley
I really love this "UI refactoring" idea as I share your point of view about the current UI being... confusing (even if Firebug is the one of the greatest thing available to a web developer ever). And I tend to agree with Simon about the "Inspect" being the most heavily used feature in Firebug : it should seat next to the Firebug Icon. Maybe a simple vertical separator will do the trick to differentiate the text button with the tabs ?

Also I like the current "Options" button to be at the far right of each section, as I usually never use them. Maybe less confusion will come from making it a small icon (a little gear as anybody will understand this icon).

Anyway, thanks for the very nice work. I'm looking forward to seeing your achievements in a future version of Firebug.

— John Riche
I posted this comment to a Firebug blog post, but it didn't appear. And I think its relevant for the UI design, so I'll repost:

A little, perhaps offtopic, proposal for changing the panel enable/disable user interface. Personally, I think the users problem is in the difference between a global enable/disable, and a per-site enable/disable. I do not know if there are two 'camps', one that always wants Firebug turned on or off, and another that wants the per-site settings. But it is pointed out that performance is unacceptable when turning Firebug panels on permanently.

So, my proposal is: remove the global enable/disable switch. This would clear up the dropdown in Firebugs tabs - you might get away with removing the dropdown fully, and replace it with a permanent 'enabled for this site' checkbox which is much more discoverable. Of, with this new design, under the Options menu.

This would also clean the site list: it would become a whitelist, no need to add disabled sites when there's no global enable.

I know this is a change that will remove behavior some people might rely on, but I believe its for the better. Love to hear comments!

— Albert
I think the re-factoring is a grand idea, and have had the desire to do it, but not the time.

The option button; since everything has options, remove them all except one. How hard is it to have one option button on the toolbar with the global options listed, and below those would be listed the context options. That would remove all the other options buttons from the UI, and centralize them. It's a bit more work to do, but a step down the proper path, yes?

Maybe I'm missing something but the inspect button, as useful as it is, logically belongs under the HTML tab, if there is that much demand for faster access, a simple FB add-on should be able to duplicate it as a short cut on the tool bar.

Just my opinion, for what it's worth.

— John Stephens
per Albert, I for one see no problem with the current enable/disable setup, there is a blacklist, a whitelist, and a global setting for all others. That seems as broad as one can get and still maintain a simple system. It allows anyone to use FB always on, or always off and still get certain sites to respond to it.
— John Stephens
@John
You're right that the Inspect button is associated with the HTML tab. But if others consider it such a fundamental feature as I do, requiring a separately installed add-on to put the button where we want it doesn't seem sensible. For me, that button is *THE* feature of Firebug - a way of quickly interrogating the properties of any element on the page. Not having it instantly available from anywhere in the UI would be a serious usability regression for me...
— Simon
@Simon:

There is always the "Inspect Element" menu item available from the context menu. That said, I think that you're right that the Inspect button *is* Firebug in some sense. I certainly use it in preference to the context menu.

— Curtis Bartley
Actually, I'd never noticed the context-menu entry until you pointed it out...
— Simon
Yes, having 2 interface elements saying "options" is rather dodgy. Not sure about a solution though.
— Marc Diethelm
Per the location of the "Inspect" button position: I'm also a heavy user of this button, but I do like the fact that it is positioned not at the edge, but rather closer to the middle, as I think that things at the middle are ,on average, closer to the position of the cursor, and therefore it takes less time to find and click on that button. And yes, making it always available seems like an important thing to keep.
Another suggestion I can think of, is of the files / scripts list in the "Script" tab - if there is a way not to present it using a menu but rather using some sort of a list, and make this list searchable could be a great help.
Overall, I really like the new UI refactoring, and I think that it should be used in FB
— Yoav Rubin
(sorry if this is a wee bit off topic) as another inspect devotee.. my dream firebug UI improvement would be the ability to inspect with a simple set of modifier key - eg: clicking on an item with control-shift, (or whatever) could in one step activate firebug for the page in question, and inspect that element. I already use the context menu, but this would be way faster and easier for something I do so often. Thanks for all the work anyway.
— Tim
Theoretically it makes sense but there's three problems:

1) Options is now given more prominence than Inspect.

2) Under the HTML tab there is less room on the right for deeper node 'tree' link lists

3) Your prototype (according to screenshots) doesn't even implement this new idea consistently since the tabs in the Side Panel Bar are still where the other tabs were - second row.

To solve these issues:

1) Put options back where it is now, or consolidate options into the 'bug' menu.

2) introduce a third 'toolbar' for the node 'tree' link lists and place it at the bottom of the HTML tab. This would mirror how Dreamweaver does this so would be quite familiar for a large chunk of existing users.

3) integrate the Side Bar Panel (which only really exists under HTML tab anyway) into the HTML tab. Give the tabs the old upside style and put them on the RHS of the second HTML toolbar (the one with the Inspect and Edit buttons. This would conflct with the suggested reverting of the HTML tab's Options link unless as also suggested that link was consolidated with the 'bug' menu or the Side Bar Panel's own Options link.

— pd
this is for pokemonindigo
— faiz
I posted a feature request for firebug here :
http://groups.google.com/group/firebug/browse_thread/thread/6f1c82a78fd56246/fe3c267a3a545f66#fe3c267a3a545f66

It's about adding a new bar that would let people save states of their work. Basically, this would help going back to a previous state of their code.

Because after modifying 20 lines of code, in different documents (css, html, js, ...) you're a click away to close your work and lose everything..

The user would also be able to affect a state to a new tab, so there would be a tab per state if the user wants to.

I added a mockup-screenshot in the above link if you're interested..

What do you think of this idea ?
I do hope firebug developers will add it in a future version. I am sure this would help editing code.

— xan