Continuity and change: proofing tools in the Office Web Apps

One of the interesting things about working on the Office Web Apps team is that we experience a recurring tension between the requirements of the past, present and future. For example, our mission demands that we interoperate with existing desktop apps, leverage present browser technology, and prepare for the future of the web platform--all in one product. Each of these could be a complete project in its own right, and so attempting to tackle all of them in a unified way is daunting to say the least.

You can see the dialogue between past, present and future in many of the features we've built. Today I'd like to give you a brief glimpse into the proofing features of the Word and OneNote Web Apps, and in doing so we'll encounter some tricky issues I hope you'll find interesting and relevant.

When we talk about a "proofing feature," we really mean any tool that helps someone check the quality of his or her document. Spell-checking and AutoCorrect are the poster-children of proofing tools--you might recognize them in the web apps by the bright red squiggles underneath misspelled words, or by the way we correct the error "teh" to "the" automatically, as one types.

Now, spell-checking and AutoCorrect have existed in Office for years, but it turned out that it's neither possible nor preferable to simply copy features into the web apps wholesale. This meant that, if we were going to re-implement proofing on the web platform, then we were going to have to re-justify the feature to ourselves. What value does proofing deliver? Relative to the desktop app, how functionally comprehensive should the feature be in the web app, and how experience-consistent? Clearly there would be great benefits if someone familiar with the desktop apps could work in the web apps effortlessly, but how much work would it be to achieve a goal like this?

In planning it was clear that proofing tools still offer enduring value: people benefit from the convenience and security of automated error checking. But as we went to convert the abstract value of proofing assistance into a concrete design, the components varied widely in the ease of their translation.

One of the features that worked out reasonably well was our multilingual spell-checking architecture. Many spell-checking systems only operate when a special spell-checking mode is manually activated, and when they operate they only check a single language at a time. For the Word and OneNote Web Apps, however, we decided to follow the Office desktop apps model and create a system that works multilingually, inline, in the background as you type. The latter system is more complex to implement, but we think delivers a tangibly better experience, because one can review errors and correct them without having to context switch to a different mode or language. For a one-time architecture cost, we built a system that works for both monolingual and multilingual users internationally, offers a good user experience, and is immediately consistent with the Office desktop apps model. So we found this part of the process fairly satisfying.

Not every part of proofing survived tradeoff-free, however. For example, in the desktop apps we have some longstanding interface conventions: red squiggles indicate spelling errors, keyboard shortcuts allow one to navigate directly to an error, and a secondary click (usually right-click) context menu provides interface to correct those errors. Ideally we would like to mirror these conventions in the web apps, but basic problems arose because browsers have their own keyboard shortcuts and context menus. The unfortunate alternatives are either to change the buttons that access our functions, which will confuse many customers or to override the browser's controls completely--there is no way for a web app to extend or modify the browser's controls. In this case, we chose to override the browser's controls and give our customers a desktop-like experience. This seem fine if people primarily think of themselves as being “in Word” when they use the Word Web App from within the browser, but they will be disappointed if they expect to use specialized browser functions from within the web apps, such as initiating new web searches from the right-click context menu. In this case there are not only past expectations colliding with present ones, but there are also real questions about the future of web apps: how people conceptualize the app vs. the browser, whether one set of interface conventions will override the other, or whether the sets of conventions will somehow exist side by side in future apps.

So in short, there's a lot of exciting work going on. The web is still a comparatively new arena for dynamic apps, and it will be fascinating to see how the technology develops to accommodate the high standards we've come to expect for software. There's a not unreasonable notion that the future will be neither “pure web/network app” nor “pure desktop app,” since computing history has already tried those, but what the exact future synthesis will be is still unknown. Truly an exciting time to be in technology.

We hope you've enjoyed this brief look at the process and product of the Office Web Apps, tune in next time!

Elliot Block
Program Manager, Office Web Apps