If Chrome doesn't look native, why does the toolkit matter? | Hacker News Reader

If Chrome doesn't look native, why does the toolkit matter?

neosmart.net

19 pointsComputerGuru11 comments

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.

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.

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!))

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.

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.

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.

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.

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.

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.

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.

I didn't notice this very much. I mostly noticed it followed web-browser design patterns: ctrl-t gave me a new tab (like IE + Firefox). ctrl-f made a float-y place for me to type a word to find, etc. Chrome is very different, I won't argue it probably broke some assumptions we make, but it mostly made me wish other apps were more like Chrome than the other way around (tear-away tabs, assemble new tab groups, wowza!)

Reply on news.ycombinator.com