O365 Client Side Devs: Be Heard

I had the opportunity and honor to be a guest on Jeremy Thake’s and Richard Richard DiZerega’s Office 365 Developer podcast a couple of weeks ago while I was  at SPTechCon DevDays in San Francisco. Jeremy and I spoke at length about a topic that I have a bit of experience with: Client Side Development.

Office 365 Developer Podcast: Episode 052 on client side dev with Mark Rackley

I’ve been writing code for over 20 years now and I’ve written my fair share of Full Trust solutions for SharePoint. However, It’s no surprise to anyone who knows me, I’ve gravitated towards Client Side Development and JavaScript over the last several years.

It’s a no brainer really; developers can create powerful scripts using JavaScript along with Web Services, REST, or CSOM and upload those scripts to a document library.  Then those scripts can be referenced on a page in SharePoint using a Content Editor Web Part or a Script Editor Web Part and bam… you’ve made SharePoint more usable, you’ve made your SharePoint form stylized with extensive business logic, you’ve called web services to create powerful dashboards AND it works in SharePoint 2007, 2010, 2013, and Office 365… PLUS you don’t need Visual Studio or any complicated IDE’s. You don’t need server access, you don’t need to worry about oauth. You can get your job done in minutes and move on to the next project.  What’s more, thousands of developers are using these development techniques every single day to get their jobs done quickly and effectively.

Sounds simple enough, what’s the problem?

The problem is that this development approach does not actually fit in with Microsoft’s ideal of using SharePoint Add-ins and Office 365 API’s.  To be fair, Microsoft is not against us sticking a script in a library and linking it to a page. It’s not a “no no”, but if you go and have a conversation or two you’ll get a lot of “Why on earth are you doing that?” and “You SHOULD be doing it this way.” So yeah, it’s “supported” but I’d say it’s not encouraged.

And to be honest, there are reasons NOT to encourage it. Putting a script in a document library and linking to it in a Content Editor Web Part is not without its issues. Chief among these issues is enterprise deployments. It’s not simple to automate the deployment of these scripts if you need to replicate it across 30 sites. If you aren’t using Visual Studio, you don’t have easy integration into TFS and other source code control options. When you scale out this type of development, there are a few cracks. Yes, you can use Visual Studio and Sandbox solutions to deploy your scripts quite effectively, but you have complicated the process for those not comfortable in Visual Studio. Throw in the add-in model and you’ve lost a huge chunk of SharePoint client side developers.

There is also the issue that a lot of times using this technique you are modifying the Document Object Model (DOM) to manipulate elements on a page. It’s rare, but Microsoft can change the elements on a page without warning. If this happens, it could break any script you have executing a page. Is this a reason NOT to use this approach? Absolutely not, just something to be aware of.

So, I understand they would like us to do something more deployable and less dependent on the DOM and let’s face it.. I would like that too… but man… it’s SO simple. SharePoint Add-ins and the Office 365 API’s are are not near as straightforward.

What Microsoft needs to understand

Yes I know where Microsoft wants us to go, and I’m totally not against it. There are just some really hard truths that need to be understood for why the add-in model and Office 365 API’s are not the best approach (yet).

It’s not about fear of change

I know I hear often that the main reason for not going to add-ins and the Office 365 API’s is a fear of change. This is simply not true. Change is good. Change keeps us on our toes. Change leads to innovation. I love change.  I also love being able to be effective and efficient at my job and serving my clients to the best of my ability. I want to enhance what SharePoint does, NOT build a whole new application for every scenario. Let SharePoint do the heavy lifting and support/enhance SharePoint with client side dev. Make that easy for us, and I’m all in.

Not everyone is Enterprise

It’s the truth. There are so many businesses out there with less than a thousand users, and they don’t need a solution that can be deployed 30 times. They need it deployed once. Why go to the headache of creating a deployable add-in that takes so much more time and is much more difficult? It’s overkill for a lot of people out there who simply don’t have the time.

Non-Developers

The minute you need to open up Visual Studio to create a solution, you’ve lost a big chunk of people who are getting stuff done by writing a little JavaScript and linking it to a page. It’s simple with low overhead and you don’t have to be a seasoned developer to do it. By forcing these people to use a tool like Visual Studio you will send them into a tailspin. I understand Visual Studio Code has the possibility to help here, so I’m excited to see how that grows.

Legacy Support

There are still a large percentage of people on SharePoint 2010 and even SharePoint 2007. These people need to get their job done and the last thing they want to hear about is the Add-in model.

Time and Budget

The most critical factors: Time and Budget. I can deploy one of my solutions in minutes on any SharePoint farm. It can be tweaked in a text editor in a few more minutes. I can point clients to my blogs to drop in my scripts and make a few tweaks to them for their needs. I can provide SOW’s to clients at a lower cost. Microsoft needs to figure out how to make add-ins that simple and fast to develop and deploy. Maybe it’s just taking the time to build up a library of add-ins instead of scripts? Maybe, we’ll see.

What can we do?

Good question. Jeremy created a new Yammer Group Office 365 Dev Client Side for the purposes of furthering this discussion and help “us” make the transition to add-ins and Office 365 API’s.  This is great news. We can voice our opinions and our frustrations in a constructive way and be heard.  At the end of the day, we need to be aligned with what Microsoft is doing in order be best serve our clients. Plus, Microsoft needs to hear from us and understand this is real development approach used by so many developers.

I plan to spend some time trying to re-write a couple of my solutions as add-ins and give some very honest feedback on the experience. Maybe our feedback will help Microsoft understand how critical this type of development is so they can best support us in our endeavors.

The goal of this blog is NOT to bash Add-Ins and the Office 365 API’s. I would actually like to use them more. The goal is to let those of us who are not in the space be heard so that our efforts, skills, and time are taken into account.

Microsoft, find a way to tweak the tooling to bring us into the fold and we’ll be more than happy to jump on board. Get us pigeon-holed client side devs excited about using add-ins for our clients.

And if you are one of us, join the Yammer group, let your voice be heard, and let’s get our jobs done…efficiently, effectively, and in the best way possible. 

Families in Germany who are facing divers health problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile heartiness problem, you probably know about Xenical and Hoodia. Probably every adult knows about Garcinia. (Read more PhentermineXenical). The symptoms of sexual health problems in men include improbability to have an erection sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its vital to cooperate with your health care professional so that the prescription can be tailored to your needs. Preparatory to capture Levitra or other preparation, speak to your pharmacist if you have any allergies. Talk to your health care provider for more details. Preparatory to ordering this remedy, tell your physician if you are allergic to anything.