Chrome OS and Android

I was surprised when Android was announced, because it didn't seem to fit with Google's principles. Not only was it client software, not cloud software to which Google had previously confined themselves, but it also created a new platform, separate to the web.

Google's search and ads have tied its fortunes to the web, and their management knows it. They dominate their industry so much that the only way to increase their revenues is to get more people using the web all the time. To achieve this, they they need not only to innovate themselves with web apps such as Google Maps or Gmail, but to nurture an ecosystem of Silicon Valley startups to work on web applications rather than on any other platform. They do this using a combination of Google Ads (providing revenues to startups), funding browser developers such as Mozilla, web developer evangelisation (such as spreading the word about Ajax) and careful purchases of the best startups.

Since Android was announced, this focus on the web has increased. Recently Google announced it is putting all its energies behind HTML5, to bring new capabilities to the platform such as video, geolocation and graphics. They have created a new browser, Chrome, and promoted it hugely on the Google homepage.

So why on earth create a new mobile operating system? Now they have to build a new developer ecosystem using the Android Marketplace. These aren't web apps, therefore Google doesn't get the same search or ad revenue. And it takes the focus in Silicon Valley away from the web.

Of course, there were good reasons for Android at the time - fixing the lack of good competition for Apple, persuading the network operators to invest in data networks, and attempting to fix the broken industry structure especially in the US. And Android is increasingly successful. But I still believe that it's the wrong solution for Google to the original problem.

Now Chrome OS is about to be released. It's another client OS, but this time the operating system is simply a web browser. No distractions from the web, no separate platforms, but still a way to shakeup the computing industry in Google's favour.

For once, I think Steve Ballmer was correct about Chrome OS - "It’s incompatible with the one operating system they have shipped. To me, still, I don’t understand why they needed another one. They must have gotten the first one wrong."

Despite it's current success, I think they did get Android wrong. There must be some huge arguments within Google about the correct model, but Chrome OS is the one that fits with the rest of the company. Time only will tell how the two operating systems sit together, but I wouldn't bet on Android surviving for longer than it takes to get Chrome OS powerful enough to drive a phone.

Telephony and the web

In the last few weeks, the web has finally started to encroach on the last holdout communications medium: the telephone. One day soon, most telephone calls will take place via Facebook, Twitter and Gmail, instead of your phone's inbuilt address book.

Internet telephony has already been through one massive hype cycle without great results:

• Skype is only real global success with consumers. Not web-based. Proprietary.
• Back-end infrastructure has been converted to IP, especially for business use and internally in telcos. But from the consumer's perspective it's still a separate network.
• Endless Voice over IP start-ups have now failed. There was clearly a missing ingredient - they focused on back-end technology e.g. SIP, not the consumer side, and they couldn't take advantage of network effects. Also, what advantages did they provide from a consumer perspective except reduced cost?

Most revealing for me is the phrase 'unified communications' in the telephony industry - it's been a mirage because they never unified with the web, surely the most important communications medium of all!

A new wave of innovation has started in Silicon Valley and this time I think they're on the right lines. Recent news includes:

• Native browser support for audio and video, in Safari 4.0, Firefox 3.5 and Chrome 2.0 is coming very soon. This enables browser-based conversations without plugins such as Flash.
• Phweet - integrates phone calls with Twitter
• Mikz - web-based access to your mobile phone call data
• Twilio - web platform for making & receiving calls, suitable for integrating into websites.
• Google Voice - web-based call management tool, due to be integrated with Gmail

You can see where this is going. The web is taking over most other communications mediums (TV, newspapers, letters, email) and telephony is up next. Telcos were never able to deliver the vision of a unified suite, centered on the address book, where customers could communicate with each other. It's now the turn of the web and its social networks.

Mozilla's web developer tools

Mozilla are best known for their browser Firefox but they're creating a steady stream of great web development tools, the latest of which was unveiled last week. Bespin is a new web-based extensible code editor with integrated command line. Although it's a very early version and lots of kinks remain (including too much inaccessible HTML5 Canvas usage), the team have already accomplished one of their first objectives, which is to prove how capable browsers now are. Could web development tools one day provide the second 'arm' of Mozilla?

Other development tools managed by Mozilla include:

• Firebug, for inspecting and editing CSS, javascript and HTML
• Bugzilla, for release planning and maintaining issues lists
• Mozilla Developer Center, for documenting web standards such as HTML and the DOM
• jQuery, a javascript library for cross-browser web development

