Office Web Apps

Last Month, Nick wrote about the Office Web Apps team attending the SharePoint Conference to discuss Office Web Apps and how they can be deployed on SharePoint Foundation Server 2010.  With the impending Beta release of both SharePoint and Office Web Apps for business customers, we thought that it would be a great time to discuss some of the content which we covered at the conference, on this blog.  Specifically, we wanted to spend just a little time in this post discussing:

1. How Office Web Apps work once deployed on SharePoint (and thus what you should expect once you complete your installation and activation)
2. What steps an administrator would need to take in order to get the Beta version of the Office Web Apps deployed

While this is not intended to be an in depth treatment of deploying and managing Office Web Apps, I hope that it provides you with enough context to get you started on the path of deploying the Office Web Apps Beta on SharePoint Foundation Server 2010.

Thus, without further ado, let's turn our attention to exactly how these components are deployed to integrate with SharePoint and how you can get them up and running in your environment. 

Office Web Apps Deployed on SharePoint: Under the hood

Before discussing the explicit steps involved in deploying Office Web Apps, I want to spend a few minutes giving an overview of how Office Web Apps work.  That way, if an issue does come up, you'll be able to better troubleshoot any issues that might arise as you begin to both deploy and run Office Web Apps on a daily basis.  Further, you'll also be able to better tune Office Web Apps for your particular environment. 

From a high level, Office Web Apps are designed to represent your document, natively, in the browser, using only standard browser objects, such as HTML, JavaScript, etc.  Tangentially related, it's because we attempt to adhere closely to HTML standards that these renditions work well in all of our supported browsers, including Firefox and Safari.  The key to understanding how Office Web Apps work is to understand where the magic happens to generate this native representation of your document in the browser.

Fundamentally, our system is designed to be run across two components: the web front end and the back-end (commonly known as the "application server" in SharePoint parlance).

As illustrated by the above diagram, the front-end components consist of a series of web pages and handlers that are largely responsible for generating and returning an HTML based representation of the document to the browser.  Additionally, some, but not all, of the front-end components rely on assistance from the backend in generating this representation of the document. These backend components, which consist of a series of services ("shared applications," again, in SharePoint parlance), are responsible for heavier weight operations, such as performing calc in the case of Excel, or generating an image based representation of the document or presentation in the case of Word or PowerPoint.  The front-end components leverage the output of each of these backend services in order to produce the final view of the document in the browser. 

It's worth noting that these components don't necessarily have to run on separate boxes.  In fact, if you install SharePoint Foundation Server 2010 in evaluation mode on a single machine, and then install Office Web Apps on top of that installation, everything will run successfully from that machine.

Deploying Office Web Apps

Now that you have a high level understanding of exactly what components Office Web Apps will add to your SharePoint installation, and how they work, let’s turn our attention to exactly how you install Office Web Apps.  While the details can be found in the deployment guide, from a high-level, the process looks like this:

• Install wcsetup.exe on every machine in your farm, and run PSConfig once installation is complete
• Once installed, start the aforementioned services on the boxes on which you want to run the supporting services for Office Web Apps, and then activate the service applications for the farm.
• If you're going to take advantage of PowerPoint Web App to power the PowerPoint Broadcast feature, add support for that feature by creating a Broadcast Site Collection (for more information on that feature, please see this link)
• Activate “Office Web Apps,” listed under SharePoint’s Site Collection Features, on each site collection for which Office Web Apps should be available.

If you are attempting to install Office Web Apps on a farm with a large number of site collections, or you are looking to do a staged roll-out, one thing to be aware of as you set out to install Office Web Apps is that they will take over the default click behavior in all document libraries automatically.  Thus, we recommend that you change settings such that default-click goes to the client, as described in the last section of the deployment guide. That way, customers will be able to continue interacting with their documents from the Office desktop applications, while the Office Web Apps installation completes.

Additional information

It's worth noting that the above information only starts to skim the surface of this topic.  To learn more about how to deploy Office Web Apps on SharePoint, you should take a closer look into the deployment guide.  Additional resources will also start to be made available for each of the individual Office Web Apps over the next 6 months, as we continue to generate more content to help you better administer the Office Web Apps deployed on SharePoint (keep an eye on the blog and Technet for more updates). 

