Tag: drupal

The Prairie Initiative – A Social Architecture Project for Drupal.org

Leisa Reichelt4 Comments

I’m excited to be making a start on my current contribution to Drupal which to help drive a project code named Prairie. This is a project with two big, ambitious goals:

1. to improve the collaboration tools on Drupal.org so that we can do more and better work together and make Drupal better, faster.

2. to make Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing to Drupal, coders and non-coders. To increase the number of Drupal.org members who are actively contributing and to recognise a wider range of contributions.

This started out as a ‘Redesign the Issue Queue’ core conversation at Drupalcon in Chicago, but rapidly increased in scope so that it’s now really more accurately described as a Social Architecture project.

For those amongst us who are actively contributing Drupallers, comfortable with the Drupal Groups infrastructure, there’s a group you can join and contribute to.

For those who find the Groups Infrastructure perplexing or just plain frustrating (and you can count me among that number – you’ll find Groups Usability as part of the scope for this project), I’m going to try to keep you up to speed here and I’m experimenting with sharing some screenshots that we can annotate together… we’ll see how well that works – at any rate, I do want to try to open the discussion up outside of the Groups infrastructure so that we’re not just a bunch of insiders talking amongst ourselves.

The issue page – Designing a tool to fit the task

So the first thing I’d love for you to give some attention to are some initial ideas on redesigning the Issue template.

The ideas in this rough wireframe draw heavily from Quora and Open Ideo and try to address opportunities for us to make our discussion more comprehensible and focussed, as well as to make sure that they move through the stages of problem solving (possibly with custom designed interfaces for the specific requirements of each phase) to make it easier to ‘call in the troops’ from the various disciplines when they’re required and also to create spaces that are more appropriate for each discipline in turn (rather than all trying to squash our requirements into the one UI). It also introduces the concept of collaboratively naming an issue and providing a summary for it.

You can take a look and provide your feedback on this wireframe and these ideas here (or in the group if you prefer).

For those who are wondering, no, I’m not being paid to do this work. I’m a freelancer, so I have to take time off consulting, playing with my kids or sleeping to do this work.

I’d happily take sponsorship to do so though, if you think the work is important enough for me to be able to dedicate more of my time to working on it. Let me know if you’re interested.

Five community challenges for design in Drupal 7 & beyond.

Leisa Reichelt36 Comments

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!

Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product)

Leisa Reichelt104 Comments

As you may know, I spent a few months this year working with Mark Boulton and the Drupal community to try to make Drupal 7 (their upcoming release) a Great User Experience. I’ve spent the past weeks reflecting on that experience and trying to understand what we learned from that project and with any luck this will be the first of several reflective posts.

It is all to easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom  of the problem and not the cause.

We faced many challenges with the D7UX project, but the greatest of all was to convince the community that the changes we were suggesting were actually going to result in an improvement to their project. There are many who steadfastly resisted our approach and who continue to do so.

It would be very easy to take this personally and to argue about the details of the way the design works (and I most definitely include Information Architecture when I say design). This would also be a fairly typical Drupal thing to do. Actually, I think almost all the issues stem from a much more fundamental place – defining the real purpose of Drupal and it’s real primary target audience.

From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. Verity and Jeremy who emerged as part of this definition embody the target audience that the design work that Mark and I were doing in this project. This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. This is key to the goal to increase the reach of Drupal, as Dries outlined in his keynote at the recent Drupalcon.

There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff.

Drupal developers (and some designers!) who want to build cool things with Drupal are the core of the Drupal community. They are the people who make Drupal the incredibly vibrant community that it is. Without these people, Drupal becomes a shadow of it’s current self. These people are more than an important audience, they are the most important audience. What this audience wants is not Drupal as a product that Verity & Jeremy can use out of the box, they want a developer toolkit that gives them more and more flexibility and capability to build cool stuff, and to push Drupal way beyond the realms of a simple Content Management System.

And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem.

