This is related to a previous post – Embedding PDFs in SharePoint.

Since showing how to embed PDF documents into SharePoint web pages, a few people have been asking how to do the same with Office documents. The answer depends on what version of SharePoint and Office you are using (and licensed for). Here are some of the different methods possible

Please note that Microsoft may not agree with or support some of these methods or opinions.

Using Office Web Apps on Windows Live

Office Web Apps is available for use as part of Windows Live Skydrive. You get up to 25Gb of storage and it includes the use of Office Web Apps. You can upload and create Word, Excel and PowerPoint files, and choose to keep them private, share them with a limited audience or share them with everyone.

• Login to Windows Live Skydrive
• Upload or create your spreadsheet (don’t forget to set access permissions)
• If not already open, select Edit in browser to open the spreadsheet
• Click on the File menu and select Properties
• From within the Properties page, copy the Embed code
• In SharePoint, add a Content Editor web part to the page and paste in the Embed code

Note: you have to use the Content Editor web part when embedding iFrames (which is what Office Web Apps uses). If you try inserting direct into the page, the HTML editor will automatically strip out the embed tags. If you are using SharePoint 2003 or 2007, modify the web part and make sure you click the Source Code button, not the Rich Text Editor button.

Using Office Web Apps as part of Office 365 (includes SharePoint Online)

Currently in beta, not yet publicly available. Details will be updated here when it is… The current versions of SharePoint Online run SharePoint 2007.

Using Office Web Apps integrated with SharePoint 2010

OK, here comes the bad news… the Office Web Apps that comes integrated with SharePoint 2010 has reduced functionality compared to Office Web Apps that is provided for free with Windows Live. You can view/edit the same types of documents in the browser, but the File menu does not include a Properties section and there is no obvious way to get the required embed code. This means you can’t easily embed the files in web pages except for where specific web parts have been provided, i.e. Excel Web Access and Visio Web Access. Those two require SharePoint 2010 Enterprise Edition.

So, to use Office Web Apps with SharePoint you need:

• A volume licensing agreement for Office 2010 covering all users, regardless of whether or not they will use the full client version or Office Web Apps
• Office Web Apps will integrate with all versions of SharePoint 2010, including Foundation Service (provided as part of the Windows Server license)
• To embed Excel or Visio files into SharePoint web pages using their respective web parts, you will need to be licensed for SharePoint 2010 Enterprise Edition
• You cannot embed Word or PowerPoint files into web pages without jumping through additional hoops like using Flash or Silverlight

The other frustration is that you cannot create new documents using Office Web Apps integrated in SharePoint 2010 if you have Office installed on your computer. There is no New button from within the Office Web Apps interface in SharePoint. To create a new document, you have to click New from within the SharePoint library and it will automatically launch the full client if it detects Office is installed. This is annoying for all the clients deploying SharePoint 2010 but delaying upgrading Office on the desktop. And whilst moaning… given the thumper licensing requirement, I’m surprised the user interface doesn’t display metadata properties anywhere. You have to return to the document library to edit them. Disappointing.

In short, Office Web Apps integrated into SharePoint could do better, like at least offer the same level of functionality provided by the free version integrated with Windows Live…

Using Excel Web Access with SharePoint 2007

SharePoint 2007 introduced Excel Web Access which made it easy to embed spreadsheets in web pages. For details on how to do it, including notes about some feature limitations, read Excel Web Access 101 (link at the end of this post).

Using Office Web Components

Note the subtle change in title – we are now talking about Office Web Components (OWC) not Office Web Access (OWA).

Office web components were first released with Office 2000 (I think) and were discontinued after Office 2003 having been replaced by Excel Services in SharePoint and now Office Web Access. They enabled you to embed Excel spreadsheets, pivot tables and charts into web pages. They are ActiveX controls which means using them can carry a pretty big security risk. Microsoft would not recommend or support using them.

