Rebuilding the Perch UI – not your usual redesign

We launched Perch CMS at the end of May 2009. Quite a lot has happened on the web since then, and Perch is still the choice of thousands of web designers building sites for their clients.

The web has changed a lot and so has Perch. We now have a companion product for larger sites in Perch Runway, and have just launched a full-scale e-commerce system for the products – Perch Shop. With the Shop launch out of the way we are turning our thoughts to what’s next, and part of that is our first full-scale UI rebuild.

There are significant challenges in developing the Perch UI, and I thought that the process might be interesting to document. So this will be the first in a series of posts as I do this work. In this first post I’ll explain some of the issues we face, for those of you not familiar with Perch.

The current Perch UI

The very first version of Perch was a very simple content editor, there wasn’t a lot to think about. It was also launched in 2009 – pre-responsive design, and before we imagined anyone would want to edit CMS content on a phone.

By the time we launched Perch 2, responsive design was more of a thing and we made some basic changes to make the admin UI reasonably responsive. However, from a business perspective, we were not being asked for a responsive control panel, there were other places we needed to invest time.

Possibly more of an issue than responsiveness has simply been that Perch as a system is outgrowing the original UI. Launching something like Shop, means that the interface has to cope with far more complexity than we ever imagined. We have large data tables for reports, complex forms, and the need for the easy display and navigation around large datasets.

Making changes to something that thousands of people use every day is daunting. While the Perch UI is getting long in the tooth it does work very well. We only rarely have reports of browser bugs; we don’t have issues of janky scrolling or other front-end weirdness. We need to be sure that by making one thing better, we don’t inadvertently make other things worse!

Aims of the rebuild

The core aim of the rebuild is to make the content editing experience on mobile a first class citizen. We now know that many people do want to update their CMS, post to the blog and create products for their Shop right from their smartphone. We also want to rebuild the Control Panel based on what Perch is now – a fully fledged CMS – rather than continue to tweak a design that was developed for a much simpler system.

It is also a good change for us to reassess any front-end technology decisions, and also to create a pattern library for the Perch UI. This will be an asset useful for us internally but also for anyone developing add-ons for Perch.

Every decision we make has to take into account a lot of things, Perch is quite a different beast to a regular website project or even a hosted SaaS application. Here are just some of the things that impact every decision we make.

Our customers. Their customers.

Our customers are typically the web designers and developers who build websites for their clients. In most cases they are the ones making the technology decision.

In Perch and Perch Runway we have a first-class system for truly managing web content in a structured way. It turns out that a CMS decision quite often has nothing to do with the content management abilities of the platform. Instead a CMS will be selected on the availability of certain plugins, if it will fit into an existing workflow, if it looks easy or fun to build with. Think about it, how often do the actual content management features of a CMS get mentioned in CMS recommendations?

We have to appeal to our customers, however we also care deeply about the experience of their customers. Clients, content editors, people who have to use the CMS every day. Ultimately the fact that end clients love using Perch is often why a web designer will continue to choose our software, happy clients make for a peaceful life as a web designer or agency! And as people who write for the web, we want to make creating content an enjoyable or at least non-stressful thing.

Any work we do has to appeal to a web designer who is assessing whether they want to use Perch, but also meet our goals of providing an excellent content editing experience for the end user.

Solid, fast and accessible software over “good demo”

It is a frustrating fact of our life that the work we do to develop true structured content management, to make Perch really really fast, to make it even work at all on many of the hosting environments we encounter, to ensure it is accessible will never win us kudos across social media. This kind of work, you only know it is working, because you hear nothing.

We could throw time into shiny features that make for good demo, that might get us some tweets or the praise of our peers. They might get us a few more customers, drawn in by the new shiny, however we won’t ever prioritise the shiny over speed, accessibility or common sense in day to day use by content editors. That’s just not how we roll.

Progressive Enhancement is how things are done around here

The Perch Control Panel is progressively enhanced. Almost all functionality of Perch is available even if you completely disable JavaScript, or if JavaScript fails to load.

I believe that progressive enhancement is the best way to ensure that the Control Panel is available to everyone, no matter how limited the device they are using is. This approach has served us well, we have anecdotal evidence of a customer who suddenly realised that their client had someone who would be using a screenreader when working with the CMS. We’d not tested the UI with a screenreader but our careful approach meant that it just worked. It’s amazing how many things “just work” when you develop with care.

That said, careful use of JavaScript obviously enhances the experience for most users and can be used to improve accessibility. However our approach means that we can’t simply throw ourselves wholesale into one of the popular frameworks – even if that might save us a lot of time initially.

Technical Challenges

in addition to the different types of customers we cater for and the fact we are a tiny team and so need to prioritise what we do, there are certain facts about Perch that create challenges in the UI.

We have no idea where Perch is running

Perch is self-hosted. Our customers download the software and install it on their web hosting. This web hosting is often terrible and places huge limitations in terms of what we can reasonably expect to be on the server. Oversold shared web hosting is also often incredibly slow. This can make the whole experience of using our software slow and laggy – before we even do anything.

In addition to poor hosting we are also at the mercy of how Perch is deployed. We often see in support people who have managed to fail to upload bits of the software – that might include a JavaScript file or anything else. We try and be as robust as possible to limit breakage should that occur.

We have no idea what any individual install looks like

In Perch the templates you create for your content, which are often then used for output, also become the schema and therefore create the admin UI. This means that we have no idea what any individual edit form a user might have looks like! An edit form could be anything from a single large text field with a WYSIWYG editor, to a complex form capturing granular structured data via many different field types.

The Control Panel may have a large number of our add-ons installed, or none. The developer may also have disabled chunks of functionality for content editors – giving them a more streamlined editing experience, but again we don’t know what any individual site has chosen to do.

Everything has to also work with the API

Perch has an API, so the work we do on the Control Panel also has to work well in our official add-ons – from the MailChimp App to our full e-commerce system Perch Shop. It also needs to be simple for anyone who has developed an add-on using the API to update existing applications.

Ideally the new work should make it easier for add-on developers to see how they can use our UI elements to create add-ons that feel fully part of Perch.

The Perch UI is translated

We have people using Perch all over the world and the Control Panel can be translated by way of a simple approach of a text file of strings. This means that we see Perch in Japanese, in Hebrew and in languages with incredibly long words such as German. The UI has to cope with all of these.

Enabling UI Customisation

We currently allow people to change simple things about the interface – adding a client logo, changing the main colours and turning off the Perch branding. We’d like to enable more of this as people enjoy being able to make the CMS their own – or brand it up for each individual project.

Next steps

I have explained some of the things I’m currently thinking about as we move into actually doing this work. I mentioned that one of our aims with this redesign was to create a pattern library for the Perch UI. In my next post I’ll talk about that process, why we think it is important and the technology we decided to use.