Electronic money and new User Interfaces

2007 is shaping up as the year of the new user interface. First we had the Wii, then the iPhone, and now the Economist is briefing us on the end of cash – apparently we will soon be swiping our mobile phones against retail terminals to pay for things.

The Economist pictures consumers swiping their phone, checking the details of their purchase on its screen, and finally clicking ‘ok’ and typing their pin number on their phone keyboard. They could also use their phone to check their bank balance.

Swiping a device is a wonderful user interface metaphor. It’s a physical way of requesting something – pointing to it and saying “I want this”.

Done via the web, the object you’re purchasing is represented at a URL. And swiping your phone is requesting that URL in your phone’s browser. This brings up a web page describing the object.

To achieve this in today’s browsers, you have to type in a URL, or click on a hyperlink. I see swiping as another method of doing this, which avoids fiddly typing – you a requesting a specific web page by reaching your hand out to the resource it represents.

Of course, on the web page is a form for confirming the details and authorizing the purchase. This is easily achieved using simple HTML.

What I’m proposing is that the technology of Near Field Communications (NFC) is based on the internet. The data is represented in HTML and transported via HTTP.

There are several benefits to this approach:

• Modern phones already have browsers, and HTML allows the use of images, styling and sophisticated user interface elements that consumers are already used to
• Retail groups already have web infrastructure in place advertising their products and services
• HTML allows tailored web forms, for confirming details and entering authorization.
• Web security measures such as SSL and secret password fields can be reused.

Enhanced security

As it stands above, the security model is the same as used on the internet today. But there are ways to make it even stronger.

Because the mobile phone is uniquely personal, it can be used to provide extra authentication of the user. Many people have suggested using the phone in two-factor authentication. Usually, this is where you type in a pin number, the phone uses it to generate another number, and this second number is submitted. The phone updates its algorithms every minute, so the second number will only work for a minute – then it is useless.

I would suggest a new HTML Form element – the “pin” input element – where the browser should carry out this algorithm automatically based on whatever is typed in, so that the second number is submitted.

That way, the “swipe” becomes even more secure than normal internet transactions.

Business Model

Will the bank or the phone company handle these transactions?

In line with previous posts, I think it’s very difficult to see the phone company as anything other than the bit pipe along which data transmission occurs.

That’s because phone companies don’t have the expertise to handle financial risk, or the willingness to be regulated as banks.

However, I can certainly see phone companies making a tidy sum by creating exclusive deals with banks to handle the transactions, or at least by providing a default bank. In some cases this could be a white-labelling service, with a bank handling the underlying transactions under the banner of a phone company.

I can also imagine my phone offering me choices – for that sofa, I could choose to use a selection of credit cards, rather than my usual bank account.

And there are opportunities for retailers to learn more about their customers. Rather than having to issue “club cards”, why shouldn’t they simply associate membership with your phone? Whenever you make a purchase, this gives them more information about you, and allows them to supply tailored adverts and special offers to your text message inbox.

The power of the swipe

What could be more intuitive and simple than swiping at something to request it? By combining swipe technology with the internet, payment systems will be revolutionised, providing many benefits to consumers and retailers.

Web Office Suites

After a decade of inactivity in the office suite industry - other than Microsoft raking in billions - suddenly there is lots of news. Now we need a brave soul to question the underlying applications themselves - the word processor, spreadsheet, and presentation.

I've already posted on the rise of OpenOffice, its standard XML Format, and Google Apps. Each of these has a momentous effect on the industry - I predict that 80% of people will find browser-based suites provide all they need. Desktop suites will be consigned to power users.

But what hasn't changed is the basic package - word processor, spreadsheet, and presentation software.

I think it's time for another look at this triumvirate. User interfaces have moved on massively since then, and so has the underlying technology; HTML, CSS and javascript are great general purpose tools. The internet is a distribution model that supports new ideas and niche applications.

So why not start from the beginning? What do people use office applications for? Does it truly split into three different use cases (spreadsheet, word processor, and presentation)?

