Firefox; FUEL but no FHIG! 3
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.
I am pleased to bring to Minimap the power and simplicity of Fire Eagle. Due to hit the addons.mozilla.org site soon, now you can access and update your Fire Eagle location right from within your favorite mapping addon.