You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
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 BlockProgram Manager, Office Web Apps
I think that's exactly the right decision; if I'm using Web Word, I care much more about the functions of Word than the functions of the browser. But I'd also like a way to get at the most useful of those browser functions - if I have a phrase selected, will there be a simpler way to search on it than copy and paste to the search bar?
Also, what about custom dictionaries and custom Autocorrect entries? These make a huge difference to my productivity and I wish there was an easy way to move these between the different machines I use rich-client Word on; I bet I'm going to wish for a way to sync those up into Web Word even more - and perhaps that could be the way I get them from machine to machine? Now that we have export for the custom ribbon, I want a good way to move that from machine to machine and have that appear on the Web. It's my experience - I want to take it everywhere with me.
wouldn't it be more natural to provide spellchecking as part of a browser? Firefox have this, so why not add specllchecking to IE?
How to integrate custom proofing langauge into the office word web apps?
Please give me some idea on this. Its an high priority work for me.
How do I turn the damn thing off? The spell-check keeps marking lots of words as misspelled, even when they're not -- when I use German names in a Norwegian text, for instance. I try to click "Do not check spelling", but it doesn't work -- the squiggles are still there. If I can't turn the spell check off, I'll stop using the web app before I even started.
@Geir Hit Ctrl+A to select all the text, and then hit the little down arrow below the "Spelling" button in the home tab of the ribbon. This will open a pop-out menu and choose "Select Proofing Language". You should then be able to either set the proofing language to something that isn't spell checked (like Latin) or check the box saying "Do not check spelling" (assuming you are in a Web App with that checkbox.)