Purchasing in the browser

One of the real benefits of App Stores versus the web is that purchases are so much easier - all you have to do is click on a link (and type your password to validate). Contrast that with the web, where every site has a detailed form to fill out - and sometimes you have to fill it out all over again, if "Verified by Visa" has anything to do with it.

Would it be possible to streamline procurement on the web? I think it could, using a browser-based "account store":

• Browser stores account details and exposes API for giving them to web page
• When web page calls API, the user is asked for confirmation (and can select which account to use). E.g. "This site wants to know your account details for a purchase - give them? If so, which account? Type your password to confirm"
• Account details are sent to page in standard format and used to automatically fill out form

This approach is simple and would work easily with existing sites, automatically populating all the fields. What's more, it allows the browser to help the user out - for example, listing all sites that have been granted access to their account details.

Unfortunately, once account details have been given out, it's difficult to control what the site does with it - they could be passed on to a bad guy, whether intentionally or not.

Here's a better approach:

• Banks could generate a new unique account number with each purchase. This account number would only work once and also has a brief expiry time, e.g. 1 hour.
• When a site requests your account details, the browser automatically requests your bank for a new account number, which is then given to the vendor. The vendor cannot then re-use the details or leak them to anyone else.

Mobile operating systems

We’ve gone from mobile operating systems not mattering, to everyone wanting one of their own: Google – Android; Samsung – Bada; Microsoft – Windows Phone; Nokia – Symbian, Meego; Intel – Meego; HP / Palm – WebOS; Apple – iOS. Compare that with the number of desktop operating systems!

This is a gold rush into the new markets opened up by the iPhone. There are two reasons to have your own mobile OS:

• Differentiation from other manufacturers – providing a unique interface and features to go with your hardware
• App Stores – make money by establishing your own App Store, selling apps along with the phones

So what happens next? Obviously, consolidation. In fact this is already happening in some areas – for example, Linux and Webkit are the foudation of many of the above operating systems.

Manufacturers will always have a need for software differentiation; they’ve learnt this through years of having to using Windows. But I don’t think they can all have App Stores with different development environments. Developers will simply not learn more than two or three.

The most obvious way to overcome this problem is to make the development platform be web standards (HTML, JS and CSS), which developers already know. This tactic is likely to be deployed by the weaker platforms, both to gain a foot up and also to undermine their more successful rivals with a common standard. It’s already been pursued by Palm with WebOS, and now Nokia are also using it with Symbian. I would expect only two or three development environments to survive that are not primarily focused on web standards: Apple’s iOS, Google’s Android (ironically, given that companies’ supposed focus on HTML5), and maybe one more.

This is likely to lead to even faster development of browser engines in the next couple of years, as mobile investment pours in. The net effect will be that the browser becomes as powerful as any native app – and, ironically, app stores will simply become websites that cost money.

One more prediction – Firefox on Mobile will be surprisingly successful. It’s had a very slow start; in fact it’s been written off in favour of webkit by almost everyone. What’s more, it will only be available on Android and Meego for the next year or two. But it’s got one major advantage: it’s not just a browser engine, it’s the chrome as well.

The current state of mobile browser chrome is terrible – features that are standard on the desktop (such as automatically remembering passwords, or auto-completing the address bar as you type based on browser history, or blocking adverts, or allowing add-ons) are completely missing on mobile, even though they should be even more important in that environment to help manage limited screen size. So I expect Firefox to take advantage of other’s complacency and inexperience and make a real impression, just as it did initially against Internet Explorer. This will likely happen over a period of two or more years as native browsers lag, then finally notice they must invest to catch up.

In a few years, then, the mobile market will have evolved substantially. Common standards based on the web will unite the weaker players against the top two or three platforms. App stores will become more like websites that cost money. And, after a hiatus, browser design will re-establish it’s importance.

Open source systems in government

In 2009 the UK government announced a new approach to open source. It ensures that open source is treated on a level playing field with proprietary solutions. But I think the government should go much further and use open source as the foundation for its core systems.

It's clear that our current approach to government IT is badly broken. Taxpayers have suffered £26bn of losses as a result of a string of computing disasters involving massively late, over-budget, and broken systems.

