Recently, one of my newsletter readers, Adrian, posed an interesting question. He asked how to decide between building a SharePoint Framework (SPFx) web part, a full-page web part like a single-page app (SPA), a tab inside Microsoft Teams. This could be a personal app or a channel app, or a Power App. This is an excellent question to cover in this week’s newsletter!
Aside on Power Apps
First, let me address the Power Apps aspect of the question. To be honest, I don’t personally build Power Apps.
It’s not that I have anything against the platform, but my primary focus is full stack developers, also known as “code-first” or web/cloud developers.
In other words, my typical audience tends to write in TypeScript, JavaScript, or C#, deploying their work via continuous integration & delivery (CI/CD) and using Azure to host cloud resources.
That doesn’t include “no code” or “low code” developers, also referred to as citizen developers, or the tools & apps they use like Power Apps.
While I don’t build or consider Power Apps, I didn’t want to ignore this part of Adrian’s question and imply that Power Apps are a bad solution. I’ll let someone else who builds apps with TypeScript/JavaScript/C# or Power Apps comment on it.
When to Create a web part, SPA, Teams app - My Decision Tree
This question doesn’t have a single correct answer. It often falls into the “it depends” category, a response we consultants, developers, and advocates frequently give to our clients, even if it elicits eye rolls.
Start with the audience
I usually start by looking at the target audience of the app. Then, I consider what kind of app would best suit this audience. The app’s utility is paramount. An unused app serves no purpose, so if people aren’t likely to use it, there’s no point in building it. Thus, I first consider my audience and ask, “Who is the target audience for this app?”
Where do they primarily spend their time?
Do users primarily spend their time in Microsoft Teams or in the web instance of SharePoint, or SharePoint Online? Are they primarily using a web-based interface within these apps, or do they bypass them and go directly to websites?
Are these apps mainly accessed on mobile, or is usage split between mobile and other devices? Each of these scenarios presents different decision points and considerations.
What is the vision of the app’s utility or user experience?
Another factor to consider is the nature of the application. Is the application we’re developing small enough to fit into larger or different experiences that users may encounter?
Could it be a widget on our phone like a stock viewer, note taker, account viewer, calendar manager, or task reminder? If the application is a small widget-style app, then a SPFx web part for SharePoint online, or an ACE component for Viva Connections, might be the best fit. These are designed to be one of many things on a page, rather than the only focus.
Consider an iPhone, which can have widgets on different pages or the main page. Users might want to quickly glance at these widgets or have limited interactions with them.
Alternatively, the application might be a larger, single-pane or single-window experience. Examples of this could be like Microsoft Outlook, PowerPoint, or a spreadsheet app. Another type of application could serve as a second brain, housing your entire personal and professional knowledge base. Or it could be a CRM-based application, or an app for managing projects or issues related to various development projects. For these types of apps, a team’s tab, like a channel app or a personal app, makes the most sense.
Additionally, it could be a single-page app (SPA). This is ideal if a user primarily operates within a web-based experience or inside a tab, both of which are well-suited to a SPA. If they spend most of their time in SharePoint, then it might be beneficial to use what the SharePoint team refers to as a full-page app within the SPFx, which is essentially a SPA in SharePoint Online.
How do you consider where you’re going to build the newest Microsoft 365 app for your clients? What questions do you ask you your customers, or do you ask yourself before you start on a project once you’ve gotten these specifications? What are your other deciding factor? What are your deciding factors?
What about you?
I’ve shared how I approach this decision tree for what to build when presented with a challenge. These are just my opinions. I’m curious how you approach this debate.
Do you consider the audience?
Do you consider the type of an app that you’re actually building?
Are there other things that you consider that I didn’t mention here?
What do you think?