This series exploring future design implications of Leopard technologies started with What’s in Leopard for Designers (1): Core Animation. Today, we’ll look at various strategic directions ushered in by WebKit and Safari 3.0.
When Apple announced Safari on Windows, it caught many developers and pundits unawares:
“For Windows users, the browser market is already far too crowded — who needs anything other than Internet Explorer or Firefox? Safari is one browser too many.”
WebKit as decoy
Traditionally, web designers and developers have targeted IE first and then Firefox, but seldom spent much additional time covering other browsers. Apple’s strategic goal is to establish WebKit as a main browsing engine alongside IE. The introduction of Safari on Windows was the first leg of that operation, iPhone is the second. In a way, Safari is Apple’s trojan horse into the developer community dressed up as an invitation to create web apps for the popular iPhone.
Taking a page out of popular Firefox plug-ins, Safari now offers an expanded WebKit Inspector, a sophisticated tool to navigate and debug web app development:
What QuickTime is to iTunes, WebKit is to Safari. Wherever OS X goes so goes WebKit: today on Macs, iPhones and iPods, perhaps tomorrow on AppleTV or other platforms yet to come. This affords Apple a strategic ability to move its technologies across platforms, if it so chooses. For example, it would not be a difficult task to take WebKit based Dashboard widgets in Leopard and move them not only to the iPhone and iPod touch but also to Windows to better compete against Vista-only Microsofts Gadgets.
Weaving an x-platform web
Who’s afraid of the browser?
Unlike Microsoft (which sat on IE for half a decade with no significant updates after vanquishing Netscape) Apple is not afraid of the web browser. In fact, until the native SDK arrives next year the only legitimate app development on the iPhone is through Safari. For Web 2.0 fans this has been a great step forward to move applications from walled gardens like Active X on IE to open platforms using familiar HTML and Ajax.
By next Spring there will be downloadable native apps running on the iPhone, but there will still be an order of magnitude more Web 2.0 developers cranking out Safari-based apps that run wherever WebKit can be found: on PCs, Macs, iPhones, iPods, and other devices/apps from Apple, Nokia and Adobe. Cloud-based applications that rely on web processing and storage (like Facebook, Salesforce or Google Apps) will find a very welcoming and fully-functional home on WebKit-based browsers.
What’s so great about WebKit?
For starters, the <canvas> element. <canvas> defines a region of an HTML page between <canvas></canvas> to be scriptable and capable of dynamically rendering a gamut of bitmap drawing functions. If you played with Dashboard widgets with flips, animations, graphs, games and other 2D effects, you’ve already seen <canvas> in action. Apple introduced <canvas> for WebKit and now it’s also part of Safari, Dashboard, as well as Mozilla, Firefox, Opera and even IE via a workaround from Google.
<canvas> is part of HTML5, a web application platform from WHATWG. It is the primary agent enabling rich presentations in HTML, inching it closer to Adobe’s Flash and Microsoft’s Silverlight plug-ins. Hardware accelerated <canvas> regions for games or 3D can’t be that far off. Open source, multi-platform and without plug-ins!
Cookies on steroids
A knock on browser-based application design and development has always been the browser’s inability to dynamically store data. For a decade, the Netscape-introduced cookies have done the yeoman’s job keeping session state, personalization data, authentication IDs, and so on. But cookies are inherently limited, fragile and cumbersome to work with. When a browser is disconnected from network connectivity, it has no way to interact with data sources. This has critically impeded online application design and development, opening opportunities for plug-in based RIA platforms like Adobe Flash or Microsoft Silverlight.
But what if the web browser had a persistence layer, where data could be locally stored not in miniscule bites of cookies, but in a proper relational database?
Welcome to HTML5 client-side database storage! The emerging API allows the browser to store structured data using plain old SQL. Further, Apple has already integrated this into the Web Inspector, allowing the developer to see contents of a database used by the browser page, run arbitrary queries against it, and navigate it like a DOM tree:
So now, imagine if you will, the Safari browser in iPhone working without disruption with locally cacheable data even when not connected via EDGE or Wi-Fi. Or Safari in Leopard being able to do all kinds of sorting and manipulations on a data table in Google Docs even when a laptop is not connected to a network.
Next, we’ll take a strategic look at other Leopard technologies that will affect designers, including virtualization, Time Machine, resolution independent UIs, widgets and others. Please come back or subscribe to the RSS feed.