Blog

Feature Requests - a Developer’s Eye View

Making up about 12% of the topics in our licensed support forums, the Feature Request forum is one of the busiest on the site.  And a perusal of the over 600 features added in ExpressionEngine’s lifetime compared to the topics in the Feature Request forum reveals that we are quite responsive to user requests.

But ExpressionEngine is not a raft floating on the sea of the masses, so to speak, with its course and heading dictated by user-submitted feature requests.  It’s a vast seaworthy ship, a galleon, and most features and improvements come out of things that the experienced captain (Rick) and his crew (we, the dev team) recognize as being useful or filling a need that we see, without a user having to ask us for it.  So what user suggestions makes the cut?  What, besides the potential benefits of a feature, increases its chances of being included down the road?  Well, I’ll tell you.

We’ve heard it before

Between the forums, emails, private messages, meeting in person, reading users’ blogs, etc., there’s a very good chance that we’ve heard your feature request before.  And with developing new things, bug fixes, writing documentation, improving our support resources, assisting with elevated support issues, and so on, we’re constantly busy.  Bombarded is an accurate description.  So before posting a feature request, pretend that we’ve already heard it, because we probably have.  That means:

How you tell us is as important as what you tell us

Since we’re working on the assumption that we’ve already heard Feature X requested before, how will you get our attention?

This won’t do it, sorry.  It’s not about raising hands (more on this later).

Believe it or not, developers are people too.  We are geeks, sure, and we love details and statistics.  These things fly in and out of our heads all day long.  What makes us sit up and listen?  Human interest stories.  Just like everyone else, we are interested in stories about people - about you.  Instead of saying “Feature X would be really handy”, tell us how you will benefit.  How will your site’s visitors benefit?  How will it save you time?  How is it better than any current methods available of implementing Feature X?

Common tricks to avoid

Often, people think that they need to give us a business reason to adopt a feature request, or tell us how everyone else needs it too.  Instead of trying to convince us how Feature X will help them, they try to convince us how Feature X will help us.  Below is a list of common ploys and tricks used to accomplish this, and why they will not help your cause.

Projecting your needs on all users of ExpressionEngine

To you, the lack of a given feature may be very important.  In a community as large as ours, there is an equal number of users who will disagree with the inclusion of Feature X as would support Feature X.  Telling us that our sales will increase if we incorporate Feature X, or that Feature X is an expected out of the box feature for a CMS only tells us that you really really really really want Feature X, as both of those statements, while perhaps true in your case, are representative of the individual, not the whole.

Feature X would be super easy to add

Let’s make the assumption that when saying this that you have first hand experience developing PHP/MySQL applications for thousands of users with very forgiving server requirements, and that the statement is true (though often when it’s used, neither are true).  Is the ease of adding a particular feature a valid reason for including it?  There are an infinite number of “easy” things that can be coded, so even when this statement is true, it carries very little weight.  At its best, its trueness would only affect the speed at which a feature is incorporated, not whether or not it would be included at all. And as developers, when it is going to be easy, we can recognize it without being told.

Vote now!  Vote now!

Why do we not let community democracy determine what features make it into ExpressionEngine?  Quite simply, it could cause an expectation that requests with a high “+1” count are automatically going to be added, or that a feature request that hasn’t rallied the troops will be ignored.  It would dramatically change the dynamic that we now have in the forums from us listening to stories about how a feature will make your life easier, and us responding with suggestions or additional questions, to simply looking at a list and working from the top down.  If that was how I interacted with the community and chose features to implement, it would completely take the fun out of the process for me as a developer.  We’re people too, and need to be happy with our work and have fun at our jobs, or the quality and willingness suffers.

It’s also not an insignificant point that users who tend to participate in polls and voting in forums are typically a tiny but vocal minority of all users.  As such, it would not be an accurate representation of the community as a whole.

Product Y has Feature X

This is ExpressionEngine, not Product Y.  There will always be differences between ExpressionEngine and Product Y.  That’s part of why they both exist and are both successful.  I’m sure Product Y is “missing” a lot of features that ExpressionEngine has, too.  This is not a valid reason for us to incorporate a feature.  If anything, it’s an additional hurdle to overcome: Does ExpressionEngine really need Feature X, or are we just copying another product’s features?

Existing Feature Y is too hard to use

This tact is taken sometimes when a user likes the idea of an existing feature, but just wants it to be easier.  This line of thought is not automatically wrong, but I’m including it here in the common tricks list because it needs to be used with care.  By making this statement, you’ve immediately put us on the defensive, because as humans we immediately read that as “you did a bad job implementing this feature”.  Often there may be room for improvement, but to overcome this hurdle in our psyche, you need to first convince us that you really gave appropriate effort to learn how the feature is supposed to work and how to use it.

Despite what Staples may tell you, not every task has an Easy Button.  In this industry, there are many parts of our jobs that in order to do right, are going to take time, money, and effort.  You need to be willing to expend those three things when working with software.  If it’s clear to us that you haven’t, or aren’t willing to do so, your voice will be lost.  Convince us that you have applied yourself to using the feature, that you have done so numerous times to the point of being experienced with it, and here are some changes that could be made that will save you time, money, and effort, not eliminate it.  Tell us how the change will make your life easier.

See?  It’s easy!

Another thing to keep in mind if we don’t respond to a feature request is that it doesn’t mean that we don’t like it.  We rarely have time to engage in every request thread.  And if we reply with a working solution that you can use now, it also doesn’t mean that we are saying “no”, it just means that we want to help you accomplish your goals as quickly as possible.

User feedback is very important to us, and we think that’s exemplified in the fact that some releases have had as many as 100 incorporated user suggestions.  So keep them coming!  And now that you’ve had a chance to peer into the thought process of a developer, you can be even better equipped to submit excellent feature requests to grab our attention.

(Hat tip to Brent Simmons’ How to manipulate me, which provided the inspiration for this post)