Business – Ion All the Things

The move towards the SPFx tool chain is good news for web development standards, but can be a headache for casual users expected to learn, implement, and handle the supporting business activities in its’ use. The client malaise – and frustration – is real.

For better or for worse, Microsoft has maligned the casual front-end developer. The advisor on the communications team, the marketing coordinator, the social media manager, the brand specialist, the technical analyst, and the summer intern doubling as an all-knowing web guru. While not always full-time developers or with a rich coding background, these “low coders” are among the target users of Office 365 – a marketing push to the casual resources that they, too, can user SharePoint, Forms, PowerApps, Flow, and other tools in the platform to build purpose-driven and valuable solutions. As a resource who helps clients adopt and use the power of Office 365, I try and identify the capabilities of client resources ability to deliver “low code” solutions in their workplaces, and it can vary dramatically based on budget, in-house skills, company size, and willingness to change.

Often, it is not just developers and trained User Experience (UX) designers that customize the branding of websites, intranets, portals and team sites. It is common in organizations large and small for resources to wear many hats, including web developer when convenient. And with that comes varying levels of developer skill sets, each approaching their code, UX and branding needs with various levels of expertise in CSS, Sass, Less, Bootstrap and other web frameworks. These folks have had various levels of development education, from formal post-secondary training to self-taught on the job because of circumstance.

Whether their skills in code are novice or advanced, one thing is for certain – the new modern sites on SharePoint require much more technical prowess than classic sites if they must be customized. This is simply because the technology has moved away from the master pages and page layouts that ruled the roost of SharePoint yester-years. SharePoint – and more specifically the SharePoint Framework (SPFx), has moved to an open-source tool chain that is more in line with modern web development standards.

And that’s all well and good – for developers.

But if I am a marketing or I.T. resource where updating styles and functions is one of my many daily tasks, it’s not an easy ask to suddenly and quickly switch to knowing the tool chain of SPFx and expect to continue development with client-side web parts and extensions. This is especially true in an area where Hub Sites are rising the ranks to tenant kings and all other sites are the spokes, where site proliferation – and maintaining corporate branding and functionality – doesn’t necessarily slow down.

Microsoft has done this before. In the last two years, they have advertised both Flow and PowerApps as “no code” solutions. But this just simply isn’t true (and have since moved to “low code” solutions that still require considerable training to be familiar with). To have any meaningful custom solution for workflows or apps for your organization, you really have to know Workflow Definition Language, Excel logic, JSON, XML, and other supporting languages. Without knowing at least some of these, it’s an uphill learning curve to become familiar with these tools and to drive true value for your organization, and make the most out of your subscription to Office 365.

Why Would I Need to Edit Modern Sites Anyways?

Modern SharePoint sites, both team sites and Communication Sites – are not really intended to be branded. Microsoft encourages the customization of their SharePoint environment by following open-source standards, but without the proper change management and training strategies available (for free), they’re assuming client organizations can sort themselves out and/or should have an advanced resource on site to manage all of this. Having to run – and know how to use – node.js, npm, Yeoman, and the rest of the SPFx tool chain – is a stacked request for regular people who need to do casual branding and functional activities, especially with people such as small business owners who need to wear many hats and have precious little available time. Customizations have been a staple part of SharePoint projects and consulting over the course of my career, and they don’t seem to be subsiding, nor can we ignore specific functionality that match the unique requirements that change from client to client.

Microsoft is doing great things putting new web parts into SharePoint Online and allowing strong APIs to grab data and feed it into intranets and team sites, but it doesn’t account for everything that a client needs. Even the absence of a Script Editor web part has caused may inconveniences and frustration among clients, something they have been able to quickly build, test, and release in previous versions of SharePoint.

Real-World Frustrations

Recently I worked with a client where I performed consulting services that included custom branding, business analysis, migrations, workflow design, etc. The client had a technical resource on their Communications team, a resource that was technically skilled but had more pressing duties as a communicator committed to other projects. While familiar with some web development, he was not necessarily an experienced developer, but rather a go-to for the rest of the Communications team to implement technical solutions when needed.

One of the requests was to inject Google Analytics onto a new Communications site. Previously, they had done this on classic sites using SharePoint Designer, and could easily handle this request for other business units so that they could track users click paths and engagement.

With the introduction of modern sites and SPFx, the technical resource now needed to implement an entire business process with the Communications and I.T. services team just to inject the necessary code they were easily able to do before. They just did not have the cycles to perform this, and would likely have to employ consultants and take time away from other projects just to handle this request. Because of these constraints, and with little time to spare for training (and being understaffed to begin with), it just simply wasn’t a priority any more to put it on sites. Not because they didn’t want it or wouldn’t use the metrics, but because it was too much of a hassle to install it and adopt a new tool chain. The client was frustrated, including not being able to inject code or custom solutions without outside help and with little time to put together a new business process and governance strategy to manage such activities.

