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.

Separating code from content and presentation

Most web designers nowadays know that content and presentation should be separated. There are still a few examples of HTML <table> and <br> elements used for layout, instead of CSS, but this is diminishing.

The same can't be said of separating code (i.e. javascript) and presentation. I still see lots of examples of layout being set via javascript. It's even built into most javascript frameworks - for example, jQuery has a set of css methods to allow the likes of $('#div1').css("color: red").

That's just wrong. You can't hope to maintain your website's style if you set CSS via javascript - it's difficult enough organising CSS files without having to wade through javascript as well to figure out why a certain style is set. Re-designing your site will require you to change all your code too!

The best solution is to remove all javascript and simply use CSS, with pseudo-classes like :hover and :active to get more control. However, if you're responding to a more complicated event, then you should use classes. Just do $('#div1').addClass('highlighted') instead. You can maintain the actual style in your CSS file, in this case div.highlighted {color: red}.

Similarly, I always try to remove all HTML from my code. It's very easy to get caught up creating and inserting whole DOM trees via javascript alone. But this is inaccessible to search engines, and creates content management nightmares. Now you have to search all your javascript to find where the image came from, as well as the HTML files!

The best solution to this is to remove all javascript and simply use HTML and CSS. However, if you're responding to a more complicated event, then you should have the additional markup already present in the HTML file, perhaps hidden using CSS display:none. You can simply turn it on in your code, without having to create 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.

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.

Blogs and online word processors

What's the difference between Google's Blogger and Google's Docs?

After all, they're both online text editors. They're also both document publishers, though by default Docs doesn't display your document to the world. They both have general document management, including tagging, though Docs also has version control. They both allow collaboration, though Blogger does it through comments and Docs through 'sharing'. They both allow insertion of images and hyperlinks, though in addition Blogger allows videos and Docs allows tables.

None of these differences are major - in fact, I can see most of them being eliminated at some point through general upgrades.

So why do Google have two different applications?

Different uses, same app

They're different because of their history - they're from different cultures. Word processing comes from years of office work, with deeply embedded notions like folders, separate files, and the A4/letter paper size. Blogging comes from an online free-flowing diary format, technically minimalist, constantly added to, and aligned to the computer screen.

That doesn't excuse the basic user interface confusion between the two systems, for example the different ways to edit the underlying HTML. At some point, surely, the solutions must converge.

I can't see that the functionality requirements are different - it's just there are two different uses. Perhaps it's fine they're branded differently, like Proctor & Gamble owning several major washing powder lines to segregate the market.

While blogging tools start to take on advanced word processing features, document tools like Google Docs will improve in "content management" - versioning, publishing, collaboration, tagging, etc.

Surely one tool that can handle both blogging and word processing will emerge soon.

Folders and File Categorisation

Microsoft's Vista, like XP, comes pre-built with folders called "My Documents", "My Photos", "My Music", "My Videos", and even "My Scans".

They're useful for about 10 mins, and then you run into issues - it stops you from categorising your files any other way, for example by project or by customer. Something is very wrong.

The best solution is multi-dimensional categorisation - being able to view your files by document type, project, customer, or any other cut.

However, since WinFS was removed from Vista's feature list, it isn't possible to do this. But for online storage, like Google Apps, these features should be straightforward - right?

Google gets it wrong too

Wrong. There's Google Docs & Spreadsheets, Google Photos (a.k.a. Picasa), Google Videos (a.k.a. YouTube), Blogger, and many other tools.

But there's still no way to group your files together into a "project folder".

They've made a few stabs in that direction - for example, you can attach Picasa images to Blogger entries, and Google Search in the US now works across file types. But in general, it's even further behind Microsoft.

How it should work

The obvious technology for combining all these file types is HTML.

Imagine creating an online project homepage, with links to the appropriate photos, videos, blogs, emails, spreadsheets, or even calendars. You could either upload new files, or link to ones previously uploaded to sites like YouTube.