Note the health warnings listed under Potential Issues. This is not a recommended solution. But if you’re determined to embed a spreadsheet one way or another and don’t have SharePoint 2007/10 Enterprise Edition or can’t use Office Web Apps on Windows Live, you could give it a try… Links on what needs to be done are at the end of the post. But what’s most interesting is that Office Web Components are still installed by default. They’re on my SharePoint demo machine, have no idea whether it was Office or SharePoint that included them in the installation. I’ll try and remember to check on the next build.

So there you have it, a few different ways for embedding Office documents in SharePoint web pages using tools provided with SharePoint and Office. None of them as easy as they should be (i.e. a certain other vendor and plenty of third parties offer easier methods). I’m guessing improvements will appear at some point in the not too distant future.

References

• Windows Live Skydrive
• Customise how Excel is embedded – useful reference for changing how your embedded spreadsheet behaves
• What happened to Office Web Components – blog post by Joel Oleson, Jan 2007
• How to manually install Office Web Components on SharePoint Server 2007 – blog post by Shane Young, Sept 2006

Related Posts

• Embedding PDFs in SharePoint
• SharePoint and Office web apps
• Excel Web Access 101 (SharePoint 2007)

Random other gripes about Office and SharePoint too short to write a separate post about:

• Office Web Apps seem to be able to ignore mandatory columns. If you set a column to mandatory, then open a document using ‘Edit in browser’, it will happily save changes without prompting you to fill in any metadata. Office will not and neither will SharePoint if you go to edit the properties in the document library. Interestingly, whilst testing I couldn’t then open the file in Excel as it had corrupted. Will be doing some more tests…
• Prepare to be frustrated with the new managed metadata service if you’re not deploying Office 2010 on the desktop. You can’t edit the columns from within Office 2007 and you can’t bulk edit them in datasheet view in SharePoint either. But they are oh so useful as search refiners that you won’t want to not use them.

With the release of SharePoint Server 2010 and Office 2010 earlier this year, a new set of applications also arrived – Office Web Applications. Office Web Apps are browser-based versions of Office, enabling you to create, view and edit presentations, spreadsheets and documents using just a web browser.

Two questions keep coming up in SharePoint conversations with clients – What’s the licensing for Office Web Apps? Can I create documents using just Office Web Apps with SharePoint or do I still need Office to be installed?

The short answers are: licensing is complicated; yes you can create documents using Office Web Apps within SharePoint and no you don’t need Office to be installed (in fact, you can only create new documents using Office Web Apps when you don’t have Office installed).

Here are the details and we’ll see if Microsoft disagrees…

Office Web Apps comes in two versions: consumer and business.

The consumer version of Office Web Apps is available for free online because it is supported by embedded advertising, similar to using Google’s various free online apps such as Google Docs. You can create, view and edit documents without needing Office installed, you just need a browser. To use it, you will need a Windows Live account just as you need a Google account to use Google Docs. The documents are stored online using Windows Live Skydrive (formerly known as Office Live Workspace).

The business version of Office Web Apps is not free. In order to use it, each user must be licensed to use the full version of Office 2010. And it has to be a volume license, i.e. your organisation has a bulk volume license (or Enterprise Agreement – EA) to install Office. Office Web Apps are not included with retail or OEM versions of Office or with any previous version of Office. And every user who accesses documents using Office Web Apps must have a volume licenses to use Office, including third parties outside your organisation. As far as I can tell, this renders Office Web Apps an expensive option for extranets and public web sites given there are free and cheaper alternatives are available. It will also exclude small businesses who purchase Office either with new PCs (OEM) or full package (retail). And it will exclude organisations who have on-site customers who may want to access documents using a web browser. Schools and colleges, for example… if the normal policy is to expect non-employees to purchase their own computers and software to access documents held on your systems, you will need to buy licences to give them access via Office Web Apps. And don’t forget you’ll need SharePoint licences too if you are running SharePoint Server 2010 instead of SharePoint Foundation Services (the latter is included with Windows licensing)…

So, that’s the licensing side. If you’ve cleared that hurdle, on to using Office Web Apps within your organisation…

