Ignite 2016 Roundup

Julie and Marc were at Microsoft Ignite in Atlanta a few weeks back, so here is a [delayed] special “Trip Report” edition of the Sympraxis Newsletter.

MSIgnite

First and foremost, what a great week.  Microsoft did a wonderful job hosting and the entire conference felt incredibly well-organized. All the lines were quite manageable, the food was pretty much edible, etc.  (Those of you who were in Chicago last year know what a difference that can make!)

Many others have written summaries of the big announcements from Microsoft at Ignite. Instead, we want to focus on what we plan to do differently at Sympraxis based on the sessions we attended and the conversations we had in the hallways and Expo halls. We don’t usually try to use the bleeding edge for our clients, but we do want them to be well-positioned to take advantage of newer, more powerful functionality and be prepared for the future. Since some of our clients are still on SharePoint 2007, 2010, and 2013, some of these approaches won’t be useful for them yet, but they will be when they decide to upgrade.

Julie and I attended many of these sessions together. Some companies try to “divide and conquer” so they can cover as many sessions as possible. Before we arrived in Atlanta, we decided to focus on the sessions where we wanted to go deeper. The Office 365 ecosystem is so broad that we know we can’t even pretend to cover it all. Instead, we focused on the aspects of the service (and its attendant hybrid connections) we expect to work with in the near term.

The big areas where we see ourselves shifting are:

  • SharePoint Framework (SPFx)
  • UI Fabric
  • Storing Code Artifacts
  • Azure Functions & SharePoint Web Hooks
  • Microsoft Graph

We’ll cover the “whats” and “whys” in the sections below.

SharePoint Framework (SPFx)

We attended three sessions by the Engineering group which covered the SharePoint Framework. Truth be told, SPFx came up in many sessions, but these were the truly focused ones.

BRK2114: Get an introduction to the SharePoint Framework

BRK4015: Build client-side web parts for Microsoft SharePoint

BRK2117: Discover the future of Microsoft SharePoint development

As you’ve heard before, both Julie and I were both at the first Developer Kitchen (DevKit) around the SPFx in February, 2016.  We’ve spent some time since then making sure we had the updates, taking a look at things, and just trying to keep an eye on what’s happening.   But let’s be honest: we’re a two-person company and our focus has to be on our clients who need work done so we really didn’t have time to spend a lot of time getting immersed in it. SPFx is also in Preview mode, so we can’t actually deploy anything to production for anyone.

What we’ve taken away from Ignite is the following:

  1. We need to start learning Typescript and merge it into our ever evolving build process. We have both fiddled with Typescript (Julie more so than me) but neither of us have built a full project with it.  Given Julie’s background in .Net MVC patterns, she’s feeling pretty confident that other than semantics the structure of a project will be something she’ll be familiar with… For me, it’s going to be a tougher learning experience, I think. Typescript seems to feel more comfortable for those coming from C# than it does to people who have been working in JavaScript. That said, it’s just another language. We both see the value more clearly now in bringing the rigor that Typescript provides to our development approaches.
  2. Both of us are fans of AngularJS (and I like KnockoutJS a lot, too). We use Angular 1.x because it supports multiple apps on one page, which fits with the widget pattern that we usually implement in SharePoint.  (Angular 2 does not support this.) For better or worse Microsoft needed to embrace a framework for SPFx and if you look at what was available when they needed to make that decision for their 400+ internal engineers, React probably made the most sense.  We’re not here to second guess that at all (though we do discuss it!) but have decided that maybe to make our solutions consistent we really need to take some time to either build or port a solution to React and see how it really feels when we get into it. So more to come there. One this is certain when it comes to frameworks: don’t just jump on whatever becomes trendy. Choose your framework(s) based on the capabilities each gives you to meet your business requirements.
  3. Julie has had significant experience using LESS, which is a CSS-type language. You use a compiler that merges your LESS files together to create a deployable CSS file by utilizing simple variables and calculations. It’s extremely powerful, and if you are building large-scale look-and-feel across your enterprise, it can really help. SPFx uses SASS, which is a similar capability. We’ll plan to embrace that and make the switch.

Office UI Fabric

The session that really gave us our “Aha!” moment on the Office UI Fabric was

BRK3246: Look behind the scenes at how we’re making SharePoint’s front end/UX modern, responsive, and open

We have both tried to build consistent UI components over the years, but they tend to vary significantly by project as well as what UI trends are happening at the time. In many cases, we choose to make those components not look like what you get out of the box with SharePoint so that we can drive very specific business processes.

That said, the UI Fabric is Microsoft’s internal set of UI standards for the Office 365 platform.  As is common with the new Microsoft, they have open sourced the entire library. There is a core library and other flavors – for plain JavaScript, React, AngularJS, and iOS – and community involvement will undoubtedly bring even more.

