- SharePoint Apps Playbook Series: Intro
- SharePoint Apps Playbook Series: Part 1 – SharePoint Apps vs SharePoint Solutions
- SharePoint Apps Playbook Series: Part 2 – SharePoint Hosted vs Provider Hosted
- SharePoint Apps Playbook Series: Part 3 – Host web vs App web
- SharePoint Apps Playbook Series: Part 4 – ‘In SharePoint’
- SharePoint Apps Playbook Series: Part 5 – Client Side API: REST vs JSOM
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.
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.
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 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.
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.
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.