In the meantime, we hope that these resources will give you everything that you need to successfully install and administer Office Web Apps in your enterprise for the Beta2 timeframe.  If you have any trouble at all, please let us know in the comments.  Thanks!

Franklin Williams,
Program Manager, Office Web Apps

Rebecca Loew from the PowerPoint team just updated the PowerPoint blog with a post about editing in the PowerPoint Web App. Here it is:

PowerPoint on the Web: Editing

Enjoy!

Nick Simons
Program Manager, Office Web Apps

About a month ago I wrote about the Technical Preview on Windows Live. Since then we’ve seen a lot of interest in Office Web Apps and received numerous requests from people wanting to try them out. To make this possible, we are opening up the Technical Preview and inviting more people to try out the Office Web Apps.

For a limited time, you can sign-up for a Technical Preview account here (if you are already a part of the technical preview, this link will generate an error): http://skydrive.live.com/acceptpreview.aspx/.documents?aobrp=browse.

The features in this expanded Technical Preview are the same as the initial preview; however, during the preview (and beyond) you can expect to see new functionality added over time. Thanks for helping us make Office Web Apps even better!

Nick Simons

Program Manager, Office Web Apps

If you’re at the SharePoint Conference in Vegas this week, come see us. Mike Morton, the Group Program Manager of the Office Web Apps team is speaking at 1:15 pm on Tuesday, October 20. The session is called “Understanding the Office Web apps and Office 2010.”

If you are looking for more technical information, Franklin Williams will be talking about “Office Web apps: Deployment and Manageability” at 4:30 pm that same day.

We are also running a discussion group on Wednesday morning for folks that go to Mike’s presentation and want a chance to give us their in-depth feedback.

And you can also find us at the SharePoint Kiosk. I’ll be there on Thursday morning but other members of the team will be there over the course of the conference.

On Wednesday evening several of us will be available at the “Ask the Experts” session and we are all really looking forward to talking to you all.

Nick Simons
Program Manager, Office Web Apps

Last Friday three members of the Office Web Apps team paid a visit to a class at the University of Washington here in Seattle. My role was to give a PowerPoint presentation and demo. All I took with me was a netbook. It didn’t have Office installed on it.

The purpose of our visit was to launch a field trial where about 30 students will be using the web apps for several weeks and then telling us what they think. The opportunity to engage face-to-face with these students is enormously valuable both as a gauge of where we are and as a source of feedback for where we should be going. I’ll post periodically about how the trial is progressing but today I want to talk about the presentation.

As I said, I showed up at UW with only a netbook without Office installed. That means no PowerPoint. I hooked the netbook up to the projector and launched IE8. I navigated to the SharePoint server that we are using for the trial and launched my presentation. I could have used Windows Live but I wanted to use the same environment that the students will be using. In only a few seconds the first slide was up on the wall in full-screen mode in PowerPoint Web App.

To really put PowerPoint Web App through its paces I made sure my presentation had lots of animations. I don’t think anybody noticed I was using PowerPoint Web App until I told them.

Nick Simons
Program Manager, Office Web Apps

As an engineer, I find myself frustrated with product blogs that spend all their time discussing the end-user experience while ignoring specific implementation details. For me, the most interesting classes in college were always the ones where guest lecturers would discuss specific challenges in developing their application, how difficulties were overcome, and why specific design decisions were made. With that in mind, I decided to talk a little about developing the Find feature in the Word Web App viewer.

Using Find

As explained in the following section, we do not render Word documents using plain HTML. As a result, your browser's native find is unhelpful when viewing documents. Rather than leave our customers without the ability to search the document they are currently reading, we chose to write a find implementation based on Word 2010’s new find experience. Using find works the same in both the Silverlight and non-Silverlight versions of the Word Web App viewer. Click the “Find” button in the toolbar, press CTRL+F, or press the F3 key to open the “Find in Document” pane. We will attempt to automatically place your insertion point in the search box. Enter the word (or sentence) which should be located in the document and press the enter key or click on the magnifying glass. Your document will be searched to find words (or phrases) that match, and the results (along with some context) will be given. You can navigate through the results with the up and down arrow keys or by clicking on the result you wish to navigate to. If a result which is not currently in view is selected, we will scroll to it. Hit highlights will be placed over the result in the document, with the currently selected result being given a different color to make it easily locatable.