We must move to a new model that avoids the reasons behind this catastrophe: reliance on massive system revolutions rather than incremental improvement, lock-in to vendors, a lack of government understanding and control of IT, and the dominance of large suppliers at the expense of small and medium sized businesses.

Contrast this approach with open source groups such as the Linux Foundation or Mozilla. They also develop complex software used by millions of people around the world, following these principles:

• An army of developers, from huge corporates to individual developers in their spare time
• A community of developers, carefully cultivated and encouraged by the foundation, with shared values
• Total freedom from lock-in, using open source licenses
• Focus on steady evolution rather then complete revolution

In this approach, the major government departments should set up their own IT foundations, with carefully written missions and a budget to encourage community participation (via public prizes, conferences, and total openness in the technical approach). Individual workers, or small, medium and large businesses alike could volunteer to develop the code, as a charity or in the hope of being hired full time.

There would be two additional benefits to developing open source government systems. Firstly, governments around the world could share development costs by contributing together. This could save the UK government huge amounts in the long term. Secondly, building a community of government IT developers in the UK would provide a huge benefit to the economy - building the skills and experience of volunteers (including students) in just the areas likely to require staffing.

So I believe it's time to get much more ambitious about open source in government. We should be using it not just to purchase cheap infrastructure, but to actually lead the development of core systems. Doing so would help free us from many of the issues plaguing government IT, but also provide a real public benefit to the citizens of this country.

SVG can't be part of the web

Microsoft's announcement that IE9 will be supporting SVG brought rejoice to many web standards aficionados. SVG 1.1 was finalised in January 2003 but Internet Explorer's previous lack of support meant that it has never really taken off on the web, despite years of patient enhancement by open source advocates.

But although I'm also an open source and web standards advocate, I still don't think SVG can ever be part of the web, because it just doesn't fit. We need a better solution.

Consider the following points:

• SVG has a totally different coordinate system to HTML - you can translate SVG coordinates but not HTML ones, and vice versa. So SVG and HTML won't sit well in the same document
• SVG has a totally different layout model to HTML. It's incompatible with CSS floats, which are fundamental to laying out HTML web pages.
• SVG has a totally different version of CSS which overlaps at best with HTML. For example, it has a "fill" property (rather than "background-color"), and it can't be positioned using CSS.
• SVG introduces duplicates of many HTML features - most notably, the hyperlink!
• SVG has a different DOM to HTML.

If you only want a vector format for image files, SVG is ok (though HTML Canvas can do everything SVG can). But if you want to use SVG to layout and style web pages, it's a terrible kludge.

I believe there's a better way. Going through the SVG table of contents:

Coordinate systems, Transformations and Units

Already covered by CSS3 Units and CSS Transformations

Paths

Not possible in HTML

Basic Shapes

Rect, Oblong and Circle are possible in HTML using CSS border radius. Polylines and Polygons are not.

Text

HTML already does text better than SVG

Painting: Filling, Stroking and Marker Symbols

Filling and Stroking are possible in HTML using CSS background-color and color. Marker symbols are not.

Color

Already covered by CSS color

Gradients and Patterns

Covered by CSS3 gradients and CSS3 backgrounds

Clipping, Masking and Compositing

HTML allows clipping and opacity, but not masking or compositing.

Filter effects

Not possible using HTML

Animation

Covered by CSS3 transitions and CSS3 animations

Fonts

Covered by WOFF

So, much of what SVG does is actually already possible using advanced CSS and HTML. So why not just extend CSS a bit more and you'd get all the power of SVG inside HTML, but without needing a whole new markup language? What's more, you'd then be able to apply all these techniques to existing HTML elements, not just SVG ones.

For example, imagine a set of CSS properties which allowed you to modify the shape of any HTML element - not just rectangles, but any shape you could think of. That would be better than introducing new SVG markup for shapes, because you could modify existing HTML semantic elements such as headings.

That's why supporters of the open web should not put their hopes into SVG. To be frank, it doesn't do what you want it to do. A much better approach would be to continue to extend CSS so that it doesn't take new markup to achieve better presentational effects.