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.
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:
We’ll cover the “whats” and “whys” in the sections below.
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.
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:
The session that really gave us our “Aha!” moment on the Office UI Fabric was
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.
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.
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).
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.
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.
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.
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.