Compare Find (Word 2010 vs. Word Web App viewer)

Before posting any pictures, I’d just like to take a moment and remind our readers, that images posted on this blog are from internal builds and the final appearance of the any product shown (including the Word Web App viewer) may change before being released.

The Word Web App is on the left and Word 2010 is on the right…

Behind the Scenes Data

As mentioned in previous posts, the primary goal of the Word Web App viewing experience is to make sure the document looks exactly as intended when viewed in the browser. To achieve this high level of fidelity, the contents of the document are displayed using XAML (if you have Silverlight installed) or images (if you don’t), rather than plain HTML. Unfortunately, by using XAML/images instead of HTML, your browser's native find does not work.

In addition to sending down the content of the document (XAML or images), we also send down some metadata. This metadata, sent in the form of a XML document, contains the bounding box for every line on each page, as well as that line’s text. We can then search this text and highlight the appropriate areas on the image/Silverlight canvas. As a side effect, this XML is often already downloaded for selection, allowing us to find search results without making an additional round-trip to the server.

To allow Silverlight to render documents identically to Word, each glyph is manually positioned on a page. This provides the added benefit of allowing perfect hit highlighting. In the non-Silverlight experience, though, hit highlighting is done by estimating the result’s position based on the match’s location in your line of text, and the line’s bounding box. This is why Gareth mentioned that Silverlight provides “improved accuracy of hit highlighting in Find.”

Compare Hit Highlighting (with and without Silverlight)

Find Without Silverlight…

Find With Silverlight…

Challenges in Highlighting Results

There was an internal discussion about whether or not we should improve the non-Silverlight experience by also sending down every character’s position on each page. Ultimately, we decided that since Silverlight typically required sending down fewer bytes to your browser, it did not make sense to further increase the divide solely for improved hit highlighting. At the same time, we felt that giving an approximate location of the result was better than eliminating the highlights entirely, as it attracts your eyes to roughly the correct location.

Some challenges that we faced included getting highlighting to work with text that is right-to-left , vertical, or a combination of the two. This required modification of the metadata to include the angle of the text line (0, 90, or 270), and the text's direction (left-to-right or right-to-left). In each of these cases, we are not highlighting actual text. Highlights are semi-transparent colored rectangles that float above the document.

Say we have a right-to-left text line that is rotated 90 degrees clockwise, and we know the hit covers the 2nd through 5th character in a line that is 25 characters long. Where should the highlight box go, and what should the dimensions be? In Silverlight, we know the widths of the characters thanks to the XAML. The height of the highlight box should be the summed width of the characters as given by the XAML. Why height? Because the text is rotated 90 degrees. We also know that the width of the highlight box is the width of the bounding box of the text line. Finally, since the text is right-to-left, the highlight box starts from the bottom. Why from the bottom? When rotating left-to-right text 90 degrees right, the first character will appear at the top. Because our line is right-to-left, the highlighting starts from the bottom.

The non-Silverlight experience is similar, only for this case the height is calculated differently. Because we don't know individual character widths, we treat the bounding box as containing 25 equally wide characters. Therefore the height is 4/25 times the height of the bounding box.

(I could talk about the multiple-characters-to-a-single-glyph issue, but that may get too technical...)

Challenges in Capturing Hot Keys

To enable the find experience described above, certain key combinations need to be overloaded. For example, if CTRL+F opened the browser’s find box instead of our custom find pane, customers would be unable to locate their query in the document. For this reason, we attempt to capture and suppress the find hotkeys before they reach your browser. Unfortunately, Safari 4.0.3 does not allow the CTRL+F combination to be easily suppressed. At the time of writing, we succeed in detecting when this key combination is pressed and opening our find pane, but we are unable to prevent the browser find from opening as well. Furthermore, Safari places the browser’s focus in its own find toolbar, so you’ll need to manually set focus in our application’s find to begin searching documents in the Word Web App viewer. I hope that further investigation into this area will allow us to succeed in preventing Safari's find toolbar from opening.

I hope this gave you a better idea of some of the challenges we faced when implementing the Find feature.

Robert Rolnick and Carrie Butler
Software Development Engineers, Office Web Apps