To use the business version of Office Web Apps, they are installed as an add-on to SharePoint 2010 <-yes, that means you need to deploy SharePoint 2010 to use Office Web Apps. You can access Office Web Apps within SharePoint from any browser-enabled device, you do not need to have Office installed. When Office Web Apps are configured, SharePoint will automatically open Office files in the browser by default. There is an icon to click if you want to edit a document. However there is no ‘New’ icon. Who knows why? The only way to create new documents using Office Web Apps on SharePoint 2010 is to click the ‘New Document’ icon from within a document library. If Office is installed, this action will launch the full client. If Office is not installed, this action will open a new document in Office Web Apps.

The official supported browsers for Office Web Apps include: Internet Explorer 7 and 8, Safari 4 on OS X, Firefox 3.5 on Windows, OS X or Linux. Other browsers may or may not work, e.g. mobile versions, they’re just not officially supported. Naturally, Microsoft being Microsoft, not all browsers are equal. Silverlight integration leads to a better ‘experience’ with Office Web Apps, such as using ClearType to improve the display of fonts.

If you are still reading and not confused, let’s correct that… there’s a third solution from Microsoft involving web access to documents – Docs.com. Docs is built on Office 2010 and Office Web Apps but is not from the Office or SharePoint teams. It has come out of Microsoft’s FUSE Labs. Docs includes integration with Facebook for creating and sharing documents with your Facebook friends. Docs is currently in beta so no news on licensing or integration with its related consumer and business siblings…

My closing thoughts

I’m disappointed but not surprised that Microsoft has made a prize mess of the licensing for Office Web Apps. In attempting to first and foremost protect their Office revenue stream, they’re proving the theory behind the Innovator’s Dilemma.

The licensing of Office Web Apps for business customers presents 3 choices:

1. Purchase/increase/maintain a volume licensing agreement to cover Office 2010 (and SharePoint 2010) for all users, employees and others, who want to access documents in a web browser using Office Web Apps.
2. Continue with the traditional methods – email documents or publish links to SharePoint libraries and people download/open the documents using any Office-compatible client installed on their computer. Naturally Office 2010 is the recommended client for integration with SharePoint.
3. Use alternative browser-based options for viewing/editing Office documents, such as Google Apps or Zoho. Evaluate the cost of the monthly subscription versus Microsoft’s licensing cost. You will also need to consider the cost/value/risk of introducing a different approach to collaboration and productivity applications. This option isn’t for integrating with Office and SharePoint. It replaces them.
4. There is a fourth option – use the free ad-funded consumer versions although those clouds are a little too grey for most organisations to fly into. Security, support and scale being the first three issues to overcome.
5. There’s also the fifth option – reduce your dependency on documents and publish more content direct into web/wiki pages… but maybe a blog post for another day

Focusing on the first three options, one may generate additional revenue for Microsoft, one will reduce revenue and none of the options are likely to increase customer satisfaction or loyalty. The first may prove too expensive to justify the benefits. The second ties Office to the desktop in an era when people want to access content from any browser-capable device. The third introduces a new approach to collaboration and productivity, one that doesn’t need SharePoint or Office (or even a PC)…

A better approach would have been to include the use of Office Web Apps within SharePoint licensing, which is complicated enough when it comes to external access so you may as well kill two birds with one stone. And including Office Web Apps may even help justify increased SharePoint licenses. Anyone who claims this will reduce Office revenue clearly hasn’t been using Office Web Apps, or at least not in the real world. Pushing organisations to try alternatives has far better odds.

Related blog posts:

• Rethinking Office: Comparing Office with Google Docs – April 2008
• Programming Office: Why the shift of apps to the cloud will be slow – May 2008

References:

• Understanding Office 2010 and the Office Web Apps – session at Microsoft’s SharePoint Conference, October 2009
• The twists and turns of Office Web Apps’ software license – Infoworld, February 2010
• Users will need a Microsoft Office licence to use Office Web Apps – ITWriting, May 2010
• Licensing of Office Web Apps when used with SharePoint 2010 – EduGeek Forum, June 2010
• The Innovator’s Dilemma – Clayton Christensen
• Office Web Apps blog
• Windows Live Skydrive / Office Live Workspace
• Docs.com