One could blame the client for not “changing with the times” or having the right resources in place, but this story is not unlike many companies of various sizes with limited time and budget. Not every client has the cycles to devote to technical training, and the “low code” advertising provides a false sense of security when the technology changes and comes with business workflow design, additional training, change management, and other related activities. The client felt as if they had been “blindsided” amid all of the changes that are constantly pushed to SharePoint and Office 365.

Don’t Forget the Low Coders

Microsoft is doing the right thing by moving SharePoint customizations to the world of open-source tools to manage client-side projects. It is in line with modern web development standards, and keeps the focus at the client-side level. But they cannot lose sight the folks they are sending into the trenches to perform the down-and-dirty of SharePoint development. It’s just as much the UX designer, brander, communicator, social media coordinator, marketing manager, and small business owner as much as it is a trained and knowledgeable developer. And SharePoint is not at a level of sophistication (yet) where all client requirements no longer need a customized solution. There just isn’t a Web Part for all of that. And for all of the great things they pack into SharePoint and Office 365, it would be great if they could wrap up the tool chain into one, all-encompassing and easy-to-use code deployment tool that makes it easy for the “low coders” to jump in and out from.

I am definitely interested in hearing your opinion on this matter. Feel free to leave comments or reach out on Twitter to continue the conversation.

You’re a good chef. Cooking food is a favorite pastime, and you are constantly making delicious meals and treats. You’ll often host dinner parties for friends and family, and they come with their own concoctions and unique dishes. Everyone shares in the feast, and your inner circle are professionals at hosting a damn good pot luck!

But you want to share the delicious food with the neighborhood; after all, you have leftovers and you don’t mind new guests joining the party. So when the new family that moved in next door is mulling about on their front lawn, you open your window, invite them over to chat and give them samples of your food. They give the samples a thumbs up, chat with you about their favorite dishes, and even share with you a can’t-miss family recipe. In turn, you give them access to add the recipe to a new online cookbook you’re putting together that will be shared among your pot luck peeps – including your now freshly minted next-door friends.

What just happened here? Well, besides food bringing the neighbors together, this is analogous to providing Guests access to your Office 365 Group. Guests can be invited to join your Group conversations, consume team files, and even join team events.

Often times I have clients that ask about external access for vendors and the plausibility of having people outside the organization participating in the day-to-day activities. And it ranges from just having people “aware” of the conversations happening among the client team all the way to workflow-based document collaboration.

Every group of clients are different for a variety of reasons, but external sharing is a growing request as people become more comfortable with the cloud and managing online content collaboratively. However, sometimes the idea of setting up extranet capabilities can seem daunting. And no one wants to spin up a random cloud space just to share files; there has to be an easier way.

Here’s the cool thing about Guests in Office 365 – Guests do not require an Office 365 license to participate if you have Business Premium or Enterprise subscriptions. This is not a scenario where you have to set up an extranet environment just to get your Guests collaborating in Office 365.

Adding Guests is pretty easy. You add a new Member to a Group like normal, but just put in their email address of choice. Office 365 will do the rest for you. And the new Guest will get an email shortly afterwards confirming their Guest status with access links.

And much like a pot luck, there are some house rules and standards for being a Guest:

The first time a Guest accesses the Group site, they will be prompted with an Office 365 message about first-time logging in. However, there is no password to set up – Guests can get straight to the content areas.
Group members can only access certain parts of the Group site such as the team Home Page, Notebook, Documents, Pages, and Site Contents. This includes uploading and interacting with files.
Guests cannot access the Conversations from the Group Site. This can only be done through email conversations (you have to email the Group email address). If you try and click on the Conversations tab, you will get a friendly error message (and this makes sense, because there is no record for a Guest as a fully-licensed user of Exchange).
Regular people in your organization are already Members in Office 365. They don’t need to be invited as Guests. But they will need to be added as Group Members to get them into the Group activities.
If you feel like adding a Profile photo or changing the Display Name for a Guest, you’ll have to do it in Azure Active Directory.

The cool thing with Guests is that the functionality allows for a decent amount of collaboration; it does not simply pay lip service to being collaborative and then having a very restricting Guest experience. The Guest can get the full GUI and most functionality much like a normal user.

With the speed, scope, and continual growth of the Office 365 platform, Guest access may tend to get lost as a handy little feature to start collaborating with the right people, right now. But make sure to get organizational buy-in before you start; for as cool as the Guest functionality is, you certain want to align with your organization’s collaboration strategy as well as your I.T. policies and rules.

Hey, maybe a food truck is in your future because of your chef and people skills (and how cool would that be?) But for now, adding Guests is an easy and neighborly way to get more friends in the door having fun at the party.