Office Web Apps: is Microsoft missing its big opportunity?

I have been found the technical preview of Microsoft’s Office Web Apps mostly disappointing. One problem is bugs. These are to be expected in a technical preview, but I have had more problems than I would expect in a widely distributed technical preview. PowerPoint has been particularly problematic. When I try to edit a PowerPoint document I now almost always get “PowerPoint Web App encountered an error. Please try again.” Once I get this error I am stuck with it for the rest of the session. On the Mac I am unable to open documents in Office 2008; I get a message that says “To open this presentation, your computer must be running a version of Microsoft PowerPoint and a browser that supports opening files directly from the Office Web Apps.” On Linux the edit features of the Web Apps seem to be disabled completely. When collaborating in Excel, you cannot see what the other person is editing, which can result in your work being overwritten. Trying to load an Excel sheet that included VBA macros gave the blunt message: “Excel Web App was unable to load the workbook that you requested”.

No doubt these things will be fixed, or at least the messages improved, but it raises doubts about whether the Web Apps will be ready in time.

The performance of the web apps overall is mixed: load times can be slow, but once loaded it is not so bad – scrolling through a Word document in the Silverlight viewer is fine. Performance seems to vary, which may suggest server load issues, and/or the effects of caching as a session continues. Anyway, it was weak enough that when I tried an experiment with a larger spreadsheet I did so with no great expectations.

Here’s what I did. I ran a script that reads every filename and writes it to a file, and ran it against a drive containing many files. I imported this to Excel (which coped without blinking) and saved it both as an .xlsx and a .xls with a little over 30,000 rows. I tried importing it to Google Apps, which says it accepts spreadsheets up to 1MB (my sheet was 883K). Google wasn’t having it, and gave me an error – maybe because an .xlsx is really zipped, and uncompressed the .xls was nearly 3MB. I cut it down to 100,000 rows, whereupon Google accepted it OK. Scrolling from top to bottom took around 15 seconds, or nearer 5 seconds in Chrome: impressive.

Next I tried Office Web Apps. To my surprise, it accepted the large sheet without protest; even the upload was quick. Better still, it was able to scroll from top to bottom in less than 10 seconds, faster once loaded.

I was impressed, though something is not quite right. I put a little calculation towards the bottom of the sheet and for some reason I can’t figure out, it isn’t working.

Still, it seems that Excel Web App is ready for workbooks larger than Google will accept. It’s a significant issue, since there are plenty of large spreadsheets in the world; and I can’t see any inherent reason why web applications should not be able to deal with them. Deep Zoom does a great job of dealing with large bitmaps, so why not spreadsheets as well, on the same principle that you only need to see a small portion at any one time?

The Office Web Apps build on Excel Services along with equivalent services that are being developed for the other Office applications, so Microsoft is in fact building a server-side Office. It is a huge opportunity given the dominance of Microsoft Office in business, with the potential to jump-start Microsoft’s efforts to establish itself alongside the likes of Google and Salesforce.com as a provider of online applications. The big question is to what extent it is willing to surface the features of server-side Office so that users can take full advantage.

The answer currently seems to be, “not much.” The editing features are extremely limited. Here’s what product manager Chris Adams told me when I asked him to describe the limitations:

Our goal is not to replicate the desktop software on the web. The web is a few years away from providing the same kind of rich, powerful experience that we have on the desktop. One of our goals is that cross-browser, cross-platform support. Without wanting to use extra add-ins to add functionality, it does limit us in some ways.

We’ve been trying to look at the key things people might want to do when they access a web app. Smart Art is an example. Smart Art was introduced in Office 2007 on the desktop. With the web app we’ll look to enable people to edit Smart Art, update some elements in it, but we won’t allow you to create new smart art.

We’re trying to replicate the right features and functionality for what we think users will want to do with the web version. This is the first time that a lot of people will get to use it, so the feedback starts now. What people tell us now will inform what we eventually end up with as a feature set.

My feedback here is that the web apps should be as full-featured as possible, so that you can do all your work without having to click that Edit in Office button – which is never going to work anyway in some scenarios, such as on Linux.

Despite denials, I am sure that Microsoft is deliberately limiting the editing options in the web apps so as to ensure that we still need desktop Office. I cannot make sense of what is on offer in Excel Web App, for example, in any other way.

It seems to me that Microsoft is choosing between two paths here.

  • On one path it makes the Web Apps as good as possible, and risks losing sales of Office licences as well as making non-Windows operating systems more viable on the desktop.
  • On the other path, it limits the capabilities of the Web Apps, and risks losing customers in their entirety as they realise that Microsoft is not serious about letting them work through a web-based system.

Not easy, but I’d suggest that the first option above is less dangerous for Microsoft than the second.

5 thoughts on “Office Web Apps: is Microsoft missing its big opportunity?”

  1. Hello Tim, I am curious to find out how much of Office/Web is written in pure HTML and how much is using Silverlight?

  2. Hi Tim, I am one of the testers for the Excel Web App and have a question about your >30K row test. Is the number format of the column that holds your data “text?” If so the calculation error you are seeing is actually expected. Same thing should happen in the client. If it’s not number formatted as text I’d love to take a look at it to see that we address this issue.

  3. @Abdullah

    I think you are right, the fact that the numbers are aligned left by default indicates that Excel is treating them as text. It’s odd because I tried entering them with the + prefix and the + did not appear in the cell, which normally means the value is accepted as a number, but still got the result as above. Further, why is the formula cell showing a left-aligned 0? If Excel is treating it as text, it should show the formula as text; but if it is treating it as a formula, shouldn’t the result be 0.00 aligned right by default?

    Anyway, if I go back to the sheet I can fix the problem by overtyping it using the + prefix. And if I insert new rows (which is how I created the space for the calculation the first time I tried this) and enter numbers, they are accepted as numbers with or without the + prefix and the calculation works. So I wonder if something has been fixed?

    Thanks for the comment.

    Tim

  4. Thanks Tim for reconfirming. Currently Excel Web App doesn’t show formula itself as text like you mentioned. 0 was left aligned because the cell was formatted as “Text”.

    Thanks again for your feedback.

Comments are closed.