We were fortunate to host a handful of SharePoint MVPs at Hyperfish HQ last week who were in town attending the latest Dev Kitchen.
I was able to grab a few of our illustrious guests and get them in front of the camera for a Facebook live session. Mark Rackley and Marc D Anderson, were two of our guests, and generously donated their time to provide their thoughts on the topic “citizen development”.
I started my career after university as a .NET developer in Visual Studio. This evolved into SharePoint development building full trust farm solutions. There have been various bloggers that I’ve followed over the years who have shared tremendous amounts of knowledge. Mark and Marc are two of these that fill a gap coined in the community as “citizen development”.
When Marc Anderson and I chatted last week, he pointed out that Gartner defined the term as early as 2009. Gartner, in October 2009, stated that citizen developers would build at least 25% of new business applications by 2014. A report Gartner never really confirmed or denied.
“A citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT. In the past, end-user application development has typically been limited to single-user or workgroup solutions built with tools like Microsoft Excel and Access. However, today, end users can build departmental, enterprise and even public applications using shared services, fourth-generation language (4GL)-style development platforms and cloud computing services.” Gartner
In context of SharePoint, a Citizen developer defines a set of JavaScript skilled professional developers that customize SharePoint. Typically they do this by uploading scripts to SharePoint document libraries and injecting them into pages using the content editor web part.
This approach is very different to how I developed customizations in SharePoint. I would check in my code to source control. Then use continuous integration to compile and package it as a .wsp solution and hand it to a SharePoint administrator for deployment. This was optimal for team development where developers were working together on a project across dev, test and production environments with a repeatable deployment process.
This is often defined as “professional” SharePoint development by Microsoft, but Marc and Mark would both say they too are “professionals”. If you watch this video I recorded with Mark, you’ll see he isn’t that happy with the term. I personally didn’t like this definition when I worked at Microsoft, but no-one can think of a better one so that’s what I’m sticking to for now.
The citizen developer approach bypasses a lot of the complexity of the packaging approach. It is extremely quick to build valuable business solutions in SharePoint with this approach.
If you’ve been lucky enough to see either Mark or Marc present on this topic before, you’ll be well aware at how quickly they can get a business solution built to solve a business problem that can impress your colleagues back in your own organization.
One of the big challenges I saw as a packaged developer is that I could build an amazing prototype in SharePoint using the citizen developer approach; in contrast it was a more time demanding exercise to build it as a package and put in source control.
Some common examples of business solutions built in SharePoint:
SharePoint getting a new fresh look was well overdue in my personal opinion. It’s well under way now, but they are playing catch up filling the functionality gaps of the previous Classic Pages model. There is an MSDN article written by Vesa Juvenon that highlights the unsupported customization scenarios for Modern Pages. It really highlights the inability currently to do what you could in classic pages as a citizen developer.
There isn’t an out of the box content editor or script editor modern web part, but Mikael Svenson has already shipped an open source one for Modern Pages. This will allow you do similar things in modern pages to what you could in classic pages.
This will require an administrator to deploy it to your SharePoint Online tenant. SharePoint Server 2016 will hopefully support SharePoint Framework packages soon.
Microsoft are not encouraging this approach and weren’t that happy about injecting JavaScript into pages to manipulate the document object model (DOM) in the first place. The reason being that it made supportability so difficult as the DOM is not considered an API to Microsoft and if things change in the DOM it’ll break your business solutions built with this approach.
Microsoft would like all customizations with code to be deployed to pages using the SharePoint Framework approach or Add-in model moving forward. The reality is, as both Marc and Mark stated, that citizen developers will continue to use their current approach of least resistance.
Citizen developers only require a text editor and a web browser to get what they need done. They can use these techniques across SharePoint 2007, SharePoint 2010, SharePoint 2013, SharePoint 2016 and even SharePoint Online. Not much has changed in the principals behind this over the years.
My blog from a few weeks back tackled how the SharePoint Framework changes things for Administrators. I talked to Eric Shupps about this exact topic. One of his biggest takeaways was, that for administrators it’s really not that different from what they do now.
For citizen developers who want to take their JavaScript to the next level and try the SharePoint Framework approach, things are more complex. There is quite a few moving parts to getting a developer environment up and running on a local machine. It will likely be the first time you’ve heard of node.js, npm and gulp. Personally, I think that Andrew Connell does the best job of this with his Voitanos training course. He gives a lot of the content away for free, so take advantage of it!
In the video with Mark, he highlights his journey with the framework. The key things I took from this was that TypeScript and React are new to him and many citizen developers. This is something that Microsoft are aware of, and they are trying to put together their own content to help bring over existing SharePoint developers (who likely come from .NET background or non tool chain based JavaScript development).
Andrew Connell explained that once the developers he worked with understood the basics of TypeScript, the initial pains were quickly forgotten.
In talking to both Mark and Marc, one thing that was clear is that there is a secondary set of JavaScript developers. Typically these developers are not professionally skilled, but are information workers within organizations that are considered power users. Typically they copy and paste from the internet directly into content editor web parts. These folks can follow instructions directly, but often can’t modify scripts. Unfortunately, because the SharePoint Framework is much more complex than copy and paste, its unlikely they’ll be able to follow these more complex steps.
With the demise of both InfoPath and SharePoint Designer, Microsoft are encouraging you to use Power Apps and Microsoft Flow. I spoke to Chris McNulty from Microsoft on this two weeks ago and it is certainly worth a listen.
I think Power Users will have to use Power Apps and Microsoft Flow moving forward to build their business applications. In future blog posts, I’ll be talking more about Power Apps and how they can start to replace scenarios Power Users have used in the past.
SharePoint is taking another step on its journey for its users, developers and administrators. I personally believe that there will continue to be citizen developers that don’t try to use the SharePoint Framework. Your best source of information for those scenarios will come from SharePoint MVPs like Mark Rackley and Marc Anderson.
The SharePoint Virtual Summit was recently announced. If you are interested in keeping up with the future of SharePoint, we encourage you to register now!