Good article written by Jakob Neilsen over on www.useit.com, discussing the history of the graphical user interface (GUI), and the reality that the current method of WYSIWYG (whizz-ee-wig: What You See Is What You Get) menus is going past its sell-by date. Jakob then discusses the work Microsoft is doing with the new Office 12 UI, and coins the term WYGIWYS (wig-ee-whizz: what you get is what you see). One of the main reasons Microsoft has decided to redesign the UI is that a ridiculous percentage of feature requests are for features already in the product, suggesting that people can’t find the tools they are looking for…

I fell into IT back in 1991, when Word Perfect led the word processing world (on DOS) and Lotus 1-2-3 was the spreadsheet to use (on Windows 3.x). In those days, a WYSIWYG menu was easier to access from the keyboard than the mouse. As a bit of a spreadsheet queen, I could update a formula, format the results and send the file to the printer in less time than it would take to move your hand over to the mouse. When I discovered macros, it just got easier You entered the commands once inside curly {} brackets, assigned a short-cut key and hey presto! Those were the days…

As desktop applications developed, it became more difficult to stick with the keyboard – so many extra key strokes were required, it was easier to just use the mouse. But the mouse was still not as efficient as those early days with the keyboard.

Radically changing the UI of such a well known application is a brave move. I’m still a bit of a spreadsheet nut, and when I first saw the O12 UI demonstrated… well… I hated it. Sure, the actual demos using data then looked very cool, but my initial reaction, when Excel was first opened, was Yuk! I was pretty disappointed with myself – I’m normally the one advocating change and here I was, hating the thought of it… So, with an Excel 12 phobia rapidly developing, I installed the code last week (note: the code is not publicly available, I work for Microosft). With trepidation, I launched Excel…. yup, same reaction. I absolutely hated looking at it. Bring back my menus I thought, I want my customised toolbar. I started to enter some data, started experimenting with formulas to play with the new visualisation capabilities (very slick), but still there was some serious animosity towards the new ribbon that has replaced my beloved menus… and then I closed Excel. I just didn’t want to play with it any more. This is the worst reaction I have ever had to a new software feature.

Why am I writing about all this? For one simple reason. I will learn to love the new UI, and when I do, I’ll find it easier to work with Excel than before, and I’ll wonder why I had such a problem with it in the beginning. But I need to remember and record this initial reaction, because I know I’m going to see it again, in the not-to-distant future. I’ll be analysing my own learning curve hopefully to make it easier amd smoother when others react like I did. Conveniently, my mom’s a bit of spreadsheet queen too, so I’ll have a volunteer to test the process on.

Back to those early days… In 1993, the company I was working for decided to switch to none other than Microsoft Word, and I was tasked with migrating the secretaries from Word Perfect (v5, still running on DOS – that’s the old blue screen version, for those who remember it). Well… Hell hath no fury like a secretary losing a customised Word Perfect menu system. You would have thought I was forcing them to switch to stone tablets. They absolutely hated Word, with a passion. I remember spending an entire weekend migrating their blessed menus, macros and short cuts to the nearest equivalents I could muster in Word. And my name was still mud for at least 6 months! I couldn’t go near one of them without receiving a lecture about why I was ruining their ability to work, how much longer it was taking them to do anything, how awful this weird GUI thingy was, yade, yade, yade. The list went on and on… But they did finally get used to it, and then they started to do stuff they couldn’t do before. When, 2 years later, it was everyone else’s turn (email had arrived and the need to swap files led to standardising on Microsoft Office – let’s not start that argument), they were the advocates who helped train everyone. Oh how they would laugh if they could see my reaction today. I seem to recall I wasn’t too sympathetic to their cause at the time…

Moral of the story: When we don’t think or realise a system is broken, we will be incredibly reluctant to change it for something unfamiliar, no matter how reasonable the argument for change is. Understanding that feeling makes working through it a whole lot easier…