XForms has a problem

XForms is the W3C’s XML language for programming forms on the web. It handles new user interface controls, better data validation, and easier form submission.

It does this by strictly following the "MVC" approach to data management – a ‘model’ is stored in the XHTML head, containing data structures bound to user interface form controls. When you enter values into the form controls, the model automatically updates too, and it’s the model that gets submitted.

In order to get the model to work, XForms defines an incredibly powerful binding engine, like a spreadsheet where cell values can depend on each other. It’s here that I have the problem. Why is the binding technology written inside the XForms spec? It’s useful for so many purposes (e.g. spreadsheets) that have nothing to do with forms – or even XHTML - and it stands on its own as a fundamental use of XML.

For example, I might have an SVG document where I want to bind the width of a circle to the length of a line. I can’t use XForms binding, because it’s not an XHTML document and even if it was, I don’t want to follow the MVC approach.

So, the tag should be pulled out of the XForms spec and put in a new XML bindings spec, that doesn’t force you to follow MVC (or even XHTML).

That way, all XML developers will gain a new technology that provides so much value, especially in animations. And XForms will become much simpler, and more targeted towards its role in enabling web forms.

Web Office suites and Vector Ajax

I’ve already argued that the lightweight web office suite will gain popularity, but not as separate presentation, spreadsheet and word processing applications, but one integrated application that caters for all three.

This application will have to take advantage of Vector Ajax – the use of inline VML / SVG to store and transfer data. That’s because it will allow lines, circles and more complex shapes to be drawn on the page.

VML / SVG is perfect for the task. It’s accessible, part of the DOM, and contains all the functionality you need (plus more) to handle drawing and annotations. In comparison, Flash doesn’t offer the same integration with the DOM – any office website will be a combination of HTML and graphics.

In fact, the <foreignobject> element in SVG is also perfect for displaying the "slide sorter" view, where you can see all the slides scaled down together and re-arrange their order.

I’m very surprised that there haven’t been more start-ups offering web presentation suites. After all, presentation software translates very well to "road warrior" types that have internet access, but no corporate LAN access. I suppose this is partly because the technology is quite a rare skill (SVG / VML) and tricky, due to differing implementations on each platform.

Maybe Google, as rumoured, will offer a presentation application as part of Google Apps.

When this happens, we’ll see the next phase of vector graphics adoption on the internet.

Browser Acceleration and Orientation

Perhaps the most revolutionary thing about both the iPhone and the Wii is their ability to detect acceleration and orientation. The iPhone automatically converts from landscape to portrait mode depending on which way you hold it, and the Wii was designed to allow tennis strokes, golf shots or boxing matches simply by moving the control.

Ideally, the same functionality should be available on the web. You can imagine a browser that

• Rotates between landscape and portrait mode, depending on device orientation
• Scrolls up, down, left and right based on device acceleration

But what if the web developer wanted access to the same information? You can imagine websites that

• Display maps, orientated to the direction the device is pointing at
• Provide games based on "pointing", e.g. golf games
• Provide games based on "moving", e.g. tennis games

The web developer will want to be able to access acceleration and orientation information, and use it to alter HTML, SVG or Flash.

Unfortunately, there's no standard for this on the internet. There is, however, a fairly obvious place where it could go - the javascript event object. In the same way that this object stores the current mouse location (for devices with mice), you can imagine it also storing x, y, and z axis acceleration and orientation (for devices with accelerometers and gyroscopes).

One interesting question concerns privacy. Does it matter that someone could track the orientation or acceleration of your phone, if you were logged on to their website?

Personally, I can't see this happening soon - the demand just isn't there yet. But once phone browsing takes off, after two or three years, it will be very interesting to see how this field develops.

In the meantime, the W3C should look at extending their standards to allow for acceleration and orientation. And phone browser providers, such as Opera, should consider upgrading their browsers to take advantage of the latest in user interface design.

Too many browser menus

Despite the huge recent improvement in browser interfaces – tabbed browsing, inbuilt search, RSS favourites, etc – I still think there’s a long way to go. In particular there are way too many inconsistent menu options.

Using Internet Explorer or Firefox, running on Windows, there is

• A title bar menu allowing minimize / maximize / close
• A standard menu, e.g. file / edit / view / tools
• A set of browser commands, e.g. back / forward / refresh / homepage
• An address bar
• A tabs menu

What’s more, they’re all inconsistent – some open new web pages, others open dialog boxes, others execute some action on the existing web page.

