Pulse Check: The SharePoint / Office365 App Model is alive and well…

There has been much talk, blogging and claims made around the health and longevity of the SharePoint App Model lately. Some have come right out, prognosticating it’s demise and looming death, soon to be part of the boneyard of deprecated features such as SandBox Solutions, Auto-Hosted Apps and the recently announced deprecation of Public Facing Websites. (BTW, Deprecation doesn’t mean dead in it’s tracks immediately, as some often fear. More on that later.)

After having the good fortune of just spending three full days in the belly of the beast at Microsoft HQ in Redmond, I can tell you that any doom and gloom predictions regarding it’s health could not be further from the truth.

These three days did not consist of fluff filled PowerPoint presentations by some Microsoft Newb that was recently introduced to SharePoint and asked to try and evangelize this fairly new and evolving concept called the SharePoint App Model to a group of Microsoft Developers, Partners and Customers.

Quite the contrary, in fact, as the key characters involved in these sessions were none other then Vesa Juvonen, Steve Walker and Jeremy Thake of Microsoft. Any experienced SharePoint Dev can appreciate the extreme value of such a three day experience. If your not entirely familiar, well, let’s just say it’s like being taught to fence by The Three Musketeers.

The sessions were spent reviewing the current state of the App Model, recommendations on using the App Model, the Vision of the App Model and so much more.

While there were many, MANY good topics covered, in an attempt to keep the length of this post within reason, I’m going to highlight my personal favorite “Top 3 Takeaways” from the event. Also keep in mind that most of the details in my takeaways are focused on Office365 and can have some relation to an On-Prem SP, but not necessarily in every case.

Top 3 Takeaways:

1. {App Model != SharePoint App Parts}
(The App Model is not just about App Parts)

As a SharePoint Developer, one of my personal favorite and strongest features to SharePoint is the modularity and ability to reuse Web Parts. When the App Model was first introduced, App Parts immediately became a topic of conversation around the SPDev water cooler. It appeared to have many of the same qualities of the older more matured Web Part cousin, although it still lacked many of the strengths of a full featured Web Part. At it’s best, it’s simply an iframe connected to a page that exists in your SharePoint App, which of course lives in an a separate Site Collection. This no doubt feels rather antiquated and programmatically has a number of challenges associated with it (ex: Responsive Design)

Flash forward to today and many developers still tend to focus (myself included, prior to these three days) on this limitation, casting aside the entire App Model as unreliable or unfit for enterprise level development.

The truth though is that the App Model has become so much more then a simple SharePoint hosted App combined with a few App Parts. An argument could be made that the App Model is not just for SharePoint, but for the entire Suite of Office365 Applications. With new and improved API’s coming out all the time, we are able to connect our SharePoint Applications to other services such as Yammer, OneDrive for Business and more using technologies like JavaScript via the Client Side Object Model (CSOM).

Yes, SharePoint continues to be the primary tool for things like Collaboration Portals, Document Management and Corporate Intranets, but it doesn’t mean that everything that helps populate those entities resides entirely in the scope of a SharePoint Site Collection.

You can be using Yammer for the social integration and then be using a Provider Hosted App to manage your Site Provisioning for a new SharePoint project or team site for example.

If you were like me and had some tunnel vision to the scope of the App Model, I encourage you to take a second look at the depth of the App Model API. Combined with samples provided in the “Office365 Developer Patterns and Practices” website (more info below), you will find alot more to the App Model then simply SharePoint Hosted Apps combined with App Parts. (Hint: Take a look at the “App Script Part”, an example that is simple, but powerful).

2. {Custom Master Pages = Null}
(Do not use custom Master Pages)

In all fairness the above expression is not entirely black and white. As with many things….ok, MOST things in SharePoint, there can be half a dozen ways to accomplish any one thing AND often times the correct answer is subjective to business requirements of the SharePoint Application being built.

