SharePoint Apps Playbook Series: Part 4 – ‘In SharePoint’

This entry is part 5 of 6 in the series The App Playbook Series

One of the biggest concerns I have heard with SharePoint Apps to date is that it’s not “in SharePoint”. As mentioned in Part 3, the experience for the Information Worker who clicks on the App from Site Contents gets a bit of a jolted experience because all that really carries through is the Suite Bar at the top and the theme colors and style (if you hook your app up correctly). You lose the Quick Launch, you lose the Top Navigation, the Search, the Share, the Sync, the Site Actions menu, the About Me menu.

The traditional Solution Model approach, as explained in Part 1, meant that essentially everything you built was grafted into existing SharePoint pages via Web Parts, Delegate Controls, Master Pages, Page Layouts, Site Pages and Application Pages. On top of that the ability to ‘hack’ at the out of the box CSS that could manipulate the DOM anyway you liked…and even more so with JavaScript.
It is no surprise that Microsoft wanted to get more control over how you could customize SharePoint. Jeff Teper, Corporate Vice President of SharePoint, quoted this in the Press Release for SharePoint 2013:

“Use SharePoint as an out-of-box application whenever possible - We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.”

This brought up a lot of debate around the future of customization in SharePoint. Every major upgrade of SharePoint caused head aches where the UI was manipulated and naturally with the continuous updates happening in Office 365, Microsoft had to try and set a new stance on what was the best way to build business solutions.
I’m guessing that the reasons that the SharePoint Designer Design View was removed in 2013 edition was part of that direction and that obviously the isolation of SharePoint Apps was yet another example of this. It will be interesting to see how Microsoft pitch the future direction of customization at SPC14.

I know I’m starting somewhat of a religious war around an art form of customizing SharePoint that has existed since SharePoint 2003. The Solution Model and SharePoint Designer tool simply encouraged this approach. My own view is that the new App Model is a solution that allows you to build your business solutions with the UI that you want without the risks that concern Microsoft and affect product design decisions to innovate the product in the future.

This is very topical right now, with posts from the likes of Marc Anderson and Andrew Connell on the topic of manipulating the DOM.The skill sets of the SharePoint Designer developer can be transitioned into App Model, yes granted it means right now either using the NAPA app or the Visual Studio tooling, but essentially you’re doing the same HTML and JavaScript stuff inside an isolated App Model on aspx pages or html pages. I know its not as quick as throwing a Content Editor Web Part on an existing page, but alas “times are changin’”.

There are obviously a few scenarios that can’t be done in the App Model yet, but I’m sure Microsoft are aware of them and will have plans to address them with the model.
It is very common to want to override the out of the box SharePoint UI whether it be for additional forms validation, hiding elements on pages, moving elements on pages etc.
The one that Marc brings up around manipulating the out of the box List Forms is certainly valid but could be addressed by building your own form in an App using a framework like AngularJS. Obviously you get a lot of plumbing for free out of the List View and List Form components that has always been a benefit of quickly building business solutions. The biggest problem here is how you block the Information Workers from going to the out of the box List Views that are available and to your customized ones in an enforceable way.
It will be interesting to see what Microsoft announce at SPC14 around the new forms engine that will replace InfoPath also.
As mentioned in my other posts, please voice your requests on the UserVoice site as Microsoft are listening.

The key strategy with getting the App to feel part of the SharePoint user experience is to leverage the hooks into the SharePoint parent Site. Right now Microsoft provide a few of these hooks:

App Parts

App Part – A component of an app for SharePoint that can be embedded on a site page to expose the functionality of the app.

The definition above comes from the SharePoint 2013 Glossary. App Parts work in a very similar way to Web Parts, the main difference being is that essentially its just an IFRAME to a page that is isolated running in the App Web. You can have Properties that can be set in Edit Mode of the Page, just like Web Parts.


Microsoft have a great reference post on leveraging the Host Web styles in App Parts. Richard diZeregas has a great post on showing how to get the App Part to inherit the look and feel of the Site Page that it lives on in the parent Site.


The main friction right now is that because it is an IFRAME its actually hard to get the App Part to have a responsive UI that stretches and shrinks with the rest of the page and flows well on multiple resolutions and form factors. Microsoft have some resizing approaches which require providing height and width. Chris O’Brien has a post that explains how to use the “AllowFraming” construct to make the App Part more responsive. I also found Leandro Bernsmuller’s post too on this with a full code example.


In some cases, your business solution may simply be just an App Part. Unfortunately to get the App Part on the page, the Site Owner is going to have to add the App, then go and edit the Page and click on Insert in the Ribbon and find your App Part in much the same way they add Web Parts to a page. Unfortunately there is no way to currently add App Parts to a Site Page in the Parent Site on installing the App so these are manual steps.


One thing to keep in mind is that you can’t have App Parts on your App Pages from other Apps, you CAN have multiple App Parts from multiple Apps in your Site Pages in the parent Site but they are not the connected Web Parts which were very well used for dashboards in the old Solution Model.

Custom Actions

There are a few different types of Custom Actions that you can hook into on the Host Web into your App Web. The first is the Ribbon Actions and the second being the ECB (Edit Control Block) menu that you see when you click on a List Item in a List View. There is a good Microsoft article on how to do this.


The best example to date right now of the Ribbon Actions is probably Nintex Workflows App in the Store. You can quickly grab this from the Store and try this in your own environment.

Wrap Up

I’m hoping that at the SharePoint Conference next month that I’ll be able to come back and update this series with some more hooks into SharePoint for the Apps. Until then I hope this helps you understand what you can do now.

Series Navigation<< SharePoint Apps Playbook Series: Part 3 – Host web vs App webSharePoint Apps Playbook Series: Part 5 – Client Side API: REST vs JSOM >>

5 thoughts on “SharePoint Apps Playbook Series: Part 4 – ‘In SharePoint’”

    1. Thanks, that’s a great sample, its a shame they don’t explain in the sample why its Sandboxed and App packages you have to deploy. Great way to experiment for sure!

  1. Another major drawback of Client App Parts is the inability of the app part to understand the context of the page that it is on, for example being aware of a querystring parameter on the hosting page. In the old web part model, we could have web parts that filtered their data in response to a querystring parameter on the host page, or use any of the Filter web parts to pass data into the web part.

    With Client App Parts, there is only the option to use Custom Properties, which are not dynamic in any way.

    I wrote about a method to achieve this using the postMessage api:

    Still, this is work that is very developer-heavy, and it would be great to see a framework from Microsoft around this, so that site owners can easily opt-in to sharing additional page information with app parts.

    1. Thanks Adam, this is another example of something that was there in the Solution Model and not in the App Model *yet*. I had seen your post and book marked it on delicious but forgot to add this to the article. Appreciate you pointing it out!

Leave a Reply