Frankly, we’ve been avoiding UI Fabric thus far because most of our clients want the custom UIs we mentioned above. We also have had the attitude that we can probably build something lighter more quickly ourselves – which still may be the case – so we spend more of our time building our own HTML and CSS.  However, I think we had our eyes opened in that we may be missing an easy timesaving investment by utilizing the controls and styling that take advantage of the Office 365 theming.

Another interesting aspect of the Fabric UI is the responsive grid they’ve built in, which is sort of like their own version of Bootstrap but customized specifically for SharePoint and Office 365.  Again, we do a lot of our own responsive work but if this can save us some time and protect us from changes going forward we’d be silly not to embrace it.

We also hope that by adjusting some of the SASS variables in the UI Fabric we could do some more “light branding” for Office 365 that works with SharePoint themes to cut down on our development time. There was even some talk in the session about the possibility of a “theme roller” a la jQueryUI’s, which would make the theming idea even more powerful.

You’ll probably see us experiment with UI Fabric in the coming weeks and months and probably see several blog articles about our findings.

Storing Code Artifacts

Microsoft announced the week before Ignite that it was making available a Preview look at a public CDN capability for Office 365.  We see this mostly in support of the new SPFx, but since it’s available now, we can take advantage of it for our ongoing and existing projects (where it makes sense).

Historically, we’ve stored our code (usually HTML, CSS, JavaScript, etc.) in either a Document Library or in the Master Page Gallery (/_catalogs/masterpage/_projectName/).With the CDN capability, we’ll be shifting [back] to using a Document Library to take advantage of it. We need to experiment with how the CDN works, but if we can get faster throughput and geolocated edges, we can’t lose. The one concern we have is how this will feel during the development process. If wthere is any delay for the CDN deployment, then we may not use the capability until we “publish” a solution; save/wait/reload is not as good as save/reload.

Microsoft will also be releasing a private version of the CDN, but the timing on that isn’t clear. In the meantime, we can use a hybrid approach using the public CDN for those things that we’re comfortable exposing via anonymous access and keeping more sensitive things in a CDN Site Collection.  As we get into this we’re hoping that we can adapt Julie’ blog post Code Creep – SharePoint “CDN”, Centralizing your SharePoint client side code to make use of the public CDN and when it comes the private one as well given that the CDN’s are implemented by exposing whatever document library you choose.

Azure Functions & SharePoint Web Hooks

Probably one of the coolest new features for Julie was Azure Functions.  Azure Functions are server less event driven code blocks that extends the existing Azure App Service platform. These nano-services can scale based on demand and you pay only for the resources you consume.  You get 1million transactions per month for FREE, and even if you go above that it’s crazy cost effective.  What really has her jazzed about Azure Functions and SharePoint is all those small bits of code that require “elevated privileges” or some other code that really needs to be hosted as a Web API or other server type endpoint.  Think of site creation functions, workflow type functions, REST API calls that are cross-domain… these types of things and WAY more can be solved with this technology.  Add on Web Hooks which was recently announced for SharePoint and there’s your event driven architecture that extends the power of SharePoint a million fold without having to actually pay for a full blown server or Azure App.  Julie heard a great interview with Jeremy Thake on the Microsoft Cloud Show that is definitely worth taking a listen to if you’re interested in hearing more.

Microsoft Graph

BRK3113: Access the Microsoft Graph API to supercharge your Line of Business Applications

BRK4016: Access SharePoint files and lists using SharePoint API in Microsoft Graph API

The Microsoft Graph has definitely grown up. There are far more capabilities there than there were early on. Right before Ignite, we heard that access to SharePoint lists and libraries had come to the Graph, and that’s exciting news.

This is another area where we can see the connection to the SPFx. It’s currently in beta, and to use it we’ll need to build in an additional authentication step which isn’t required when we’re acting in the user context with a plain REST call, but from what we’ve seen the API in the Microsoft Graph gives us some things we don’t have and makes other things a little easier.  It’s certainly going to come in handy when building Office Add-Ins.

Conclusion

So, there you have it. That’s our list of things we hope to change about how we work based on Ignite. To be honest, we don’t always get this long a list of action items from a Microsoft marketing event. Many times in the past, the messaging has been too future-oriented or non-concrete to really change mush of our thinking. Because of the directness in the presentation and the great stories we heard which demonstrated true business value, this time we have a good, long list.

We may not be able to affect all of these changes quickly, but they will be part of our modernization strategy going forward. Our clients should be better positioned for the future, which is the best story we can possibly tell.

Leave a Reply

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

Sympraxis Consulting, LLC | 831 Beacon Street, Suite 118 | Newton Center, MA 02459 | Phone: 617.633.2051