When clients roar (or how clients can drive development)

by Rob Chant on March 12, 2009

I’ve always been highly independent. I’ve worked in an actual job for all of one week in my entire life (and that was work experience at school). I deliberately know next to nothing about standard coding conventions and I love to re-invent the wheel, just so it can be my own kind of wheel. And the only psychometric test I’ve ever taken said, quite resolutely, “Don’t even think about trying to manage this person.”

With that in mind, I’m always kind of shocked to think about how client driven Renaissance’s development has been. I started it because a client asked for a CMS driven web site, and a huge number of its features, from core processes right the way across to little tweaks came from client requirements (I hate to admit it, but most of the features I thought up for myself rarely get used in comparison).

In fact, clients were even the driving force for Renaissance’s true raison d’êtra, flexibility.

Flexibility

Right from the word go, I’ve been using Renaissance to build web sites for clients. For the first few sites, it didn’t have a name as such, it was just my own web framework that I customised a bit for each site. But before long, it began to evolve into having its own, separate existence.

Something I quickly came up against was the problem of flexibility. Clients would tell me that they just wanted text on every page, but when push came to shove, they actually wanted all kind of things in the same place of different pages—galleries, forms, all sorts of stuff. They also wanted to present the same content in different ways on different pages, and have different templates for different pages of the site (if only subtly different).

Renaissance, at the time, just had a page creation and editing console. It had a bunch of inputs—enter your text here, upload a photo for this area, do you want a form on this page?, et cetera. Well, that soon had to change, and the methodology that arose is still the core of the system.

So…

The system is still very much template driven. You can have as many templates as you want (even one for each page). Templates are very simple to create—they’re just a bit of XHTML and CSS. The key to this whole flexibility thing is that each template has content areas specified within it, along with what types of content are allowed to be plugged into each area.

So, within those rules, the user can create the content they want (out of the 20 or so different content types and counting) and slot that content into their pages as and how they like. Yes, there’s an extra step involved compared to something such as WordPress, but it’s a lot more flexible.

But, I’m kind of digressing here. This post is meant to be about client driven development! Maybe it’s time for…

An example

A client recently asked my company to re-develop her property web site, with full property listings, needless to say. “No problem,” I thought, “I’ll knock up a new property content type, give it as many fields as I can think of and some suitable views and different ways to group the fields, and that’ll be that.”

Needless to say, I was wrong. When the client started sending over her property specifications, there were about half a dozen fields of which I hadn’t thought. Not only that, she didn’t just want ordinary property in there. She wanted holiday accommodation too, which meant rental rates and a whole bunch of other information had to go in. And, the way she wanted the properties presenting on her site was utterly, utterly different than what I had thought was logical.

Now, I’m not complaining here. It just goes to show that no matter how accurately you, as a developer, think you’ll be able to predict an application’s users’ needs, you’ ill almost always fall short.

In this case, luckily, my job wasn’t too hard. I just had to add those extra fields (easy) and change the view system for the property content type to make it a lot more flexible (note, I didn’t just change it so it would meet my client’s requirements instead of my original idea; I changed it so it could do pretty much anything).

The Last Note

As much as I fancy myself as being an extremely independent designer and developer, I truly understand how much Renaissance has benefited from the level of client involvement in its development that it has had.

I actually find it quite unbelievable how most other applications, in general, only have a bit of client testing and resultant tweaking at the end. The problem with this approach is that the people testing the application are already blinkered by what they’ve been told it can do, so they’re never going to suggest that different.

I also think that lack really shows with most applications. As soon as I go to use something such as Joomla! or CMS Made Simple that a client has installed I’m pulling my hair out in frustration. There’s just so much that they can’t or won’t do that I take absolutely for granted. I guess most people don’t seem to notice as they’re so used to this poor fare.


PS Did I say roar? I surely meant to say, “When clients ask quietly and politely.”

PPS I must also stress that Renaissance is far from perfect. I just get frustated with the lack of flexibility in other applications.

No related posts.

{ 1 comment… read it below or add one }

1

Adeline 03.12.09 at 1:17 pm

I don’t think the fact that Renaissance is very client driven should conflict even remotely with your independence. Being independent doesn’t mean you are shut off from the influences and opinions of others, especially when you are producing a product which is for other people as well as yourself.

I think the best sort of independent state is one in which you keep yourself open to any ideas, suggestions, criticisms etc, that might come your way, but don’t ever compromise on the things that are truly important to you.

With Renaissance it seems to me that the clients’ needs have never resulted in you compromising your vision, so you’re probably on the right track!

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>