Tools for web development fit naturally into Mozilla's goals for extending the reach of the open web. In fact it seems strange that Mozilla don't have more competition in this area - there is a surprising lack of offerings from Yahoo, Microsoft, Amazon and even Google, especially considering how tools can be used to bind developers towards vendors.

I hope that Mozilla's plans for Bespin are ambitious, because I see it as the centrepiece for all their development tools. Imagine if you while editing your code you could click once to find help in Mozilla Developer Center, again to visualise the results via Firebug, another time to track your bugs in Bugzilla and finally to resolve DOM issues using jQuery. In this way, Bespin can integrate all Mozilla's tools together.

I would also add additional tools to the slate, all of which should integrate back with Bespin. For example:

• Version Control System (e.g. hg, git) integration - create a fork or merge at the click of a hyperlink
• Validation / Best Practices - automatically check all your code against standards or best practices such as jslint
• Web design - online tool for visualising and editing site design
• Security - automatic checks for common flaws such as XSS

Such a suite would constitute a second 'arm' of Mozilla. It would perhaps also provide a second source of funding for the organisation, with the support of web companies that use the tools. It could certainly improve the productivity of hundreds of thousands of web developers, while spreading standards and best practices. It's a very ambitious goal, but Mozilla has already proven capable of delivering great tools like jQuery and Firebug that now dominate their markets.

I believe it's time for Mozilla to take a step up and treat development tools as a priority alongside Firefox itself.

Unexpected convergence: smartphones and TVs

CES this year was fascinating. The Palm Pre is the perfect example of where I see consumer devices heading. The whole phone is basically a browser; it's built using web standards (HTML, CSS and javascript) from top to bottom. As Tim Bray states, "Speaking personally, as a person who'd never thought I needed the Internet in my pocket, I find myself using my G1 to approve comments and check the weather and fetch maps and so on all the time." To create the Pre, Palm (like Apple and Google), has focused on creating a browser for small screens. They've had to get rid of all the menus, options and buttons that desktop browsers are infested with, while also removing much of the need for fiddly keyboard entry.

Which brings me to the following quote last week from the CEO of Netflix, commenting on new internet-enabled TVs: "Think of Internet on the TV like the Web browser. One view is that the Web, a browser like Firefox, Chrome or I.E., will be right on the television in the next couple years. Another view is, no, a PC-based Web is just too complex. The second one is the phase that we're in now."

I agree that the PC-based browser is just too complex to use while standing metres away with a remote control. But the smartphone-based browser might work perfectly on your TV!

After all, stripping out the menus, options, buttons and keyboard navigation is the first step to getting a working browser on the TV, too. And though you can't touch your TV from the sofa, you can imagine using a control like the Wii to navigate a pointer round the screen in much the same way. Download the Wii Opera browser to see what I mean. Or just imagine the Palm Pre interface on your TV!

It seems odd that smartphones and 50" TVs could share the same interface. But that's the lesson of this year's CES for me.

Nokia

Nokia is at a turning point. Long the dominant supplier of mobile phones worldwide, it faces new deep-pocketed competitors in Google & Apple, plus structural changes in the industry. Nokia is losing market share and needs a clear strategy.

The mobile phone industry has matured rapidly. Until very recently, companies competed by offering features - a better camera phone, more storage for music, a more colourful screen. The big manufacturers created vast portfolios of phones tailored to different market segments and geographies - camera phones, music phones, children's phones, smartphones, and economy phones.

Smartphones have now converged on a standard set of these features. The next battlefield is the software platform that ties it all together. Apple and Google have turned their phones into general purpose digital devices - in other words, personal computers. They are competing by attracting third party application developers to take advantage of the computing power in their phones. The Apple store, for example, is one of the key selling points behind the iPhone, with more than 5,000 applications already created.

To attract this kind of ecosystem, you need to develop a strong platform. Apple have done this by porting Mac OS to the phone. Google have developed Android. Various other vendors have combined forces to develop LiMo, using Linux. Unfortunately for Nokia, their operating system Symbian is not popular and needs significant investment. Nokia have taken control and will open source the OS. But by the time it's complete, it may be too late.

