Firefox; FUEL but no FHIG!
Mozilla support developers well, with MDC an excellent resource. A giant step forward was taken with FUEL (Firefox User Extension Library) in Firefox 3, but for me the serious missing piece in the puzzle; where is the FHIG (Firefox Human Interface Guidelines)?
Mozilla have always been protective of their brand (perhaps overly), and went to great lengths to produce platform specific versions of Firefox 3 that differed, whilst retaining an overiding Firefox look. Conversely however, they let developers loose on the product with very little in the way of user interface guidelines.
As a developer, I not only want code snippets to get functionality working, but also guidance on how best to fit my addon into the parent browser.
As an example, lets take a look at the XUL <panel> element. With vast improvements to this element, I see it’s use massively increasing in extensions (and indeed we can see it used a lot in Firefox 3 such as the bookmark dialog and securty info dialog). Up until now, people used <window> or <dialog> which, by their very nature, retained the look of the operating system windowing. However, the power (but arguably weakness) of the <panel> is that it allows developers to pretty much create any style ‘window’ they like.
The image below shows a screenshot of the bookmarks dialog in Mac OSX
Now lets compare it to a screenshot of the ctrl-tab extension. Not much different, both are opaque greys, albeit slightly different shades. My Minimap Preview Panel uses the same colours and opacity as the bookmarks, so a little bit of consistency is possible.
Lets look at Ubiquity.
Again, an opque grey, so all is ok right? Well not so fast. Is it ok to call them consistent just because we have slightly transparent grey dialogs? To me the devil is in the detail: different shades of grey, different opacity, different border radii, and in the case of Ubiquity no border radius at all.
Now lets throw a real spanner in the works: look at the Linux or Windows bookmark dialog.
Hmm, it’s not grey, but a colour designed to match the operating system. Now the differing panels of minimap/ctrl-tab/ubiquity start to stand out.
I’ll not go into showing examples too much more, but you get the picture. This discussion can also be applied to the colour of textboxes, of the drop down arrows used in the bookmarks dialog etc.
Perhaps a FHIG could have guidance on the use of <panel>, with a supplied class from the global skin people are recommended to use. For example <panel class=”dialog” /> will produce a panel that matches that used by the bookmarks dialog, and developers can rest easy that their extension is going to match the look and feel of the parent browser no matter what operating system it resides on.
In addition, if developers really want a grey <panel>, then supply us with a default recommendation such as #333, opacity 0.8 so that extensions can begin to look and feel part of the same ecosystem, without us having to go crawling through the source code or other extension code to see what is already being used.
I for one am not saying I have achieved some state of zen with Minimap, far from it (as anyone looking at it and my underlying code will agree!), it would just make my life a hell of a lot easier in the long run if Mozilla supplemented FUEL with FHIG.
One of the best things about Firefox extensions is the wide range of creativity and innovation we see in how people develop various interactions and appearances. This means that sometimes extensions are designed better than traditional human interface guidelines, and sometimes they are a lot worse
Despite the name Human Interface _Guidelines_ people often interrupt HIGs as rules that must be followed. I’m a little reluctant to release a HIG for people developing on top of Firefox since I am scared it might limit people’s creativity. However, I think if we framed the document as “some interactions that we have found tend to work pretty well,” that might help us raise the bar without forcing everyone to the same level of mediocrity.
In terms of visual appearance, since control-tab and Ubiquity are still both experimental interfaces, I’m not as concerned that they don’t currently perfectly match the OS. However, if they end up landing in Firefox we will want to make sure they visually integrate as closely as possible (Boriss has some nice OS X control tab mockups here: http://people.mozilla.com/~jboriss/blog/with_quick_large.png )
We also need to make sure that it is as easy as possible for people building interfaces on top of Firefox to leverage these visual styles, if they want to. In the case of command-tab (and possibly other keyboard based UI’s in the future like ubiquity), we are using the “KUI-panel” class.
“To me the devil is in the detail: different shades of grey, different opacity, different border radii, and in the case of Ubiquity no border radius at all.”
I agree completely; the standardization of properties throughout the browser would be very helpful.
Also, be aware that the final Ubiquity UI is likely to look completely different. We’re mostly focusing on the technology and concepts at this stage, so the UI hasn’t gotten much attention yet.