

If Chrome doesn't look native, why does the toolkit matter? - ComputerGuru
http://neosmart.net/blog/2009/does-it-gtkqtwin32-really-matter-for-chrome/

======
nickb
_The problem is.... Google's Chrome for Windows doesn't look native._

And which app does? MS Office doesn't look native either. Neither does IE. In
fact, very few MS apps actually use their guidelines and default widget sets.
Office, for example, has a completely different widget set and even has a
different toolbar (ribbon).... not to mention a completely different window
chrome and that big round button in top left. And many other Windows apps
don't follow the guidelines either.

 _A non-native UI that looks the same on Mac, Windows, and Linux would be the
answer to such a browser OS. It would indicate that Chrome is its own product
- from the codebase to the user experience - and that to the end user it
shouldn't matter what OS you're on._

Except that people today do use different OSes and nativeness does matter!
Inconveniencing and annoying your users with an intent to make them aware that
your app is somehow different is opposite from what you should be doing:
conforming to their learned patterns of how their UI works and making the
transition to a new app painless and 'invisible.'

I'm in complete agreement with Goodger on this one: none of the cross platform
widget sets feel native on any of the OSes. Firefox still feels awkward on OS
X and has a lot of deficiencies in the way the text boxes work, keyboard
navigation for assistive devices. In-browser widgets like buttons and drop-
down menus are just off when you compare them with native widgets (drop-down
in particular) and feel weird.

They invoke that 'the uncanny' feeling:
<http://en.wikipedia.org/wiki/The_Uncanny> They look like the real thing but
aren't and give you that uncomfortable feeling.

------
icefox
Oh it isn't just look and feel. They are re-discovering everything. Just a
week ago they were discussing how to solve the "string" problem. They realize
they need a common cross platform string class.

For most C++ developers stuff like this has been solved for a very long time.
Even WebKit itself _includes_ a free string class. Why wasn't it used from the
start? All this re-solving of old issues is puzzling.

Google talks about how they try to sell their products internally first (says
Jeff Huber, the company’s senior vice president of engineering),

"For many ideas, Google’s first and most important audience is its employees,
and it typically tries products internally before releasing them."

Why wasn't Chrome used internally? Google presents itself as a Linux shop, but
why didn't Linux developers internally help on Chrome with their 20% time?
Chrome isn't a new application, it is two a half years old. That should have
been more then enough time to at least discover these basic issues. Why did
Ben Goodger allow Chrome to create its interface code in a very non portable
and Windows only way? As the "lead Chrome UI developer" he should have brought
up these problem years ago.

------
thesethings
Native-ness isn't just there for look+feel, it usually brings speed. I've used
Chrome, it's just incredibly fast. It's not just the Javascript engine. Even
on pages without Javascript, it's just the fastest feeling app of any type
I've used. (I love Linux, I didn't want to have a reason to be tempted to
Windows, but it's that good. (Good job Chrome folks!))

~~~
zmimon
Agree - chrome is now my default browser purely because it can bring up a
window so fast I can barely see a delay, even if I have bogged down the
machine with compiling or other intensive tasks. A couple times I have caught
myself firing up Chrome to do a quick check on news or mail _while waiting for
FireFox to start!_. It is that fast and pleasurable to use. Frankly, I don't
know how Google did it.

I suspect the answer is, as much as anything, that Google simply isn't willing
to sacrifice control of any corner of the browser to make the user experience
fast and slick and that includes optimizing right down to the fine details of
the UI toolkit.

------
antipax
I get the feeling that Chrome will look similar on Windows and Linux. This
would not come as a shock to Windows or Linux users, as there are no real
"standard" user interfaces for those systems. Obviously, on Windows and Linux,
there are unspoken guidelines and the usual GUI toolkits, so you have many
applications that do look similar and a few that look different, but on Mac OS
X, an application that doesn't look like it fits with every other one is
simply unattractive, distracting and harder to learn. Of course, that ability
to learn quickly is detracted from by the non-standard controls that are
already in Chrome.

A great strength of Mac OS X is just that -- that it's UI is consistent.

------
unalone
Of course Chrome looks native. On Windows Vista, it emulates the design
aspects of Vista. It has its own feel, but by-and-large it's modeled around
the design theory of Windows. I'm hoping their Mac program will be very much
Mac-focused.

~~~
ComputerGuru
It doesn't follow the Windows design paradigm. One of the examples in the
article is the dialog boxes that cannot have their buttons pressed by using
the "spacebar" key.

They use their own UI controls & elements that behave similar but not
identical to their win32 counterparts... in the way any non-native UI toolkit
would.

~~~
tolmasky
If your point is that the buttons don't _behave_ the way they should on
Windows, then clearly this is just a bug, and programs can be successful with
bugs. I could make the exact same argument about accessibility "such and such
program has no support for accessibility and yet still sells really well, so
why do we need accessibility?" The idea is to provide quality beyond the
minimum which is necessary to get you to use the thing.

If you could make a toolkit that was non-native, but behaved as if native on
all its target platforms then obviously that would be key. Also, Chrome
currently only officially exists for Windows, a platform whose users are less
picky about native look and feel. You would probably have a harder time
getting away with this on Mac OS X. Similarly, you can have a java app that
runs pretty well on most mobile phones, but a straight port that didn't
include native widgets on the iPhone would probably not be well accepted.

~~~
ComputerGuru
My point is that you're using javascript pop-up boxes for the browser itself
(like the save password prompt) that don't use the win32 code nor conform to
its interface behavior.

~~~
tolmasky
Again, this is a matter of opinion and platform. Firefox had to do a lot of
work to make their widgets much _more_ Mac-like because this was one of the
biggest gripes from Mac users, the fact that they just had some generic UI
elements in their web pages that didn't conform to what they were used to.
This is the sole reason the Mozilla Camino project was even started, and
again, one of the main focuses of Firefox 3 for the Mac.