When I first heard the recommendation to NOT use custom Master Pages, it stung….BAD. Custom branding and a rich UX for a SharePoint site is my bag. Now Microsoft wants to take that away? I thought I was having a nightmare….someone pulled the old “Abby Normal” / “Hans Delbrück” switcheroo on me.
After-all, the first thing often uttered out of a clients mouth is….”Can you make it NOT look like SharePoint?”
So first, let’s clarify the position. Microsoft is NOT saying DON’T use a custom Master Page. Their simply saying, please understand the risks associated to using a custom Master Page. What are those risks you ask? 
When SharePoint online continues to receive improvements, which is occurring at a much faster rate then ever before, changes to the Out-Of-The-Box (OOB) Master Pages receive those improvements too. When a custom Master Page is used and a change to the OOB Mater Page is made, the custom Master Page does not receive this improvement. This is understandable to me as there is no plausible way Microsoft can sift through every custom Master Page, find where to make the changes and then make them. Honestly, if you have a custom Master Page, you likely wouldn’t want them to do this anyways. 
What this means though is that as improvements are made, for example to the Office365 Suite Bar, your custom Master Page will not “automagically” receive these improvements, leaving a maintenance burden to have to keep track of the changes and improvements and manually integrate them into your custom Master Pages as the changes are introduced. Now this may be fine for your SharePoint environment and Microsoft isn’t even saying don’t do this….their simply saying understand the risks and costs associated with making this choice.
What this doesn’t mean though is that the only other choice is to have a plain vanilla, OOB SharePoint site using the built in theme options. (Which are getting better, but still lack any real ability to completely brand a rich user experience for say a corporate intranet.) 
One of the alternative choices, as I was eager to learn, was using the App Model to perform actions such as setting the Alternate CSS and perform JavaScript Injection into your SharePoint application. 
“Well, wouldn’t this also have certain risks involved too? And what benefit’s do I receive by following this model?”, you might be asking.
The answer is no doubt “Yes”. There are risks using this model too. You can come in to work one day and find that CSS classname or ID you used has been changed or worse just gone, thereby rendering your custom JavaScript or CSS null and void and destroying the beautiful work of art that is your SharePoint site…..
……BUT….Microsoft is aware of this. They understand and admit that when they start making recommendations such as this, we as developers are going to become dependent on certain CSS classnames and ID’s to ensure our CSS and JavaScript continue to function without the rug being pulled out from under us.
In fact, Steve and Vesa are working with the engineering team to communicate and ensure that we can have that reliability on specific classnames and ID’s and if/when changes are going to occur, it’s communicated back to us.
Now, the benefits…..These are just a few and surely more will become visible:
  • Brought out in one of the sessions is by not using a custom Master Page, Microsoft owns full responsibility on the support of the Master Page. No more can anyone blame your custom Master Page for causing issues. I’ve experienced this on more then one occasion, even when it’s not the fault of the custom Master Page. Spending time proving my custom Master Page’s innocence takes time.
     
  • You automatically receive all the upgrades to the Master Page, without having to keep track of the changes made. You might say, “What if I don’t want the upgrades??” Well, some might be visible upgrades, but some might simply be performance based upgrades that provide no visual change, but greatly enhance performance. (This point I feel is very undervalued, so keep it in mind when weighing your decision)
     
  • These methods allow you to ensure that you have one single point of reference for your CSS and JavaScript files across site collections, even non-publishing based Site Collections. (To me, this was another huge benefit that I think can be under-valued) Highly Branded Team Sites anyone? Need to update a plethora of team sites? No problem!
Personally, I love a good challenge. Perhaps it’s one of the reasons I continue to develop for SharePoint..lol. I’m going to do my best to embrace this new recommendation and see just how far I can push that envelope of not using a custom Master Page, yet still creating a highly branded, interactive user experience using the techniques of the App Model.

Custom Master Page Challenges

3. {Microsoft != Man Behind The Curtain}
(Microsoft is not telling you to do as they say..with no questions asked!)

I will save you the many jokes to be made contrasting the Wizard Of Oz hiding behind the curtain in the Emerald City and Microsoft HQ being located in the real Emerald City, hiding behind their own curtain, but I can tell you personally this contrast couldn’t be further from the truth.
More now then ever, Microsoft is embracing and encouraging an open relationship and communication with the community of developers. Using GitHub and the Office365 Developer Patterns and Practices you will find all kinds of recommendations and code samples. In fact, you can even contribute to the community via a GitHub Pull Request using the submission guidelines.
There is a Office 365 Dev PnP Yammer group where you can submit questions and feedback to the community and not just a community of peers, but where the Microsoft folks are actively involved as well.
You can also submit to a UserVoice forum, the Customer Feedback for the Office Developer Platform, where you are able to make suggestions and recommendations, then allow fellow community members to vote for your suggestion. You can also vote for other submissions that already exist to help provide exposure to the more important issues or features you would like to see addressed.


Conclusion

At the end of the three days, one thing was evident, the App Model is no where near dead. It’s full of life and growing all the time.
While some are hesitant to jump entirely on board, worried about the App Model being deprecated the way of Sandboxed Solutions, it’s understandable. I personally don’t see it ending up like that, not anytime soon at least. The App Model is becoming much larger then just SharePoint. 
Will there be improvements and/or deprecation of features that are not working as well as originally expected? Probably….But remember, as Microsoft pointed out in the session’s, “deprecated” doesn’t mean that the features are dead upon announcement of said deprecated features. It means there is no more investment in improving those features.
Sometimes with such growth comes growing pains. It might not…likely will not be easy migrating to new processes that are recommended in the realm of the App Model.  We will have to change the way we scope and tackle requirements, unlearn if you will, what we have historically been told was the right way to do things. 
Remember though, providing new recommendations and best practices doesn’t render the previous recommendations and best practices as wrong. It simply means that improved recommendations and best practices are being defined and this is a natural part of software evolution. If we just accepted what we have today as “good enough” and never sought improvement, we’d probably still be on DOS. No Thanks. 
What we gain, in my opinion, is significant. Using all of the outlet’s mentioned above (Yammer, UserVoice, etc.), we are no longer stuck with a platform that takes 3 years to see significant improvements. 
I remember the debut of SharePoint 2010 and there were some features I so hoped would be included and they were not. At that point you simply hope they will be in the next version…around 3 years from now.
Not anymore….in this agile cloud based environment, suggested improvements, reported bugs and enhancements can come in mere months, if not weeks. Even better, our ability as developers to be involved with those changes has never been greater.
No longer are we simply on the sidelines, a mere consumer of a platform, accepting what we are given, but we are now empowered to actively participate in and collaborate on the growth of a platform.

Personally, I find that exciting and plan on taking advantage of this new exposure as much as possible. Whose ready to join the ranks and make a difference?

Share:

Author: David Warner II

Leave a Reply

Your email address will not be published. Required fields are marked *