Nokia have pushed into software and services. "Comes with Music" is an innovative attempt to establish a new business model for digital music, but it's losing money. The purchase of Navteq enabled Nokia to move into location-based services. Neither has yet attracted much interest by the consumer. This is an uphill battle.

A new approach

Nokia is still a profitable company, and it still has marketshare dominance. It just needs to follow the principles below:

Device Convergence

Now the platform is all-important, simplify the device portfolio. Nokia should be offering no more then 3-5 phones in each country, each based off the same platform. After all, Apple have only got one phone, but they're still the second biggest smartphone manufacturer in the world!

Also, now phones are becoming general purpose computers, why not merge with a PC company such as Acer or Dell? The platform should work across all shapes and sizes, perhaps extending upwards from mobile through the Netbook format.

The web is your platform

Fighting against Windows, Mac OS and Linux is a fool's game. Instead, Nokia should align themselves to the biggest platform of all ... the web. Nokia should become a platinum sponsor of Firefox, who are writing an amazing-looking mobile browser, and make it the whole front end to their phones. Creating code for a Nokia phone would then be easy - any web designer could do it.

Nokia could create Firefox extensions to give the browser power over local features such as the microphone, camera and accelerometer. Nokia would instantly have the biggest group of developers and the most third-party innovation of any mobile platform, and they would have the future on their side.

Partner with Silicon Valley

The hotbed of software innovation is Silicon Valley. Writing applications is a totally different business to selling hardware, and Nokia is going to struggle with its services strategy. Nokia should partner, not compete, with Silicon Valley. Why create your own email application if you can just recommend GMail? Why create your own photo application if you can just recommend Flickr? Why not partner with Facebook and Twitter to provide the next level of communications?

Remember, the web is your platform, not the operating system. So please, no more do-it-yourself services after music and maps.

Each of these principles could be easily achieved in a year or so. But they would establish Nokia on the right side of the changes taking place in the mobile industry.

Web services

Tim O'Reilly has written another great essay explaining the three types of cloud computing: Utility Computing, Platform as a Service, and cloud-based end-user applications.

For now let's focus on just one consequence: "Web Services" finally get real. Let's go through the various services that are already emerging. Remember, these are not only services for consumers, but also a platform for developers.

Most obviously, identity. This includes authorisation, authentication, presence, and basic user data e.g. email address. OpenID and OAuth are the emerging standards in this space, with support already from Google, MySpace, Microsoft, and Yahoo.

Secondly, social networking basics : Friends & the Activity Stream. OpenSocial is the emerging standard here.

Third, basic content: Images, Videos, Audio, Blogs. The emerging standard here is Atom. However services will likely get enhancements; for example, the ability to manipulate the underlying files e.g. removing red-eye on photos or enhancing audio treble.

Fourth, various additional services:

• Location-based services e.g. Maps / GPS
• Time-based services e.g. calendars / tasklists / clocks
• Messaging (email, instant messaging, phone)
• Financial services (payments, credit checking, etc)

Finally, professional content:

• News
• Sport
• Financial

All of these services already exist on the web, but they are in silos and can't easily be accessed by developers. Finally now, web application providers are rushing to become platforms for developers, opening up their data using standard patterns like REST and OAuth.

For example, Paypal could offer to track your payments in Google Calendar. Or you could ask the BBC to enter any news items within 20 miles of your house into your Myspace Activity stream. Or you could put your phonecall history there. Or your project management system at work could put events into your personal calendar or task list.

From the consumer perspective, the web will become a lot more connected and personalised. From the developer perspective, there will be a huge number of web services making user data available securely (photos, videos, friend list). Writing a web application will involve plugging in to these standard services. Finally, the vision of web services will become real.

Web Office suites are a dead end

So, Microsoft have finally confirmed that a web-based version of Office is due soon.

That's good news. It means that Microsoft are responding to competition from Google and Zoho; hopefully in turn Google and Zoho will improve their products, which can only benefit the end consumer. It also means that the web has finally broached the biggest consumer software market in the world, the office suite. Web 2.0 has won!

However, while Web 2.0 might have won, I don't think the office suite will survive much longer. Microsoft, Google and Zoho may have faithfully reproduced the troika (word processor, spreadsheet, presentation) on the web, but its time has passed.

We've been stuck with these three applications for so long that it's difficult to see past them. But they've only survived due to network effects: everyone has them, because everyone else has them. It's time to re-examine their purpose.

