Sunday, 16 November 2014

More speaking – SharePoint Connect 2014 (Amsterdam) and SharePoint Saturday UK

I’ll be doing a couple more talks in the next few weeks – these will cover different topics, ranging from the new Office 365 APIs to techniques for cloud-friendly SharePoint development, and also Apps for Office. Hopefully see you at one of these events!

SharePoint Connect 2014 (Amsterdam)

  • Modern SharePoint development - techniques for moving code off servers (Tuesday November 18, 14:50)
    • Those implementing Office 365 know that custom code cannot run on the SharePoint servers, and remote code alternatives must be used. However, it can be valuable to adopt the same "cloud-friendly" development techniques even for on-premises implementations. In addition to increasing platform stability, this enables you to build in flexibility to your deployment - leaving the door open to a potential move to Office 365 in the future without major re-engineering. With several code-focused demos, this session examines approaches for switching to "off-box" code - including Remote Event Receivers, PowerShell and CSOM scripts and client-side JavaScript.
  • An intro to the new Office 365 APIs (Wednesday November 19, 11:15)
    • Microsoft have stated that they will move away from SharePoint, Exchange and Lync APIs towards generic Office 365 APIs. The preview version of the first APIs were announced in March 2014, and cover several core building blocks for user collaboration - including mail, OneDrive files, calendar entries and contacts. Developers who need awareness of Office 365/hybrid scenarios can expect more such APIs in the future.

      Get on the bus early - come learn about the APIs and the new permissions model ("the Common Consent framework") in this code-focused session.

SharePoint Saturday UK (Hinckley, UK)

  • Apps for Office - the hidden gem that's easier than you think (Saturday November 28, 12:15)
    • Most developers know that it's now possible to develop Apps for Office which are based on core web technologies - HTML, CSS and JavaScript. But the take-up appears to be fairly limited - why is that when development and deployment (even in the enterprise) are fairly easy? This session takes a renewed look at Apps for Office, now that the Word, Excel and Mail APIs have been enhanced and the app model is no longer the weird new kid on the block. Some cool demos are involved, including a Word task pane app which analyses the contents of a document to find you similar items across your SharePoint environment/tenancy whilst you're working with the document.

Sunday, 9 November 2014

Slides/video from my Apps for Office talk at TechEd 2014 now available

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 - 

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:



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):

Find similar docs app

Here’s what my app does:

  1. Analyzes the document content (or the user can choose to analyze just a specific part), and extracts the most relevant keywords/phrases:

    Find similar docs app - keywords

    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.

    1. As a bonus, it also analyzes the document for “sentiment” – and reports whether the document is mainly positive/negative:

      Find similar docs app - sentiment

      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.

  2. 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:

    Find similar docs app 
  3. 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:

    Find similar docs app - saved references in OneDrive

    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:

  4. 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):

    Find similar docs app - saved references in search 

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.


  • 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