
Firefox Australis: One browser interface to rule them all - SkippyZA
http://www.extremetech.com/computing/128161-firefox-australis-one-browser-interface-to-rule-them-all
======
sho_hn
Web-based live demos of the new UI:

Linux: [http://people.mozilla.com/~shorlander/files/australis-
design...](http://people.mozilla.com/~shorlander/files/australis-
designSpecs/australis-designSpecs-linux-mainWindow.html)

OS X: [http://people.mozilla.com/~shorlander/files/australis-
design...](http://people.mozilla.com/~shorlander/files/australis-
designSpecs/australis-designSpecs-osx-mainWindow.html)

Windows 7: [http://people.mozilla.com/~shorlander/files/australis-
design...](http://people.mozilla.com/~shorlander/files/australis-
designSpecs/australis-designSpecs-windows7-mainWindow.html)

~~~
marcusf
I guess this goes without saying, but view them in Firefox. At least the OS X
one looked thoroughly screwed in Chrome.

~~~
aeurielesn
No wonder since it is full of -moz-* vendor prefixes.

------
acabal
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_hn
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...](http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAAAAkc/cU1uZDq1WxM/s1600/oxygen-
gtk-demo.png)

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 :).

~~~
SkyMarshal
_> 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.

~~~
sho_hn
Right, no objections if that makes things better for you. I would like to
mention that in Plasma Netbook (the netbook-optimized edition of our
workspace) we've tried a sort of alternative approach where if windows
maximize, we disable the borders and merge the window controls into the top
panel, to achieve the space saving. You can also set that up in Plasma Desktop
of course.

As for app menu in a panel: That's actually something we had back in KDE 3.x
but are still lacking in the KDE 4 mainline at present, mainly because it's
taken a while to coordinate the standard with folks like Canonical and because
we really wanted the core patches to be integrated at the Qt level. Things
look to be coming together now for the upcoming 4.9 release, though I believe
(K)Ubuntu has actually been shipping the patches for a while already, for the
benefit of KDE apps running in Unity, but also to support the same sort of
arrangement in KDE workspaces.

As for CSDs, there's bunch of other things they break that I didn't list in
the original post. For example, with WM-provided decos, the window manager can
detect when you're trying to interact with a frozen app and offer to kill it,
which is in fact something we're doing. If you move the deco into the app
process, though, well, then it hangs together with the app, and things get a
little more complicated. And there's performance issues in some remote desktop
cases, and so on.

------
Zirro
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.

------
sirn
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?

~~~
Zirro
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.

------
munchor
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_.

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

------
peedy
I'd still use Vimperator.

------
conradfr
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
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_hn
> 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/>

~~~
chris_wot
My goodness! Finally, someone giving Apple a run for their money in terms of
obsessive design! I love how they do tabs right to left when using an Arabic
locale... They've really thought it out.

Incidentally, no idea who voted you down. That was a very insightful link!

~~~
sho_hn
Just to add to that, re reversing in Arabic locales: All KDE/Qt apps will do
the same with their tabs and have done so for at least a decade, and you can
even get a feel for it in an LTR locale by running them with --reverse (useful
for devs to check for issues in custom widgets).

(And thanks for the kind words. :)

------
Tomis02
The tab thumbnails look a lot like Opera's.

------
horv
Is it just me or does the first mock-up look a lot like Chrome?

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

~~~
chris_wot
That joke is tera-ble.

~~~
generateui
pǝǝɹƃɐ