I often see spreadsheets with paragraphs of text in them - which surely is best done in a word processor. And I've lost count of how many word documents or presentations with embedded tables of data I've seen.

So why not combine them all into one application? Imagine a WYSIWYG web page editor, where you could drag and drop text and shapes around the page. And further, imagine you could add tables to the page - each having full spreadsheet power (functions, financial / date-time formatting, sort, filter, etc). Just like spreadsheets, each table cell can depend on any HTML element on the page (or any other URL) for its value.

It isn't too tricky to combine applications if you leave out the bloat - adding power user features is the main approach Microsoft has taken to persuade us to upgrade.

And by combining applications into one, users are freed from having to make the choice of format (is this a Word Document or Powerpoint deck) that often seems arbitary at the beginning.

Microsoft themselves often hinted, during the 90s, that the future lay in integrating office applications. In the end, they settled with clunky COM components, inserting for example whole Excel spreadsheets inside Word documents, which is visually a mess.

I've played round with a few concepts and reckon that it's easily possible to write a combined suite using simply HTML, CSS and javascript (with VML / SVG to support drawing).

So come on, does anyone fancy helping me create a concept website?

HTML menus

Menus - like the file menu at the top of every application - have always been tricky to code in HTML. They involved reams of javascript and endless workarounds for the deficiencies in each browser.

The HTML 5 working group are talking about a new HTML tag to enable menus. This would be great, but for now, why not just use the ordered list tag <ol>? After all, that's what menus are - ordered lists.

So it's a great relief to see menus done properly - with no javascript in sight, just the <ol> tag and some CSS.

But before we congratulate ourselves on proving the power of HTML yet again, it's worth asking what menus are for in the first place.

I count three uses:

1. Site navigation hyperlinks (e.g. the left hand pane of http://www.microsoft.com/sql/default.mspx)
2. Standard application menus (e.g. the MS Word file menu)
3. Context-sensitive application menus (e.g. right mouse button options)

On the web, most people just think of the first use, because web pages still aren't seen as applications in their own right. For those using web-based spreadsheets, however, uses 2 and 3 are more important - rather than navigating to different pages, the menu options manipulate the existing page.

Most desktop-based applications are just as poor at menus as web-based ones. Even commonly used ones - such as Internet Explorer itself - do a bad job here. There is a very complicated File-Edit-View-Favorites-Tools-Help, there are the standard buttons (back / forward / refresh), there is the address bar plus optional extra bars, and only then do you get the page itself, which will often have its own menus too.

So Microsoft is due some praise for recognizing this, and innovating with the new Office 2007 ribbon, which combines uses 2 and 3. Maybe they did it to stay ahead of websites like Google Docs; if so, the effect was diminished by successfully mimicking it in the MS Office website!

How is a ribbon menu best achieved on the web? Well, in theory, just using additional <ol> tags and CSS. In practice, this is a nightmare without a properly CSS-compliant browser; even Internet Explorer 7 falls somewhat short. But never underestimate the resourcefulness of web developers - there's plenty of innovation to come using existing tools. I wouldn't be surprised if ribbons started appearing on websites very soon.

Context-sensitive menus are by far the rarest on the web. In Google spreadsheets, an HTML menu opens up when the right mouse button is clicked on a cell. To be frank, I'm not sure this is good practice - think of smartphones, PDAs, Tablet PCs, Apple Macs, and voice-activated browsers - none have a "right mouse button". And a huge proportion of users never think of using the right mouse button (see Jon Udell's discussion on saving web pages) - instead, context-sensitive menus should probably appear as part of a ribbon.

In fact, it's pretty easy to code context sensitive menus using simple javascript. For example, you could dynamically swap out the contents of a menu <ol> tag based on browser focus and DOM events.

So I predict a migration to menus based on <ol> and CSS.

Continued user interface innovation will make menus as friendly and accessible as possible. Menus inspired by the Office 2007 ribbon will become more popular for true web applications, like Hotmail or Google Spreadsheets.

And context-sensitive menus will appear through the web, as developers realise the power of simple HTML, CSS and javascript.