Chris Bryant from Office spends 20 minutes showing Excel Web App, PowerPoint Web App and Word Web App in action. The demos focus on the experience in Windows Live but Chris also talks about the other ways that we are delivering Office Web Apps to customers. Enjoy!

Nick Simons
Program Manager, Office Web Apps

Today is an exciting day for us! We are making available Excel, Word and PowerPoint Web Apps for a select group of Windows Live users as part of the Office Web Apps Technical Preview. While the initial functionality is modest it will expand over time. As we get closer to the release of Office 2010 we will make the Office Web Apps available to more Windows Live users.

This early peek at the Office Web Apps will include high-fidelity viewing of Word, Excel and PowerPoint files in the browser. Invitees will also be able to edit Excel and PowerPoint files. Over time we’ll add OneNote Web App and the ability to edit Word files as well. Stay tuned to this blog to hear more about the upcoming features.

Brian Hall from Windows Live has also written about the Office Web Apps on Windows Live.

Thanks,
Nick Simons
Program Manager, Office Web Apps

Terry Crowley is featured in “The Making of the Office Web Applications.” Terry talks about shipping a new version of Office for about the first minute. After that, he focuses on the Office Web Apps. Five minutes well spent!

Nick Simons
Program Manager, 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

On my last vacation I went back home to visit family. As anyone who works in technology can appreciate, I quickly became the designated tech support person. So I spent part of my vacation patching, installing software and fixing computers, while learning how each of my family’s computer setups differ.

My mom runs Vista with IE 7, my brothers both use Macs and Safari (and wisely didn’t let me touch them), my dad runs Windows XP, and my in-laws run Vista with Firefox. This experience made me appreciate on a personal level how valuable it is to be able to work anywhere, regardless of the machine setup.

The Office Web Apps Are Cross Platform, Cross Browser

As we were building the Office Web Apps we set out to provide an Office quality experience regardless of which platform and which browser you use. We know that our customers will have diverse configurations, and in some cases (such as working from a library or airport kiosk) there isn’t an option to install a different browser.

The Office Web Apps work with some of the most widely used browsers, and we officially support:

• Internet Explorer 7 and 8
• Firefox 3.5 on Windows, Mac and Linux
• Safari 4 on Mac

If you prefer to use another browser you should still give the Web Apps a try. While we cannot officially support all browsers, customers will not be blocked from using them. It is a goal of the Web Apps to have broad compatibility and reach.

Not All Browsers Are Equal

While we strive to make the experience consistent across each browser we support, sometimes this isn’t possible. A browser may not offer the same level of extensibility for certain scenarios. One example of this is copying text by pressing the ‘copy’ button on the ribbon. In Internet Explorer this will work (after a prompt), but Firefox doesn’t support copying to the clipboard through mouse actions, so you’ll see a dialog from the Office Web Apps similar to the one below.

The Office Web Apps Get Better With Silverlight

Microsoft just released Silverlight 3, a free browser plugin that allows developers to build richer web experiences for many browsers and platforms. The Office Web Apps will work well without any plugins installed, but they get even better if you have Silverlight.

You may notice that when you view a Word document or PowerPoint presentation you’re prompted to install Silverlight. That’s because the Word and PowerPoint viewing experiences benefit from Silverlight.

How Does Word Web App Get Better With Silverlight?

• Faster load performance, since typically fewer bytes need to be downloaded before showing the document.
• Improved text fidelity at 100% zoom. This includes better text spacing and rendering.
• Greatly improved text fidelity at other zoom levels not 100%.
• Text will respect settings set in cleartype tuner, so you’re able to determine how much (if any) cleartype you’d like to see. The cleartype tuner is available on the web for older versions of Windows, and is included in Windows 7.
• Improved accuracy of hit highlighting in Find.

PowerPoint Web App Gets Better With Silverlight Too

There are some automatic benefits to having Silverlight installed when running the PowerPoint Web App. For example, animations smooth out a bit, and the slide will scale with the browser window size. However Silverlight is not required for rendering or animation.

If you’d like to get the benefits mentioned above when using the Office Web Apps, install Silverlight. If you’d prefer not to install Silverlight the Office Web Apps will still work well in the browser you choose to use - allowing you to work anywhere, no matter what machine setup you happen to find.

Gareth Howell
Program Manager, Office Web Apps

