I presented at TechEd 2014 last week (Barcelona) on “Weave your enterprise solutions directly into Office products with the app model”, alongside Andrew Salamatov from the Exchange product group - in this post I want to provide the PowerPoint deck and link to the TechEd video, but I also to provide some thoughts on Apps for Office in general. First off, here is the slide deck:
Link to TechEd video
The TechEd video can be watched in the embedded video at the bottom of this post, or the link to the video over on Channel 9 is - http://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B307
General information
If you’ve read other posts of mine, you’ll know that I’ve spent a lot of time developing Apps for SharePoint and Office 365 recently and doing “cloud-friendly” SharePoint development in general – but (like many people I suspect) I hadn’t spent too much time around Apps for Office. Having spent the last couple of months preparing to talk on the subject at TechEd last week, I feel like my eyes have been opened a bit here – Apps for Office have HUGE potential, and I feel you could easily become a hero in your client or organization with the right idea and a bit of dev effort!
The big game-changer is the development model for how Office is extended these days:
| Model | Development | Deployment to users |
| Some weird VSTO/VSTA stuff that I never did :) | Write code in C# against slightly strange APIs specific to Word, Excel etc. | Have to get a DLL deployed to each user’s machine – good luck with that |
| Apps for Office | Web page hosted in client app (e.g. Word) – developer writes HTML, CSS and JavaScript.
JavaScript API for interacting with document. Many methods work across all client apps (e.g. Word, Excel, PowerPoint etc.) | No deployment to user’s machine – it’s a web page |
Additionally, an App for Office could optionally make use of SharePoint/Office 365 building blocks if useful. Some apps will just relate to Office (e.g. the Wikipedia app in the Office Store), but in the enterprise there are quite a few scenarios where it would be useful to bring in SharePoint/Office 365 – perhaps to store files (e.g. in a team site, or the user’s OneDrive For Business site), or access the user’s calendar, mail, contacts etc. When you need an Office app which uses these things, there are two high-level approaches:
- Implement your app as an App for SharePoint (usually provider-hosted), which encompasses an App for SharePoint
- This works for both on-premises SharePoint and Office 365, but has some trade-offs (e.g. App for SharePoint needs to be deployed to sites, or tenant-scoped install)
- Implement your app as a standalone/external app, which consumes Office 365 services via the new Office 365 APIs and is registered in Azure AD
- This only works for Office 365, but lots of advantages (e.g. app can be made available in the new App Launcher)
This is a decision that will come up quite frequently for Office 365 development from this point (autumn/fall 2014) onwards, and I’m sure I’ll be touching on it in quite a few future articles.
My “find similar documents” sample app
For the talk, I developed an app which surfaces in Word - specifically in the “task pane” which sits alongside the document. My app is nowhere near production-ready, but it tries to illustrate a few concepts, including use of SharePoint/Office 365 for surrounding functionality. Since I wanted it to work with both on-premises SharePoint and Office 365, I chose the provider-hosted App for SharePoint model – but my conclusion now is that the Azure AD/Office 365 APIs approach is preferable if the app only needs to work with Office 365 and you can go that way. Anyway, my app is based around the idea of “finding documents similar to the one you are working with” – perhaps to identify similar or duplicate content within your organization, find other people with expertise on the same topic, and so on. Here’s a screenshot to give you the idea (click on an image to enlarge):
Here’s what my app does:
- Analyzes the document content (or the user can choose to analyze just a specific part), and extracts the most relevant keywords/phrases:
It uses the top 3 keywords/phrases to search your SharePoint/Office 365 environment for similar content. I wanted something which worked purely on the content of the document, so that the user doesn’t need to tag the document in any way (to find related documents). By using the Office JavaScript API, I’m able to fetch the content of the document (or even just the content selected by the cursor) and then perform some analysis on it. Other, less important keywords/phrases are listed for information.
- As a bonus, it also analyzes the document for “sentiment” – and reports whether the document is mainly positive/negative:
At this point, you might be wondering what kind of analysis I do to extract the keywords and determine the sentiment score. I’d love to tell you it’s some amazing algorithm that I spent weeks on and have registered for patent :) In reality of course, there’s actually a bunch of services on the internet that do this kind of thing – so (unfortunately) my smartness only extends to combining the Apps for Office model with one of these services! The one I chose is called AlchemyAPI, and it seems pretty cool. It’s a pay-for service to use in production, but you can obtain a free key for demos/evaluation etc.
- As shown in the image above, those top 3 keywords/phrases are used to power a SharePoint search query. The results are shown in the task pane – each result has a “Save” button (floppy disk icon!) next to it:
- The user can save any interesting references for follow-up – these get saved into a list in the user’s OneDrive For Business site (i.e. what we used to call their “My Site” in SharePoint). Here, the user can edit the list item and add notes if they choose – the main thing is they have the link and author details stored for future reference:
From here I thought it might be interesting if these “saved references” could be easily searched by other users – almost in a social bookmarking kinda way. So, I thought some enhancement of the search experience would be useful here:
- If any “saved references” appear in search results, they are highlighted with some special presentation (mainly just a grey background, some tweaks to the display so that the author’s notes and details of the “linked to” item are shown, along with a custom hover panel):
I also implemented a custom Result Source for saved references, so that a search only within these items can be done if desired.
Over the next few weeks, I’ll tidy up the implementation somewhat and publish the code somewhere.
Summary
- Apps for Office have huge potential in putting useful business tools in front of users, so that they don’t need multiple windows/applications open. We can put the experience right there in the applications they would already be in – and this makes even more sense when the functionality somehow relates to documents or e-mail
- The development model is WAY simpler than previous versions of extending Office – if you’re comfortable with a little JavaScript, you can interact with Office documents and implement apps which in Word, Excel, PowerPoint, Outlook and so on. The beauty is that your app will appear in the rich client, as well as web *and* mobile versions where appropriate – there are some caveats here, such as Word task pane apps only appearing in the rich client (for now), but for other permutations (e.g. mail apps and Excel apps) it’s a pretty good story already
- Deployment and making your app available to end–users is also much simpler than before. There *are* some things to take care of on the IT Pro side (e.g.. deploying Office Trust Center settings through Group Policy), but these aren’t too tricky – I cover them towards the end of the slides
I’ll definitely be looking for opportunities to bring in Apps for Office to my client solutions moving forward – cool stuff indeed.
TechEd Video