First, the rise of the long tail. Because the browser is a general purpose platform, all sorts of special-purpose applications can be used instead of an office suite. Why use Microsoft Word to manage your CV, if you can use jobsite.co.uk instead, which gives you CV advice and links you to employers? Why use Excel to manage your personal finances, if you can use Mint.com, which automatically downloads, categorises and charts your bank accounts for you? Why use Powerpoint to explain your business, if you have a business website that does the same and is accessible to millions?

Second, the rise of the widget. Ever seen a video embedded in a spreadsheet, or an interactive calendar embedded in a presentation? I thought not! But because the browser is a general purpose platform, it's possible on the web. Many widgets like these that defy categorisation will spring up. Is it really a spreadsheet if you use it to post photos? Is it really a word processor if there is a table with formulas embedded? The spreadsheet, word processor and presentation will merge together into a single platform with many different widgets.

Finally, of course, the rise of collaboration. To an elder generation, something you did with the Nazis. To the younger generation, the whole point of content. If you can't see your friends, and make your content available to them, then they won't want it. That applies at work even more than outside work. The web office will be embedded inside a social network. It'll look more like Facebook than Powerpoint.

Microsoft's screenshots of the web version of Office look like they've faithfully reproduced Office in the browser. I think this approach will lead to a dead end. The all-powerful office suite is fading fast, and even the web can't save it.

Microsoft Mesh

Details of Microsoft Mesh are finally emerging through the fog of Microsoft's PR department, and I think it's going to be absolutely massive. They've found a way to extend their C: drive monopoly to the web.

Basically, Mesh will turn your PC into an Atom Store, publishing your C: drive to the internet as a set of feeds. You can publish any local Word Documents, images, videos, or even folders.

What's more, your C: drive will obey the Atom Publishing Protocol, meaning other services will be able to post, edit or delete local files. This will be used to synchronise your local content with an online space, presumably a version of Sharepoint with developer APIs. Of course, this will turn every PC into a web server - I suspect the only connections allowed will be to Microsoft's servers.

This is exactly the kind of service I had in mind here!

Microsoft have finally found a way to extend their dominance of the PC to the web - via the C: drive. Now, your pictures in "My Pictures" will be automatically synched with Microsoft Live Photos whenever you turn your PC on. Why would you ever then manually upload them to Flickr? And your Office documents will be automatically synched with a personal Sharepoint that presumably enables document sharing. What's the point now of Google Apps?

Mesh finally makes the slogan "software plus services" meaningful. And they do it by using web standards - HTTP, ATOM and URLs. However, the remaining web standards - HTML, CSS and Javascript - are still being avoided on the client, in favour of binary files like Office documents. That will make it difficult to synch HTML documents created on the web (e.g. lists, and tables) back to the client.

This is definitely a half-way house. The only reason synchronisation is such an issue is that we're still storing data locally on clients, rather than in the cloud. But 50% web technology is much better than 0%, which is what Microsoft provide at the moment. Mesh will protect their Office monopoly for a few more years, but it will still surely crumble eventually in the face of HTML5 and CSS3. Microsoft are betting that Mesh will carry them over until they develop more competitive web applications.

Of course, if you have an Apple iPhone or Mac, or indeed use Linux, you will not synch with Microsoft. You will also have no need to synch with Microsoft if you already rely on full web technology, such as Google Apps. But if they can execute, Microsoft will once more be a force in Silicon Valley.

Language services on the web

Applications like Microsoft Word have embedded spelling and grammar checks for years. So Google's recent release of a web-based API for language translation made me think - just how far could these automated services go?

There are huge benefits to hosting language services on the web, rather than installing them locally on each PC. The clearest is the availability of enormous data sets. For example, it turns out that Google's spell check service is totally automated - there is no manually maintained database of words, it simply searches the web for common character sequences. The top 10,000 sequences must surely be correctly spelt words!