When I talk to people about how Office Web Apps provide “browser-based viewing and editing” of Word, Excel, PowerPoint, and OneNote files, the thing people immediately get excited about is the “editing” part. That’s understandable: browser-based editing is new for Office, and editing is what makes “information workers” feel productive. Viewing – we’ve been viewing documents since people etched things on stone. Old hat. Boring.

And what difference does browser-based viewing make, especially for docs on my team’s SharePoint site, since I’m always accessing the site from a computer that has Office desktop apps installed? I click the link, the file opens in the app; I can read it. Big deal.

It turns out, it is a big deal. Think about it. If you’re an information worker, you probably read at least 10 documents or spreadsheets for every one you create. You probably watch scads of slide decks – maybe after the actual presentation, when someone archives it to the SharePoint site. If you’re clicking those links dozens of times a day, it means you get asked to whether you want to edit the file or open it read-only dozens of times a day.

And if it's that PowerPoint deck that shows how your team is getting closer to your goal, you miss out on seeing the animations flow on a single slide because you're just in too big a hurry to switch to Slide Show.

You've probably gotten so used to this, you don't even notice that it's a pain to open desktop apps just to read content. Once Office Web Apps got deployed to a SharePoint site I use all the time, I quickly became accustomed to navigating Office files as breezily as I surf the Web. I can read the things I need to, without all those read-only things getting in the way of what I’m working on in my desktop apps. A teammate can send me a link to a spec as easily as he sends me a link to information about the 40th Anniversary of Apollo 11 on NASA’s website – and following the link is just as quick and easy for me.

This is the Word Web App viewer:

Word docs look beautiful, in Page Layout view, the way the author intended. Excel workbooks are well behaved, opening on Sheet 1, with the top row visible. I click through PowerPoint presentations and see the animations, right there in the browser.

I frequently also use another SharePoint site, which has not yet had Office Web Apps installed. I’ve noticed lately a twinge when someone sends me links to libraries on this other site. It’s not that I dread the repetitious decisions (Read-only or Edit? Paper or plastic?) or the bazillion Word windows marching up from my Taskbar (which one has the blog post again?). It’s just that I’ve gotten used to a more lightweight, browser-based way of reading documents. I can’t wait for Office Web Apps to be deployed on all the SharePoint sites I use.

Roxanne Kenison
Content Publisher, Office

Sean Lyndersay, Lead Program Manager on the PowerPoint Web App team, has just put up a post that talks about some of the high level considerations of creating a web-based version of PowerPoint. The post links back to this blog at one point so if you find yourself back here, be careful to avoid getting into an infinite loop. Sean's post is here:

http://blogs.msdn.com/powerpoint/archive/2009/07/24/bringing-powerpoint-to-the-web.aspx

Nick Simons
Program Manager, Office Web Apps

For the first post to the Office Web Apps blog (not counting the 'hello world' post we did on Monday!) I thought it would be appropriate to discuss the tenets that drive our design and engineering. These tenets reflect the fundamentals that we aim to achieve and should provide insight into the tradeoffs we make.   

Tenet #1: Trustworthy

First and foremost we want to build web applications that users can trust. Many elements regarding trust are quite common amongst web applications. For example, most web applications need to be reliable, available, responsive, respect user's privacy, backup data, etc. For the purpose of this blog post I will not spend time talking about these aspects of 'trust' as most web applications share these principles. What I do want to discuss is how our team views 'trust' in the context of web productivity applications and some specifics about what we are doing to earn trust.

Round-tripping (or preservation) of documents:

When a user works with a document in an Office Web App, the Web app will preserve the data in the document, even if the Web app doesn't support a specific feature.  For example, the Word Web App will not support editing 'Watermarks' in the initial version. However if a user opens a document with a 'Watermark' in the Word Web App, makes some changes and saves, the 'Watermark' will remain in the document. It is very important that when customers use the Web apps they can do so trusting that they will not lose data or 'mess up' the document.

Another example is that I may create a spreadsheet in the Excel desktop app and then share it with a friend. My friend may want to add data or change numbers, even though she doesn't have Office installed on her machine. Using the Excel Web App, she can make changes knowing that the integrity of the spreadsheet will be preserved. The formulas, charts, worksheets, pivot tables will all continue to be intact in the spreadsheet (unless changed by my friend).

