This week sees the release of Drupal 7 – a big event for the Drupal community and also individually for myself and the team at Mark Boulton Design as we worked together with the community on the D7UX project which aimed to significantly evolve and improve the user experience and usability of Drupal.
I’d like to start by congratulating the community on coming together to once again significantly improve Drupal and give it all away for free. Let us never forget what an amazing thing open source software development is.
The last couple of years have been interesting both as a participant and as spectator (because I do feel as though I occupy both of these roles, as incompatible as they may seem… many others who have attempted to participate as a designer in an open source community can probably empathise). It has been exciting to see Drupal embrace the idea of design and user experience as vocally and visibly as it has. I think this visible and actual (financial) commitment has really paid dividends although – as ever, the numbers will ultimately tell that story.
There have also been some fairly significant frustrations. I hope that as we raise a glass to celebrate the release of Drupal 7, we also take some time to resolve to think about how we can make design work even better in this community (and all open source software communities).
To that end, here are some challenges I’d love us to attack:
1. Designing participation for designers
Issues queues and IRC are the traditional communication environment for open source development. If you want to be involved in design for an open source community that’s where you need to be.
During D7UX I was there all the time. Since then – not so much.
I have no idea how people keep track of what’s going on in the issue queue – on it’s own, it doesn’t work (unless I’m doing it all wrong?). You need people to ping issues at you in IRC (or elsewhere) to make sure you know what’s going on.
Being on IRC 24/7 is just not an option for me – much of my work is done away from my computer (sketching, running workshops, doing research) and when I’m at my computer I need to be focussed – IRC is not good for focus.A culture of participation that is designed around IRC and the issue queue is not compatible with getting designers to participate in design problems at the right time (that is, toward the beginning, not at the very last moment).
We need to come up with a way that is more proactive – that goes out an pings designers who might be interested in participating, rather than relying on them coming across something in a timely manner.
Yes, this means changing the way the system works because designers have special needs. Do you want good designers to participate in a meaningful way?
Deal with it. (And yes, we’ll help you design this change. Happily.)
2. Recognising participation for non-developers
At this point I’d like to give the accessibility team, the security team, the documentation team a shout out and congratulate them for their brilliant work on Drupal 7.
I regret that there are probably more people whose lack or recognition I am currently perpetuating, because in Drupal, if you’re not listed in the commit message, your contribution, literally, doesn’t count.The Drupal community subscribes to the saying ‘talk is silver, code is gold’ and there’s been no better demonstration of this then the various thank you pages that have been posted recently using the list of commits to Drupal 7 as an indication of the amount you have contributed to the project.
This means that someone who, in a few hours here and there, submits a handful of minor patches is more recognised than someone who spends hours every week taking all kinds of flak from the community trying to educate them on the importance of accessibility, or explaining a design pattern, or reviewing Drupal.org and organising the design and content work required in preparation for the product launch. For many of us (and in fact, probably for developers as well) there is a whole lot of thinking and talking and sketching and research that happens before any code is written – actually writing the code is (sometimes) the easy part.
We need to change this culture. We need to make non-code contributions much more visible and recognised. (And this can’t be achieved by simply sitting in IRC 24/7 having a presence and ‘gaining respect’).
Yes, again – people who don’t write code have special needs.
If we want more of these people we need to change the environment because these needs will not change.
3. Maintaining coherence without ‘owning’ design
Design ideas in the Drupal community need a maintainer, just like core or a module or any important piece of code.
How is it that the Drupal.org homepage can be radically changed within the space of a few hours without any consultation at all with the people who did the research and design work behind it? Or even any adherance to the style guide that accompanies it. (Not to suggest that a style guide is capable of providing specific guidance for every possible outcome).
Of course design needs to evolve as the community and product needs evolve. Of course designers need to respond to the competing requirements of end users, developers, and everything else. This is not about design being precious and permanent.
Just because you *can* change the design, doesn’t mean you should be allowed to – not without a ‘maintainer’ of the design giving approval or at least feedback that you can then act on or against. There is no point investing in good, thoughtful design and then not making any effort to preserve it. Especially when the designers who have done the work are around and more than happy to contribute.
This is not about ‘special needs’ – this is about crediting designers with some ownership over their own work. Not wholesale ownership, just a little. Enough to warrant the opportunity to participate and be consulted.
4. Design leadership in open source communities
Reliance on the current model of participation (issue queues and IRC) means that leaders in the design/ux community currently emerge by virtue of presence – being available on IRC and active in the issue queues. You can’t ‘commit’ design in the same way that you commit code, so you can’t build your reputation in many other ways than being there and participating. (The relatively recent movement toward designed distributions is possibly starting to shift this a little, although still relies on code).
This is good because it means that these people are passionate about design and UX in Drupal and show commitment to the project. It is bad because it naturally privileges people who have more available time and who tend to be less experienced. Designing for Drupal and in the Drupal community is a challenging prospect. UX and product design considerations impact an ever increasing audience who rely on Drupal for ever more critical capabilities.
We need to find a way to allow experienced designers (and in this I include UX/Usability people) to play a proactive, leading role in shaping design in the Drupal community at a strategic, not just tactical level, without requiring them to be on IRC every hour of the day and night and having to respond within minutes.
It is not an acceptable response to say (or think) that there are no designers or usability people out there who are interested in participating or that they just don’t have what it takes to stick it out. There’s no shortage of people who would willingly contribute time and expertise and many who, over the years, have attempted to contribute much more.
I’ve been reading a lot about change management lately and one of the keys to successfully making change is making the environment conducive to the behaviour you want to achieve. That’s our challenge moving forward.
I think this is possibly the most important consideration in my list.
5. Defining our value proposition
I’ve said it before and I’ll no doubt say it again – you can’t meet the needs of the wide range of activities of the incredibly broad Drupal audience in the one interface. Not well. Drupal 7 via D7UX is – hopefully- a better experience for both newcomers, content creators and, in some ways, developers. It is nowhere near an optimal experience for any one of these groups, because they have conflicting needs, behaviours, and characteristics.
Drupal is just like most of the clients I’ve ever worked with who are seeking growth – struggling with their value proposition. I’m not saying we need to abandon any one of our audiences, but we need to address them in different ways, not through one incredible interface. Thankfully I’m now able to stop just talking about this and actually do something through the Project Verity theme work Mark Boulton & I are doing together. (It’s really starting to come together now – stay tuned!) We need to define a UX strategy for our key audiences and then optimise the environment for people to design most effectively for them. We need to do that before we start designing Drupal 8.
It has been a great honour to have worked on the D7UX project and the Drupal.org redesign and, through that, to have had the opportunity to work with some of the passionate and talented people who contribute – in many ways – to Drupal, it’s current and future success.
I look forward to having some kind of continued involvement in the community – exactly what that is will depend on how seriously the community takes some of the issues I’ve outlined above. Regardless of that, I’m here – you want some help, you know how to find me.
Cheers Drupal – Congratulations!
Here’s to the success of Drupal 7 and beyond.
I’m thrilled to be attending Drupalcon Chicago in March – I’m even doing a pre-conference training session called What Users Want that I think will be really fun and which is focussed on teaching people to do what I do (UX research and design), especially those who have never done it before (managers, developers, marketers, I’m looking at you!).
Want to talk about this stuff in person? I’d love to see you at Drupalcon. It’s a great conference and, with Jared Spool, Clay Shirky, Mark Boulton, Jeremy Keith, Russ Unger, Karen McGrane and more coming to share their experience, it’s almost a design conference with added Drupal – hooray!
Regarding your first point: Seems to me that what is needed is much better visualisation (and effective prioritisation) of the task/request list and its progress through the design process.
And that process isn’t necessarily the same for non-functional design as for functional development, as you note.
Maybe something like Kanban would help to give a sense of what’s in the queue already, what’s underway already and what’s done, without needing constantly back and forth pinging: the board constantly broadcasts status and supports decisions of “what should I work on next?”
Yeah, I agree – I wish we’d had time (and known enough at the time) to have redesigned the way the issue list works on Drupal.org. I have some thoughts of a few things we might do that might help a little – I’ll sketch them up and share them when I can.
Awesome thoughts! Well said. I’m one of those designers in the Drupal community who would love to participate more, has limited available FREE time, am never going to hang out in IRC all day, hates trying to solve 50 problems for 10 personas in 1 interface, and fears putting my name on things I have no continued ownership of :-)
Thank you for sharing your thoughts. Communities are always evolving and posts like this are really important for that process.
I’m not sure if I agree with you on point 4. Why is committing design any different from committing code? If you see a problem (be it function, design, security, documentation or something else) you can create an issue to discuss the problem and work on a solution. Every issue needs to draw the attention of other community members, because they need to review, test and finally accept the solution. Every solution is a proposed change that needs support to make it happen. Sometimes that means I have to do some ‘advertising’ for my own issue on drupal.org, twitter or IRC. I think that every design/UX/usability person can do the same – am I wrong?
marcvangend, I think what you are missing is the design process and how the tools fit or don’t fit into it. The tools and processes we currently have are built out of code development processes. They are there to support crafting code.
Now, other types of work do not have the same processes. The tools we have don’t necessarily map or support those processes. IRC, the issue queue, etc are all used to support certain types of roles. Other roles don’t use these channels but that their own.
I think what you are missing is seeing how others operate outside the common developer circles or people within the Drupal community. You don’t know what you don’t know.
The tools we have should be there to support and enable the people we have. If we have a bunch of different groups and only support the tools for one of those groups it’s not going to be all good. We have room for improvement when it comes to enabling and supporting all the people who make drupal and drupal sites great.
Matt, thanks for your response.
Of course I don’t know what I don’t know – it’s hard argue with that :-) However I do see “how others operate outside the common developer circles” on a daily basis. I have colleagues who work with Drupal but are not involved in the community like I am. Myself, I have only been involved in core development for about a year. Before that, I was mostly active in the forums and I didn’t have a clue about IRC. Today, I still wonder how some decisions were made, and how I could have known about it. What I’m saying is: many people are disconnected from (and confused about) the issue/irc work flow. It’s not something that differentiates designers from coders.
I have seen designers use the issue queue just like coders do, but I completely understand that it’s not ideal. If designers need other tools to collaborate on improvements and influence the decision makers, then we need to think of something and make it work. However, even if the tools are right, the Drupal community is a meritocracy. People who do a lot and are available often will gain respect and influence. Tools cannot change that, I’m afraid.
Thank you for writing a brilliant and insightful post. As someone who has been one of the louder voices in the room regarding designers in the Drupal community (at least in Boston), but has felt like my lack of availability to be on IRC/the issue queue leads to a lack of recognition for my contribution, I’m looking forward to seeing how the community starts working to really appreciate the designers among them.
Solid write up. It’s hard to argue with any of these points. Thanks for the contribution.
Leisa, I hope you can take a deep breath and feel proud of the tremendous jump forward that the new D7 interface is. Last night, I took the time to live the out-of-the-box D7 experience, and I was truly impressed.
After all this enormous effort, I hope you and the D7UX team can really begin to see the fruits of all your work. The new interface will hopefully be a game-changer.
It’s great to see the results of all of the collaboration. last night, I had the same feeling of pride that I would watching a NASA launch.
I hope you do, too.
Very insightful post. Over and over, it has been illustrated that design in the Open Source world is a different bird than code. It cannot be subjected to the exact same process as code. What impresses me, though, is that you continue to work hard to find the right way to mesh the OS community’s principles with the principles of good UX, long-term usability, and design.
I find this issues you bring up in #1 and #4 to extend well beyond design/UX. I think they hamper good code development, too. Any system that requires a participant to be 100% involved 100% of the time is going to play to the wrong strengths. Frankly, shuttling even the most mundane patches through the project is way too time consuming, and this is largely because it requires contributors to constantly and actively seek for information over multiple communication channels. Thus amount of time available for information hunting is an attribute “selected for”, while actual expertise, experience, and skill level are surprisingly irrelevant (or at least under-relevant).
Leisa, I actually have to disagree with you a bit. These are not 5 challenges felt by designers. These are 5 challenges felt by everyone, that are a problem for everybody, regardless of role. Coders just feel them less than other groups, for various reasons.
I’ve been a long-time critic of the “talk is silver, code is gold” definition of “meritocracy”. Even within just the engineering realm that is wrong. It emphasizes code slinging over thoughtful analysis, planning, architecting, managing, and other important engineering-related tasks. Without those, code slinging is useless. In fact, I’d argue that our emphasis on “working code” rather than “working strategy” is one of the key reasons that Drupal 7 is now so internally inconsistent.
On the design side, nearly everything a designer does is “thoughtful analysis, planning, architecting, etc.” The “code slinging” part would be actually implementing a theme… which is a form of coding, even if it’s not in PHP. It still uses the same patch process that code does.
Working in open source is, for better or worse, an inherently collaborative, endlessly iterative process. Design doesn’t fit that model very well. That’s not just an open source thing, really. Even at work I still have no good way to track the evolution of a design concept from start to finish between both design and implementation teams in a way that doesn’t involve emailing PSDs around that become outdated in two days. If you have a suggestion for a workflow that would work better I’d love to hear it, because I haven’t found one yet. :-)
Back at DrupalCon Paris, I had a great conversation with Mark Boulton over lunch where we observed that part of the issue is designers are not used to having their work dissected and being forced to explain every detail. It’s their job to get it right, a lot of it is just “feel” and emotion, and a consistent approach is more important than a precise explanation of every pixel. Open source folk, by contrast, are by nature predisposed to rip everything they see apart to see how every detail works; that’s why they’re in open source, where you can do that! That’s an inherent conflict, and I still don’t know a good way to resolve that.
That we have no unified design leadership is true; but then, it’s not a design problem. We have no unified architectural leadership either. Dries does not really provide it, and we have no one else that has the karma and time to provide it, nor a way to “enforce” it. (Because Drupal abhors enforcing anything.) One-off changes to the front page may grate on you like nails on a chalkboard; similar one-off changes or implementations happen every day in the code, and they grate on me the same way.
In fact, I would summarize the entire problem this way:
Drupal has no structure or organization. That makes planning and coordinating haphazard at best, and impossible at worst. This sucks for everyone. It results in a “do-ocracy”, where everyone “do-es” something different and we just suck it up. OCD code monkeys naturally get hurt by it least, so they become the loudest voice. This results in mediocre everything. It’s just more noticeable in design because it’s in more people’s faces.
This is a problem we must solve.
Thanks for making those points Larry.
Designers and developers can have both design and implementation work that are more similar to each other than not. And for both roles, they mostly only see the implementation work of the other role.
The current infrastructure and tools are sort of OK* for tweaking or implementing an existing design, but aren’t really suited for the design side of either role. As far as I can tell, when new subsystems like PHPTemplate, Form API or D7s DB layer came along, they were worked on by a small group of people elsewhere and didn’t really hit the issue queue until after the design is mostly done and it’s time to implement them.
* Keeping track of what’s going on across something the size of Drupal 7 is going to be extremely hard no matter what your role is or how brilliant the tools are. And I’m sure a significant number of coders (like me) don’t like using IRC much either.
I suspect designers finding it difficult to keep up might not understand how difficult it is for coders to keep up also, or how difficult it is for the coders to keep any kind of overall code design consistent too.
Yes, a few people have commented that many of these thoughts are not unique to designers and I’m sure that’s true – it’s just not something I’m as familiar with/energised by. I’ve said often in the past that a lot of things are blamed on the designer/developer divide that shouldn’t be so I’m heartened to hear that these challenges are also shared. Makes it more likely that, should we find a good solution, it may actually get implemented.
See – I still have my optimistic hat on :)
The pain points you describe are not unique to designers – they are felt by different people with different skill sets.
Personally, I use email subscriptions and selective filters to stay on top of issues. I don’t spend much time in IRC because (as you mention) it can be a distraction from other work. My lack of a regular presence in IRC reduces my community visibility.
And the “talk is silver, code is gold” mentality means that people (like me) who don’t code aren’t as visible in the community. But, my goals for involvement don’t really include being visible, and the notion of “ownership” gets a little muddy when we are talking about “owning” something that sits atop the product of tens of thousands of person hours that have gone into the Drupal project.
But with all that said, what would be the ideal workflow for designers? If you could build the Best System Ever ™ to encourage designer involvement, what would that look like?
I can understand many of your concerns, but I have to disagree with the assumption that designers work fundamentally differently than coders, so can’t and won’t work with the distractions of IRC.
There have been quite a few peer-reviewed studies of how coders work and the best productivity comes from a person locked in a quiet room with some caffeine and no distractions. People that spend a lot of time in IRC also produce a lot of quality code, so they are either really good at multitasking, or know when and how to tune it out.
IRC is where the action is and I would argue that some form of real time chat is absolutely necessary for any geographically distributed team.
Designers shouldn’t have to participate in IRC to effectively contribute, but being willing to participate will definitely help.
I didn’t mean to imply that developers *can* work with IRC on in the background and that they are different from designers in this way – although I can see how it’s come across this way. I also agree that some level of interaction on IRC is really valuable because of the distributed team. Your final statement – that you shouldn’t *have* to be on IRC to participate but you should *want* to (at least occasionally) – sounds just right to me.
You can’t use the same process for assigning merit that is used for coders that you can for design, because fundamentally coding is about tasks (rolling out features and bug fixes) while designing is about choices, giving precedence to one thing over another. Making choices is a deeply individual act, and all open-source projects have trouble handling this unless they are owner-driven (WordPress).
There is the additional problem of how to reward designers who make right choices. You can’t build an open-source community unless you reward contributions. It’s very clear who contributes what to modules, and who gets the rewards, so Drupal has a lot of module contributions. You don’t get any reward for writing documentation, or any ownership of your contribution, so Drupal’s documentation is insane.
@Mathieu – saying that coding is fundamentally about
rolling out features and bug fixes is like saying that design is
rolling out sizing boxes and picking color schemes. To bring any
design to life, there are a number of choices that have to be made
when it comes time to implement them in code (both front-end and
back-end code). And, although choices are deeply individual, we’ve
found ways to come to a consensus and make group decisions. For
Designers who think there work ends with producing a PSD or other
mockup, the issue queue + IRC are not going to fit their work
habits. Neither will having to defend most of their decisions after
they have been made. I think designers have a tough job there,
because good design is holistic. The Open Source community is used
to testing and challenging proposed solutions, so designers might
feel like they’re precious creations get unduly criticized when
shared. Also, Drupal needs to be flexible to fit different use
cases, so trying to have a one-true-solution is
impossible.
If we as a community were to develop a set of UX guidelines (Leisa, did you in fact already do that?) and/or architectural guidelines/roadmaps for Drupal core as well as contributed modules, where on drupal.org would this happen? I think groups is too peripheral a location. It shouldn’t just be thrown into a core issue either because UX and architectural guidelines should influence nearly every issue queue. Therefore they should have their own tab so to speak parallel with core and projects. And these (as well as coding standards) should always be referenced when for example providing examples of how to write your own module. We can’t control what’s contributed via contrb but we could create a certification standard (does a module or theme conform to the architectural, coding, and/or design principles or not) and assign grades or pass/fail. We can, however, ask that those with commit privileges in core refuse to commit patches that do not conform, and we can ask them to also make it their intention to emphasize the principles from the beginning stages of any queue/conversation about new developments. Finally, we could assign a design leader (or even an Architecture leader) to Drupal 8 with authority and responsibility comparable to what WebChick has (for Drupal 7).
Drupal.org has a style guide that lives here and seems to be referenced occasionally. D7UX had some design principles that live over on the now redundant D7UX website (not sure if anywhere else). There is definitely an opportunity to make these more extensive and better communicated/used by the community.
I agree that there needs to be some authority given to maintain, maybe even enhance, the coherence and quality of the design work undertaken to date both on d.o and within Drupal itself.
The main UX guidelines for Drupal itself (not drupal.org) are hosted here: http://drupal.org/ui-standards
There is definitely room for them to be expanded and improved. I guess the way to do that is to file issues at http://drupal.org/project/issues/documentation?categories=All
Saying that Drupal has no structure or organisation is a really, really inaccurate and potentially harmful way to view the current development process. There is no official structure (apart from Dries and branch maintainers), but there is a vast amount of unofficial structure and organisation which has developed organically over time.
This is made up of the communication networks of the issue queue and irc (with groups, blog posts etc. in a wider circle around that), and various conventions – whether code style, what it means to review a patch, issue statuses and priorities etc. all of which allow allow thousands of people to collaborate with more or less a shared understanding of the process.
Just because it’s massive, bottom-up, fluid and driven by convention and communication rather than rules and hierarchy does not mean it has ‘no structure or organization’. Would you say that London or Tokyo have “no structure or organization”? They have massive idiosyncrasies which have built up over decades or centuries, changes are driven by vast and often contradictory relationships between various sections of society, businesses and various national and local government bodies – with none of these winning all the time and often making things worse when they do.
But the structure is there, they provide habitation and the rest for tens of millions of people, and they’re infinitely more interesting places to live than the 100% planned monstrosities you can find (usually on a much tinier scale, often now empty or stagnant) elsewhere.
None of this is to say that Drupal (or major international cities) don’t have serious problems that need to be sorted out. But simply declaring there’s no structure then trying to impose one is not going to cut it.
The first step to making changes is understanding what the problems are, and I feel very strongly that Drupal 7 has been the first release where we already know what a lot of those problems are (and have done for some time), even though we’ve only just got the release out. Whether this is easing the routes to participation for designers, or improving performance, or API consistency, a lot of discussions going on at the moment were barely happening when Drupal 6 was released, or not at anywhere near the level of depth. A lot of work to resolve these issues was not finished (or in some cases even started) during the release cycle, but we are in a very good position to continue this work for Drupal 8. However doing that needs to happen via an honest examination of the strengths and weaknesses of what we currently have – and there is plenty of diagnosis still to be done before declaring the cure.
Hmm, this was supposed to be in reply to Larry’s comment, but appears to have started a new thread instead.
Great post! I think it tackles many of the major problems, and would even deserve their own page. With Drupal 8 development/design starting soon – I think we should carefully think about how we can provide solutions for this.
When I started out with Drupal, I quickly realized that issue queues is basically where everything happened but also where good design was least likely to happen. Beside the time commitment, design is a high-bandwidth activity that requires a lot of going back and fort between ideas, possibilities, strategy and more – the issue queue is far from ideal for this.
Designing involvement from designers, I think we should have a platform that allows us to run discussions on preset topics. For example having 4/5 weeks of exploring on how to improve the design behind blocks, from concept to interaction – with feedback from the community, anyone can sign up – but there is a platform and culture in place to allow explorations. This could be similar to Mozilla Labs design challenge, and the platform is not a technical challenge but rather a design challenge how we can shape these “projects†to be as efficient as possible.
So far, I have tried to ping you or mark whenever there is a crucial point that needs your feedback. However that strategy is totally dependant on my own availability, its not scalable and not open – I am not sure yet how we can close these ties.
Again, having a platform(in any form, actual site or blog discussions) where both exploration and discussion can happen with designers would be a big deal. But designing it so, that our development community has a intense involvement(so we can turn ideas into reality) is a daunting undertaking.
2. Contribution
Others have tackled this more gracefully, I think we are aware of the problem – we just have absolutely no solution for it yet. I don’t think metrics are the problem, we will never get them right to recognize activities that are simply hard to measure.
I have always liked the appreciation you get from community members, as they see all the non-measurable activities. But yes communicating this to outside the community, we still have a long way ahead of us.
3. Coherence, no owner.
Knowing how to handle “no control†but guiding the flow, to me has been an important realization in terms of creating coherence.. In reality this has meant that most of the strategy in the D7UX project, required constant repeating and hashing out how it applied to whatever interface we where designing.
Over time, we kind of got at the point that UI changes need a check by the UX-Team. I think this is a great step towards coherence, not to say some things did go in that didn’t meet our quality standards (e.g. Dashboard) – it does allow more direction.
Given that the UX-Team is so small and most knowledge is hard to transfer, we haven’t found a way to make this a scalable approach to everything that needs design. But enlarging the UX-team on the different areas of focus, should give us a far great deal of flexibility and involve more designers.
4. Design leadership
I think this goes back to 1. Designing involvement of designers. We need a way for designers to be able to significantly contribute both on a strategic and tactile level. IRC is the current primary communication channel, because it lends itself for insightful discussion in such a high-bandwith activity as design, but its not a platform that allows many occasional contributions.
I feel somewhat uncomfortable with the undertone of this whole post, that UX’rs are unable to be active in IRC/Issue queue due to time commitments. I don’t think it’s a matter of time commitment but rather that the current process of doing design in the community is frustrating and difficult. Programmers can, and their time commitment is no different from designers.
“It is bad because it naturally privileges people who have more available time and who tend to be less experienced.†I don’t know who this is targeted at, but it seems rather contradicting to the truth – most top contributors have more available time, because they can choose to make more unbillable hours (freelance/employed) – this often does not apply to juniors, the few rare ones a side.
As UX-Team we have a great deal of involvement in both the tactile and strategic level, I hope we can more clearly unify this.
5. Value proposition
As a community we should get around the table and start hashing out the strategy for the different audiences. I think this is clear, so lets get this going.
6. Resources
This is incredibly important, the D7UX project clearly showed that. For any strategic work to actually get done, we will need a whole lot more interaction designers, researchers, visual designers etc to be involved – likely even in the trenches to make it happen.
With our offset of about 1 designer per 100 developers and a UX-Team of at best 6/7 people – its unlikely we will get to truly informed design decisions and action without draining people. If I want to dedicate more time to strategic work, research and communicating in D8 – I need to slide some of the specifics work.
I think the idea of some longer term ‘sessions’ focussed on solving particularly gnarly issues or addressing some big outstanding design challenges is a great idea.
Re: pinging myself or Mark – my experience has been that we’re finding out about things right at the last minute and asked to provide ‘feedback’ on work that has been done. We both feel that we’d be able to provide much more value to the community if we knew what was going on at a much earlier stage and could provide guidance proactively rather than trying to rescue things at the last moment.
I have to disagree and say that I think metrics *are* the problem (or, at least, a part of one of the problems) – it’s pretty well accepted saying that ‘what’s measured matters’ – yes, something things, like good design, are very difficult to quantify and measure. If we’re going to admit failure on measuring *all* the contributions then I think we need to make some social rules about not using what we can measure as a way of determining who is most valued in the community.
I’d rather we try to be creative about finding ways to recognise and reward different kinds of contributions in a way that *can* be measured. I don’t think this is rocket science. It’s a great design problem/challenge. Personally I’d be quite excited to try to tackle it (we did have some initials ideas when doing the d.o. redesign but ran out of time to explore them).
With regards to time constraints, I think it *is* different to be a designer than a developer in the Drupal community. If you’re a Drupal developer and you’re employed to do Drupal work you’re going to be creating things that you can and are hopefully encouraged to contribute back to the community. You can get paid to do this as a part of your job. Can you do this as a designer? I haven’t seen it yet, or certainly, not much. (I’d love to be proven wrong here tho!)
With regards to experienced UX/Designers participating in the Drupal community – I am doing my best to keep this as impersonal as possible, but I think you will have to agree that we are hardly over-run by really good experienced UXers or designers, are we? Can you name more than a dozen (even a dozen?) UX and Design people combined who have more than five years commercial experience and who actively participate in improving the UX/design of Drupal.org or Drupal core UX? And this for a project that was listed as a top site/project to watch on Mashable this week?
I agree that *everyone* who is much good is short on time and I agree that the gross frustrations of trying to do good design in the Drupal community is far from an incentive to spend your limited time this way, but I think it is also true that there is a much greater incentive for those who are new to design/UX to invest their time and put up with the frustration.
At the moment, Open Source is very much seen as a place where you can go to potentially get experience as a newcomer to UX or design. Unfortunately, due to the dearth of good design/UX mentoring in this space, it’s not really a great way to become a better designer – although your career may benefit from the visibility I guess.
We do agree, though, that we need more good people and we need a way to be able to step back and address the strategic challenges rather than constantly putting out fires at a tactical level. We ‘bought’ some of this time temporarily for D7UX and D.O in recent times but what’s our strategy in the longer term?
It’s probably true that it’s easier for developers to get paid to contribute to Drupal as part of their jobs than it is for designers. But there are exceptions.
Jeff’s work on Views is one good example.
The part of this discussion that bothers me the most, is the assumption that designers and other non-developers involved in the site building process are such a precious resource and that the entire community needs to upend its processes in order to incorporate their feedback.
I have worked with many different designers of different technical levels, and have actively encouraged them to contribute to Drupal. Of those designers I have only convinced one to make any contribution at all.
Is it possible that the majority of designers and non-developers don’t appreciate the value of open source and this is the reason for their lack of participation?
It is also sometimes difficult to convince coders to participate as well, but I feel like they understand the inherent value the first time they install a module instead of spending a week writing code.
What worries me most is we spend a lot of effort creating new processes to encourage design involvement and end up with the same situation we have now: a few awesome committed designers willing to but heads with the coders, but not enough help to go around.
Failure should not be an option. And if we prioritize it highly enough, then we should succeed. If we need to attract designers into the Drupal project moreso than communicating with already participating designers (which we of course need to do better at also), then we need to draft a very clear and compelling call for designers that describes the opportunities, needs, benefits, and challenges. duple is a big enough and exciting en ough project that it/we should be able to attract the needed talent if the intention to do so is there (meaning the time and effort are invested to make sure it happens).
I will again say that I think there needs to be a very prominent location for this kind of communication (and the communication that results from attracting designers and getting them involved) on drupal.org. Like, on the home page. And I imagine that this is something that Dries and the Drupal Association (and probably Acquia) need to be persuaded to spearhead. Bringing Mark and Leisa into Drupal in the first place was (in my opinion) an invaluable step, but only a step, in the right direction. How many paid engineers have been brought in by Acquia versus how many designers? We don’t need only to focus on getting designers to volunteer. Most of the top code contributors to Drupal get paid to develop (and volunteer more hours on top of that). We need to persuade top corporate sponsors of Drupal coders to also sponsor design contributors. Again, if we define the problems, goals, and opportunities clearly and strongly enough, then we can start to make this happen. And again, it would seen that Drupal Assoc should play a leading role in this.
I am not a Drupal Assoc member so I am speaking simply as a semi-outside observer. Scratch your own itch drives a lot of specific improvements but not so much re-architecting or re-designing across the whole Drupal project. These need to be coordinated. Hopefully, we can create the mechanism for coordination and leadership of such activity within the fluid/organic/informal semi-hierarchical community structure that we have now. It’s just a matter of convincing enough key players to take an active interest and make it happen.
This is my impression. Feel free to disagree, correct, dismiss, or expand on my thoughts….
So is the only viable solution to pay designers and UX people to contribute? I was fully behind the decision to pay for the recent work that has been done, and I’m happy with the results, so I’m not saying this in a negative way at all.
Many Drupal contributors work at companies that pay them to develop code for clients, which can sometimes be shared, but the vast majority of development for Drupal is done in people’s free time.
I have worked with designers that have been paid to design many different Drupal sites, but that did not translate into them wanting to contribute any of their skills back to the project on a voluntary basis.
I’m less concerned with finding leadership than finding an army of design volunteers that can all fix small problems and help out the leadership with sticking to style guidelines etc.
Its not particularly difficult for a designer who knows html and css to put together a really great looking Drupal theme and contribute it back to Drupal but http://drupal.org/project/themes is not exactly overflowing with great examples. A designer that put their work out there proving they understand Drupal would have no shortage of offers from companies looking to hire them, so why is nobody doing it?
Who can we learn from? It seems wordpress has a bunch of really quality themes available, but Ubuntu had to contract out its UI design to get the quality they wanted. Any other open source projects that stand out for good design?
The reason for the dearth of great free themes is probably
somewhat different than the reason form the lack of graf designers
helping to plan UX throughout the developmental arc of core and key
modules such as views, paels, etc. (although I can see that Views 3
development has included a lot of discussion of how to improve the
UX). In regards to the latter, it may be that there is simply not
much tradition of that anywhere (other than Apple and Microsoft,
where they are paid). Is there an example of another open source
project where you see designers participating in discussions with
coders on a daily basis over a months to years long development
cycle? With themes, people often say that cvs (now git) is a big
barrier. Would it be possible to create an intermediary, a place
(or person) that designers simply upload their designs to and the
designs can put into version control and onto Drupal.org for them?
Word press themers have it easier because most of them know that
they are designing for a specific function and audience: bloggers.
And so they look nice and finished out of the box. The most well
known themes on drupal.org on the other hand for the most part are
intended to be used as platforms on which one can more quickly
build one’s own design. And the most activity such Drupal gardens
theme builder is in theming tools. Because Drupal can be used to
build just about any kind of site, and because it is difficult to
impossible to create a great finished but all-purpose theme, it
seems like we would be better served if the themes on Drupal.org
were tagged and searchable by their intended use and could display
multiple screenshots showing different configuration and use
options. If end users could easily search for blog themes and
commerce themes and magazine themes and portfolio themes etc, then
themers might be more tempted to contribute more use-specific
themes. Coders may come in because they see in Drupal a tool to
create something that they couldn’t have created easily before.
Contributing code makes their own lives/work easier. Scratch your
own itch. What itch is Drupal scratching for designers (the
designers who don’t also build their designs but rather hand them
off to others to build)? What Drupal offers is just another way to
attract clients (and great designers may already be making enough
money to not be so enticed by this oppoprtunity) and the
opportunity to be part of a great open-source community (which we
hear all the time is actually somewhat antagonistic to them despite
being otherwise great). I think we really need to figure out how
Drupal can be appealing to top designers. Wherever it is on
drupal.org that we solicit the contribution of themes and explain
clearly how to do this (do we even have an attractive user-friendly
and prominently located page that does this?), we should also make
clear that designers who contribute themes will be able to list
links to their business and advertise that they also do paid
designs, consulting, etc. whatever it is they do to make money, and
we could describe topnotch themes (or others) as an example of how
this business model can actually work. Once we have figured out
what kind of appeal we SHOULD be making to designers, we need to
actually make it! The last two years of DrupalCons and the
drupal.org redesign (and Dries’ message from the beginning) have
been largely about reaching out to new people outside of the
community, about making the message more simple and clear and
appealing, rather than simply waiting for people to wander in and
figure out everything for themselves. It’s not an either/or. it’s
just common sense that we need to develop specific strategies and
implementations to attract outsiders into something that is or has
been very complex, especially if, at first blush, we need them
(designers) more than they need us.
This was an interesting read.
I think “Talk is silver, code is gold” needs to be retired. It doesn’t make much sense for code, let alone other kinds of contributions. However, it contains an important idea that is worth preserving: Discussions aren’t useful unless they evolve into something that actually works. If you were trying to rephrase that for designers, what would it be? Maybe “Designs are silver, designs backed by user testing are gold”? It’s important that we have some way to communicate these essential Drupal community values to everyone.
The frequency with which names appear in the Drupal 7 commit messages is a poor metric for contributions (although it’s not really correct to imply that designers, documentation writers, etc are always ignored by it – they are often mentioned in the commits also). If anyone wants to help fix the way we use that metric, I started an issue here: http://drupal.org/node/1020680
Being on IRC all the time is not actually a requirement for being an effective contributor to Drupal (if you look at the numbers, many active contributors don’t do that – most people, including developers, simply don’t have the time or inclination to be “on call” that often). Staying on top of the issue queues is more important though. It would be useful to hear specific ideas for how to make the issue queue more effective for everyone. Having been part of a group of people who once tried to organize user testing there (see here, here, and here) I think it can be done as is, but a different outlet might work better. This is mainly because user testing and design naturally tend to spill over into many different areas, whereas issues within the queue work better when they are focused.
Regarding point #4, I think the number of experienced designers participating in Drupal is on the rise. Do we know there’s a current problem recruiting them, or is it just that developers have had a head start, and we are still in the process of seeing things equalize naturally? How will we know? With the focus on user experience in Drupal 7 core (and the potential to leverage that into further improvements in Drupal 7 contrib), I think more will continue to jump in. It’s always a tough sell to convince anyone with experience to join the Drupal community (not just designers), since it basically requires them to throw out their resumé and prove themselves anew, with the quality of their Drupal contributions being the metric on which they’re judged. That process is an essential Drupal community value. But notice that I said quality, not quantity; in my experience, the Drupal ecosystem is pretty good at promoting people who do great community work, even if they don’t have time to do a lot of it. Certainly that’s something I look for when recruiting or recommending people for Drupal jobs. I hope that designers who have experience and skill, but not tons of time, can still become influential in the Drupal community by making high-quality contributions to a few specific areas.
Personally I, like many of my co-users and other persons, I have met on net the use of pop-up black-background areas in admin interface confusing. This is because I have to check once again how the matter *actually* looks in the site design.
There has still been not mass shift of user base from Drupal 5 or 6, and 7 is being adopted very slowly, even drupal.org has not adopted. Which means sites big or complex as drupal.org do not find it easy to jump to drupal 7 just as drupal.org finds it impossible.
So far users are concerned, users in the sense of registered members of a site, the actual end-users find it still *not easy* to add a photo or media as easy as in say, facebook. If you have a facebook account just see the ease and practicality they offer. At this point for our site members drupal 5 or 6 or 7 does not make any difference.
The discussion of code and design may need to be thought about with regards to elements and patterns. In the world of architecture the code can be the building materials and components wood, bricks, steel, windows, doors, roofs, etc These are the modules, HTML, and CSS of that world. The structures that these modules create when applied all work to a some degrees of success. But a house and a commercial building serve different audiences and needs but both have doors, windows, etc. This to me is the difficulty in contributing design solutions like they are code or modules. Design by it nature and requirements is the use of patterns and components to solve a problem that has an expressed need. Not many of which are necessarily shared by individual clients across many individual projects. Its like looking a housing development of identical homes vs a house design for a specific client, same components, same modules radically different outcome. We can learn from the design of others but it the application of the elements to the problem where the real lesson is, not it just how it looks. Design is not just a visual solution or style to be replicated without regard to the audience being served.