Firefox Australis: One browser interface to rule them all

In these screenshots, the borders of inactive tabs disappear. This doesn't seem like a good idea. Wouldn't it be hard for users to identify them as tabs?

DanBC• 14 years ago

I'd really like tabs to auto-hide. I'd really like a bunch of the UI to be auto-hiding.

Just hiding the tab borders does seem sub-optimal.

kibwen2• 14 years ago

Note that these demos are early mockups from September 2011. Some details of the UI are bound to have changed since then.

sho_hn7• 14 years ago

Are you sure? I do remember a mockup from that timeframe that showed all platforms on one page, and was static rather than interactive. Given the greater sophistication in these and the fact that they're still linked from their wiki (https://wiki.mozilla.org/Firefox/Features/Theme_Refinement_a...) I had assumed these to be recent.

Edit: The older set I was referring to: http://people.mozilla.com/~shorlander/ux-presentation/ux-pre...

Edit2: The OP links were added to that wiki page in an early March 2012 revision.

UIZealot• 14 years ago

Thank you for the links, as I wasn't going to visit the brain dead extremetech site on my iPad.

OS X mockup: the window control traffic lights don't line up vertically with the toolbar/tab bar icons, looks jarring. The close tab button is still on the right, tab titles are still left-aligned instead of centered, not impressed.

Firefox team: stop trying to ape the Chrome UI and think for yourselves for once, put the tab bar on the left or right side.

acabal• 14 years ago

I actually prefer when apps respect the UI guidelines of the OS they're running on. I understand the desire for one unified interface, but there's also much to be said for intra-OS UI consistency. FF has done really well in the past with that, but I guess they're jumping on the Chrome bandwagon.

sho_hn7• 14 years ago

Speaking as a Linux user, I don't think they have. Their use of and integration with the UI primitives of the GTK+ toolkit has been, well, primitive and unsatisfying, and Qt support is virtually non-existant (there was some porting done, but not enough to be anywhere near usable). However, even on OS X and Windows they don't use, say, native tab buttons. In fact, looking at the live demos I linked earlier, I don't think it's any more or less differenciated from each system's native style than the current design, purely in terms of for what elements it calls into that style for and for what elements it doesn't.

As for Chrome, the sin Chrome commits on Linux in particular is that it defaults to something called client-side window decorations, that is it tells the window manager not to display the decorations it would normally put around the client area and then proceeds to draw its own inside this client area, which behave potentially vastly differently from whatever the user has configured for his native system decorations. This is less of a sin on Windows because client-side decorations are in some sense almost the norm there (and in the technical sense they in fact are). The new Firefox design still appears to avoid it on Chrome and thus is still better, though in fairness Chrome also offers the option to disable it.

Let's face it, desktop Firefox has in fact never been using the native toolkit of the platform on any platform it supports in the conventional sense (reason for the desktop qualifier: I heard the Android version now intends to go native). Rather it uses its own UI toolkit that has a set of platform backends that call into native APIs to, say, grab a pixmap of a native element and then weaves that into its own rendering, which is very different from actually putting a native element on screen, since the original code implementing its behavior and the details of its rendering doesn't actually run[1]. Rather, any time Firefox makes something look native it's just a case of more or less close emulation.

Now interestingly, this is not uncommon among browsers, especially in the document viewport: As far as I know, even MSHTML reimplements all of the form controls it embeds into websites by itself rather than use native Windows widgets, and for the longest time you could easily spot the differences in behavioral details. To my knowledge KHTML is the only browser engine which ever used (and still does use) native platform widgets directly. And in the case of Firefox, the Gecko engine powering the viewport also powers the browser chrome. This is one reason that you had number of semi-popular browsers embedding Gecko into chromes actually using native platform toolkits, like Camino on OS X and K-Meleon on Windows.

1 = Let me give a concrete technical example of why this is a problem. In KDE 4, our default style engine renders combination of radial and vertical gradients into the background of windows. Cf. this screenshot of a plain, empty window: http://www.eikehein.com/kde/window.png