While this may seem obvious, it’s harder than it seems. Others use an 'import/export' model and convert the documents to a simpler form for editing on the web. This approach works adequately for some scenarios, but it takes just one or two instances of content being 'lost in translation' for users to lose trust in the Web Apps. With Office Web Apps, we want people to use them with confidence and knowing that their content will be safe.

Tenet #2: Familiar Office User Experience

We want Office Web Apps to be easy and fun to use. We know that the 'Office' brand comes with high expectations and we aim for the Web apps to have a high quality look, feel, and level of usability. We use the word 'Familiar' in this tenet as there are hundreds of millions of Office users today and that consistency with existing experiences will make it easier for customers to work with the Web apps' interface.

It is important to note that the tenet is not called "Replicate the Office desktop apps' interface exactly in the browser".  We recognize that the web platform has different conventions and we want to ensure that the Web apps utilize the best of the web and take advantage of the web platform's strengths. An analogy is Mac Office and Windows Office. While much of the UI/behavior is consistent, the interfaces are not identical as each is optimized for the underlying platform.  

Perhaps the most obvious place where customers will recognize our efforts towards this tenet is in the look and feel of the application. The icons will be familiar, the text of commands will match the desktop apps, all the apps use the 'Ribbon' interface, etc. In the individual apps you can expect to see sheet 'tabs' at the bottom of Excel, a view of the slides on the left in PowerPoint, or the familiar formatting commands in Word. 

We’ve also made a big investment in consistent behaviors. This includes some of the basics that Office users have come to expect like AutoCorrect and background spellchecking. I'll provide a more detailed example to illustrate the level of thought that goes into building a productivity application. Try the following in the text editor of your choice:

1.       Create a new document

2.       Insert a table at the very top of the document

3.       Add text above the table

In Word (both the dektop app and the Web app), if you simply hit 'enter' while your IP (insertion pointer) is in the upper-left of the table it will create a new paragraph above the table. This makes sense but requires special logic, as normally hitting 'enter' in a cell creates a new line in that cell. Most users likely never notice this, but without this type of subtle logic editing can be frustrating. This attention to detail is part of what separates basic editors (or spreadsheets/presentations) from applications designed to provide an 'Office quality experience'. 

Below is a visual showing this behavioral difference between Microsoft Word (top) and Microsoft Writer (bottom).

Tenet #3: High Fidelity

For many people, Office documents are their 'work product'. Most people take pride in their work and their documents. With Office Web Apps, we want to ensure that users can view and share content with the confidence that others will see their work as intended. We've even seen a major product category (Adobe PDF/Acrobat) designed for this express goal.

With the Web apps, we use the term 'fidelity' to span a broad spectrum from visual fidelity (e.g. formatting and layout) to data fidelity (e.g. calculations and formulas) to behavioral fidelity (e.g. builds/animations in presentations). Office customers will expect that their content will look and act the same on the web as it does on their PC. For an engineer, this could mean that a design document has the correct layout, diagrams, pictures, and pagination when shared. For an accountant they want to be sure that the formulas always compute the same way and that their charts or tables accurately represent the data. A salesperson will want his/her slide deck to look professional and as designed, builds/animations to work, and for the notes to be available.   

Some Additional thoughts

I do want to be clear that what is listed above are 'tenets' ('tenet' is defined by Merriam-Webster as a principle, belief, or doctrine generally held to be true) and not absolutes or promises. Software is never perfect, and I'm sure many readers of this blog will be quick to point out bugs/features/flaws where the Web apps don’t quite live up to these tenets. However they do guide us through the engineering process and hopefully many readers of this blog agree that these are the right tenets for Office Web Apps. If you have an opinion, please share it in the comments!

Mike Morton

Office Web Apps Group Program Manager

In October of 2008, Microsoft publically announced that the next release of Office would include web-based versions of Word, Excel, PowerPoint and OneNote. Since then, we have been excited about starting this blog. We have been working hard on the Office Web Apps and we look forward to talking about how they work, how they evolved, and what it’s like to translate some of the most used software on the planet to the Web.

Today, Microsoft publically revealed more about Office 2010 which gives us the green light to start blogging. Our Product Manager, Monica, is also featured in a video about the Office Web Apps.

Check back often (or, even better, subscribe) to get the latest.

Mike Morton

Office Web Apps Group Program Manager