On Sep 3, 2008, at 6:56 PM, Kontra wrote:
Not by Google. You need to read up on what the Google principals
have been saying in various interviews and Levy's Wired account.
Everything I've been reading refers to Chrome as a "browser." As in
"web browser."
http://www.wired.com/techbiz/it/magazine/16-10/mf_chrome
Money quote: "The browser matters," CEO Eric Schmidt says. He should
know, because he was CTO of Sun Microsystems during the great browser
wars of the 1990s. Google cofounders Larry Page and Sergey Brin know
it, too. "When I joined Google in 2001, Larry and Sergey immediately
said, 'We should build our own browser,'" Schmidt says. "And I said no."
The word "browser" is basically percolated throughout that entire
article. It's always discussed in reference to Firefox and IE, not in
reference to what AIR is.
Your premise is one I obviously don't share. I don't think the browser
can evolve into the next rich interaction platform without breaking it
out of the browser paradigm itself. It has some tipping point where
your basically constantly faking it and fundamentally ignoring what
the basic premise of a browser is: a single window, page oriented
experience, no matter how much you can get away with in that context.
It's inherently held back by being a *browser.*
Example: Palettes. How will palette slave windows work in the browser
driven web application world? Currently, they don't. They live inside
the parent port and and are fundamentally faked. Is that bad? No. It's
fine up to a point. But once you reach that point, you suddenly want a
lot more.
Can you get really far with that approach? Absolutely. We've done it
here many times now. Is that distance far enough to negate things like
AIR and such? I'm not confident of that sort of claim whatsoever. I
honestly don't know.
But you will hit a ceiling in designing for a browser because it's
fundamentally a browser paradigm! If you break that ceiling, you've
broken what it means to be a browser, and have entered new territory.
(Or old territory if you've been designing applications since the 80s
because its basically all the old stuff brought back again.) At which
point, you have to ask yourself why be a "browser?"
You can literally embed a web "browser" inside an app, desktop or
otherwise. That's what folks do with WebKit on Mac OS X.
I'm well aware of that. In fact, that's how we partially built our
most recent prototypes.
"But can one application environment handle both and innovate in
both simultaneously? Not that I've ever seen."
I don't see why not.
We'll have to see if people get confused with the distinction. And by
people, I mean "end users" not developers.
I think semantics here matter. If you tell people or let people think
Chrome is a "browser" then you've set up all sorts of expectations.
Those expectations actually matter as they put constraints on what
designers ad developers are allowed to do.
Like I said, you need to read the Wired article to get the color on
Chrome team's approach to "throw out everything not absolutely
necessary" approach.
Then they'll have to stomach not adding those features back in any
time soon. If they pass that test, I'll be more convinced it has a
chance in that realm. Outside of that, it still becomes basically
Browser #4 but with zippy JavaScript for people like me to check
against, versus when I do a project in AIR, I design basically for
"AIR" and what I can get away with without nary a worry about if it
works in IE6, 7 or 8.
That last statement by the way is a *very big deal.*
That's not necessarily a binary decision. The path is an app
platform that has a fully-capable browser embedded.
I think we're actually in agreement on that point, if we disagree
about the way it's being discussed and written about.
But what I see with Chrome, based on how they've now shipped, is a
browser with a potential web app platform as an extension. I still see
a browser, and all the limitations that implies. The default state and
experience of Chrome is Firefox but without the main menu or all the
add-ons people want and it's either really zippy and about the same
speed wise.
I think AIR is more like what you are claiming Chrome is from a
product definition point of view. And while AIR apps can feel like web
apps (single windows, inlaid content, page like experience), there's
nothing inherent whatsoever that drives that decision in designing or
building an AIR app.
My point is that Chrome can easily be an general app platform that has
fully-capable browser embedded, like AIR, as long as Google always
discusses it like this and frames every single conversation like this
and does a ton of work to make sure people writing about it do so
properly. But that's not how they shipped out of the gate. Out of the
gate, they have Back, Forward buttons, URL/Search, Bookmarks, etc. and
have set the initial expectation in the minds of now millions that
Chrome is a "browser" whether by not being stronger in their own
language in promoting it as an app platform first or not.
Now that they've done that, how will they be able to add more robust
and rich application specific features -- like say the slave Palette
windows -- without suddenly being incompatible with other "browsers?"
They can only do that if they make it clear that Chrome is *not*
Browser #4 and can therefore break new ground if they so choose
whenever they so choose. Unless of course Chrome is just another
browser, but faster, with this nice little shortcut to launch
something sans browser chrome that you can already do with other
browsers as well. I'm not exactly sure how that is any different from
where IE8, Firefox and Safari have been heading for some time now, or
how at the end user experience level, it's radically different at all.
That's precisely the direction they are pursuing by eliminating the
"chrome" when a "tab" is turned into an "app".
How is this fundamentally different from what you can already do by
launching a new window sans browser chrome in IE, Safari and Firefox?
And that you have been able to do for many years now? I get that tabs
in Chrome run in their own processes. Ok... and? It's still then a
browser based web application in a browser based design paradigm.
That's not at all where AIR applications are going.
--
Andrei Herasimchuk
Principal, Involution Studios
innovating the digital world
e. [EMAIL PROTECTED]
c. +1 408 306 6422
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
