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.
[+] [-] nickb|17 years ago|reply
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|17 years ago|reply
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|17 years ago|reply
[+] [-] zmimon|17 years ago|reply
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|17 years ago|reply
A great strength of Mac OS X is just that -- that it's UI is consistent.
[+] [-] unknown|17 years ago|reply
[deleted]
[+] [-] unalone|17 years ago|reply
[+] [-] ComputerGuru|17 years ago|reply
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.