Export (0) Print
Expand All

Apps for SharePoint UX design guidelines

apps for SharePoint

Learn about general user experience (UX) design guidelines for apps in SharePoint 2013, including choosing the chrome, using CSS, managing user licenses, and other design tasks.

The first thing you have to determine when you are building an app is how much or how little you want to brand your pages and where you want them to be hosted. Depending on those choices, which technology you use to power your chrome will be relatively obvious:

  • ASPX pages hosted in SharePoint: Use the app template.

  • HTML pages hosted in SharePoint or any pages outside SharePoint: Use the chrome control.

  • Custom branded pages: Use your own chrome.

Using the app template for SharePoint-hosted pages

The app template can be used only for SharePoint-hosted ASPX pages. The template includes the app.master master page (which contains chrome appropriate for an app and is designed to theme with the host site), and it hides some SharePoint functionality that either wouldn’t work or doesn’t make sense inside of an app web. Figure 1 shows a SharePoint-hosted page that uses the app template.

Figure 1. SharePoint-hosted page using the app template

A SharePoint-hosted page using the app template

The app template is the default in Visual Studio when you create an app web and pages within that web.

Using the chrome control in apps for SharePoint

If you’re not building SharePoint-hosted ASPX pages, but you still want your app to fit in naturally with the host site that it is used from, the chrome control is the right choice. Figure 2 shows the chrome control.

Figure 2. Chrome control in a webpage

Chrome control in a webpage

Watch the video: SharePoint 2013 chrome control


