August 30th, 2009
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.
The Spark
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 title</a> </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"> <h2><a href="#" >This is the title</a></h2> <p>Example teaser content in here...</p> </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?
Back in January of 2008, Chris Messina wrote:
… 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.
By the way, Mark, congrats on your award from .NET Mag (http://www.netmag.co.uk/zine/discover-culture/the-world-s-top-20-web-designers) for your design work.
I’m glad you wrote this post. I had watched the exchange that I think inspired this post on Twitter. I’ve seen the same argument time and time again — and, as a themer/developer of primarily the front-end variety, I understand both sides of the situation — the need for something semantically correct, usable AND flexible.
I think that the formation of the Drupal Usability team is a great thing but, ultimately, real UX improvements will happen only once we’ve gone through this awkward period where designers are being fit into the work in progress. Unfortunately there has been such a gap of this perspective during the time some of the really formative work has been done on Drupal.
I think we’re seeing this begin — a design track at Drupalcon (although I think some design is, sadly, conflated with theming when they are not the same!), conversations, and even conflict, between designers and devs.
I personally know some talented developers in the community who have softened to the plight of designers over the months and I think we’re going to see more working relationships between devs and designers come out of this. I, personally, am excited about the work that is proposed by your and Leisa’s recommendations although I can see the enormous technical challenges some of them provide — the Views markup and well beyond.
Don’t become discouraged. If you’re causing conflict I see it as a sign that you’re serving a vital function in the community.
I think with the adoption of a UX head for drupal core going forward will help towards the points you mentioned. Treat UX as a first class citizen as code. For any programmer to get a patch into Drupal, not only would it go through Dries and webchick, it should go through UX review if it has any UI. This person would make sure any new UX is consistent with the Drupal principles and guidelines. There’s a lot of details to work out like CVS skills that would be required by this person but that’s beyond the scope of this post. I really hope someone steps up to the plate and fills this role. Dries said that he is open to the possibility.
As for views, yeah it’s quirky. If and when Views UI becomes part of core, many, many more people will scrutinize and polish views for the better, and I am excited at the prospect.
As Drupal User Experience team member, so I am probally at the center of this discussion. I have shared the exact same experience as I became member of the Drupal community. Concluding that you need to know PHP, CVS and the Issue queue in order to contribute. I think the latter is certainly true, but the former I still can’t do and CVS I wasn’t able to do for like a year.
I have spend the greater deal of my time, creating a better process for designers to work on Drupal core — and many ideas are only now taking ground. Therefor I completely agree with your thoughts on fact that our issue queue process does not accommodate designers very well, but what is the alternative/improvements? Is there one without excluding the ones who will implement your design?
Singular vision to me sounds against the principles on which open source exists. I do think the UX-team has a vision, which is not shared very vocally but this vision is expressed in which direction they steer the hundreds of issues that they need to continuously follow. We need to have a vision, otherwise it would be impossible to create a better experience — because every design problem is isolated in the development process.
When it comes to being an ‘insider’ I agree we have grown to become a part of the community and its shared principles, but not more then you. The negative load that an ‘insider’ brings is the inability, to make good judgement calls on how new users behave and use Drupal — which I dont agree with. Any good user experience practitioner should be able to divide between the opinions of his team of how the users would behave, and the actual behaviour of users. Otherwise by this standard any software design team is unable to create an informed design and great design?
Visual designers, yes — hard to find software designers that can endure the pain that opensource design is.
Onto the developer versus designer discussion — I think its all about beign open and willingness to collaborate. Loads of important core developers totally are — because they have grown accustom to the UX-Team, many core devs though arn’t and the assumptions that they bring trouble many conversations. But please, lets not forget that designers have a lot of assumptions to– you have probably learned to dimiss many in the last months (and many are now part of this discussion in the community), as long as both do we won’t collaborate fully.
I consider you part of the UX-Team, if not hereby my invitation to become one and tackle all of these problems. I truly think we have been aware of all them, but actually fixing them is very hard work.
This is a great post, it confirms a lot of my intuitions about the open source movement.
Open source projects are really set up to give programmers a lot of autonomy and decision-making power that they don’t usually have in their work-life, including over design & interaction. Programmers are almost always building products for other people, and open source is an opportunity to build something for themselves. Maybe this explains the “your moving our furniture around” comment, and why projects are organized in ways that make it difficult for non-programmers to contribute meaningfully.
In a sense, they’re right to not trust designers. Developers get involved in open source projects for a lot of reasons, and one of the most important ones is that they don’t have to deal with things they view as meaningless overhead, which includes everything that matters to designers.
The difficulty is that changing an open source project so that designers could contribute would alter the project so that it wouldn’t be attractive to many developers.
Interested to hear your thoughts,
Mike
These debates are good and healthy. On the other hand they are cyclical and old. My opinion for better or worse…
To start with: the second error you made was choosing Drupal/views for your project when it doesn’t (yet) meet your needs for semantic html output.
The /first/ error was to drink the kool-aid of a vocal slice of the Drupal community who think you need to *use* Drupal in order to contribute to Drupal. Whether this is true or not, it lead to the second error.
Since it was your decision to use Drupal, many project leads I know would have no sympathy for you. Many project leads are told by their boss that they *must* use Drupal — and subsequently they are forced to use PHP OR non-OO code OR a difficult to deploy system OR, as in your case, a big ol’ CMS with questionable HTML output.
Which leads me to suggest: the so-called designer VS developer problem is simply a challenge, and it’s not the only one that the Drupal community faces trying to make the best web framework around.
You vented, and it caused ripples, you blogged. For many, this stuff is life and death. For many others, it’s just the issue de jour!
Hope to meet you at Drupalcon btw :)
This seems like a very good, truthful perspective on the Drupal community and software. Your points are a partial reason why I, as a front end designer, find Drupal to be tedious and worthless for most of my projects. It’s another reason why I prefer Wordpress for projects which Drupal might even work better. Drupal is not UX friendly, has a tedious UI and too complicated architecture. I can’t wait to see positive changes that benefit the designer in the next version!
This attitude is exactly why Ruby on Rails came on so strong, and became the darling of the Web 2.0 era. (Passing the much more entrenched PHP to the side, hint hint…)
Ultimately, designers were enabled, and empowered by RoR. With PHP projects, they were given second-class citizen status. Even my beloved Joomla!, of which I am a founder, forgot how important design was — and you can see as so many non-core groups had to produce their own semantic markup to override the garbage HTML that the core was spitting out.
I know I’m being a lightning rod on this one, but just can’t keep my mouth shut about it any longer. Designers are absolutely as important as the code, or your project is NOT WORTH SPIT.
(Feel free to replace the last word above with whatever unpleasant word you choose. Thank you.)
I remember back in the pre-Joomla! days of Mambo when folks compared Mambo sites and Drupal. It was brutal. The Mambo sites had dozens of template clubs and template galleries and showrooms and all that jazz, and Drupal was, well, didn’t show up to the party.
Now Drupal is making awesome progress in so many ways. But for this success to be lasting and meaningful, designers and what many call “front end coders” are not only desired but required.
It’s just not enough to have kewl 3l337 doodads on your site or include jquery for every page whether it needs it or not. You need clean markup that someone can make beautiful. And it needs to render on a great many cell phones and all kinds of devices that you are not quite aware of yet. Developers are not good for this; and I know because I am one. Owning Photoshop does not make you an artist! *blush*
Anyway, you are dead on the money. I think all open source projects need to embrace design, or they will continue to look like poo.
I think the thing that I keep bashing my head on in this debate is, what is it you want the devs to _do_? You don’t want to use our issue queues. Ok, so where would you like to report your issues? If you have a problem with one of our modules but don’t want to use the queue, are we supposed to go elsewhere to find your complaints? Where? You want the HTML to be pure and wonderful. Ok, so how do we get it there without having to become as expert as you on the subject? If you want to contribute, there’s a great place to start. Find a module who’s markup bugs the heck out of you and help the developer fix it. If you don’t want to use the issue queues, that makes life difficult. But if some designer is willing to fix the HTML in my modules, shoot me a URL to whatever you want to use in place of an issue queue and I’ll be there.
I’m more than willing to work with designers. What pisses me off, though, is constantly hearing how devs don’t welcome designers, we don’t do this and we don’t do that. I hear designers are different and so we have to treat them special. We can’t expect them to use our tools or speak our language or do anything that we devs in our dev centric community are used to because that would be hostile. We have to change the way we do things so the designers are happy. But no one seems to be able to explain exactly how we are supposed to change. All I ever hear is that we’re doing it wrong.
So what do you want from us?
Michelle
The solution to closing the designer / developer divide is communication and understanding. This is done with shared knowledge. It requires the designers to learn more about programming, OOP, and software architecture while the developers learn about about UX, usability, and accessibility. Mastery of these isn’t required, but without shared knowledge, solid communication cant really take place. After each side has learned about the others’ importance and the value they add — only then will things be better.
As developer of a few open-source projects, I must say I’m having a hard time agreeing with the idea that designers *want* to be involved in our project. I’ve always been waiting for designers to step in and help, and I’ve never seen one of them contribute of his own free will (they’ve always been hired to do a very specific bit of design and then disappeared).
In fact, it gives me the feeling that motivated designers only get involved when a product is already hugely successful.
This, however, leads me to agreeing with the suggestion that open-source projects lack design vision (as they lack designers in the first place), but I’m open and willing to help designers step in, and to make exceptions or change our development rules a little bit so that they feel encouraged to get involved.
So, from my point of view, I’m a little sad (as a developer) to have never seen a designer attempt at participation or contribution inside my own projects (dokeos, widelands, openC2C and a few more).
Nevertheless, this article is clearly a large step in the right direction, as it puts things in a synthetic form and allows us developers to understand designers views better. Thanks.
@Bojhan: The thing about the issue queue that doesn’t sit well with me is that the design is broken up into tiny little chunks in order to be dealt with. When that happens, you lose context of the greater whole. You lose the a holistic view of the design. We’re seeing this result of this *right now* with the d7ux work. It’s half-implemented, and because of the process of the issue queue, the greater whole is invisible. The goal is invisible, as is the vision.
@Michelle I really did try and explain my point of view. I also tried to offer up some solutions. And, if you read the post again, I’m *not* _expecting_ developers to do anything for me at all.
@Yannick Ok, so first of all, _why_ do you think many designers are not participating? I’m sure lots would want to participate and contribute to open source. Why do you think this is? I’ve postulated in this post, that’s it’s because of infrastructure, environment, and tools. Not because you say tomato and I say toe-may-toe.
I’m glad you think my post explains things–even if in a brain-dump kind of way. All of this stuff has been floating around in my head for a year now. More sense will hopefully form soon.
Sorry to be out of subject, but what do you mean by “designers who know how to set Palatino” ?
Do you mean, designers who have a background working with fonts?
Sorry if this is something obvious for native english, but it isn’t for me.
[…] Design. Es geht eine Debatte um Designprozesse in Open-Source-Communities und Marc Boultons Beitrag Design in Open Source stellt seine Ambivalenz zu Drupal dar, an dessen Design er sich beteiligt. Gleichzeitig zeigt sein […]
@michelle : are you saying it is beyond the strenght of a developper to output semantic html? He just has to be aware of that; and maybe the voices of designers can help to that.
I think that view or wathever else COULD be more semantic in Drupal; i think that is just not a priority for the community… but maybe it should be from now?
I think that always answer ” what ? you criticizes us ? just contribute instead of complaining ! “is not a solution.
Mark, you are genious of design. A true artist. I use the process you adopted for the Drupal.org redesign when I want to give people an example of how brilliant design is born. And that it can benefit from being done in the open.
I think once it’s live, it will give the community a new design vision just on its own.
But you’re a relatively new migrant to the nation of Drupal. I think you immediately demonstrated that you have the design chops and the openness chops and gained respect of everyone. But the question is are you really one of us? Will you stick around even after you stop getting paid for the infrastructure gigs? That doesn’t mean do Drupal for free, but find ways of generating revenue in such a way that you can see value in contributing to Drupal? For instance, set up a Drupal design shop and spend 10% of your time in the Drupal issue queues because you can see a benefit for your company?
Because that’s what most (though not all) of the key Drupal devs do. Drupal is their main tool and they spend the time making it better.
You say design needs a unified vision and cannot use the same community approach that software development does. And you may be right. But I don’t think you can say that with certainty, yet. Some people used and still do say the same thing about code. And they’re obviously wrong. Community-based Open Source code development has been done for about 15–20 years now. Design has come into this arena only relatively recently (say 5 years) and in my view hasn’t tried hard enough to find the right metaphor for itself to fit with the community model.
The thing non-coder designers don’t appreciate about projects like Drupal is that the developers actually do have a very strong esthetic and ethical agenda for their code. Code can be beautiful and it requires a lot of work to make the community produce beautiful code. (But you know that because you can appreciate pretty semantic markup). You may say that design is fundamentally different because of its medium, indivisible nature, etc. but I’d suggest that you try take the design-is-like-code metaphor further and see what happens.
But you can only do that if you stay with the community long enough (not forever, but longer than 2 years). And being a member of a community (just like with families) is 2 parts frustration and 1 part satisfaction. Can you stay through periods when your design vision is being mangled to try another day? Can you find a way of modularizing your design so that enough can be preserved, even if not of all of it is? Can you figure out a way (a metaphor really) of having a design API so that even new people can contribute to it (the sort of thing that happens automatically in the small project teams you mention).
Designers complain that their ideas aren’t listened to. But I don’t know that it’s true. They’re just not listened to always or not accepted in full. Exactly the same thing happens to developers. Not all patches make it into core or contrib modules for a variety of reasons: sometimes because they don’t fit with the overall ‘esthetic’ vision of the whole project, sometimes because there just isn’t time, sometimes because they are misunderstood, and sometimes simply because they are overlooked. (Occasionally, they are completely misguided.)
And as a result, some developers leave the community in a huff, some grin and bear it, while others come back to fight another day or find a way to implement their vision in contrib — refine it, make it prove itself and eventually become standard bound for core (CCK and Views). Why aren’t Views and Panels in core yet? Because they’re not ready (according to Earl, at least) to have their design vision diluted by the ruthless compromise machine that is core development.
Communities aren’t perfect. They give you shelter and succour but sometimes they unleash what feels like the Salem witch trials. They are protective and oppressive at the same time. Open Source communities are better than most because of their underlying philosophy but their cohesion and effectiveness rests on their ability to sometimes suppress individualism. But again you know that. Everyone knows that.
The question is again, will this matter enough to you to stay, bang your head against the wall, find a truly new way of doing community design or will you come in, do your job and leave? This sounds like a value-laden question. But it is not meant to be. You’ve done a great job and if D.o and D7UX are your only legacies, you have nothing to be ashamed of. But I wish you could find a way to stay to make Drupal a better place. I just can’t promise not to occasionally dilute your vision.
I can’t believe I misspelled ‘genius’ as ‘genious’. It’s part of me trying to spell British trying to be a good ‘neighbour’.
I think more developers should learn about design and typography. I’ve learned so much in the last half a year. I think half the problem is that developers don’t usually understand the art. A black screen with green text is what they want.
Also, is it just me, or do others pronounce ‘d7ux’ as ‘Seven Ducks’?
As a something of a coding usher (I open the curtain but i don’t take a seat) I don’t really get the huge importance of another Content/System Frame work. They are always flawed on both sides of the code/UX street because they are always designed by committee. A committee that normally includes individuals who have taken experience and passion and completely alienated the very people who the system may have ultimately been built for. I’d rather pay for something quite frankly than put up with the Diva’s on both sides of the Code/Design street.
As for the output from Views… pathetic. I expect it looks great on a green screened Amstrad.
Well I at least think you’re doing a smashing job with both the website and the Drupal 7 design. I’ve never been as excited about Drupal as I am now, and it’s not just because I’m shallow. User experience has been sadly underrated by most open source developers but I think this has been changing the last couple of years.
Designed as designer
@Yann: I don’t know what “semantic html” even is. When I put HTML in my modules, I try to make sure there’s enough divs that you can do everything with CSS and that stuff makes sense but I’m not a designer and I’m sure a designer would look at it and groan.
Sure, I could learn how to do better markup… Just like a designer could learn PHP. But it’s not where my interests lie. I know enough HTML to get by. Some designers don’t even know that much PHP. While I’m sure there’s some folks that excel at both, most of the time a designer that wants a solid module written needs to ask a developer and a developer that wants solid markup and beautiful design needs to ask a designer.
@Mark: Well, if you don’t want developers to do anything, then we’re just going to continue on as we are. I’m close to giving up on the whole mess. I would love to see designers more active in Drupal but if all we’re going to get is criticized for being devs and then told “nothing” when we ask what we can do, well, then, nothing is what I’m going to do.
Michelle
As a designer, you would find MODx (modxcms.com) very refreshing. It is a breeze to create pure and beautiful XHTML, and you don’t need to learn PHP to do it.
Very nice post, Mark. I know things can get snippy on twitter–who doesn’t love 1–2 line zingers?–but ultimately I think you’ve shown a clear way forward.
My longer, slightly less offensive, post is here (I wrote it last night and didn’t check twitter before I submitted it, or I probably would have included some of your thoughts): http://www.zivtech.com/blog/continuing-climb-drupal-does-design
One item that I wanted to highlight is the idea of creating a Google Summer of Code (which I administered for Drupal) type mentoring program for designers (I’m talking more about graphic/visual design, we already have had a few usability projects, and the push for usability improvements seems much more accepted in the community at this point)
Anyway, thanks for continuing the conversation in a realistic and rational way and for staying engaged in the Drupal community.
Michelle, you said: “I don’t know what “semantic html” even is. Sure, I could learn how to do better markup… But it’s not where my interests lie. I know enough HTML to get by. While I’m sure there’s some folks that excel at both, most of the time a designer that wants a solid module written needs to ask a developer and a developer that wants solid markup and beautiful design needs to ask a designer.”
Wrong attitude.
Michelle, if you are a web developer you have to, need to, should take an interest in semantic HTML. As a web developer what you do is output HTML, that’s your end product. I find your response mind-boggling to say the least.
Congrats Mark for firing off a very eventful post ;-)
One thing I’d like to throw into the discussion is that developers keep using a passive reference to designers — “I keep waiting for designers to show up” and “until they tell us what they want us to do, we’ll do nothing”; and that is the problem.
Experiment for the reader: Start an open source project, and only meet your needs and interests. Do absolutely nothing to encourage contribution or participation in any way. Discourage change.
Three months later, I can guarantee what you will have as a result: NOTHING.
That is the point here, if you want to create a project on the internet and make it so anyone that wants to get involved can, then spend just a few brain cells on ways to setup your project to encourage participation.
Any other approach kinda says you’re only _pretending_ to want help with your project. As the founder of the project, the onus is on _you_ to figure out how to make your project attractive for other folks to participate, and that includes people that are not necessarily coders.
Great thoughts — nice to hear someone putting words to this. Although I do agree with Steve Jobs when he said “Design is not just what it looks like and feels like. Design is how it works.” I think you were getting at that anyway. What excites me the most about the drupal community is all the resources and effort being put into helping designers like me to learn php and contribute.
@Spacemonkey I think you’re making a large asumption here. In my experience, there are a lot of open-source projects where developers do a specific effort to attract designers (they organize contests with prizes for them, they design better interfaces to help them, they write designer-specific documentation), but the result is… not good. As far as my experience goes, only the global popularity of a product is a good incentive to voluntary designers, but as someone else mentioned, the problem might be the fact that the efforts provided are not so long-lasting as they would be with developers (this is a *global* assumption).
This all very subjective, I know, but I think saying developers in general don’t take any step forward to attract designers is a bit aggressive and untrue, at least generally speaking.
There are a few projects, however, that *do* attract great designers, but these are more based into the game or graphic-specific area (Blender, Wesnoth, …), although there are projects which are surprisingly ugly, given they are directed to the multimedia market (like Cinelerra — awful :-))
Developers need to learn and understand semantic markup in order to contribute to open source projects. Period. It’s an issue of knowing the rules before you can break the rules.
Maybe someone *hint hint* should start a conference for developers to become “User Experience Developers.”
@Caroline & @Chris: So that gets back to the old argument that developers are expected to know both code and design but it’s ok for designers to refuse to learn any code and we’re supposed to make it so they don’t have to. That doesn’t fly with me.
I’m working for free here. My HTML works and gets the job done. As long as stuff renders reasonably well cross browser and has enough markup for targeted styling, I call it good. If it’s not good enough for the HTML purists, then step up and make it better. Don’t go telling me that I’m expected to use even more of my time for free to learn how to do it your way. That’s not my itch to scratch.
Michelle
What Caroline said.
This isn’t rocket science. As I see it, there are two issues:
1 — What developers do “upstream” from themers/front-end developers causes problems. Example: The Views mark-up above.
2 — What developers could gain from involving user experience design to improve their product. (IMHO, Earl did this admirably with Views. Could it be better? Sure, but there were several weeks there where designers were creating mock-ups for the Views admin UI. It was a great process to come into being.)
#1 is easy in that there are reasonably objective ways to evaluate semantic output. This ain’t rocket science.
#2 is harder only in that we get into more cat herding — needing to find designer and developer both (all) interested in achieving a better experience.
I believe both are possible. We make small kaizen-like improvements in the Drupal core output’s markup, and more can be done. Maybe if these could be something that is not frozen at code freeze, we as a community could make some more real improvements.
I’m delighted that out of this debate we’ve had several interesting, well-expressed (and cordial) posts presenting all kinds of perspectives. You can’t say that for some other projects, like HTML5.
This is why I have hope. I’ll maybe try to tie some of my thoughts together on this into my presentation on Friday morning at DrupalCon.
@Michelle I fully agree that you don’t need to be and shouldn’t have to become a “designer” as well as a developer. However, I have a few points I’d like to make on that front.
1. You’re not doing this for free. Whether you mean to or not, your development efforts will (if you are any good) result in one of the following: A. freelance development jobs B. full-time employment as a result of your body of work C. a website that utilizes code you’ve written which in turn makes you money.
2. As a developer, you should strive to learn more about the complete UX design process and everyone’s role as it relates to a well-rounded design process. When I started as a designer, I wanted desperately to understand the entire process in order to make it easier for my UX team to work with me.
3. Writing markup is a very large part of development, or at least it should be. It will allow you to worry less about markup and more about that server-side magic you have to execute on a daily basis. Read a book on HTML or something. This is not too much to ask.
I understand you’re “working for free.” I get that. But why not become a better developer as a result of your free work? A better developer knows their HTML inside and out.
@Michelle I just realized who you are. You maintain Advanced Forum, right? Just wanted to say hi :)
I completely agree with this comment by Steven Wittens on Earl’s blog.
We need an API that enables a developer to just flag a particular object/element with certain semantic meaning without having to put in one character of markup into their code.
1. Actually, I _am_ doing this for free. I did an extremely small amount of freelancing in the past and may, someday, get a job with Drupal but I’ve put thousands of hours into it for free. My websites don’t make money, either. This is a hobby for me.
2. I don’t have a UX team or the luxury of time spent in study. I enjoy coding. That’s what I do.
3. I’ve learned quite a bit about HTML and CSS in applied problem solving. It’s not like I’m in there putting font tags in my code. My point is that HTML/CSS isn’t my _focus_. I do a passable job at it but I have no interest in taking that next step to become an _expert_ in it. I would rather spend my time getting better at PHP.
The point of this is you folks need to meet us halfway. Seriously, listen to what you’re saying. You say developers _should_ be able to do your side of things but if a developer thinks a designer shouldn’t freak out at a print statement, we’re being hostile.
Sure, developers need to know the basics of HTML unless you’re really deep in code that has no user facing parts. But we shouldn’t be expected to be experts in it any more than designers should be expected to be experts in PHP. If I said I couldn’t fathom the attitude of a designer not being able to write a module because, after all, that’s where the stuff they are designing on comes from, I’d be laughed at.
Michelle
@Chris: Yeah, that’s me. And there’s quite a lot of not perfect but perfectly usable HTML and CSS in there. I have had some help from themers but I know it still could be better. And maybe some day I’ll read a book on HTML and fix it myself. But there’s only so many kid free hours in the day and I have a lot of php to learn first.
Michelle
Michelle: what’s your definition of “designer”? Do you consider a designer “one who designs” or “one who does front end coding” or both?
@MCrittenden: I’m referring to the people who want to theme a site without touching PHP and expect us to deliver them perfect markup because they don’t want to learn how to override it. So maybe the designer-wanna-be-themer group. I suppose a pure designer wouldn’t care about the markup because they are just desiging and leaving the implementation to others to deal with.
Basically, devs, in general, don’t make perfect markup that is a thing of beauty to behold. We make workable markup that gets the job done. Designers, themers, whoever is working with it can either override it and mold it to their desires or help us make it better to begin with. Telling us the markup sucks and we need to go read books and learn to do it right so we can make their lives easier just causes friction.
Michelle
@Michelle Just to clarify my position, I don’t care what your markup looks like as long as it gets the job done and doesn’t make my life as a “themer” completely miserable. Ultimately, I care about how easy it is for my users to manage their Drupal website.
@Chris: Then you’re not the target for my ranting. :) Believe it or not, I don’t hate designers/themers and I _do_ think Drupal needs them. I just think we need clear objectives that are reasonable for both sides. Both sides have work to do, not just the devs.
Michelle
@Michelle: If I’m the target for your ranting, I really do suggest you read the post again. The markup debate is pretty off topic imho.
@Mark: I’m not targeting anyone in particular but more the attitude that has pushed me to the breaking point.
I apologize for taking your blog off topic. I thought you wanted better markup in Drupal. I guess I misread. I’ll leave your blog now.
Michelle
Honestly, this sort of developer centric thinking is why I won’t use Drupal, and why other solutions outpace it.
Thanks for the great article: I’ve had similar experiences to yours with Wordpress– though they took a commercial route to image their user experience, when it was first rolling the idea of volunteering design services was met with ‘only if you can code php or build a template’ ideal. Ironically, I’m just as skilled with php and Wordpress itself, but the community didn’t seem to warm to the design ideal, so it wasn’t much of an interest for me to be involved.
Maybe it’ll happen when these open source projects specifically make a user experience category for experienced designers, or design/developers, to jump in and support… I know I’d be interested in working on that project, it might get me to change CMS.
Hmm, I wonder if DJango has this problem, I’ve been using it for some time now without any slack on UI comments…
Nice post, and agree with most of these statements.
[…] of the comments made by an alleged developer in response to Mark‘s blog post included this: I don‘t know what “semantic […]
[…] food for thought pour #spip aussi http://www.markboulton.co.uk/journal/comments/design-in-open-source […]
Ah, you nailed it right Mark. That same view module =) … the first thing I noticed it made me sad.
Hey Mark, just another thought on this. Putting aside the fact that there’s no good/structured way for design experts and practitioners to contribute to the Drupal development process (which is a big problem, but one I believe we can fix), it seems to me that designing something “for Drupal” is a universe apart from designing something for “a website,” and that we need to acknowledge that we are wrestling with a really hard set of issues when it comes to talking about “what Drupal should do.”
Designing for Drupal itself is in effect designing for 1000s of sites. It’s product-design, not site design. And it’s a product that is even used to make other products. That’s really hard! You can assume nothing (or at most very little) about the content, purpose, audience or intention of the end result.
Frameworks don’t really have this problem since they don’t have any UI out of the box, and there are probably good lessons for Drupal to learn here. I don’t quite understand what made RoR empowering to designers, but there’s probably some patterns worth copying from that.
Josh Koenig said: “I don’t quite understand what made RoR empowering to designers, but there’s probably some patterns worth copying from that.”
Rails and Django both approach development from a completely opposite perspective as your typical PHP app — they design first, then mock up the layout in templates, and THEN plug in the functionality after the UI has been laid out. Basically the developer is the last person to work on the project.
You could call this design-driven development, I suppose; and most PHP projects I’ve been involved in or used were the exact opposite. Usually the developer sits down with the requirements and starts building code to accomplish those tasks, with the UI to come later. This is bad, as the UI is what the end user sees; and the designer is stuck making a UI “just work” in a predetermined application that was written without regard to user experience.
So far every time I have taken the opposite approach I’ve been pleasantly surprised.
[…] also gave a big thumbs up to Mark Boulton’s blog post titles “Design in Open Source“. An excellent article and must-read for anyone who’s involved with open-source and […]
In Margaret J. Wheatley’s book entitled “Finding Our Way, Leadership for an Uncertain Time”, she relays the importance of identifying the passionate heart of a community to overcome the problematic behaviours within it.
“Other problematic behaviours also disappear when a community knows it’s heart, its purpose for being together. Boundaries between self and other, who’s outside and who’s inside, get weaker and weaker. The deep interior clarity we share frees us to look for partners who can help us achieve our purpose. We reach out farther and welcome in more diverse voices because we learn that they are helpful contributors to what we are trying to birth.”
“We don’t have to interpret an event or issue the same, but we do have to share a sense that it is significant. In our experience, as soon as people realize that others around them, no matter how different, share this sense of significance, they quickly move into new relationships with one another. They become able to work together, not because they have won anyone over to their view but because they have connected in a deeper place, a place we identify as the organizing center or heart of the community.”
That to me is the greatest thing that needs to be worked upon first for Drupal. It’s need to identify it’s heart, what it’s all about (i.e. personality, characteristics, values). You touched upon this briefly with your “How Does Drupal talk?” post on the D7 UX site but it didn’t go far enough though. Once this is determined though and you get both developers and designers identifying and relating to different aspects of Drupal’s universal identity, you’ll have much more clarity of focus between different diverse groups of people. This is critical though because diversity is a foundational strength of every community which helps it sustain itself and Drupal will need that going forward otherwise it will begin to start fracturing itself from within.
Great article Mark, I fail to see why the comment section is turning into a markup argument considering it is rather off-topic with the post.
When I heard that Mark was going to work on the design of Drupal, I had the sort of elation that the person who first put bread on butter must have felt.
If the community can change its processes to accommodate designers in the overall vision, the whole project will be ten times more successful.
I don’t know what the answer is, but please don’t give up anybody.
Can’t we just get along?
Developers love to pursue efficient functionality, but this often ignores how normal humans (neither developers or designers fall into this category, sorry!) will actually want or need to use the software. Sorry, but if humans can’t use it, it is a hobby for a few code ascetics working in a bubble.
Designers love to fix problems on the human perception and interaction side of things, but often ignore practical matters for the sake of petulant ‘make it work anyway’ attitude.
Sounds like a marriage to me! Til death do us part!
I love the challenge of programming good looking and functional websites with Drupal. Therefore I think Marks (and other great designers) contributions to Drupal are essential and very inspiring. Keep it up! To a happy marriage.
Where does the gap really come from?
Experience taught me long ago that when there are stereotypes in software development the end product can’t be great. It can be lame or mediocre at best. Since Drupal’s is such a passionate community I guess it’s safe to say that the end goal here is a great product, so trying to break the illusions those stereotypes bring is a good way of moving forward.
The stereotypes I’m talking about in this case are “the programmer”, “the designer”, “the contributor”, “the open source way”, “designers need programmers because designers can’t code” and many more…
It’s been mentioned that code/functionality is a necessity but design (and all the other things that get thrown into the same bag like UI etc) not so much. This approach gets applied in some companies and in the development of particular applications but you can bet those aren’t high quality products.
When you do a bit of a research about how to make a software product that’s going to be successful you often hear that customers value usability greatly, and don’t care much about how clean the code is or how many features it has. This is not to say that code and features aren’t important, it just states that if something isn’t easy to use the users won’t be inclined to start using it even if it has the features they need, I’ve witnessed this many times with general desktop applications as well as websites. This particular stereotype about sanctity of code is commonly found in developers minds.
Designers also play mind tricks on themselves when forming opinions about programmers. It seems they aren’t too open to learn about that other part of production process. They don’t need to learn to code, but they do need to learn about it, enough to enable them to do their (design for CMS) jobs effectively.
As far as I can see this gap isn’t from within the Drupal community, it’s a general left brain vs right brain type issue.
I have only seen one strategy that can help in these situations, and that is for each “side” to learn a bit about the “other”, so they can work *together* on parts of projects that need that kind of collaboration.
How do you do that, and can it be done in the first place?
The point is to have people work for the same end goal. I guess most contributors are scratching their itch, as open source development is often described, but they are kind enough to release their work back to the community so more people can benefit from it. Here the community benefit is kinda like a byproduct, the end goal is to scratch an itch. And that is all ok, but it’s not enough to make an overall great product. There must exist a critical mass of those who’s goal is the end product, this motivates them to open their mind towards collaboration with all the different niches needed to make a great product.
Drupal community seems to be on that track already. There’s no need to impose the same rules on everybody, it’s enough to have a dedicated team to take care of the issues that involve both worlds and let the others “choose sides” where they feel they can contribute the most.
The dedicated team must have great communicational and organizational skills, and understand and respect both worlds.
I’ve talked to some developers about this and they said that the reason why they don’t like the “furniture being totally rearranged during the coffee break” is because it often causes unnecessary extra work, that can be avoided by having the room arranged right from the beginning. This means having good guides, specs etc. They already exist, maybe all is needed is to add software and data structure guides, UI guide etc. All developers I’ve come in contact with hate when project specs change in the middle of development, this is their pet peeve. They are happy to work according to whatever guides you require them to follow as long as they are clear and don’t change, and they usually like having guides for areas they are not expert in. It makes their jobs easier and less stressful, there’s more certainty about the whole feel of the project.
The thing to understand about designers is the importance of their work, how greatly it influences the value of the product and it’s overall success. Design is not art, it’s craft. Art’s purpose is self-fulfilling and the artist sends a message to the crowd in whatever form he feels the urge to send it. Design is functional, it also needs to send a message but it is important to know what message to send (you aren’t expressing yourself, but the client you’re working for) and find the most effective form for that particular message. Designers shouldn’t be marked as non-contributors for not having coding skills, writing code isn’t one of the requirements to do great design.
Everyone who spends their time and expertize deserves the title of a contributor, they are doing exactly what they should be doing. Making up different labels (contributor/participator) for basically the same thing (using your expertize to work on community projects) is the wrong way to go about organizing any community. All the pieces of the puzzle have their purpose and must come together, one isn’t more important than the other.
I hope this helps someone, warn me to duck before throwing something at me I’m a slow moving target :D
Thanks for this in-depth article. It shows a lot of the troubles I had with a Drupal-project, where I as a Designer had to be a developer, who I’m not.
Anyway I could understand some of the logic behind Drupal, but in the end I have to stick with a weird mix of design and code (for me).
But it is generally a problem mixing up both into themes of the most of typical cms’s which are published and popular.
I didn’t do so much for now in Django, but I did a little work and this is something I would appreciate for any other project: split the development and the design section. Django does this very gracefully and I’m keen for the next thing where I can concentrate on my job as a designer and where a developer can concentrate on his power serving excellent code.
In the webprogramming world everything else is more or less unstable and insustainable, I guess.
Actually — I now will pour some oil into this discussion — why is Apple so damn sexy for so many people — could it be there is a designer with a vision?
Obviously — and this is a great point in this article — is the fact, that design is led by one who knows to communicate by color, elements, typo and so on. Developers are the poeple to get the function, bringing life into the vision of the design. So everybody can see his own part if there are guidelines. This is something Apple did very succesfully in the last years. Every App feels like it is part of the whole system and so you can persuade people more easily using it.
I think there will be more to come on this process, but there is sure a light for both sides togehter. And in the end we all are people who work on INFORMATION TECHNOLOGY. This means we all are dependent on HOW to communicate, right?
We’re all humans behind screens, but we are still humans ;)
I believe open source & Drupal is going to be the #1 open source for a long time to come
Orlando Website Design