The same brute force data attacks could surely also provide a grammar check service. For automatic translation, you just need to analyse enough Rosetta Stones, where the same text is written in multiple languages. And Google has been operating a free telephone 411 service in the US, supposedly so that it can gather enough data (through recording people's voices) to eventually deliver good speech recognition.

It's also important whether a service is descriptive (merely the result of viewing how language is used) or prescriptive (defining rules for people to follow). The writers of the Oxford English Dictionary claim their work reflects the usage patterns of different words; entries in the dictionary are not meant as prescriptive rules, though it clearly helps if you want to be understood! This is important because a descriptive service could in theory be automated simply by analysing literary data, whereas descriptive services can't.

Finally, services that require a semantic understanding of language are clearly some way off.

Service	Authority	Enough Data	Semantics
Spelling	Descriptive	Yes	No
Grammar	Descriptive	Yes	No
Speech recognition	Descriptive	Not yet	No
Thesaurus	Descriptive	Not yet	No
Translation	Descriptive	Not yet	Maybe
Dictionary	Descriptive	Yes	Yes
Encyclopedia	Prescriptive	Not yet	Yes

This table is saying that pretty much every service could be generated automatically simply by analysing huge amounts of data, without the need for understanding. The only exceptions are translations, dictionaries, and encyclopaedias - and for translations, as Google has proved, you can still get a useful part of the way there.

The main takeaway is that there's one massively important side benefit of search engines that has yet to be fully appreciated; they revolutionise linguistics. In fact, they turn it from a mainly qualitative area into a quantitative science.

We now have the tools to analyse language variations as they spread through time and geography, or to discover the common elements in every language, or to watch how language style depends on context, using as a data set the entire internet!

If there's one thing that makes us human, it's language. Computers will help us to understand ourselves!

MSFT!

So it happened. Microsoft finally took the plunge and made a offer to Yahoo! they couldn't refuse.

Microsoft's reasoning is straightforward - they want to catch up with Google in the search and advertising business, which will require tens of billions of dollars of capital investment in the next few years. Sharing that load is a no-brainer; this is a game where scale wins.

Though Microsoft are focusing on the first two elements of Google's tagline "search, ads and apps" with their acquisition, I find their apps strategy - "Live" far more interesting.

Live has never seemed coherent. There is Microsoft live, Windows Live, and Office live. There is Hotmail Live, not to be confused with Windows Mail Live. All of these products overlap in confusing ways with their traditional client software equivalents. It's an utter mess, and it still seems to be going nowhere, perhaps due to cultural problems - Microsoft still don't seem to get the web.

Similarly, Yahoo's apps seem to have no connections or synergy between them, and they have a serious "peanut butter" prioritisation issue. However, in Yahoo's case, they at least own some incredible assets (Flickr, del.icio.us, Yahoo Mail, Yahoo Music), and some talented people that truly understand the web.

Hopefully the merger will force both companies to list their apps and place them in a simple, overarching framework. For example, a matrix with content types (text, raster images, vector images, audio, video) versus functions (CRUD, publish, collaborate, version, syndicate, search, store). That would even beat Google at their goal of features, not products. Because every month they dither, Google will move even further ahead.

Apple's strategy: iTunes

With their latest Apple TV product, Apple's strategy is becoming ever clearer: tie everyone to iTunes.

Want to synch your iPod or iPhone? Use iTunes. Purchase new music? Use iTunes. Rent movies? Display photos on your TV? Store your calender, address book and notes? iTunes is Apple's answer to every question about content.

This unsettles me. Apple's customers are tying all their data into a proprietary, closed client application. You might be able now to import Flickr photos into iTunes, but what are your chances of ever exporting them back?

At a time when openness is not just a buzzphrase, but a basic principle of many in Silicon Valley, Apple are probably the only major company still seriously trying to build a walled garden. They truly do 'think differently'!

I personally hope their iTunes strategy doesn't succeed. Their fabulous hardware and awesome user interfaces - in particular, the iPod Touch - are beguiling users into data hell.

Companies like Yahoo and Amazon have a massive opportunity to build a competing stack, based in the browser using open technologies such as HTML, RSS, and even the forthcoming HTML5 audio and video elements. Ironically, these very technologies have superb support in Safari, Apple's browser.

With iTunes, Apple are betting against the web. Time will tell whether this strategy works.

The rise of Webkit

Webkit, the browser engine for Apple's browser Safari, has had an incredible six months.

• First, the iPhone - the first mobile device with proper internet access that people like to use, based on Webkit
• Safari was released for Windows, and bundled with iTunes, ensuring a huge distribution
• Webkit is the foundation for Google's new mobile platform, Android, which will surely be massive next year
• Nokia uses Webkit for its Series 60 browser in its flagship smartphones
• The KHTML open source Linux developers announced they are merging back in to Webkit

From a standing start of 3% of browser market share at the start of the year, Safari is already up to more than 5%. I wouldn't be surprised if it reached 15% by the end of 2008, if its momentum (and Apple's) continues.