The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities. An attempt to devise an interface to suit both will result in an outcome that I expect we’ll see in the release of Drupal 7 – that is a compromise to both parties. Verity is still going to need a lot of support to get anything done in Drupal 7. If Drupal 7 had been designed primarily as  developer tool, it would be a much more focussed and efficient tool for developers. As it is now, it is hopefully an improvement on Drupal 6, but certainly not the best that it could be for developers.

For Drupal to really succeed, a decision has to be made, and I think there is only one decision that can be made. Drupal 8 should be designed with developers as the primary target audience and the language, tools, interface should be designed to support them in their goals of building really amazing stuff using Drupal.

That doesn’t mean that there is not still a lot of work for the User Experience people in the Drupal community to do – there is still an enormous learning curve even for those new to Drupal who have great PHP and other technical skills. It’s going to be much easier to address that learning curve with a more finely targeted audience in mind – or more importantly, with the right target audience in mind.

So what of Verity & Jeremy? How will they ever come to know and love Drupal?

There are a number of ways that we can address the experience of non-technical users of Drupal and to ‘productise’ Drupal as a content management system. The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration.

I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise).

There are also opportunities to be explored with installation profiles (see above though re: the fact that they don’t really exist now and no one seems motivated to work on them, where is the incentive?).

And, of course, we have the emergence of tools such as Buzzr from Lullabot and Gardens from Acquia, perhaps also products like Open Atrium from Development Seed can included in this list.

A tough decision but a necessary one

I know that for many people the idea of making a Drupal that Verity can love, making something that can actively compete from a UX perspective with the likes of WordPress, is a grand aspiration. So it is, but unfortunately I also think it is the wrong aspiration for Drupal core.

The sooner we focus on the core target audience of Drupal core – the developers – and commit to making a user experience that supports them in their use of Drupal, the sooner we’ll really have actually achieved a really Great User Experience for Drupal.

If that is really our goal, then let’s get focussed, let’s re-write the design strategy and principles, and let’s take the work we’ve done already and refocus it more tightly on the community we know and love. Focussing on the strength of Drupal and then looking for new and innovative ways to create and motivate the Drupal community to do a better job of looking after our Verity’s and our Jeremy’s.

The Economist/Drupal Project – An introduction

Leisa Reichelt12 Comments

Economist/Drupal – Intro to the Publishing Tools Project from Leisa on Vimeo.

Some of you may know that The Economist is in the process of moving their web content management over to Drupal and I am really excited to be joining the team working on the implementation of these publishing tools over the coming months – my mission is to wrangle the Drupal6 interface such that journalists will be able to spend more time doing what they love to do – chasing and writing stories – and less time doing what currently drives them mad – dealing with content publishing tools.

There are a few reasons that I’m excited about this project:

  1. it’s The Economist! – it’s a company full of clever people writing thoughtful, well researched material
  2. it’s Drupal! – also full of clever, thoughtful people
  3. it’s a really logical progression from all the work that we’ve been doing on d7ux throughout the year which has really been focused on transforming the Drupal admin interface to be more friendly to content producers
  4. it’s a big deal – getting this right is really important to The Economist being able to realise their potential and ambition in the online space
  5. it’s Agile – we’re doing SCRUM in 1 week iterations with an experienced scrum master and even a scrum master master! I am a big fan of well run agile and always looking for opportunities to experience design working well in Agile projects
  6. it’s end user focussed – each one week iteration includes user research/design evaluation (ah, the luxury of known and easily accessible end users)
  7. we’re sharing the process – when The Economist signed on with Drupal the community and open source philosophy was a big part of this decision. We think this is a great opportunity to contribute a case study and some more exposed design methodology back to the community, along the lines of what we’ve done with the D7UX project, so I’m going to be sharing our work on the project here in the coming weeks and months (if you’re interested!)

To kick off the sharing process, I asked Kerrie Lapworth, Production Manager, and Barney Southin, Managing Editor of Economist.com to give you an introduction to the project in the video above, and I look forward to sharing more with you as we move forward!