We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
About two months ago, I was pointed to an article that talked about SharePoint Apps and how some people are starting to call them “Crapps”: SharePoint 2013 Preview – Apps or Crapps? I didn’t want to add my two cents right away because I hadn’t really had a chance to play with the App Model in SharePoint 2013 and I didn’t want to sound sycophantic.
However, now that I’ve been deeply immersed in building a complex on-premise SharePoint 2013 app for the better part of 2 months, I find myself firmly in the “major improvement” camp. In case you haven’t read Doug Ware’s article, I’ll summarize it here briefly:
Doug talks about how, in SharePoint 2010, Sandboxed Solutions were supposed to be so amazing and make everything better and it turned out that Sandboxed Solutions actually had too many limitations to be useful for a lot of work streams and that the same thing could happen with Apps. In addition, he points out that people like creating Farm Solutions, the concept of clean deletion is broken because SharePoint is not a phone, and there are no guidelines for creating apps yet. In the end, he decides that the devil is in the details with how you create the app.
This is About More Than Just Apps
From a developer standpoint, this is huge because I can basically do everything I was going to do as a Farm Solution (aside from certain SharePoint-specific assets) from an App. As an administrator, I can control what Apps are deployable where, which allows me to control my system better. I can also be sure that Apps aren’t running against SharePoint, preventing some system and security issues. As a user, I can find and deploy apps (with the approval of IT) in a matter of seconds and the App need not know or care about SharePoint a whole lot to work. An App could simply be a window into another system.
When I first started working with SharePoint, it was billed as the hub in a company where collaboration and work would take place. You could surface information into SharePoint through various means (BCS, Search, etc.) and interact with that data without leaving SharePoint. With SharePoint 2013, that’s still the goal of SharePoint, but the addition of Apps improves upon those two different aspects by allowing already existing but previously segregated items to be surfaced from SharePoint as well as providing new avenues that are more lightweight to interact with data in SharePoint.
In essence, the only thing tying us to Farm Solutions over Apps in SharePoint 2013 is our own comfort with Farm Solutions. It’s easy to do something when you have Full Trust and complete access to everything through RunWithElevatedPrivileges. However, that’s a lazy way of doing things. It doesn’t require a lot of thought to generate such a solution and leads to bad programming practices. We as developers can do better and, with SharePoint Apps, we have that opportunity. So I say, call them Apps!