The key point is that every perspective - project, file type, author, etc - should have its own homepage, allowing you to view or edit appropriate files. Many of these files will appear in several different places - the author's homepage, plus the project homepage, plus YouTube - but that's ok, because it reflects life!

Why WinFS didn't work

Looked at this way, it's obvious why WinFS failed, and Vista still has those pre-built folders like "My Photos". You simply can't categorise files without web technology - the URL, the hyperlink, the homepage, mashups, even the Wiki.

It's also a reminder that we're still at the foundation stages of computing - categorising files is a basic requirement that no one has truly accomplished yet.

Free your data: use HTML tables

Recently I've concluded that spreadsheets are not an optimal way to manage tabular data.

That's quite a claim - Excel earns billions for Microsoft every year, and the recent upsurge for OpenOffice is about standards and open source, not about form and functionality. Even Google has faithfully represented the spreadsheet as an online application.

So, let's review the problems with spreadsheets:

1. Page layout, text, and multimedia. You can't simply relegate this to MS Word - people want to annotate, explain and display their data professionally. Spreadsheets are awful at this.
2. WYSIWYG. Spreadsheets display endless rows and columns, no matter the amount of data.
3. Semantic. You can't distinguish headers, footers, or captions, except through styling. That prevents spreadsheets from being properly computer readable.
4. Storing data. it's hidden in a binary or zip file, among heaps of formatting, configuration data, etc.
5. Linking to external data especially on the internet - if you can only analyse your own data, you're missing a lot out - e.g. mashups.
6. Publishing data If you give someone a spreadsheet, they can edit all the cells - unless you rely on hopelessly insecure password protection!
7. Collaboration - online discussions, versioning, and synchronous editing

The first three issues are fundamental and inherent with any spreadsheet. The final three are inherent with client-based spreadsheets, but could be partially solved using online tools like Google Spreadsheets.

Using web standards for tabular data

Let's take a step back and categorize everything that spreadsheets do with tabular data, and whether there are any internet technologies with equivalent functionality:

Spreadsheet capabilities, Web technologies

Capability	Description	Web technology
Store	Visually in cells, semantically in data format	HTML tables
Transform	Sort, group, filter, pivot, consolidate, chart	DOM / XSL
Style	Borders, shading, text formatting	CSS
Model	Functions, calculated values, goal seek	Javascript, XPath

All these use cases - with the possible exception of conditional formatting, where CSS falls short - can be simply achieved using HTML, CSS, XSL, and a bit of javascript. The browser can beat both MS Excel and OpenOffice - we can free our data.

So what does it look like?

The solution is an editable HTML table inside a web page. The table contains all the spreadsheet functionality you need - sorting, grouping, functions, etc - but rather than taking up the whole page, it's just part of the page, and only contains the amount of cells you need. This allows analysts to surround their data with website text, images, or video (solving problem 1).

Only the appropriate number of rows and columns are displayed in the table - if you want more, you can add them (solving problem 2). This makes the page much more natural and avoids existing problems with people getting lost at the 64,000th row.

HTML tables are the best semantic way to store tabular data (solving problem 3), since there are a range of elements - from rows, to columns, to header and footers and captions - to label the contents. And because it's a web page, all sorts of collaboration, linking, and publishing techniques are immediately available (solving problems 4-7).

New use cases

There are plenty of new opportunities once you use the web to manage tabular data. None are particularly feasible using spreadsheets:

• mashups
• new widgets, e.g. maps
• embedded microformats (e.g. addresses, calendars, etc)
• version management (rather than endless versions on corporate C: drives)
• publishing and read-only tables
• extensibility - new functions & transformations
• using the web as a database, e.g. DabbleDB

Web Data Management

I don't think this even requires a new online application. You can easily imagine it being part of a blogging website - when you insert a table into your blog entry, the spreadsheet functionality immediately becomes available.

It's just a matter of imagination and time before this happens - and personally, I can't wait!

Semantic text editors and Wikis

