Wednesday, 1 August 2012

SharePoint 2013 apps – architecture, capability and UX considerations

UPDATE: this article turned into part 1 of a series on SharePoint apps - here's the table of contents:

  1. SharePoint 2013 apps – architecture, capability and UX considerations [this article]
  2. Getting started – creating lists, content types, fields etc. within a SharePoint app (provisioning)
  3. Working with data in the app web, and why you should
  4. Access end-user data (in the host web) from a SharePoint 2013 app
  5. Rolling out SharePoint 2013 apps to the enterprise - tenant scope and PowerShell installs
  6. Azure is the new SharePoint ‘_layouts’ directory
  7. “Host web apps” – provisioning files (e.g. master pages) to the host web
  8. “Host web apps” – provisioning fields and content types
  9. Deploying SP2013 provider-hosted apps/Remote Event Receivers to Azure Websites (for Office 365 apps)
  10. Working with web parts within a SharePoint app
SharePoint 2013 brings the “app” framework and the Office/SharePoint app store - and whenever a new version of SharePoint brings a new development approach, developers often OpeningAnApp700leap on it as some internal challenge which they have to conquer (sometimes at the expense of actual client requirements). Other bloggers have published similar “when to build apps” articles as this one, but I noticed I’d perhaps come at it from a different angle. Specifically, after I had built my first “hello world” SharePoint 2013 app, the internal question I wanted to prepare myself for was:

Should I develop the feature my client is asking for as an app? The client has no strong opinions on the matter (they do not know the app framework well) and are looking for guidance from me/my company.”

Initially I wanted to focus on the user experience of using a piece of functionality developed as an app. Most folks who have had direct experience of SharePoint users would agree this is definitely a key consideration. So, the last half of this article is dedicated to UX.  However, it’s fair to say that there are potentially bigger aspects to think about too – after all, it might not even be possible to create the desired functionality as an app. So let’s start with app architecture and capability considerations.
One final thing - to frame this discussion, consider that Microsoft say “develop an app where you can” (although their motives may not be the same as you/your client – I’ll come back to this point in the closing summary).
Disclaimer July 31 2012 – SharePoint 2013 is in preview at this stage, so some specifics and user experiences may change slightly between now and release time.

Architecture considerations

Guided by MSDN (see reading list at the end of this article), when considering app development my summarized checklist here would be:
  • From the 3 hosting options, which are available to me?
    • SharePoint-hosted – [this one is a given since you have a SharePoint environment]
    • Externally hosted (to the SharePoint farm)
      • Do we have some non-SharePoint servers which could host this app, or could some be created?
      • Assuming resilience is required, is there a load-balancing/failover solution in place?
      • How much effort would be required to give them the same business continuity (DR, backup/restore) as the SharePoint servers?
      • Is capacity planning required around processing power, memory usage, network latency/throughput, disk performance and data storage?
      • If we want do develop in .Net, do they run IIS?
      • If the app(s) need to store data, where would this be?
    • Auto-hosted (SharePoint Online + Azure)
      • Does the client’s web application where the app(s) would be deployed run in SharePoint Online (since Azure auto-hosting is only available to apps deployed to SharePoint Online)?
      • Does the client have an Azure subscription?
      • Has Azure capacity planning been done? Is any more CPU/memory/disk needed for the new app(s)?
      • Can we accurately estimate how much the Azure costs will be each month?
      • Do we have the skills to develop in Azure, or can the devs learn on the project?
  • Is a combined app hosting approach appropriate? (e.g. some SharePoint artifacts, and some external to SharePoint)
  • Does the selected app hosting model fit with business and I.T. strategy?
With these points in mind, I wonder if purely SharePoint-hosted apps could be easier to achieve than externally-hosted apps for some non-Office 365/SPO clients. I’ve seen some organizations take months to provision servers, so even in this virtualized world standing up some .Net servers to support a SharePoint app might not be the easiest thing. But, SharePoint-hosted apps do not have the same capability as apps with an external component, so let’s think about that for a second..

Capability considerations