This is great for the internet. A popular open source project, a keen proponent of existing and forthcoming standards such as HTML5 and CSS3, the ability to innovate rapidly (including recently CSS animations and transformations!)

Good luck to Webkit for next year.

Microsoft's Internet Strategy

Microsoft is in a bind. It's just not competing with internet companies in search or advertising. It's having to compete against free and ever-improving open source applications like Firefox and Apache. Due to issues such as lack of standards compliance e.g. CSS, the company has lost its good reputation with web developers. It seems to be fighting too many battles, and hasn't convinced with its new suite of online applications, Live, which anyway could cannibalize some of its most profitable products.

Most of all, Microsoft hasn't figured out how to capture the internet wave. It's being totally left behind on the web.

I'd like to propose a solution. It's a web solution, and one that plays to values that Microsoft has always understood - "developers, developers, developers".

Why not offer a web-based version of Visual Studio - call it Developer Live - that hosts web applications? Go the whole hog - different language choices, bug databases, software configuration management, test environments on the fly, GUI design tools. Charge by memory & processor usage, with reduced rates for students.

This strategy takes advantage of their incredible expertise for development tools and server systems.

The market is enormous - every application in the world! It avoids open source, which can never pay for massive data centers. It builds a whole new developer ecosystem, and no-one else (except maybe Amazon) seems to be thinking about it.

Microsoft would then offer three things - apps (e.g. Office), development (Developer Live), and clients (e.g. XBox / Vista). That's much cleaner than today's sprawl. And most importantly, they would regain clear leadership of the most important platform in the world - the web.

Social Graphs and Unsocial Graphs

Tim Berners-Lee just wrote a wonderful note on the social graph. He points out that just as the "III" (net) connected computers, and the "WWW" (web) connected documents, the "GGG" (giant global graph) will connect real objects - including people.

So let's return to OpenSocial, Google's new social networking API. I already commented that it might (just) be an open API, but it certainly doesn't open the data - connections between people - which is the important thing. It shouldn't be only Myspace widgets that can securely access this information, but any website.

Tim's blog reveals a further issue - it's not just about connecting people, but connecting anything! OpenSocial doesn't seem to handle my CV, my possessions, my train tickets or what I ate for breakfast this morning. OpenSocial might be a small step forward, but it's not nearly the full answer - it only handles basic information about people.

Tim has clearly found a huge and important issue to resolve, and more people in the industry should be paying attention. Unfortunately, I just don't think they are.

Part of the issue is that he's way before his time - everyone is still focused on the document (HTML). Another issue is that his proposed solution, rdf, doesn't carry enough incentives for people to use it - I can't put adverts in rdf, I can't directly create compelling content with rdf, and anyway no applications take advantage of it yet. A third issue is that it's not clear how HTML (e.g. a Wikipedia entry on breakfasts) would sit alongside rdf (some XML technical markup that describes the same thing).

There is a way out. Create a new open data format standard that describes a person (Google have made a start on this already with GData), and add it to OpenSocial. Make this data format compatible with RDF, e.g. FOAF. And finally, hand the data over to the user - it's theirs to manage.

That way, at least one usage of RDF will take off - information about people and their connections. OpenSocial will gain new momentum, since the data will be free, not just the API. And finally we'll have a springboard for the graph - not just social ones, but any graph - to take off.

The new iPhone SDK will be Safari

Apple's recent announcement of a native iPhone SDK seemed a massive U-turn; first Steve Jobs promised pure web development, then he relented. But I suspect their native SDK will in fact be an upgraded version of Safari - web development on steroids!

There are several reasons why web applications failed the iPhone:

• Connectivity - endless waits for page load over slow and uncertain EDGE networks
• Presentation - browsers can't handle coverflow, smooth animation or rotations
• Awkward audio and video - no flash plugins lead to messy javascript solutions
• Memory access - you can't access the phone memory using javascript
• Sensor access - you can't control the camera, microphone, touch sensor or proximity sensor using javascript
• Cultural - people still expect the mobile web to be crap

Within the last month, a series of announcements have led me to believe that Apple will chip away at all of these issues.

Safari have already announced local SQL database support, which is part of the draft HTML 5 spec. Combined with other HTML 5 sections like caching, this would solve the connectivity and memory issues above, allowing offline access via local memory.

