SharePoint has come a long way in the past decade. In this, the final installment of my three part series, we'll be looking at the new capabilities introduced in SharePoint 2013 that change how companies can collaborate -- remember, if you’re still treating SharePoint like the Web-based file share it was in 2003, it's time for a reappraisal.
In part one of this series -- SharePoint 2013, This Old House Style - Moving In and Living Together -- we covered some of the base enhancements for capacity and information management. Part two, SharePoint, This Old House Style - Interior Design, Decorating, covered the user interface -- designing a new user experience, and coloring documents with rich palettes of metadata.
Today, we turn our attention to one of the most transformative changes in SharePoint today -- collaboration. In 2003, working on documents in SharePoint was centered on the idea of “single occupancy vehicles.” Much of the functionality was based on this sort of editing process:
- Original author writes a document
- Document version 1 uploaded to SharePoint
- First author sends an email to reviewers asking for updates
- First reviewer “checks out” the document
- Other people wait until the document “becomes available”
- First reviewer makes further edits
- Document checked back in (version 1.1)
- Edits are reviewed and approved
- Second reviewer checks out document, edits, checks in (version 1.2)
- Process continues until document version 2.0 is published and updates are seen by: everyone
- Additional document updates continue by returning to step three.
This was obviously a lot more structured than using a file share. But this collaboration process opens up a lot of risks:
- Users get impatient waiting for a document to be checked back in so they email a copy to other editors, creating a duplicate that lives outside SharePoint
- Parallel editing on different copies (one in SharePoint and one from email) creating two similar but different editions of the “same” document.
- Versioning was poorly understood or severely constrained -- so people made duplicate copies with similar names:
- Proposal April
- Proposal April w JKR comments
- Proposal Final
- Proposal Final2
- Proposal Final as Approved
- As a result, no one is 100 percent sure which document is controlling or final, leading to a loss of confidence in SharePoint as the file store "of record"
Despite these issues, SharePoint 2003 offered much better support for controlled, reviewed editing among multiple contributors than anything else.
SharePoint 2013 is different. It offers intrinsic capabilities that are much more flexible than prior editions -- letting you keep the documents entirely in the SharePoint universe while extending them to new people and new devices flexibly, especially:
- Reviewing documents directly in the browser, without downloading a copy or launching a full version of Word/PowerPoint/Excel etc. (Office Web Apps)
- Taking a synced copy of selected documents offline on multiple devices – laptop, smartphone, or tablet (SkyDrive Pro)
- Letting multiple editors work on the same document simultaneously (co-authoring)
Taken together, this allows for much more flexible and dynamic editing periods. These capabilities build extensively on the capacity, versioning and sharing capabilities as detailed in part one of the series. We know that collaboration -- working together -- happens not just in formal processes, but as time and opportunity present themselves. Let look at how SharePoint helps us work together in our own style and timing.
Office Web Apps (OWA)
Microsoft introduced the idea of browser based Office as part of SharePoint 2010. These proved to be so successful that Microsoft moved them “outside” SharePoint to allow other enterprise systems (Exchange, Lync) to use them as well.
Technically, OWA isn’t mandatory for SharePoint -- you can run the farm just fine without it. But you don’t get document previews or the ability to make minor edits from inside the browser without it.
What's the best way to install OWA? The simplest by far is Office 365. In the cloud, OWA is preinstalled for you and requires no additional configuration. However, for on premises installations you’ll need to set up a small server(s) to run OWA.
The detailed steps for setting up and scaling OWA are beyond the scope of the post, but the summary steps are outlined here:
- Install OWA prerequisites on a server or servers NOT already part of the SharePoint farm:
- Server Features: .NET Framework 4.5 and partially selected. Expand it and also add ASP.NET 4.5
- Ink and Handwriting
- Web Server Roles (IIS)
- Security/Windows Authentication
- Application Development
- NET Extensibility 4.5
- ISAPI Extension
- ISAPI Filters
- Server Side Includes
- Install OWA on those servers
- Use the PowerShell command New-OfficeWebAppsFarm to start a new instance of OWA
- On the SharePoint farm, use the PowerShell command New-SPWOPIBinding to connect the SharePoint farm to the OWA services
And voila! If you’re an admin, it’s not hard. And if you’re not, Office 365 comes with all of this engineering prebuilt. In addition to the edit features shown above, you’ll now be able to get document previews in context menus and searches.