How we've been creating the best tool for customizing SharePoint forms. 10 thrilling years.

 

Can't keep it, I'm bursting with excitement! We took Designer 3 out of Beta—now, it is a primary tool for customizing SharePoint forms in Microsoft 365.

You'll ask, "Wait, what will happen with the current designer and my custom forms?" Everything will continue working. We trained the new designer to open forms created in the previous designer; and the previous designer will continue working as well but won't be available for download from Plumsail Account.

We're shifting our focus to the new designer to publish updates much faster as it shares a code base with our designer for public web forms despite it is made as a desktop application. I'll explain this further.

Big hand, please!

 

Most of the changes are related to UI/UX but are not limited to this; we ditched the outdated web browser control and now support all authentication methods including 3rd party MFA services.

Next, I wanted to dive into our history. First, it pleases me greatly to recall how we started and have been moving towards this moment. And I also want to share the obstacles we encountered on our way so that you can see the reasons for some decisions or others; and how much specialists we are in such a narrow niche as customization of SharePoint forms.

Steve Jobs once said, "Deciding what not to do is as important as deciding what to do". In Plumsail, we had to start from scratch multiple times in response to evolving technologies, but we always approached it with enthusiasm, constant improvement, and enjoyment.

SharePoint 2010. Silverlight.

The initial tool for designing SharePoint forms was developed in 2012 for SharePoint 2010 and used Microsoft Silverlight framework which was quite young but promising those days. JavaScript was not as popular as it is now and did not have a part of its current capabilities. Each browser's developer had their own vision of what should be supported and how it should behave in particular situations. And Silverlight was the instrument that allowed us to create apps with certain functionality and appearance working identically in every browser. It was a breakthrough. Like Adobe Flash, if you remember, but with C# as a language and .NET as a framework with an excessive variety of UI-elements. Those days, it was the best decision to opt for Silverlight.

We made an extremely basic prototype, without form sets, JavaScript framework, the support of advanced columns and rich controls. It had just essential elements but even those were much more than Microsoft offered then and I believe now.

This is how it looked in design-time:

 

And this is a customized SharePoint 2010 form:

 

Don’t laugh but we started getting our first fans (with offered functionality, it is the only suitable word describing our users). One of them wrote to us:

In our business case we set permissions on item level and user level. It would be extremely handy if we could capture the read/contribute permissions form the current user and based on this show a specific read or write form.

When you don’t have so many users and don’t know what to do next, you can afford the luxury of adapting the product to every single request. That’s what we did, and this is how the form sets appeared. The support is still driving the development, but we're not able to satisfy each request anymore. Where it's possible, we provide JavaScript and CSS code examples, or offer paid support service. Once we see that a request is not just a whim or relating to a very specific situation but something a must, we put it in our backlog. If you miss some functionality, feel free to contact us or leave a comment in our community.

The next step was the migration to SharePoint 2013 which went smoothly as the ancestor used the same paradigm for form's rendering. Some controls became more interactive, but the general idea remained the same—forms were fully rendered on the server side with final adjustments in the browser with JavaScript. Read more about the evolution of SharePoint forms in How to customize SharePoint list forms post. Everything was going well—we added a lot of features and received positive feedback from our customers.

It's still a primary fuel for the entire team to acknowledge that they do the right things resonating with people’s needs. So, my advice—if you want something to get better, do not just criticize, praise the good and show the makers how their product lives in the world, adds value to businesses, eases troubles, and shoulders burdens. Keep this in mind while writing a review :)

This a pretty amazing product. It’s so simple to use and it creates ASP forms with greater ease than InfoPath forms. The price point is also fantastic for what you get considering most SharePoint enterprise products cost thousands of pounds/dollars.

But the dark was looming. Microsoft announced the deprecation of Silverlight, without which our designer couldn't run.

SharePoint 2013/2016/2019 and Microsoft 365. Desktop application.

The Silverlight was popular especially for business applications but upcoming updates to most of the browsers would prevent the Silverlight engine from running in them due to security restrictions. Microsoft couldn't afford to support just their Internet Explorer as in this case the cross-browsing gist of the framework would dissolve. And they came to an unpleasant and unexpected decision to discontinue the support of their brainchild.

We had to find a fast and reliable method for migrating our designer to a new platform, ensuring clients’ forms would be saved. And the simplest way to achieve this was converting the Silverlight application into the Desktop application as both shared the same engine for rendering user interface—WPF. All we had to do was fix minor incompatibilities between desktop and browser implementations of WPF and voila! But this approach had some drawbacks; as now we were not able to run the designer in the browser and use the current user's session, we had to add a login screen and support of all SharePoint authentication methods—NTLM, Kerberos, basic, forms, and SharePoint Online authentication for Microsoft 365.

A new twist of fate awaited us by the time the product became mature and robust. In 2016, Microsoft launched modern experience and modern sites in SharePoint Online, introduced SPFx as a new framework for developing custom solutions and App Catalog as a new way of deploying solutions to Microsoft 365 tenants. Guys from Microsoft love making such broad sweeping gestures and generously supply SharePoint developers with challenges freaking them out.

This time Microsoft jumped over their head by announcing that everything companies invested in for years will not work in modern UI—master pages and custom themes, web parts, custom scripts, custom forms, sandbox solutions, add-ins. Nothing. A common recommendation from MVPs was keeping custom code out of SharePoint—develop standalone web applications and don't even think about deep integrations into SharePoint UI.

Don’t like the client-side development world? Fine… then stay with your server-side code and build ASP.NET MVC or Node.js or use whatever technology you want, just don’t put it in SharePoint… put it outside.

This announcement made developers with 12+ years of SharePoint experience unionize and go on strike. But not us—we saw a rising sun over a boundaryless field of the modern JavaScript era. Our expertise, maintained by the hundreds of business forms we helped to design, gave us the strength to move forward.