David Hyatt, the lead Safari developer, has also hinted (see comments) that perspective transformations (enabling coverflow) will shortly become available in Safari. CSS animations and affine transformations, including rotations, have also been added to the beta version of Safari.

Now, Safari have announced support for HTML 5 media, bringing first-class audio and video to the iPhone's browser.

Putting two and two together

I just can't see why people aren't putting two and two together! The only remaining technical issue with using Safari as a client development platform is access to the iPhone's sensors - so I fully expect Steve Jobs to announce a javascript API in January's Macworld.

It also provides another reason why Apple released Safari for Windows; they're building a browser competitor to Windows, and they need maximum distribution to persuade developers to use the new web SDK.

For Apple it makes good sense to convert the browser into an OS; they sell hardware, and they get to ride the internet wave. Safari as the client development platform is the classic disruptive innovation!

OpenSocial isn't open enough

Google's OpenSocial has attracted enormous publicity over the last week - it's seen as the entry of the big beast into social networking, fighting Facebook and Microsoft by transforming the rules of the game.

But I honestly don't think it has changed the rules of the game. The API is only 'open' in the sense that lots of companies have signed up to using it - it does pretty much the same as Facebook's API, albeit using HTML rather than Facebook's weird proprietary markup.

It's the basic premise that I disagree with - that social networks are 'container' applications, within which every other application is hosted, as a 'widget'.

The problem with apps hosted INSIDE social networks is that you get data silos - not everyone I know is in Myspace, and they never will be.

Instead, we need apps that work ACROSS social networks, gathering the relevant friends and details from each to provide the complete picture - e.g. a complete address book.

Writing one of these apps is not about data storage, it's about data aggregation from all across the web. For example, a photo editing website should allow you to import your friends and colleagues from ANY social network, to allow you to collaborate on a picture. That's not possible with OpenSocial.

Of course, I'm sure OpenSocial will be extended in future. Since Brad Fitzpatrick is reportedly behind both OpenID and OpenSocial, I wouldn't be surprised if we see some immediate progress on this front from his employers Google. If my URI for OpenID is the same as my URI for OpenSocial, then whenever I log in someplace, it gets automatic controlled access to my details.

So OpenSocial gets us some of the way there, but the vision is still not complete - it may be a relatively open API, but it currently enforces a closed data model.

Web Communication

Technology is there to enable people to do things. So, if you want to write a successful application, it's worth asking what things people like to do! And there's one answer that has proved itself time and time again - people like to communicate.

The killer apps of the internet have always been communication tools - starting with email, moving to webmail, instant messaging, blogging, Twitter streaming, and most recently social networking.

So how far has the web come in enabling communications? I put chart together to work this out.

Communication types

Timing	View	Add	Method
Asynchronous	Private	Private	Notebook
Asynchronous	Private	Public	Email / Voicemail
Asynchronous	Public	Private	Blog
Asynchronous	Public	Public	Wiki
Realtime	Private	Private	Dictaphone, CCTV
Realtime	Private	Public	Instant Message
Realtime	Public	Private	Twitter / TV / Radio / Webcam
Realtime	Public	Public	Phone / video conference

The most obvious thing to note is that every cell in the table has something in it, so there are no obvious gaps - but many are filled with very recent technology, and it's still changing very quickly.

Secondly, the table drives home just how important and useful the Atom Publishing Protocol is - starting from blogging, it is spreading to all the asynchronous types of communication. That shows some foresight from Google, who have based their architecture around the standard.

Thirdly, realtime communications technology seems less mature. That's not a surprise - HTTP was designed for the asynchronous request / response pattern. So it will be interesting to see how this piece develops.

CSS and XPath selectors

Many people have noticed the similarities between CSS selectors and XPath - and it's fair to say that XPath is far more powerful.

In fact, XPath can do pretty much anything that CSS can, plus much more.

select the parents of all paragraphs:

//p..

select alternate list items:

//ul/li[position() mod 2 = 0]

select table cells with a value less than 10

//tr[number(td) < 10]/td

Yet another CSS wish - XPath stylesheet selectors

No existing browsers have XPath enabled inside stylesheets. But wouldn't it be great if they did?

All it takes is a new CSS selector - XPath(string), where string is an XPath expression.

For example, selecting paragraphs containing the word 'Chris':