The result is that half the screen gets taken up by confusing options and buttons before the content itself appears.

So what hope does a web application like Google Spreadsheets or SAP (themselves containing another two or three menus) have?

I think it’s time for a rethink. So I’ve listed some principles to re-organize the browser.

1. Use a ribbon bar The old file / edit / view / favourites / tools / help menu should be replaced by a new ribbon bar. Ribbon bars are simple, clear, and effective, and would merge the currently overlapping file menu and buttons underneath.

2. Hardware for common options The most selected browsers button are undoubtedly “back”, “forward”, “refresh” and “home”. In fact, they’re so common, and natural, that they deserve their own hardware.

The buttons F1 through F12 on the keyboard are rarely used and even more rarely understood. Why not replace them with “Back”, “Forward”, “Refresh” and “Home” buttons? This would free up screen real estate, and avoid unnecessary and error-prone mouse use.

The benefits are even bigger on touch-screen interfaces like the iPhone – you can imagine the standard buttons fitting underneath the screen.

It’s likely to be hardware vendors pushing this change. But Microsoft managed to get the new “Windows Start” button implemented, and a similar trick now could allow them to claim innovation and alignment with the internet.

3. No dialog boxes Dialog boxes crop up throughout browsers, especially in the tools and options menus. They’re not accessible – you can’t change font settings or view source – and they’re visually confusing, since they look different to web pages.

All these dialog boxes should be replaced by web pages that open up within the browser. There should be a local web page to allow you to edit connection settings or security options. And why doesn’t browser help open in the browser?

4. Reclaim the home page This is the most controversial principle. Your homepage should be set by the browser – you shouldn’t be allowed to change it to anywhere else, whether Google or Myspace.

On the homepage should be:

• Your favourites (editable)
• Your RSS feeds (editable)
• Your history (with options to delete it)
• Browser options (editable) – e.g. connection settings, security settings, view settings. Some of these will take you to other pages for more detail - see principle 3 above

5. Lose the title bar What use does the windows title bar have, for browsers? It tells you what the title of the page is – but so does the tab bar. It allows you to minimize, maximize, or close a window – but so does the tab bar.

Once you’ve got tabbed browsing, there’s absolutely no use for the title bar. In fact, it gets in the way – not only does it take up screen real estate, but it makes mouse control trickier (it’s far easier to select a button at the top of the page than one 12 pixels down).

So let’s get rid of the title bar!

Simpler, clearer, more concise So there you have it – five principles to get rid of the clutter of modern browsers. There’s plenty of innovation still to come in browser design!

Google Mobile Phone

Current rumours suggest Google is preparing a mobile phone. But I would be very surprised if Google got involved in designing hardware - it's not their core competency. Instead, I think the focus will be on a phone communications suite that revolutionizes the way we manage our inboxes, contacts, and calendars.

After all, the excitement surrounding the iPhone proves that people are looking for a better way to manage their personal communications. Blackberries are too corporate and clunky, phone address books are lost when you get a new phone, PC synchronization is a pain, and emails, voicemails, and text messages are all handled in different ways.

So it's worth asking what a mobile phone communications suite, done properly, would include:

• A unified inbox - email, phone / voicemail, IM, text messages - that synchronizes with Gmail
• A unified contacts database / phone address book, incorporating presence information, that synchronizes with Gmail contacts
• A calendar application, incorporating alerts, that synchronizes with Google Calendar

All of this could be achieved using just the phone's web browser, local HTML pages, and synchronization software to transfer data between the phone and Google.

In fact, most of the synchronization software already exists - GData, Google's Atom store of calendar and contacts information. All that's required is an application on the phone to acccess it.

By implementing these ideas, Google would be playing to their strengths - they understand the internet, and this approach brings the basic internet tools of the URL, HTTP, HTML, CSS, and Javascript to the mobile phone.

Immediately, Google would lock in new customers to Gmail and Google Calendar. And one day, I'm sure you will see Google adverts alongside your phone's address book

Personally, I'm excited by this vision. I long for the day where I can access my personal data from any device, especially one as handy as the phone. Let's hope Google follow their instincts and bring the internet to the mobile phone.

Enterprise IT and Business Processes

How successful is enterprise IT? Very successful, most business people would say; look at the boom in US productivity during the late 1990s, or look at the market capitalisation of the IT industry, or even the massive growth in IT-intensive industries such as financial services.