The designer for classic SharePoint forms is still available and supports all editions of SharePoint—SharePoint 2013/2016/2019/SE and Online in Microsoft 365 but as Microsoft doesn't invest a penny into classic UI anymore, the development of this product is hibernating. If you're still using it along with classic UI, this is the right time to turn towards modern UI, next I'll show you what we did there.

The designer for classic SharePoint forms:

 

A classic SharePoint form with related items from another list:

 

Modern SharePoint forms. Birth of Plumsail Forms.

Microsoft introduced modern sites and gave developers SPFx as a platform for developing apps in JavaScript, modern JavaScript as now we had the complete environment for building and testing applications, using TypeScript and SCSS, interacting with SharePoint and Microsoft 365 services via handy HTTP-client, choosing from any JavaScript frameworks—React, Angular, or Vue. SPFx dictated strict limitations on what exactly we could change inside SharePoint but how we do that—this was totally on us.

We already had a desktop application for creating forms by dragging and dropping fields, adjusting their properties, adding views of other lists and document libraries but the part that renders a customized form in SharePoint as well as the saving mechanism required sweeping revision. First, we needed to decide on JavaScript and CSS-frameworks.

Regarding the CSS-framework, we didn't hesitate much and picked Bootstrap because we wanted to make forms responsive by default, make them fit the screen size automatically without the need to design a separate form for every device. The second argument was its wide-spreading—many of our customers polished their forms with custom CSS, and having Bootstrap in their arsenal would make the road to their ideal form fast and easy. Concerning the JavaScript framework, we had some discussions and I asked for opinions from my colleague and friend, Ann, and she removed all doubts by saying:

If we go with React, we'll have to hire only React-people, if we go with Angular, we'll be limited to Angular-people, whereas if go with Vue, we can take both and even jQuery-people—that's how simple it is.

We developed rendering engine for SharePoint forms, components for all column types, advanced components for editing items in related lists and libraries, gathering signatures, and collecting repeating rows in data tables; and since all this was based on the client-side technologies and worked almost independently from SharePoint UI, we could reuse it for designing public web forms.

We argued as follows: If we have both the designer and the rendering engine, why should they be limited to SharePoint? We can allow users to design and publish their forms anywhere, embed to their own websites or share by a link. And where will the data from public web forms be stored? Anywhere. We created connectors for Microsoft Power Automate and Zapier—cloud-based platforms for integrating web services. In a few clicks, you can set a workflow that receives data from a submitted form and saves it to OneDrive or Google Sheets, generates a document, sends an email, creates a lead in a CRM system.

This is how we released two products simultaneously—the designer for modern SharePoint forms and the designer for public web forms. It looked fine and worked well, but one problem remained—the desktop application. Not every person was ready to install the desktop application for designing a basic web form such as a contact form or a quote request.

We finished working on the initial release of the separate web designer for public forms by 2020 while the desktop application continued serving SharePoint forms for years because it allowed to configure SharePoint specific components such as List or Library or Lookup controls and to set up routing between form sets; and second, we didn't want to request users for permissions to their tenants as they created forms under their own Microsoft 365 accounts without passing credentials outside.

This is the designer many of you are familiar with:

 

Customized modern SharePoint form:

 

At that time point, we had two primary problems:

• Two different designers had to be maintained and improved at the same time—a WPF Desktop application and a JavaScript application.

• The SharePoint designer used WebBrowser control for authentication purposes. Under the hood, it is a wrapper around Internet Explorer. But since Microsoft discontinued the support of IE by 2022, some 3rd party services used for multi-factor authentication could not work in the designer. Even Microsoft Defender for Cloud Apps does not support IE; and those who activated it for their organizations were not able to use the designer.

2023. New Designer 3.

The next obvious step was unification of the designers, turning them into a builder for both public and SharePoint forms. But we didn't want to make the SharePoint designer web based as in this case we had to make customers grant access to their tenants which would be acceptable to only a fraction of them. We decided to stick with a desktop application behaving as a browser, a modern browser rendering a JavaScript application inside a desktop application.

Electron is probably the most popular framework for doing this, but after some research, we discovered that even a basic application weights hundreds of megabytes; comparing to 13MB of our current desktop designer, it would be a huge increase. Then, we took a look at WebView2, a Chromium-based component for rendering web content in desktop applications from Microsoft. Usually, it doesn't require a separate installation as it's already included in Window 11 which makes a distributing package much lighter.

Initially, I saw the new designer as a mix of WPF and JavaScript, but Wasim, our JavaScript guru, told me:

In 2-3 years, nobody will be able to maintain WPF applications. We should either minimize the usage of WPF or find someone who does still know what the dependency property is and tie him up to a radiator (or wed her?) just to ensure their unwavering dedication to solving any future problem. Believe me, taking a long-term perspective, it's better to rewrite everything in JavaScript.

I thought for a moment about tying Wasim to a radiator but… eventually, we rethought and remade everything in JavaScript and now, have a common code base for both designers which should increase the speed of releasing new features drastically. What's improved comparing to the previous designer:

• The support of all authentication methods including 3rd party MFA services.
• Designing custom forms for different lists simultaneously with multi-tab UI.
• UI/UX improvements: adjusting the size of elements with a cursor, configuring settings in the context toolbox or comprehensive property grid.
• Coping and pasting elements.
• More options for text formatting.

 

It's not the final station, just an intermediate stop. We keep moving and working on new features. Please share your thoughts about the release in comments and stay tuned!

P.S. Thanks to Angelika, our Head of Marketing, for editing this post!

Dmitry, better write code. Leave texts to us. As for the new designer, it looks badass!