Now, KDE is based upon the Qt toolkit, and the traditional Linux platform backend of Firefox uses the GTK+ toolkit instead (as mentioned there are the beginnings of a Qt port, but it's not anywhere near useful yet). Obviously we prefer Qt over at KDE, but since application developers who chose differently have written some perfectly excellent applications using GTK+ and we believe users should be free to use them without suffering aesthetic consequences, we in fact sat down and wrote an essentially feature-equivalent, visually faithful and fully native GTK+ version of Oxygen. It's the most sophisticated style engine available for GTK+ today (in ways screenshots don't entirely do justice - there's e.g. tons of subtle transition animations in there you don't usually see in a GTK+ engine, say fading in focus rings). This makes actual, native GTK+ windows look just fine. Here's one and the same demo application written using three different toolkits, Qt 4, GTK+ 2 and GTK+ 3: http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAAAAk...

Firefox however isn't a native GTK+ application, but instead just calls into GTK+ to let it render certain UI elements (or even only parts of them) into buffers it then uses as sort of raw materials in the painting of its own UI elements. And this abstraction over the native GTK+ is leaky, i.e. it suffers from limitations where Firefox' indirect use of GTK+ doesn't account for something a GTK+ style engine might be doing because it wasn't anticipated. And our gradient window backgrounds are where one of those limitations hits: Firefox doesn't ask GTK+ for the window background to draw into its own window. As a result, you don't get the gradient in a Firefox window using the Oxygen GTK+ style engine - and we even had to add a system to our window decoration to allow the special-casing of such windows to tick off the gradient in the deco as well, so you don't get a seam. This makes it look reasonably okay, but it's just not fully there: http://www.eikehein.com/kde/firefox-oxygen.png

And let's not even talk about those transition animations ... or actually, let's, to pre-empt the counter-argument of them not being desirable in the first place: You can turn these off if you don't like them. The point is that by not actually using the native widget, Firefox is not in a position to follow the user's preference in the matter either.

So, there you have it - here's the KDE guy in fact not complaining about Firefox not doing Qt, but actually doing GTK+ so poorly we can't make it fit even by embracing GTK+. Clearly it's not us not going the extra mile for integration :).

panacea• 14 years ago

Speaking as a Mac user I agree. The Mac Firefox browser has always been clunky and never felt particularly 'native' to Os X. Camino was a far more native Gecko-based Mac browser.

SkyMarshal• 14 years ago

> As for Chrome, the sin Chrome commits on Linux in particular is that it defaults to something called client-side window decorations, that is it tells the window manager not to display the decorations it would normally put around the client area and then proceeds to draw its own inside this client area, which behave potentially vastly differently from whatever the user has configured for his native system decorations.

One man's sin is another man's salvation. That's one of the main reasons I use Chromium and Chrome as my primary browsers on Linux, besides their superb performance optimization. It works well with Ubuntu's integration of the top OS info bar and the app's menu bar, and saves noticeable screen space. I love it.

I'm hoping Firefox at least provides that as an option in future builds as well.

stuartjmoore• 14 years ago

It looks like they're still keeping the subtleties of each OS (eg the ICS action bar), just adding they're own styling, icons, branding, and flow on top.

Looks a lot better than apps that just port iOS apps to Android pixel-for-pixel.

generateui6• 14 years ago

The browser is an exempli primus of an app allowed to break the OS UI guidelines. This is becase the browser is becoming the OS, and the OS becoming the browser. Said differently, the only UI on the OS is coming from the browser.

This of course is not yet the case, but soon it will be.

debacle2• 14 years ago

Tell that to anyone who uses their PC for programming, document creation, graphics design, or is comfortable with the command line.

mattgreenrocks• 14 years ago

I'm pretty sure I recall the same concessions being made for Swing when Java was up and coming.

(Of course, the difference here is that this is actually happening, but still...)

Tomis02• 14 years ago

The tab thumbnails look a lot like Opera's.

sirn• 14 years ago

I've been wondering about this for a while: what's with the large back button? Back when it was introduced, it was cool because back button was the most often-use one of all nav buttons (next, reload, stop, home) but now they're reduced to one, large back buttons just doesn't seems to make any sense anymore.

Are they still doing it as a part of Firefox UI identity or is there any (recent) usability research on this?

Zirro2• 14 years ago

The forward-button still appears when there actually is a link to go forward to (instead of having it greyed-out a lot of the time). My personal opinion is that it looks good, and that the round back-button has become a way of recognizing Firefox. The option to shrink it isn't that hard to find though, you just choose "Small icons" in the UI-settings.

sho_hn7• 14 years ago

You kind of allude to this with the identity bit, but to spell it out I remember reading in their docs that part of the original motivation for the large button was the idea to establish a cross-platform "keyhole shape" element (formed together with the forward button) there to identify Firefox by.

Avshalom• 14 years ago

Branding aside it's usual a good idea to make the most used elements of the UI big, it makes them easy to click.

generateui6• 14 years ago

The article is showing the wrong screenshots. Here is the accurate one: http://imgur.com/NdNif

chris_wot2• 14 years ago

That joke is tera-ble.

generateui6• 14 years ago

pǝǝɹƃɐ

peedy• 14 years ago

I'd still use Vimperator.

Zirro2• 14 years ago

The mock-ups of future Firefox-versions always look gorgeous but they usually start running into issues at the implementation-stage. Some things are left out, corners are cut and in the end it doesn't give the full experience the mock-ups are giving the impression of. Firefox 4 is a good example of this, where the original designs were showing much more than what actually shipped in the end.

I hope that they have learned from this during the past redesigns and assign someone responsible for making sure that the mock-ups are followed thoroughly.

conradfr2• 14 years ago

You know I don't use Chrome (which is sooo fast) partly because I don't like its UX (especially the tab design).

Copying it will not gain back the lost market share, it will only give more reason to use Chrome.

kijin• 14 years ago

The only difference between Chrome's tab design and Firefox's is that Chrome's tabs have rounded corners and Firefox's tabs are rectangular. You refuse to use a browser because it has rounded corners? Really?

Anyway, there will probably be add-ons to bring back the rectangular look if enough people prefer it to the rounded look. If I were a real fan of Firefox's current look, I'd be more worried about the big orange button being dropped in favor of an options button in the exact same place where Chrome puts it.

sho_hn7• 14 years ago

> The only difference between Chrome's tab design and Firefox's is that Chrome's tabs have rounded corners and Firefox's tabs are rectangular.

While I'm overall not a fan of Chrome's UI and this may speak correctly to the present state of affairs, I feel there's something worth adding to give credit to Chrome for advancing the state of the art: They implemented a bunch of smart behaviors Firefox later copied. Good piece on this: http://www.theinvisibl.com/2009/12/08/chrometabs/

conradfr2• 14 years ago

Well yes, it's a detail but it's in my face all day long. Also, on XP (that I still use at work ...) it has that ugly xp-esque blue.

Nux• 14 years ago

As long as they keep the add-on bar they can do whatever they want to the UI.

munchor• 14 years ago

My issue with this interface is the following:

You either have round tabs or rectangular tabs. Firefox used to have rectangular tabs, Chrome has rounded ones.

The new Firefox ones has, well, I don't know. It's a mix of both, please choose one, and I prefer rectangular. Seriously, they are mixing rounded and rectangular, it's ugly.

Firefox Australis: One browser interface to rule them all

Related Stories