To use the chrome control

  1. Add a reference to the controls library. There are two ways to do this:

    • Point to the library at the root of the layouts folder, as shown in the following example.

          src="http://{server URL}/_layouts/15/sp.ui.controls.js">
    • Copy the library to your own website, and reference it from there.

      Caution note Caution

      If you opt for this alternative your app will not benefit from updates to the control.

  2. Add the placeholder DOM element where the control will be rendered, as shown in this example.

    <div id=’chromeControlContainer’></div>
  3. Instantiate the control.

    function addchromecontrol(){
        var options = {};
        options.siteTitle ="{host site title}";
        options.siteUrl = "{host URL}";
        options.appHelpPageUrl = "{help page URL}";
        options.appIconUrl = "{app icon URL}";
        options.appTitle = "App Title";
        nav = new SP.UI.Controls.Navigation("chromeControlContainer", options);
  4. (Optional) If you don’t want to have the title area on your page, you can remove it by running the following JavaScript code.


The chrome control provides for two optional app icons: one on the top navigation bar and one in the title area. The app icon on the top navigation bar is 24 x 24 pixels (px), and the icon in the title area is the same size as SharePoint site icons—up to 64 px high by up to 180 px long. We recommend you use a PNG image that you have tested on white, black, gray, bright, and muted backgrounds because users and admins can change the site theme. For more information about using the chrome control, see How to: Use the client chrome control in apps for SharePoint.

Creating a custom branded UI in apps for SharePoint

If, instead of aligning to the host site’s theme and fitting into the SharePoint site where your app is installed, you want to use your own brand inside your app, you will have to build your chrome from scratch. However, you should still have a "back to site" link in the upper-left corner of the page (upper-left in right-to-left [RTL] languages) that redirects the user back to the site where the app is installed.

By using the same styles that are used on the host web, you can ensure that your apps will remain consistent with the SharePoint site that they came from. The actual styles may change based on the design of the site, but by referencing the CSS file of the host web, you will know that your app will fit in no matter where it’s installed.

To get the CSS styles from the host web, you have to reference its CSS file. You can do this in several different ways.

To reference the host web’s CSS file

  1. If you’re using the app template or app chrome control, this is automatically taken care of for you.

  2. If you’re inside the app web, you can use the CssRegistration and CssLink controls to reference the CSS file by putting the following code on either your master page or ASPX page:

    <SharePoint:CssRegistration runat="server" name="default" />
    <SharePoint:CssLink runat="server />
  3. You can use a <link> element to reference the CSS file by building a URL off of the host web’s URL, as shown in this example.

    <link rel="stylesheet" href="{host web URL}/_layouts/15/defaultcss.ashx" />

    If you use this approach, you have to run JavaScript in the page to get the host web’s URL off the query string. Then you can insert the host web’s URL into the link element before you write the element to the page’s DOM.

The first thing to do when you are styling your app is to use semantic HTML as much as possible. That means using H1, H2, H3, and so on, for the various headings, and input tags for buttons. You should also try to use SharePoint core styles as much as possible so that when the theme of the host site changes, your app picks up those changes seamlessly and automatically. The following tables show how styles are used in the default theme.

Table 1. Body text styles


Used for



Extra large body text



Large body text



Normal body text

Inherited automatically


Small body text



Metadata text


Table 2. Title and header styles


Used for



Main title on the page



Title for dialog boxes, forms, blogs, and discussion posts. It's an alternative "primary" title for special content types or apps that take up the entire pagethat you want to be different from a regular wiki or Web Parts page.



Secondary heading in relation to H1. For example, Communities uses H1 Accent for the title of a post, and H2 Accent for the best "response" to the post.



Generally a subheading under H2.



Subheadings under H3.



Title of the main/primary Web Part on a page, or for main section headers.



Title for headings within dialog boxes or callouts.


Table 3. Navigation styles


Used for



Heading of the left navigation bar.

.ms-core-listMenu-verticalBox > .ms-core-listMenu-root > li > .ms-core-listMenu-item


Link in the left navigation bar.



Selected item in the left navigation bar.

.ms-core-listMenu-verticalBox + .ms-accentText


Item in the top navigation bar.


Selected item in the top navigation bar.

Table 4. Command styles


Used for



Primary action links you expect the user to take within a given container or page. For example, this would be used to style the commands underneath a callout. This will always be the same color for visited and non-visited commands.



Also used to style action links, but for actions that are secondary to the content. This style is used for these secondary actions, so they don't compete with content for attention.



Links in the callout.


Table 5. Modifier styles


Used for



Helper class that will provide the accent color from the current theme for text.



Links in the content should inherit from default hyperlink styling and behavior. Hyperlink styling applies a color and a hover effect to indicate that it's a link instead of normal text.

Inherited from using <a>.


Error messages that occur in forms.



Helper class that provides a softened gray for text that should be less emphasized than normal body text.



Helper class that applies the "disabled" color to text, which is used for denoting disabled states.



Helper class that transforms the text to all caps.



Helper class to style text like forms.



Dashed line divider that is used to divide sections in the Quick Launch and in menus.


Table 6. Part user interface styles


Used for


drag files

Main inline text at the top of a part.

.ms-textXLarge + .ms-soften


Commands in the top line of a part; at most there should be only one or two of these per part.



Text shown to entice the user to interact with the part when it doesn’t contain data.



Text shown to the user when there is no data available.



View controls, such as a pivot.



List items that are also links.


Table 7. Background and border styles


Used for



To style a rectangle that should be heavily emphasized on the page.



Border of an emphasized element.



A more subtle emphasis of an element.



Commands in an element styled with ms-subtleEmphasis.



Disabled command in an element styled with ms-subtleEmphasis.



Side navigation elements.



To style the selected side navigation element.



To emphasize an element using a border.



To emphasize an element using a subtle border.



To emphasize an element using a strong or colored border.



To emphasize a disabled element using a border.



To emphasize an element using an accent border.



To contain pop-up windows.



To apply an overlay on the background element.



To make the background of an element appear disabled.



To apply the header background color.



To apply the footer background color.


md-bghoverable normal

Elements that should have a highlighted color on hover. The example shows the element when the mouse is not hovering over it.



Elements that should have a highlighted color on hover. The example shows the element when the mouse is hovering over it.



To show selection on an element.



Elements in the top bar of the page.


For more information, see How to: Use a SharePoint website's style sheet in apps for SharePoint.

To help users learn skills that translate between SharePoint and apps, you should style several common elements consistently.

Internal navigation

To provide navigation within your app, there are two main patterns to follow: left navigation and top navigation. Which option you use depends somewhat on what the content is in the rest of your app. In general, left navigation will be the correct choice, particularly if you’re switching between different lists, or the focus of your app is a master-detail view. On the other hand, if your navigation mainly switches between what could be considered different views of the same list, you could choose to use top navigation instead.

Both left navigation and top navigation have object model representations that will be styled correctly when they are set in SharePoint. Outside of SharePoint pages, you’ll have to do a bit more work to create the markup for the top or left navigation yourself, and then add the appropriate CSS classes so that it’s styled correctly.


In many cases, you will have a small number of commands that you want to surface quickly to the user. If you are using the ribbon on your page already, the best choice is to add those commands to logical locations within the existing ribbon. However, in the case where you don’t already have a ribbon on the page, it probably doesn’t make sense to add one for a handful of commands. In that case, we recommend that you add a toolbar contextual to the item where the commands will apply. You should use either glyph, text styled with ms-commandLink, or both, to represent your commands on the toolbar, which should have the same background color as the rest of the page.


Lists are a common way to represent data to users. If your app is using SharePoint pages, you could use the List View Web Part to represent the data to users and get the styling and interaction that comes with it. However, if you have your pages elsewhere, or you want more control over the interaction that users have with your list, you should mimic the styling of lists in SharePoint while providing your own rendering and interaction. The following are some style issues to keep in mind when you are using lists in your app:

  • Views: When representing multiple views on a single list, you should use a pivot at the top of the list, just as regular SharePoint lists do. You should never use pivots as a way of representing master-detail data.

  • Filters: When providing a filter on an existing list or a master-detail arrangement, you should use a sidebar that is flush with the left side of the content area and that is at least 300-pixels wide. You should also copy the SharePoint selection styling to indicate to the user which filters or items are selected.

  • Forms: When a user is viewing or editing a single item, you should either use the built-in SharePoint forms or mimic their styling for a consistent experience.

Forms, dialog boxes, and callouts

There are three distinct patterns for providing the user with more information about an object, or for providing a user interface (UI) for user input: full-page forms, dialog boxes, and callouts. Whichever one you use depends on the user intent and how much information will be shown or requested.

  • Full-page forms: This is the best choice when you want users to enter several different pieces of information, or you want to show them a lot of structured information at one time. Full-page forms also make the most sense in scenarios where more complex interaction models, such as the ribbon, are required. In this case, you would point the user to the form page when necessary. You should make sure that there is a clear way to save or cancel their changes, by using either buttons or the ribbon. In very long forms that might require scrolling, it’s a good idea to place the Save and Cancel options at both the top and bottom of the form.

  • Dialog boxes: These are modal UI containers that are typically used to show more information or actions in a contextual manner. They are also used for shorter forms or user input. In general, the UI that is hosted within a dialog box should be simple and well suited for a smaller rendering surface. Longer forms or more complex interaction models, such as the ribbon, are better served by full-page forms instead.

  • Callouts: These provide relevant contextual information and actions around a particular item. Callouts are generally used to show the user more information or actions about an item in a lightweight UI. If scrollbars or user input are necessary, the callout is probably not a good choice.


Although animation can lead to a more vibrant and engaging experience, you should be careful to not overuse it in your UI. Animation that is done well will be hardly noticeable by the user, but it will give the impression of faster, better-performing UI. When using animation, you should make sure to respect concepts like physics and inertia and provide UI that seems natural and graceful. We strongly recommend against exaggerated animations like excessive bouncing or elasticity, or having objects fly around the screen at the slightest user action. Objects should generally take a direct path to their destination, and often will only need the first or last 10 percent of the actual change to be animated in order to give the user the sense that it has moved.

Tabs and pivots

In SharePoint, the only place where you should use tabs is on the ribbon. Everywhere else in SharePoint should use pivots to express the concept of changing the content area.

SharePoint allows apps to extend some of the existing UI, which enables you to make your app available in the places where users might need it. You can extend the host web’s UI by using the following methods:

  • App parts: Enable you to surface an iframe element to contain content from your app.

  • Custom actions: You can extend the ribbon or contextual menu through custom actions. Custom actions make your app available on list items or documents, or anywhere else the ribbon is shown.

Adding app parts to the host web

Parts are a way for your app to surface some information or a small interaction point in the host web where the app is installed. End users can embed those parts in their pages by using the Web Part framework in SharePoint. Figure 3 shows the tag cloud part as an example of a part.

Figure 3. Tag cloud part

Tag cloud part

In Figure 3, the Tag Cloud from UX Design app is the title of the part. The tag cloud itself is served from the app content, and it is hosted in an iframe element and fully isolated from the hosting page. Because the app content is using the host web’s CSS file, it fits in seamlessly with the host page.

Some kinds of UI lend themselves well to being exposed through part UI. For example, you might want to provide a set of shortcuts into different experiences of your app, or even a single launch point that users can embed on other pages. Another use might be to show a small subset of the data in the app, or show the most recent changes to something. You might want to provide a small interactive zone for performing quick actions with the app without having to open it to do so. What type of part you provide will be driven by the scenarios your app supports. You should keep in mind that not all apps will have parts, you should only provide them if they make sense for the user experience.

The page you display inside the part will be hosted in an iframe, so you should make sure that any JavaScript you write is aware of that and is smart about accessing things like the window object. Even if the rest of your app is heavily branded, you should consider adopting the host web’s styling for your part, because it will be embedded within the host web’s pages and will look jarring and unappealing if it doesn’t fit in. In order to use the host web’s styling, you’ll have to build the link to the default CSS file manually. For more information, see How to: Reference the host web’s CSS file in this article. There also should not be any chrome on the page, because it will be embedded on a page that already has chrome itself.

The page has to work nicely in an iframe across different domains, so you’ll have to make sure that you do not specify same-origin only for X-Framing-Options of this page. By default, SharePoint pages do specify that they should only be in an iframe within the same domain. So for pages that are hosted in SharePoint, you’ll have to opt out of that behavior for the pages you want to show in parts by adding the AllowFraming Web Part somewhere on the page, as shown in the following example.

<WebPartPages:AllowFraming ID="AllowFraming1" runat="server" />

Because you cannot enforce which domains your pages are iframed into, the pages you host in app parts are vulnerable to a clickjacking security attack. In clickjacking attacks, pages can be in an iframe on a malicious page, and users could be tricked into choosing buttons to take actions they’re not aware of. When designing your page, you should be aware of this and make sure you’re not exposing any functionality in the page for the part that would be dangerous if surfaced in a malicious page.

Although users can manually set a different size on your part, you are able to set a particular size for the part in the part definition. You also have the ability to request that your part is resized dynamically through postmessages. By default, we recommend that your part choose sizes in increments of 30px (for example, 150px or 210px) so that when parts from different apps are mixed on the same page, the user can still get a sense that each of the parts was built to work in the same space. If your part is meant to mimic a tile from the getting started experience, it should have a height and width of 150px. If the part is meant to display in a side column to show details, it should have a width of 300px.

If your part displays dynamic content, it’s a good idea to request a resize to reduce having scrollbars embedded within a page. The following example shows you how to use postmessages to resize the part:

window.parent.postMessage(‘<message senderId={your ID}>resize(120, 300)</message>’, {hostweburl});

In the example above, the senderId value will be set on the query string of the page automatically by the app part code when the page is rendered. Your page would just need to read the SenderId value off of the query string and use it when requesting a resize. You can retrieve the host web URL from the query string by appending the StandardTokens or HostUrl tokens to the Src attribute in your app part definition.

To specify a part for the host web, you must specify a client Web Part in the feature file in the app package (not the feature file in the WSP in the package). You can create a part that could be configurable by the end user, such as by specifying a ZIP or postal code. The following markup specifies an app part, and the Properties element is optional:

    Name="Sample App Part" 
    Title="Sample App Part" 
    Description="This is a sample part with properties.">
    <Content Type="html" Src="~appWebUrl/Pages/Part.aspx?Property1=_prop1_&amp;Property2=_prop2_&amp;Property3=_prop3_&amp;Property4=_prop4_" />
            WebDisplayName="First Property" 
            WebDescription="Description 1" 
            WebCategory="Custom Properties" 
            DefaultValue="String Property" 
            RequiresDesignerPermission="true" />
            WebDisplayName="Second Property" 
            WebDescription="Description 2" 
            WebCategory="Custom Properties" 
            RequiresDesignerPermission="true" />
            WebDisplayName="Third Property" 
            WebDescription="Description 3" 
            WebCategory="Custom Properties" 
            RequiresDesignerPermission="true" />
            WebDisplayName="Fourth Property" 
            WebDescription="Description 4" 
            WebCategory="Custom Properties" 
            RequiresDesignerPermission="true" >
                <EnumItem Value="one" WebDisplayName="One" />
                <EnumItem Value="two" WebDisplayName="Two" />
                <EnumItem Value="three" WebDisplayName="Three" />

In your ClientWebPart element, you’ll want to specify the following things:

  • Name: An internal name that is used to identify the app; must be unique.

  • DefaultWidth/DefaultHeight: The default size of the Web Part. If necessary, you can resize the page inside the part.

  • Title: The name that is displayed to end users when they add your part to a page through the Web Part adder.

  • Description: The description that is shown to end users when they add your part to a page through the Web Part adder.

You can specify part properties of type string, enum, int, and Boolean. You can specify the toolpart category that you want your properties to appear in by using the WebCategory attribute. The attributes on the Property element that you want to specify are as follows:

  • Name: The name used to match this property with a token on the query string to replace.

  • WebDisplayName: The name used in the tool part.

  • WebCategory: The tool part in the toolpane to add this property to.

  • Type: The input data type that is expected from the user. Type can be string, enum, int, or Boolean.

  • DefaultValue: The default value for your property.

When the part is added to the page, any strings in the query string that match the pattern _propertyName_ are automatically replaced with the value of the property with that Name on the Web Part instance, or the default value if the user hasn’t set it. You would then run code inside the page to parse through the query string and pull out the properties to use them in rendering and interaction on your page.

You can also choose to have the Web Part ID sent on the query string by using the _wpid_ string to represent where you want it to be replaced on the query string. This can be helpful in differentiating different part instances if you want to be able to store information about user choices or interactions on a per-instance basis. For more information, see How to: Create app parts to install with your app for SharePoint.

Adding custom actions to the host web

If you have functionality that would make sense to surface in the context of list items or documents, or on particular ribbon tabs in the host web, you can add those to the context menu or the ribbon by using custom actions. To surface custom actions in the host web, you’ll need to define them in the same kind of loose feature file in the app package as the one that contains ClientWebPart definitions.

Figure 4. A custom action in the contextual menu

A custom action in the contextual menu

The code for custom actions that are surfaced in the host web is the same as in previous versions of SharePoint, with the following restrictions:

  • The Location attribute must be either CommandUI.Ribbon or EditControlBlock.

  • CustomAction cannot contain JavaScript:

    • Any UrlActions or CommandActions must be a URL to navigate to. The URL can be parameterized with normal custom actions tokens in addition to the app-specific tokens.

    • EnabledScript is not allowed in ribbon customizations.

Normally when a user chooses a custom action, it will navigate them to the URL you have specified with any tokens resolved based on their selections. However, there are some cases where you might want the user to stay in context on the page, such as for quick actions on a particular document. If you want to have your custom action open a dialog box instead of navigating, you should add the following attributes to the CustomAction element.


The HostWebDialogHeight attribute and the HostWebDialogWidth attribute are optional. If the attributes are not specified, the default size for a dialog box in SharePoint will be used. In general, though, you should specify the size of your dialog box so that it looks right and doesn’t use scrollbars when it is displayed to the user.

The dialog box always includes a Close button in the dialog box chrome. You can also include buttons on your page that will close the dialog box and tell the originating page whether it needs to refresh. If you’ve done something that could be reflected in the view the user is looking at (for example: updating properties on a document), you should refresh the page. On the other hand, if you didn’t update anything (for example: a "cancel" action or sending a file to an archive without updating any properties), you can tell the page that no refresh is necessary. The following examples show you how to send POST messages to close the dialog box.

window.parent.postMessage('CloseCustomActionDialogRefresh', ‘*’);
window.parent.postMessage('CloseCustomActionDialogNoRefresh', ‘*’);

Depending on whether you use CloseCustomActionDialogRefresh or CloseCustomActionDialogNoRefresh, the dialog box closes, and it either refreshes the page behind it or it does not.

You cannot add a custom tab to the ribbon of the host web from your app. You can only add custom groups or individual controls. You should not override any of the default SharePoint ribbon controls. You should have your controls exist side-by-side with the SharePoint controls.

If you have a few controls that are related to each other, or that the user will likely associate with using your app, you should group them in their own custom group so that the user is more likely to find them. If, on the other hand, the functionality you’re adding is more likely to be something the user considers part of the core experience of their site, you should try to fit that control into a logical spot in the existing ribbon locations. For more information, see How to: Create custom actions to deploy with apps for SharePoint.

In many cases, it makes sense for your app to have some configuration information that the user can change, and to expose this information through the use of a settings page. Ideally, you can choose reasonable defaults for those settings, and users can choose to go to the settings UI only if they need to modify those defaults. In some cases, the app will require certain information or choices to be provided before the app can function. When your app requires information before it can function, you should provide a user experience that guides the user to the settings page to update the configuration.

You should add the settings page URL to the app’s top-right menu if appropriate so that users can find it easily. If your app has a getting started experience or other settings, you can add those also. For more information, see How to: Use the client chrome control in apps for SharePoint.

You should also keep in mind that the user who is currently visiting the app might not be able to configure it. Your UI should also not assume that the current user is able to complete the configuration. Your app should guide the user to find the right person if they cannot configure it.

If your app is not free, you should find a good balance between the features that are available or restricted in the trial or unlicensed modes versus the fully paid version.

If you provide a time-limited trial, the trial version should act just like the paid version during the trial period. Give users a realistic expectation of what they will get when they pay for the app. If you choose to restrict anything during the trial period, be very clear about how the user can get more when they pay. For unlimited trials, you should expose as much functionality as you think is needed for the user to get a good sense of the value of your app. Make it clear what extra benefits they would get by paying for it.

When people first see your app, they may not have a license for it. For example, one user might add your app to a team site, but forget to license anyone else. Other users on the team site would be using your app without a license until the license manager fixes the situation. You should make sure they get a good impression so they will be more likely to demand or buy a license. It is a good idea to always let users view and navigate through the data in your app. Be clear about how having a license will enable more features, but don’t remind them more than once per session.

If your app’s core value is in displaying data (and you don’t want to give that away for free), you should show a limited subset of the data, or show the data without any interactivity. You should not block unlicensed users from viewing your app. Unlicensed users should get a taste of what your app can do for them so that they are more likely to buy it.

Encouraging users to get a license

In the case where an unlicensed or trial license user is using your app, you should encourage them to get a full license. There are two ways to encourage users to get a full license:

  • With a status bar at the top of the page that indicates their license state.

  • In context when the user tries to access content or functionality that requires a license.

You should be very careful about overusing the second case of license warnings. It is a better experience for the user when you use the top-level status message and disable any unlicensed functionality than to let the user be unpleasantly surprised by an inability to do something. In either case, your message should be friendly and encouraging rather than stern. You should give the user a link to the storefront app details page for your app, where they can get a license.

Licensing status bar

SharePoint has a built-in status bar that you can use on SharePoint pages by calling the JavaScript API. You can also copy the styling of the built-in status bar. You should use the yellow "warning"" color, with a message appropriate to the situation the user is in, for example:

  • For users of an unlimited trial: This is a trial version of <app name>. Go here to purchase the full version and unlock <paid functionality>.

  • For users of an unexpired time-limited trial: There [is|are] <amount of time, expressed in a human-readable metric like "3 days" not "73:42:12"> left in this trial of <app name>. Go here to purchase the full version and ensure you don’t miss a moment of full functionality.

  • For users of an expired time-limited trial: Unfortunately, there is no more time left in this trial of <app name>. Go here to purchase the full version and return to full functionality.

  • For users without any license: Unfortunately, you don’t have a license for <app name>. Go here to purchase the full version and enable <paid functionality>.

In addition to what has already been explored, you should keep these things in mind when you are creating your app for SharePoint.

Persisting necessary information in cookies

There will be a lot of information that your app will need to be able to interact with SharePoint, such as the URL of the host site or the POST message with SharePoint credentials. Persisting information in a client cookie means that your app doesn’t have to keep requesting the information from SharePoint, which leads to a smoother, better-performing experience for the end user.

Requesting a new OAuth token

If your app doesn’t have credentials, you can request a new one by redirecting the user to the redirect page with your app ID and the URL that the user is trying to go to. The URL must be under the domain of the redirect URL that is registered for the OAuth app ID that you are using. The following URL is an example of how to redirect your app users. For more information, see App redirect page .


Checking for read-only mode on SharePoint sites

Due to upgrades or site maintenance, there might be times when SharePoint is in read-only mode at the moment the user accesses your app. If you’re going to allow the user to manipulate SharePoint data, you should make sure you don’t let the user make changes that can’t be saved back to the server. Disable the editing UI when in read-only mode. To check if the site is in read-only mode, you can call this API:


© 2014 Microsoft