Most text editors nowadays (including Microsoft Word) provide a huge range of different styles for the user to present their documents - bold, alignment, indent, border, background-color, spacing, font color, and many more.

As a result, their range of semantic elements is poor. As Ian Hixie says, "People think visually. Trying to ask a Web designer to think in terms of (e.g.) headers instead of font sizes is just something that WYSIWYG implementers and UI researchers simply haven't solved yet."

Too much style, too little semantics

This doesn't matter too much in a stand-alone Word Document. But in a collaborative environment - like a corporate portal, or a web community - it's much more important. It enforces a consistent look and feel, it allows for re-styling of the entire site if required, it reduces storage size, and it aids search engines.

The solution may be the Wiki. The Wiki designer selects site-wide CSS styles for each HTML element, with some options where necessary. For example, they may select:

• standard paragraph font type, color, size
• three types of <emp> element, with bold, italic and underline
• standard header elements
• standard list types
• various different table options, e.g. header rows and cells, data rows and cells

Then end users must choose the relevant elements, rather than using arbitrary styling. By removing unnecessary options - for example, enforcing the Arial font - Wikis are also actually easier to use.

The semantic text editor is an old vision. But new ideas about content management and user collaboration - specifically, Wikis, which will grow massively in usage - offer a solution.

Content Management

Content Management is one the most important categories of software. Two years ago, Microsoft Office was the inevitable choice, with various hosting applications like Sharepoint for the enterprise. But there's been a huge amount of change in the last two years - from OpenOffice to Google Spreadsheets to Youtube.

It's now (just) possible to see what Content Management will be like in future - and it's already clear that no one is near yet.

About Content Management

The first question is, what is content?

• text (e.g. HTML, doc or xls)
• raster images (e.g. JPG, PNG)
• vector images (e.g. SVG)
• audio (e.g. mp3)
• video (e.g. mpeg)
• structured data (e.g. various XML)

The last category is really a miscellaneous bucket, which I don't expect to contain much except for niche applications. Raw XML is great for data crunching and back-end configurations, but I don't see it being used much for content - we have more specific languages (like HTML and SVG) for that.

The second question is, what is management?

• CRUD (create, read, update, delete)
• publishing
• collaboration (CRUD permissions, discussion tools)
• versioning & audit trail
• syndication (subscribing to feed)
• search
• storage (includes records management)

Web Office Suites

If you look through this list, Microsoft Office only really handles the first option. Sharepoint handles most of the rest, but that's only used in the enterprise - what about other people?

That's why you can't rule out web office suites like Google Apps - they may be very basic at CRUD, but they can be excellent at management functions 2 through 7 - and how many people really want complicated document formatting options anyway?

The most interesting content management technology is, of course, the Wiki. Wikis naturally cater for all seven management functions above. The only problem is, traditionally Wikis have been restricted to plain text and totally open permissions, but there's no reason why that couldn't change.

For example, JotSpot was (until being acquired by Google) selling a Wiki for corporate use that included HTML calendars and spreadsheets as editable pages. And I don't see why you couldn't edit other media collaboratively using a Wiki - especially vector graphics.

Ideas for a Web Office

Google has been suprisingly quiet about the future of JotSpot since acquiring it. If I'm right, their strategy will be to convert Google Apps into a Wiki suite that covers all types of content (1-6 above), and all types of management (1-7 above).

For example, Youtube could become a Wiki, including video editing capability (with permissions settings). Picasa will become a Wiki-based competitor to Photoshop. They could be packaged up with general Wiki website editing functionality, and sold to corporates (or made available to consumers, supported by ads).

To compete, Microsoft will have to cannibalize their existing Office suite, including Sharepoint. I'm still not sure they're ready for this yet.

In summary

The future of content management is Wikis, allowing management of all types of content: web pages, photos, vector diagrams and videos. It'll be based in the browser, using standard web technology like HTML, CSS, javascript and SVG. There'll be a lot more emphasis on collaboration, syndication, and search. And now the future is clear, there will be a race to achieve it - and Google has the head start.