Share and Enjoy !

I was fortunate to get to attend this year’s SharePoint conference in Las Vegas.  I saw some great presentations (and one or two that weren’t so great), but overall it was a useful event. It is an exciting time to be a SharePoint developer, and as someone in that role as well as an educational role I thought it would be useful to bring the top 5 things I learned at the event. So, here we go…

Number 5: InfoPath may not be dead, but it’s future doesn’t look very bright

When someone begins a talk with “fully supported” and “protects your investment”, you have to believe that they are talking about a product that doesn’t have much of a future. So it seems with InfoPath. There was exactly one paragraph in one presentation about InfoPath for the entire SPC 2013 event. So what’s the takeaway?

On the positive side, InfoPath 2013 is a new tool that includes a couple of nice features, including much improved integration with Visual Studio 2012.

On the negative side, the lack of InfoPath material at the event speaks volumes about its lack of importance for the future. InfoPath is a farm-only proposition; if you’re doing SharePoint in the cloud, or want to be cloud-compliant for the future, you will have to pursue other options. So what will your other forms-authoring options be?

  1. Build a SharePoint App using Visual Studio 2012 (more about that later)
  2. Build a SharePoint App using Access 2013 (are you kidding me?!?!?!?)

Now, for those of you that just got a little nauseous when I said “Access”, a little clarification is in order. Access is no longer a file-based DB tool; there are no more .MDB files. Instead, Access 2013 is now the forms designer tool of choice. Access stores and retrieves data from Azure DB or SQL Server.  Access 2013 forms are HTML-5 based (I even saw one run on an iPad!). So what’s the SharePoint connection? Access 2013 Forms can be packaged and deployed as SharePoint Apps. So, in a manner of speaking, all of your cloud-compliant options involve “apps”, it’s just a matter of what tool you’ll use and where you’ll store your data.

Number 4: “Themes” may finally be a legitimate branding tool

Let’s face it… the history of “themes” on SharePoint is not a great one. There have been several formats and engines along the way; the tooling was pretty weak; and, most of all, the results were just amateurish. SharePoint 2010’s theming options were particularly disappointing.

SharePoint 2013 brings a new theming engine and new options for building your own themes. Theme information is provided using XML files, and the results shown in the demonstration session at the SharePoint conference were pretty impressive. I consider themes to now fall under the heading of “branding light” – they may be suitable to get the job done in a case where one lacks the skill (or the will) to undertake the changing of a master page of other more invasive forms of branding.

One last thought – the team responsible for themes will be providing some tooling as time passes.  They demonstrated a pre-release tool named “Theme Slots” and promised a release in the near future.

Number 3: You kids get off my server!

Most servers like SharePoint have an extensibility model that will allow developers to extend and customize the product to meet the needs of a company. While this is a compelling option, it has two big downfalls:

  1. Bad code = bad server performance
  2. Upgrades are rarely smooth

So, how does SharePoint 2013 solve this dilemma? By kicking us all off the server (so to speak). Going forward, it will be very rare for us developers to write farm solutions using the server object model. Instead, we will write SharePoint Apps using Visual Studio 2013. These apps will contain code that that runs in the browser or in another server process and employ the client object model to communicate with SharePoint. The good news on this approach is that the server is less vulnerable to errant or malicious code, and that the path to upgrading to the next version of SharePoint is less encumbered. The bad news: it’s going to be a pretty epic shift in how we write custom SharePoint code. We’ll be using the client object model with JavaScript and C#, and we’ll also be using the SharePoint REST APIs. All of this leads to my next point:

Number 2: If you hate JavaScript you’re gonna have to get over it!

For the record, I could go on a long rant on why I hate JavaScript.  I could enumerate all of its shortcomings, and tell you why it’s not a real programming language. But, the reality is, we find ourselves in a world where its shortcomings are outweighed by its benefits. Ironically, JavaScript may actually come closer to the “write once run anywhere” mantra than Java did; or, if you prefer, JavaScript has become the universal client language that calls out to whatever server platform and language that you prefer or need.

So, if you’re going down this JavaScript road for the first time, here are some things that might ease the journey:

  • Embrace jQuery – it is the way to manipulate the HTML DOM.
  • Educate yourself on other useful JavaScript libraries (Knockout is an interesting one that I saw in action this week).
  • Investigate TypeScript – while it still has some rough edges, it may lessen your hatred if you come from the strongly-typed-compiled-language camp.

And finally…

Number 1: A quote to live by…

One presenter from the Netherlands used an interesting phrase when describing the fact that all his demos were live and legitimate:

“There is no bogus here.”

Time will tell if that’s true of SharePoint 2013.

Share and Enjoy !

Related Content: