An improved Webform user interface for Drupal | Dries Buytaert
Drupal 7 gets a nifty new Webform Builder: (via @Dries)
Announcing Project Verity
As you may know, Leisa Reichelt and I have been working for the past year or so with the Drupal community; first on the redesign of Drupal.org, then the User Experience project for Drupal 7. Since then, I've been using Drupal more and more. My company has hired two Drupal developers, we use Drupal 6 every day to build new sites and applications for ourselves and for our clients. Throughout all of this work, there is one thing lacking: Drupal does not do a great job at providing an admin for content creators.
During the D7UX project, we defined two personas: Verity and Jeremy. Let's focus on Verity for a moment. Verity is a content creator. She's not a developer. She doesn't care how Drupal works, she doesn't need to know Drupal terminology. All she needs to do is manage her content. Then she leaves work and goes home to do other things. Verity needs the admin of Drupal to help her do her daily job. Currently, Drupal doesn't do a great job of that. That's where Project Verity comes in.
Project Verity launched today. Leisa and the team at Mark Boulton Design are teaming up to design a paid/premium admin theme for Drupal 6 designed to make you look good and your clients feel great. From the Project Verity site:
The Verity Theme (a paid/premium admin theme for Drupal 6) will allow you to hand over a website backend that you can feel proud of, that has a great User Experience and that continues the great design experience you’ve created for the front end through to your clients experience of managing the website. You develop the site in whatever theme you like, then when you’re done developing, switch to the Verity theme to create a user experience specifically designed for content creators like Verity.
I'm very excited about this little project.
We're designing in the open -- as we did with the two other previous Drupal related projects. We're doing this at the blog at Project Verity, and you can keep up to date by following the Twitter account: http://twitter.com/projectverity
Design in Open Source
Since August last year, together with Leisa Reichelt, I've been involved in working with the Drupal community. Firstly, on the redesign of drupal.org, and more recently, overhauling the user experience of the software itself. All of which was done openly, and in close partnership with the Drupal community. Recently, the question of the practice of good design (and by design, I mean the kind of design I do, not software design) has once again arisen in the open source community. From Linux to Mozilla, Drupal to Wordpress, this is a question that keeps bubbling to the surface.
I've only recently been involved in open source through the Drupal project although I've been a member of many communities online, going back to 1995 or so, but none so passionate as the Drupal community. Honestly, it astounds me--almost daily--of the dedication and commitment many of the members of this community show to their project. But that's the positive side. It's understandable, then, with so much passion flying around, that there are frequent heated debates. I've had my fair share of these over the past year. One debate, admittedly instigated by me, happened on Thursday and has, once again, created ripples in the Drupal pond.
It all started last Thursday morning. At Mark Boulton Design, we're finally getting around to redesigning the studio site, and we're using Drupal to do it. The whole team is hard at work, but probably none more so than our developer, Tim. As you do, first thing in the morning I was checking out the work been done to date and, typically, I was viewing source. Having been an advocate for Web Standards for so long, the semantic structure of a document matters to me. I didn't like what I saw, and I knew the cause: the html generated out of the box by a module called 'Views'. And, as you do when you're frustrated, I vented. On Twitter.
This was the code I was venting about:
<div class="views-row views-row-2 views-row-even"> <span class="views-field-title"> <a href="#">This is the titlea> span>
<div class="views-field-teaser"> <div class="field-content">Example teaser content in here...div> div> div>
This is the code automatically generated by views and it apparently looks this way because it has to cope with many different uses. If you ignore the classes for one second, I would have obviously preferred the html to look a little something like this for a header and a teaser.
<div class="views-row views-row-2 views-row-even">
<a href="#" >This is the titlea>
Example teaser content in here...div>
I was a little too soon to vent about this in relation to Views. It seems this argument/discussion has been going on for a long time. Everybody is bored with it. There are reasons the markup looks this way. And, as with all of Drupal, if you have the chops, you can override it all anyway. Some people thought I was attacking Earl Miles, the creator of Views. I wasn't (and hopefully that is now cleared up). My initial venting added fuel to the fire of a long-running debate that is still going pretty strong today: a wider discussion of design, and particularly the existence, and participation of, designers in the Drupal community.
Designers vs Developers
For a long, long time now, there has been friction between designers and developers. Back in heady days of the dot com boom, when I was working in a company in London, that division was strong and apparent. Over the years though, as designers working in this industry have moved beyond trying to make the web look, and behave, like print, this division has become much more grey. I'd say, in the past three or four years, I've personally not felt any division at all. Not until I started work on d7ux.
Drupal 7 is the fruit of developer labour. And lots of it. For a designer to even enter the fray requires trust on behalf of the developer community. And buckets of the stuff. As one developer put it:
You've come into our front room, and, while we were making a cup of tea, you moved all the furniture around. Not only that, but you redecorated, changed the carpet, and removed all of our belongings.
When you put it like this, it's no wonder Leisa and I have been subject to some hostility along the way.
On the back of our little fracas last week, Earl penned a considered response as to why he thinks there is a division in the Drupal community between designers and developers. He starts off by stating this observation:
In software, the roles of the designer and the developer are tiered. The developer writes the code and ultimately gets a piece of functionality, whatever it is, to work. In fact, the services of a designer are never required to make this code work. The fact that the services of a designer is a really good idea doesn't really come into this.
He goes on:
The converse, however, is not true. If a designer desires a particular piece of functionality, the services of a developer are required.
In any open source community that exists to further the development of a software product, this is of course, true. So, with that in mind, and a proposed source of designer/developer friction. What can we do about it? Is it possible to overcome this less-than-symbiotic relationship? I'm not sure it is, to be honest.
Participating vs Contributing
There are a couple of propositions that are regularly thrown at me as a designer working on Drupal.org and d7ux. The first is: 'Ah, but that won't work with contributed modules'. I call this the contrib grenade. It's normally thrown in when someone doesn't agree with your design direction and they're using the power of 'contribution' - the very life blood of open source - as ammunition for their argument. The second is: 'It's a do-ocrasy. Either contribute, or get out of the way.' And, in there lies the problem. At least as far as I see it.
Designers can currently participate, but not contribute, to the Drupal community.
Drupal is a software project. Like many other open source software projects, in order to contribute you have to understand the following:
- Usually the software language the thing is written in. In Drupal's case, PHP.
- The other software associated with the project. Eg. CVS.
- The process of contribution. In Drupal's case, the Issue Queue.
To contribute, developers scratch their own itch. For designers to contribute, we have to find the same itchy developer, that has the same itch. The chances of this happening is pretty slim. To participate is different. Currently, in addition to my contributory work (which, I might add, is because I'm in a unique position), I participate. I'm sometimes in IRC. I've attended two Drupal conferences and will be at my third, in Paris, next week. This is participation. It's discussion. But, not contribution. In this do-ocrasy, I'm not doing. Because I can't. Because I don't know PHP, I don't know how to use CVS, and I don't think the Issue Queue sits well with the design process.
That's just my take. At the moment. But what about open source as a whole. What about other designers?
... I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.
He goes on to say:
... Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.
Not sure I agree on that last point. But the art vs design argument is one I don't want to get into here. But I do agree with the first statement. At least for any aspect of visual design.
Great design requires a singular vision.
Now, when I say design, I mean the kind of design I do. Graphic design, Interaction design - all under the banner of UX. Web design. I think design requires a singular vision that can only really exist in a closed system. A system of control. A system where decisions and solutions are protected from dilution. It's no coincidence that many design classics are the result of the single vision of one individual. Of course, I include teams in this. Teams of designers can produce stunning work, but usually only under the instruction and guidance of a senior figure, with a vision. An art director. A creative director. Commercially, we're the fall guys if the design goes bad.
So, where does this leave us with open systems like open source?
Well, it leaves us as it has for years. In a place where good design, and good designers, are craved by many in the open source community. It leaves designers wanting to be involved but lacking the skills to do so. It leaves designers who have dipped our toe in the water wanting more, but clashing with the community as we grow in numbers. In my opinion, it leaves open source software lacking design vision. But, most importantly to me, it leaves this particular designer feeling a little sad.
Is there any way forward? I think so, yes.
For Drupal at least, I think there should be a team responsible for safe-guarding the user experience. Currently, that is, in part, done by the Drupal Usability team. They do a grand job, but I feel are lacking in one or two crucial areas. For one, they are all 'insiders'. Drupal needs people from outside of the walled garden to provide perspective. Secondly, Drupal needs more visual designers. Not 'themers' (the Drupal word for front end developers), but designers who can know their way around UI conventions, but also know how to set Palatino.
And with that, I'm going to stop writing. The next few years are an exciting time to be involved in this particular corner of the web.
Austin Zen Sub Theme
Aforementioned Zen sub-theme being developed by Colleen Carroll.
Drupal Voices 02: Colleen Carroll on SXSW CMS Showdown & Zen Theming | Lullabot
Interview with Colleen Carroll on building the theme for the #CMSshowdown panel in SXSW this year from my design. This is now being made available as a Drupal 6 typographic theme.