The key question here is:- can the functionality be built using the app hosting options I have available to me? Consider the following:
  • An app cannot have any server-side SharePoint code – all code must use client APIs such as CSOM, the REST API and web services
  • By default, any SharePoint artifacts provisioned (lists, web parts, content types, site columns, master pages, content pages, other files) do not get provisioned in the site end user browses –  rather, they get created in a special “app web” on a special URL which is isolated from the original SharePoint web. This could be particularly relevant if, for example, if there needed to be some kind of aggregation or link between user content and content related to the app.
  • Unless the app requests special permissions (which must be agreed to at install time), an app does not have permission to talk to the parent site or site collection – furthermore, there is no permission possible which allows the client APIs talk to the parent web application or farm. [See Working with the app web, and why you should for more info on these points.]
  • Deep changes to the user site are not possible with an app – site definitions, branding, themes, most types of ribbon customization or link changes which would require a CustomAction are examples
  • Timer jobs are not possible within an app – within a SharePoint-hosted app, it’s difficult to see how any “scheduled processing” could ever be implemented. This is a key difference to an Azure or externally-hosted app (or single app component), which could either use the Azure Service Bus or even a scheduled task on a non-SharePoint server which calls into SharePoint using a client API
  • Custom field types are not possible within an app

User experience considerations

  • How will users obtain the app?
    • Will it be rolled out to all/selected sites automatically?
    • Will site owners/users with Full Control be responsible for obtaining the app from the App Catalog? (for this discussion we’ll assume the app will not be pushed to the public store)
  • For apps not automatically rolled out, could the app’s trust/capability requirements alarm some site owners and cause them to cancel app installation? (see later screenshots). If we haven’t educated them about this process, could it result in helpdesk calls?
  • Which of the user experience options will the app make use of?
    • Navigation to separate SharePoint app web?
    • Navigation to external site which uses the chrome control? (note that this is only applicable if any app UI components are hosted externally to SharePoint)
    • App parts (ClientWebPart) which use an IFrame to bring app content into the host web ?
    • Navigation through a list item’s dropdown (Edit Control Block [ECB]) links, ribbon customizations
  • Does the separation of app and other site content work?
    • Could users be confused that (e.g.) a document library provisioned by your app cannot be found next to their other document libraries? (Remember that to find the app’s document library, they have to “enter” the app and be taken to the separate app web which contains it’s data/artifacts.)
With the above points in mind, let’s take a look at the user experience for site owners and end users.

The site owner experience – adding a SharePoint app

Apps can only be added by users with Full Control permission to the site (typically site owners only), so this process only applies to them. We’ll show obtaining an app from the App Catalog here, but remember site owners may also be able to purchase from the public store, if so configured.
  1. A site owner would navigate to the app “area” (‘Your Apps’) which shows apps published to the App Catalog and has a link to the public SharePoint Store. A site owner can get there either by using the link on the Site Actions menu:

    ContextMenu - AddApp
    ..or the link in the Site Contents page:

    SiteContents - AddApp
  2. In ‘Your Apps’, the site owner would then find an app..

    AddAnApp 
  3. .. and optionally click the ‘App Details’ link to see more about the app. As you might expect, this page has some blurb from the publisher and some screenshots of the app in action:

    AppDetailsPage 
  4. If the site owner is happy with this, they can click the ‘Add it’ button – at this point, they are presented with some permission requirements the app has. This could be to SharePoint content such as lists/libraries, but also other items such as calling into a service application. Remember that an app can run with different permission levels than the actual person using it (e.g. an app could be allowed to delete documents where the user cannot directly), and this step ensures someone responsible for the site grants the required access. This is known as an app permission request.

    Adding-app---trust-request

    (As a sidenote, it will be more normal to see an app requesting to work with a specific list, rather than the site owner selecting a list from a dropdown – the image above shows the result of me specifying that the app requires ‘Manage list’ rights, but not specifying a particular list that this applies to).
  5. If the permission request is granted, then the app is added to the site and is then accessible from the ‘Site Contents’ area:

    OpeningAnApp
At this point, the app is now usable by regular site users.

The end-user experience – using an app

Actually you just saw it. For ‘full page’ apps, users will access apps from the ‘Site Contents’ area as shown in the last image. Here they can also find other apps, lists, document libraries and so on. When the app icon is clicked, the user will be redirected to the start page for the app (as defined in the ‘StartPage’ property in AppManifest.xml). In the SharePoint-hosted example I showed in my last post, this could be a page provisioned to the app web:
 COBAppDefaultPage
Regardless of where the user goes within the app, the header maintains a simple breadcrumb link back to the host web (where the app was accessed from).
Note that apps can also be surfaced in other ways than the full page model – if a web part is effectively all that’s needed, then SharePoint 2013 provides ‘app parts’ (aka ClientWebPart) which is an IFrame-wrapper to bring the UI of an app into the host web. In the case of a SharePoint-hosted app, this could be a page provisioned into the app web (as shown above), or if the app has external components it could be a page hosted on some external servers.

