SharePoint 2013 major disruption in UI and UX

SharePoint 2013 Team Site in Office 365 is a major change in UI, making a more tablet friendly simply design

 One of the most striking things about SharePoint 2013 is simply how it look.  The new SharePoint is a radical brake from all earlier UIs.  SharePoint 2013 UI is more tablet friendly and simpler, with larger objects and less clutter.  SharePoint is also reducing the number of objects the confront the user.

SharePoint 2010 Team Site has most of the same features as the 2013 site, but is fully grounded in the PC world or mouse clicks.  Imagine trying to manage this thing with a finger.

I am finding SharePoint 2013 much easier to work with than SharePoint 2010, and a greater improvement over 2010 than 2010 was over 2007.

SharePoint 2007, while the UI changes between SharePoint 2007 and 2010 were in large part cosmetic, SharePoint 2013 is a real change in how people will be able to interact with SharePoint.

I think it would be a major mistake to think this is just a skin deep transformation, which it is easy to think.  Working with the new SharePoint 2013 you quickly see that it is mostly the same as 2010 under the hood.  But the new UI also comes with a new App model, new RESTful web services interface that returns JSON and ATOM, new JavaScript API model for cross domain communication.

Microsoft is embracing disruptive web technology from places like Google, Twitter, Facebook and the start-up culture of open interfaces.  Things are going to change a great deal, SharePoint silo nature may change for something more like Twitter.

A use case for SharePoint 2013 App Model

There probably is a heavy temptation for managed services providers who host large data centers that are sold as Clouds, to continue to develop Full Trust Web Parts even when going to SharePoint 2013.  Web Parts are what coders are used to, they may have a large library of existing Web Parts as WSP files that run in full trust.  This is possible, and it means working pretty much as you always did.

But if you are like most managed service providers I know you have some kind of internal structure between your infrastructure providers who build and maintain the farms and the application and solutions providers who face the customers and develop SharePoint from a raw out of the box in to something more specific and rich for their needs.

This DevOps work has been traditionally very difficult to manage in SharePoint.  When you would develop a solution to run in SharePoint 2010 you would hand it off to a deployment management team who would have to review the code for security risks, and impact on the servers. Since the code would run in the Farm it had an Enterprise level impact. This would involve extensive documentation and review, and complex levels of support for your solutions.  In the end you would probably be dependent on a different department of the company to deploy your work but still own the risks if they made a mistake.

By adopting a SharePoint 2013 App Model you can move away from this.  Two teams, even if they work in the same company can concentrate on what they are best at.  Infrastructure can concentrate on meeting SLAs, providing backup and DR and applying patches.  

Solution providers can create partial trust solution that use .NET SCOM or REST and JSON to create rich interfaces that are hosted in other domains, perhaps even other server farms with different domain controllers.  You now no longer have the tight link between the people installing SharePoint farm and the developers of solution, in fact you can separate your teams so that one applications team can create solutions, potentially in PHP or Ruby or anything really, that work off more than one SharePoint 2013 farm.

And if your clients decide to not renew the hosting contract with SharePoint to go with Office365 or another vendor, you don't necessarily lose your applications business.  You can still provide your application solutions simply by changing the RESTful web link.  You can de-risk big SharePoint deployments by breaking hosting from solutions, allowing your customer the option to keep one if they are unhappy with the other.  

So it makes solid business sense even for established big players to embrace JQuery and RESTful and build App that run in separate domains using OAuth and OData to communicate with SharePoint, creating UI in HTML 5 and CSS 3 because after all we all hated SharePoint OTB UI (admit it).

The potential is perhaps even greater for smaller firms.   Now a smaller firm with a team of talented web developers who know about JQuery, mobile, tablets, RESTful, OData and rapid design can muscle in on a space that previously only the provider could have.  And I speak from hard earned experience when I say that the big guys will be more than happy to have third party code isolated in its own IIS server rather than installed on perm SharePoint farm.  

It also my experience that the culture that makes a first rate development and business solutions firm (agility, innovation, creativity and social understanding) is often different than what makes a first rate hosting firm (stability, precision, technical expertise, compliance and control).  With the App Model the the create web designers don't make anything you host on the SharePoint Domains and the systems admins are not going to dictate solutions to the creatives.  You can have a more comfortable distance between application developers culture and hosting culture, and we all know sometimes IT people don't play nice together.

Really it is worth taking the time to really think through the changes to the ecosystem that Cloud hosting of SharePoint and App solutions will bring.  SharePoint has had a series of evolutionary changes since 2003 and its made some of us lazy (looks down in shame).  New SharePoint releases were a matter of learning a few new features and services.  But the App Model is a much more revolutionary change and it will change the business model.

Be ready or you will lose.