How your feature requests have shaped Perch

When we look back over the five and a half years of Perch, it’s plain to see just how many of your feature requests have shaped the product that it is today. I thought it would be fun to look over a couple of old blog posts and see how things have changed.

On 1st June 2011, we asked What keeps you from being able to use Perch? This post was of course referring to a very early version of Perch 1 and a huge amount of improvements and changes have been made since then.

Based on your responses Perch got:

In July 2013 we asked the question, What is your top feature request for Perch? At this point we were starting to think about how we could shape Perch to cope with larger and more complex sites. Those thoughts ultimately have become Perch Runway. However we have also added a number of features to Core Perch that you asked for.

The standout request was described in various ways, as “nested repeaters” or “repeating regions in repeating regions”. Essentially the ability to have a multiple-item region that also contained a block that repeated. We introduced the <perch:repeater> tag in Perch 2.3 to solve this problem.

Something we weren’t really aware was an issue until we posted that post was that people wanted to be able to change the author in the Blog App, a simple change and something we added.

Several of the other issues raised in this post were the sort of features that stray into “larger site territory”. In particular the Collections feature in Perch Runway covers many of the requests. If you’ve not taken a look at Collections yet there is a video on the Runway announcement page.

More recently we have released Assets Management with Perch 2.5 and Categories in Perch 2.6. Both of these features had become our top feature requests. Both were complex pieces of work that had been in planning for some time. Assets in particular we had been planning for and gathering use case information for well over a year.

How features become part of Perch

As this post shows we improve Perch based on the features you ask for, however we can’t always simply implement something exactly as you might describe it. If we did that Perch would become yet another messy system with a million settings to wade through.

When we get a feature request we look at how many other people have asked for that feature or something similar. We try to get to the core problem that feature is trying to solve, this is why we sometimes ask you “What is the use case for this?” when you submit a feature request in the forum. What we are trying to do when asking this is to find out what the problem is. Once we understand the problem we can look at other feature requests that might be trying to solve the same issue and come up with a feature that will cover lots of use cases.

We really do encourage you to submit feature requests and the best place to do that is in our forum. Write it up and tag it with ‘Suggestions’. If you can explain the problem this would solve for you, so much the better. If you spot someone else posting something and you have a similar problem to solve, add your use case to the thread. It might not be something we can jump on straightaway but as this post shows we are listening and working out how to bring the features you need to Perch.