The site owner experience – adding from the public SharePoint Store

In case you’re wondering, the experience of using the public app store is not hugely dissimilar to using the internal App Catalog. Some bits are not live yet (e.g. the financial transaction bit), but effectively there’s a big categorized list of apps to pick from:

SharePointAppsInStore

The site owner experience – where app feature/capability requirements are not met

Regardless of where the app comes from, in addition to permission requests (which the site owner must acknowledge when trusting the app during installation), apps can also specify prerequisites in terms of SharePoint features. After all, if an app is dependent on say, the SharePoint 2013 social features, it would clearly fall over in a heap if that service isn’t available in an environment where the app is being installed. So, the app framework does not allow installation of an app if these prerequisites are not met – the site owner will see a message stating that the app cannot be added:
AppCannotBeAdded
In this scenario, the ‘app details’ page lists the reasons why the app cannot be added:

AppCannotBeAdded---Storefro
The important thing here though is that there is no magic - SharePoint is not doing some inspection of every line of code behind the app to work out what it needs. Instead, it’s up to the app developer to specify all prerequisites (including permissions requests) before the app is packaged – this info goes into the AppManifest.xml file, but there is a handy designer in Visual Studio 2013:

VS_AppPermissionAndOtherPre

Other user experiences e.g. SharePoint administrator

In addition to the site owner ‘app install’ experience and the end-user ‘app usage’ experience, there are other stakeholders to consider too. Administrators will want to know things like:
  • Which apps are in use where
  • If any apps are currently experiencing problems
  • Which apps in the public SharePoint Store are the top requested apps – this applies in the scenario where site owners are not allowed to directly obtain apps from the public SharePoint store, but are allowed to log an ‘app request’
A series of screens in Central Administration supports these administrator needs, but I’ll save that for another post.

Summary

The SharePoint 2013 app framework is a fairly radical departure in the world of SharePoint development, and when formulating SharePoint strategy it’s important to understand when apps are appropriate and when they are not. A piece of functionality can now effectively be rolled out to SharePoint in three different ways:
  • Farm solution
  • Sandboxed solution
  • SharePoint app (which as discussed above, could be a purely SharePoint-hosted app, an app hosted on non-SharePoint hardware [possibly by a vendor] or an Azure auto-provisioned app – my intro post also has more details)
Microsoft guidance says “develop an app wherever you can”, but consider that they may not have the same goals as your project/environment. Personally, I buy into the idea that a key MS driver for apps was to reduce SharePoint upgrade complexity and therefore maintain the license income stream. If you have evaluated your development/customization strategy and are of the view that upgrade to whatever the next version of SharePoint will be is entirely manageable, then I wouldn’t necessarily conclude that apps are in any way mandatory.
In that case, the question might then be “do the semantics and user experience of the app model give me something over and above other customization approaches?”. Some examples of this could be the App Catalog experience, or perhaps keeping in line with the way other customizations have been developed – either way, there might be fewer things to consider if you aren’t constrained by upgrade/architecture concerns.

Further reading

17 comments:

levalencia said...

I really love this post because it shows the hidden disadvantages of Apps, After reading this post however I have a few questions:

You say:
Any SharePoint artifacts provisioned (lists, web parts, content types, site columns, master pages, content pages, other files) do not get provisioned in the site end user browses

So, where are the lists stored? In a different content database?


2nd. If artifacts provisioned are not in the site the end user browse, so I suppose you cant access lists created by other apps, or OOTB lists in the sharepoint site?


I am still thinking that for corporate development, webparts/farm solutions will be the way to go.


3rd. After reading your feature upgrading posts many times, I must ask, Apps can be upgraded the same way? What about if you create version 1.0 of an app with 3 fields, and later you need to add another 2 fields in version 2.0?

Chris O'Brien said...

@levalencia,

Thanks. Those are all good questions. Let me try to answer:

1. Yes, the artifacts are in a different site collection and content database. See my image with the stacks of dollars - notice the URL is to a different web application.

2. Yes and no. Apps are isolated, so they cannot access data provisioned by other apps. However, an app may be able to access data in the 'host web' - e.g. OOTB list/libraries which the users use. This is what the site owner must agree (the app permission request) when he/she installs the app to the site.

3. Apps have their own upgrade lifecycle. I haven't yet looked at this in detail, but I am expecting that upgrades to SharePoint artifacts in the app web would indeed be handled by the Feature Upgrade framework. I'll follow up on this in future articles.

