future of mobile SDKs
Joel writes a really interesting essay which is part history lesson and part predictor of the future of AJAX and SDKS.
I’d like to quickly explain my conclusions from the article and then discuss what this might mean for mobile phones.
Starting with the mistakes when Lotus Symphony was being built, removing all the innovation to fit the constraints of the most accessible computing platform of the time. The Lotus approach was compared with the Microsoft approach that meant the software was bloated but innovative. The argument is that the smart guys learnt you either spend 6 months trimming your software to give it better performance or you just waited six months and found out that Moore’s law helped you get better performance.
History lesson over he then looks at the state of AJAX technology and web apps - and compares Google’s fast and lightweight approach with gmail, docs and spreadsheet etc with other new technologies. The vision he creates is that someone will come up with a newSDK which solves not only cross browser compatibility problem, but starts on the real holy grail of web apps and starts to make web apps inter-operable in the same way cut and paste did for the desktop. I like the vision and see how it could work, but I am not sure that perhaps this idea of inter-op may not just be more a technical dream than a consumer ideal - especially with the security concerns etc.
The lessons to be learned and the conclusions he comes to make a lot of sense, I wish he had spent more time analysing the candidates for the NewSDK though.
I guess Joel is talking about two types of competitors for Google - those that are creating platforms (Microsoft, Adobe) and those that are competing on applications (Zoho, Salesforce, Microsoft). Google I think has a good chance of making their work become de facto standards as they tend to embrace open source but also open up their own ideas. I think that Google Gears is a great example of this - and Zoho are now working with them on the project and using the technology in their software.
I understand the compromises between efficient feature low and bloated feature rich applications - and I think that Googe have got gMail spot on I have no idea what I needed Outlook for all those years. The docs package is different though - I have tried both Google Docs and Zoho and I think that the simple interface for Google means that I miss a lot of things from word - however I love Google’s simple approach to collaboration. Zoho is feature rich but is also harder to use as it is harder to work out where the limits are - but if my key need is to quickly put together a nice looking document - I use Word, if my need is to collaborate on a doc then I use Google Docs as it doesn’t confuse other users so much.
So if we say that Google have usability worked out and their approach is working well and keeping users (the Spreadsheet I think is fantastic) I guess we are left with inter-operability. Is inter-operability important to users? and how can security issues be handled?
The platform at the moment is Facebook for interop - you can access a lot of applications and share data using their API and this is clearly going to advance - but the goal that Joel mentions of being able to cut a picture from flickr into gmail is not going to be enable by facebook. This sort of goal is going to need a change is the browsers and who is looking at making platforms and the browser work differently - Micrtosoft, Adobe and Google Gears. Which of these approaches is Open, lightweight and not bloated? Google Gears.
So to learn the lessons that Joel has pointed out and use them in making my prediction for the future of Web apps the newSDK he talks about to me won’t be a single javascript library. I think Prototype and jQuery and Scriptalicious will all continue to develop in the ways and compliment each other. I think that Microsoft will have a big problem using previous techniques to bundle Silverlight into the OS which will take away their normal tactical advantage. Abode will need to make sure that AIR has lightweight access in addition to using full flash functionality and gets installed as part of Flash installs. Google gears will need to have proper infrastructure set-up perhaps even a more open name and path forward “Web Gears”?. One of these three will be the choice of developers and with a complimentary back end Facebook, OpenId or some other system will allow the Web 3.0 apps to be about collaboration and interoperability.
So what does this mean for mobile?
Well lessons learnt from Joel’s history lesson and lessons to be learnt from future predictions mean that I think that Apple’s approach to phone apps is going to become predominant. The browser will be king - but browser choice will have to come into play if innovation is going to move us forward. Mobile has to have off-line more than desktop, mobile apps must have access to device capabilities to truly create innovative apps. I think that the rumoured gPhone will contain something similar to Google Gears and will allow developers to use the back-end infrastructure of Google to enable their apps to interoperate - I hope this can all be made much more open though. I think Apple with adopt Google Gears into Safari and other manufacturers will be able to use it too. As the number of iPhone and facebook applications rise - so too will compatible browsers on other phones - either Opera or manufacturer ones. So the iPhone API will become quite a standard - and if it is widely enough used and complimentary enough the Google Gears one - I hope both of them are already looking for W3C approval.
So my predictions for Web 3.0 and Mobile 3.0 see them converging - Google Gears (or some other candidate) along with facebook (or next years equivalent or openId) will be key to both platforms and the iPhone API (or a cross platform javascript library) will be key to mobile interactions and Prototype (or another dominant javascript library) will become a key API for the Desktop.
Popularity: 100% [?]