XPath("//p[contains(., 'Chris')]") {border: 1px solid black}

Of course, XPath doesn't itself handle pseudo-elements or pseudo-classes like :hover - but we can mix and match the XPath function with other CSS (e.g. colouring any hovered paragraphs containing two hyperlinks):

XPath("//p[count(.//a) = 2]") :hover {background-color:red}

And it can work with other selectors too, e.g. finding <ul>s directly underneath any <p> element, and shading them alternate colours:

p XPath("ul/li[position() mod 2 = 0]") {background-color: white}
p XPath("ul/li[position() mod 2 = 1]") {background-color: silver}

Following the usual CSS rules, if the XPath function contained mis-formed XPath, the style could be ignored. Also, it would be ignored if it returned anything other than element nodes (i.e. no attribute nodes or strings). And the default starting node of the XPath query is the document element, unless clarified by preceding CSS selectors.

Why not implement it?

As you can see, just by adding a single new selector, the CSS language is extended in so many ways.

XPath has already been agreed as a W3C recommendation, and has already been implemented in the major browsers.

I therefore see no good reason, other than inertia, why such a powerful new feature can't be added as soon as possible!

Data mismatches

Over the years, each of the traditional system tiers - database, web server, browser - has grown more powerful, reliable and manageable.

The problem is, they still don't work with each other well!

I still haven't seen an elegant way to create object oriented code from queries of relational tables (although LINQ comes closest).

And using objects to manage semi-structured, hierarchical HTML doesn't work nicely either - that's why the DOM is so ugly.

Finally, placing (X)HTML neatly in a relational database is very awkward, although that hasn't stopped vendors from attempting it.

Different forms of data

That's because they all use different approaches to model data - table, object, and document.

Each approach has many advantages, each requires a different technical skill and personality type to use, and each works best in different circumstances. Unfortunately, they don't work together particularly well.

Can this last?

At the moment there are a few creaks, but no cracks. The creaks are

• The success of scripting languages like PHP in managing documents, rather than formal object oriented code
• Buzz around REST, which uses URLs and HTTP to store (and even edit) data, hiding the underlying relational database
• Relational databases increasingly outputting XML, rather than proprietary data

Another approach - REST, XQuery

It is now (just) possible to use the document approach throughout every tier. It makes code enormously easy to write and maintain, and it fits perfectly into the web.

You wouldn't want to do this for data-intensive applications, such as handling financial market data. But for document-intensive web applications, such as social networking, blogging and photo-sharing, it's perfect.

The idea is to follow the REST approach:

• carefully construct a URL for every resource important to your site
• decide which resources require create, review, update, and delete (CRUD) permissions
• enable HTTP PUT, GET, POST, and DELETE commands against these URLs

Even if these resources are eventually stored in a relational database, this approach totally shields the relational viewpoint in favour of the document.

You can even write most of the server-side code in XQuery. The advantage of doing this is that it fits perfectly with (X)HTML and REST - you can GET documents, extract the relevant parts using XPath, and insert them into page markup using straightforward inline code. No object orientation in sight!

After all, server-side code does four things:

Action	Technology
read / update a database	REST, HTTP
get / set HTTP headers	XQuery functions
manage sessions	XQuery functions
construct HTML output	XQuery, HTML

It's very useful if you've got a huge number of URIs (as per REST) - you just have a central application that parses the URI and returns the appropriate mashed-up resources. XQuery is good at this parsing and returning.

One for the future

Unfortunately, the technologies behind REST and XQuery are still very immature and there isn't much support from libraries, documentation, or tools.

And given the immense standing base of relational databases and object-oriented code, and their use in so many different areas, I can't see their support diminishing soon.

That's ok - the point is that new ideas are still bubbling forward for improving developer productivity. SQL and OOP both pre-date the web; they have survived well, but it's always worth taking a step back and asking if there's a better approach.

Microsoft still don't get it

quote this week from their CEO:

Ballmer explained that Microsoft already is rearchitecting its core platform to be more of a Web-centric one. As he told the Partner Conference audience, “the programming model stays .Net and Windows.” But beyond that, Microsoft is is redoing its products and business models from scratch.

How do they expect to be Web-centric, if they're using tools for programming client-server? What's wrong with HTML, javascript, RSS, and dynamic server-side languages like PHP? Google must be laughing all the way to the bank.