Thanks!

Chris.

Amol Ghuge said...

Useful information shared..I am very happy to read this article..Thanks for giving us nice info. Fantastic walk-through. I appreciate this post.

Andrew Burns said...

So, Azure auto-hosting is only available in SharePoint Online - but would it be possible to use Externally Hosted Azure application? Just that would seem to solve many of the questions around externally hosted - except, of course, that your SharePoint farm would need to be able to access the external host.

Would that be possible? Does that make sense?

Chris O'Brien said...

@Andrew,

Yes and yes. It would be entirely possible to host external components in Azure but not take advantage of auto-hosting for deployment. Indeed, auto-hosting may not make sense in some scenarios.

So long as the external site (in Azure or elsewhere) can call into SharePoint via CSOM/REST etc., it's a workable option for app hosting.

Cheers,

Chris.

Anonymous said...

Nice post. One clarification: The app web is not in a separate web application from the host web. In fact, it is a subweb of the host web, and thus it is the same site collection and content database. The app web a different base URL from the host web because it has its own domain name. This is for security reasons. For more information see this SDK topic: http://msdn.microsoft.com/en-us/library/fp179925(office.15).aspx
In fact, if you open Site Settings on the host web and then click the Site Hierarchy link, you'll see the app webs listed as subsites.

Nik Patel said...

I am trying to confirm from many sources and yours seems only resource mentioned this.. Azure auto-hosting is only available to apps deployed to SharePoint Online.

Is that true? Auto-hosted Apps are available only in SharePoint Online? Only provider/developer hosted and SharePoint hosted Apps are available for On-premises?

Nik

Nik Patel said...

It seems like you have confirmed earliar in the comments - Azure auto-hosting is only available in SharePoint Online.. Never mind...

Chris O'Brien said...

@Anonymous,

That's a great clarification, thank you! I had missed the fact that actually the app web is on a different domain for HTTP request processing, but in storage terms it's actually in the same site collection. This makes more sense in terms of capacity planning etc.

I'll update the main article text shortly. Thanks again.

Chris.

Natalia Tsymbalenko said...

Correction on:
An app is effectively scoped to a web only – the client APIs do not provide the ability to talk to the parent site collection, web application or farm

You can talk to host web (spweb) or event site collection (SPSite) via APPS in case you have asked permission to access it.

But for web application and farm, yes, it's correct. You can't get access to it even with Read

Chris O'Brien said...

@Natalia,

You're absolutely correct - I actually talk about this a lot in my next article Working with the app web, and why you should.

The idea of apps which have, say, a Manage Web permission request for the host web (or even Full Control to the host site collection) and use stuff there came to light (for me) between writing this article and that one, but I hadn't got round to correcting this one yet.

Thanks for the comment, appreciate it!

Chris.

Chris O'Brien said...

@Natalia,

Main article text now updated, thanks again for the prompt :)

Chris.

Kourosh said...

Hi and thanks for this useful post.I have a problem and hoping you can help med to solve it. I have created a SharePoint hosted app based on the template which is in VS 2012. I add nothing to it. When I hit F5 it works but when I publish it (adding .app file to app-catalog site collection) and add it to a site collection and browse to it, it says "This page can't be displayed make sure the web address http_mysite is correct. blah blah. Thank you alot.

Chris O'Brien said...

@Kourosh,

It sounds like you haven't configured your app domain properly. Check out Configure an environment for apps for SharePoint (SharePoint 2013) on TechNet.

HTH,

Chris.

Keith Tuomi said...

Hi Chris,

Do you know if it's possible to customize the small icon that appears in Edit Page > Insert > App Part?

Jurgen Wiersema said...

Hello,

What do you think about the following idea:

Create a normal webpart that is perfectly programmed. All it does is allow you to select an App in the App web in the webpart properties.
Then it shows the app-page that is in the app web in an iFrame on any regular publishing page.

The advantages would be:
1) that you only have to deploy the code of that App-wrapper webpart.
2) it would allow site owners and contributors to securely add new functionalities by adding new apps, that are then wrapped in a webpart. 3) The apps' data can all be stored in the app web and it doesn't need to have permissions outside of the app web.
4) For end-user a sharepoint site works the same as before (i.e. statis + dynamic content).

The downside is that you'd be immediately violating the app principle and you'd need a separate server for the small amount of farm-deployed code.

Johnny said...

Great series of articles, Chris - do you happen to know anything about when it will be possible to submit Autohosted apps to the Marketplace? At the moment it isn't available.