But to truly answer this question, you’ve got to ask what the goal of enterprise IT is – and measured against this goal, I don’t think enterprise IT is successful yet at all.

There are many definitions of what corporate IT is for, but nearly all of them paraphrase “IT is there to enable the business’ processes”. Only once you’ve understood the business processes, should you apply IT to make them faster, better, and cheaper.

There still isn’t a good way to fully document (in business terms) a process, and quickly and easily convert it into a working application, and back again, no matter what the UML / BPEL folk say.

That’s because, ironically, IT hasn’t yet properly automated its own processes. The most basic IT process is the one that starts with a set of requirements, and ends with a working application. This process is very manual and prone to massive cost, scope and time overruns.

We’re missing the spreadsheet of the 2000s, where business users could go in and create a quick application to support their needs.

Neither of the existing approaches (buy a process off the shelf via SAP or Oracle, or create your own using a BPMS) really does it for me. If you want a competitive advantage, it makes sense to stay clear from SAP; and BPMS are still some way off their end goal.

Fortunately, there’s plenty of years left of incremental improvement before we need a breakthrough. In the meantime, enterprise IT will have to get used to mediocrity.

Virgin Media, BSkyB, and network monopolies

The recent spat between Virgin Media and BSkyB is partly a battle of billionaire egos between the bruising Rupert Murdoch and the self-styled plucky underdog Richard Branson. It's resulted in customer anger as Virgin Media's cable (previously NTL) stopped serving Sky TV channels, in a disagreement over fees.

Now the regulators are stepping in, and they have some very interesting questions to ponder. Should cable companies be forced to open up their distribution networks to competitors?

Of course, this is a question that applies in many industries. Should gas, water, or electricity companies be forced to open up their national networks to competitors? Should telecoms companies be forced to open up their national communications networks?

It's all about preventing monopolistic behaviour. And its a delicate balance - often, for example with water utilities, the technology seems designed to lead to natural monoplies.

But now the interent is starting to shake up the TV industry. It's the new distribution method for video (and much else), and it's very first principle is that anyone can request any URL. So, despite BSkyB buying up ISPs, they can't prevent their customers from accessing YouTube or www.bbc.com. And anyone using Virgin Medias' broadband will still be able to access Sky TV online.

I've already argued strongly that the industry will split between content generation (e.g. Sky TV) and content distribution (e.g. your local ISP). I just can't see what the synergies are for vertical integration.

So perhaps the regulators can afford to overlook the Sky TV spat, in the knowledge that the internet will soon recast the whole problem.

And more importantly, the consumer can look forward to the day when all media is available online, and the media companies won't be able to do anything about it.

XML Events 2.0

The latest draft of XML Events 2.0 contains a new, simple, and very powerful idea - allowing XPath to handle events and even animate elements.

But there are a few ways it could be extended even further.

XPath observers

Firstly, the draft spec hints that the "observer" attribute could in future be used to give any URI, not just from the current document. But it would be far better to allow an XPath statement, rather than a URI. Then you could specify a whole set of nodes. For example, consider:

<.script event="mouseclick" observer="//img">.
  document.getElementById("paragraph2").style.fontSize = "5";
<./script>.

which uses the XML Events namespace "ev" to alter the paragraph font when any image is clicked.

XPath event() function

Secondly, there's a new XPath event() function, which coupled with the new "while" attribute allows for animation. Consider this implementation of drag and drop:

<.script observer="//img" while="event(button) =1" />.
left="event.clientX";
top="event.clientY" 
<.script/>.

Not bad eh, especially compared to mountains of javascript. The new XPath event() function allows you to figure out mouse position and even the time when the event occured - which is very useful when it comes to animation and controlling timing.

<.style observer="//img" while="true()">.
./@css:left = //div1/@css:left + 10;
<./style>.

Note the "style" element - this is just a CSS stylesheet using XPath. It positions each image 10 pixels to the right of the div1 element. If the div1 element is moved, then the images will move to maintain their relative position.

There are two benefits to this approach. Firstly, rather than using CSS selectors, you can use the full power of XPath to indicate the elements being styled. And secondly, you can use all sorts of XPath functions to assign values - like avg() or sum() or even sin().

XPath + XML Events

So I would urge the XML Events authors to extend the use of XPath in their spec. Firstly, XPath should be used in the observer attribute, to allow any collection of elements to be handled. Secondly, please keep the new event() funtion - it's great! And thirdly, XPath should be used to allow the animation of XML values.