Archive for June, 2007
Friday, June 22nd, 2007
Some interesting news at the WWDC today - Apple is releasing Safari 3 for Windows XP/Vista, alongside OS X. In fact, you can now download a public beta.
What does this mean? In my opinion this changes everything.
For many years, web developers have focused on supporting a wide variety of browsers, but in practice, this has often been interpreted as supporting Internet Explorer and Mozilla/Firefox. Very few developers go out of the way to support Safari, for the simple fact that it has been limited to the Mac OS platform and it is used by likely only around 3-4% of user’s, however this figure has been growing quite significantly in the past year. (Opera is another story, it accounts for around 0.2% of users and this never seems to change! Opera users also seem used to switching browsers in the event a site doens’t work for them!).
Now, Safari has a chance to get into the mainstream, and this will force developers to pay attention to it. With Mac gaining market share, there was some additional pressure to support Safari, but now that it is becoming cross-platform, this becomes essential.
It also makes it easier for developers - the three major browser rendering engines; Trident (IE), Gecko (Firefox) and WebKit (Safari) are now easily available on Windows and Mac OS, leaving no excuse for lack of testing or consideration.
Do I see Safari gaining market share? It is a difficult one to judge - on one hand Firefox has been around for ages, and still see’s only 15-20% usage on your average non-geek commercial website, on the other, Apple have twice as many people downloading iTunes downloads than Firefox on Windows - if they can use this as a launching platform then perhaps there is hope.
If nothing else, it will serve to give Microsoft and the Mozilla platform an incentive to focus on supporting web standards, alleviating any kind of development hell that may await; whilst at the same time, increasing developer awareness and ushering in a compatible, cross-platform, web, which can be enjoyed by anyone - wether the computer be white, brushed metal or beige!
Earlier this week, Google Gears was unveiled to the public, it represents Google’s solution to the eternal problem - how do I make my web application’s functionality available offline?Gears comprises of three components:
- A local web server, for storing HTML/Image/CSS/JavaScript assets locally.
- A local database server, for storing data used by web applications.
- A worker thread pool, allowing CPU intensive operations to be performed in the background.
All of this functionality is accessed by extensions to the JavaScript API which are enabled by a component which must be downloaded and installed. Currently Firefox is supported on Windows, OS X and Linux; along with Internet Explorer 6+ on Windows.
Whilst this is a nice idea, I have to say that I am skeptical about wether or not this is indeed the right way to go with regard to offline applications…
First of all, you have a dependancy on an external piece of software - one which at the moment has very limited market/user penetration. Sure, you will find web-savvy individuals likely to be running Gears, who can leverage your gears application, however the vast majority of your userbase will likely be oblivious to what Gear’s is, or where to get it.
This can likely be addressed if Google decide to bundle Gears with some of their other products, such as Toolbar. In addition, developers themselves can use the promise of offline functionality to drive users to install Gears… but still, it is going to be a long time before Google Gears has the universal ubiquity of, say, the Flash Player (over 95% user penetration). Until Gear’s reaches a similar level of ubiquity, its bound to be a hard choice as to wether to invest effort in developing an offline application which may not reach the majority of your user-base.
Other minor points here revolve around lack of browser support (in particular Safari, though Google are working on this), and the (likely) perpetual beta status of Gears.
The other main point I want to touch upon is simple - we talk about wanting our data offline, and that is fair enough, but is the browser the correct front-end for this?
Users have been conditioned to associate the browser with connectivity, and even though you can migrate applications to the desktop, you cannot migrate all the data - you will reach a point where you need to go online to download additional data. For example, your reading your email’s in a Gears-enabled Google Mail and you click a hyperlink a friend is telling you to check out… 404 page not found. Although its obvious, it represents a massive downward dip in the user experience.
Also, many features which are great offline, are simply not relevant or workable in an offline application. Although many web applications let you perform a Google Maps lookup with a simple click, a lot of this functionality could never work offline - either due to the size of the dataset which would need to be stored locally, or due to the fact that the functionality is owned by a 3rd party and you have no control over wether it can be made available offline (and then you find out they are adding offline functionality, but building it around a platform like Morfik!).
Rather than looking to bring entire web sites to the desktop, we should look at what functionality user’s actually want to access when they are offline. From there, developers can move on to deciding the appropriate means of user interaction and technology platform.
Looking towards either native applications or OS-Neutral platforms such as Apollo or Google Gadgets may be the right way to go. Appropriate functionality can be developed with ease (and if your using Apollo or Gadgets, using web development skills), and you have the capability to develop much richer and targeted features for desktop users.



