Friday, April 3, 2009

Web Two point Buh

We all know what Web 2.0 is by now: separation of form and content. The current batch of CMS's out there do a great job of doing this: databases and templates are kept in nicely separate environments, allowing data to be reused without having to pull data out of heinously formatted HTML files.

Bravo. Good job, all. But we're not where we need to be yet.

After working on NASAScience for two years, I've come to the conclusion that we need more walls than just between form and content.

We need a wall between the developers and designers.

Theoretically, we have that. In practice, we're not even close. Many of the people who design CMS's have never had to sit in meetings with designers in the midst of a crazed fit of inspiration, or with a interface expert who's trying to nudge things to be just right. They want to make changes to the sites they have to manage. They want ultimate freedom.

They want the right to have a better idea.

After a week off from my usual job, I have to say, I have a bit more sympathy for them. I can see the appeal for just doing a site in Flash, though it still makes my soul hurt. Flash, they can control. They don't have to wait for developers to get through their most recent agile cycle to deal with their needs. Six weeks is short for developers. For a designer, that is nigh on forever.

Inspired and refreshed, I sketched out an idea for giving designers much more control over the visual aspects of their websites. Some features:

Lots of views

Instead of making tons of content types, make a few that cover many cases.


  1. Flash object pages

  2. Image pages

  3. Image galleries

  4. Text heavy pages

  5. Video pages



Note: there's a few more, but I'm on the train and can't pull out my notes, which are on 11x17 sheets of paper.

We shouldn't restrict where objects should be put. They should be able to put new page types wherever they need. Updating the structure of the website shouldn't have to wait for a developer to be free.

The secret to just a few content types is to have lots of views. Give the designer lots of options, and make it easy for them to update these views if they need, or add some new ones. Don't make them drudge through the ZMI. For ghu's sake, who wants designers going through the hell that's the ZMI? Or poking at ambiguously named admin functions. Do you want your site deleted?! I've almost had dev vets of 20+ years delete my site. What do you think a designer would do?

CSS on demand

Sometimes you need to tweak the CSS. Sometimes, you just want a bit of CSS to do something you need. Why should you have to wait for a new deployment? However, you don't want them adding CSS inline, as that's impossible to find later. Instead, give them a slot to add chunks of CSS. Then, at the end of your dev period, you can do a report that pulls up all the new CSS chunks and incorporate them into your master CSS.

Customize everything on demand

Everything should be up for customization. The header image. The navigation. The footer. Elements that should be on every page, but a use case has come up where a widget needs to go away. Let them do it. Let them make a special page with pink ponies in the middle of the site, if that's what they've discovered they need to do.

Parts making up the whole

Sometimes, you have things that, in the initial design, are 'whole'. Headers are a good example. Normally, there's a nice, long header image. Give the designer the option to break that whole thing into parts. In our case, I'm adding two more elements that they can plug images or html or whatever they want into it, adding visual interest as needed.

Designer friendly

Sure, sure, this is usually all very doable in most CMS's without having to make huge fuss about the interface. But think about what a designer would have to do in order to affect most of these changes. They'd have to troll through dozens of dangerous, application killing options that are all speaking geek to find the option that will let them do what they need. This should all be exposed on the page they want to edit. Want to modify a template? There you go. A button will take you the the right screen with a warning that this changes -all- templates of that type. Want a new template? There you go. New template, and I'll even add it to the view options for you. Have some CSS for me? Why look, I have a box for that right here.

Why go to the bother?

Yes, this looks like a lot of work, and I'm sure it will be. I'm sure my devs are going to HATE me when they get back into work today. But in the end, I think we all do our job better when we don't have to worry about waiting on other people. I love my designers, I really do. I think they're awesome, creative people. I'd just much rather be playing Zombie! and talking about video games with them, rather than arguing about why we can't make the site like they need it right now.

2 comments:

dgou said...

I hope the devs don't hate it, since it should free their time up from having to do work that someone else can do.

This is an interesting parallel to how Interactive Fiction(IF) systems were built. In "Twisty Little Passages"
it's reported that IF designers wanted "the world" to be made of hooks.

At pycon 2009 there were at least two formal talks that talked about hooks, plugins and monkeypatching. Dr. André Roberge's talk "Plugins and monkeypatching: increasing flexibility, dealing with inflexibility" and
Alex Martelli's talk "Abstraction as Leverage"
and several Open Spaces around plugins. IIRC there was an Open Spaces session defining a common plug-in interface for py.test and nose.

dgou said...

P.S. to previous comment:
A Simple Plugin Framework