If you’ve been following along with the Drupal 7 User Experience Project (now codenamed D7UX) at d7ux.org you’ll know that it’s starting to get pretty interesting in the project. We’ve been so busy doing the work I’ve been a little remiss in cross posting over here, so, here is a quick consolidated update for you now!
Initial Concepts:
Last Thursday afternoon we posted our initial concepts for the interface model for Drupal 7. You can see an overview in the video above and we describe it a little over here. If you haven’t already given us your feedback I’d be really interested to hear what you think of the direction we’re proposing to take (even if you’re not a Drupal user!)
Design Principles and Our Process
We also recently shared some more about the thinking and approach we’re taking with a couple of videos, the first on our Design Principles for Drupal 7, and also a bit of an overview into the process we are taking and why we’re so into paper prototyping in this stage of the project.
Crowdsource Usability Testing is Go!
You might also be interested to know that our first round of Crowd Sourced Usability Testing kicked off last week (I know, I should have let you know here too!) – we’re really pleased that we have around a dozen submissions already from all around the world and in multiple languages (which is a challenge we’re still dealing with!). You can see some of the submissions on our YouTube Group. Another round of CrowdTesting is coming up very soon, so stay tuned for that if you’re interested in participating.
A question for you…
As we continue to work on this project we’re continually having to question and refine and experiment with the ways that we work. Up until recently, I’ve used this blog as place to communicate about the project and to ask you – whoever you are! – to participate in the project if you’re interested. One of the reasons I’ve done this is to try to get people who aren’t very experienced, or experienced at all, with Drupal to participate, which we think is incredibly important.
Something different has happened lately, which is that we’ve launched the D7UX website, which is now the primarily place that we’re sharing updates on the project. Since doing that, I’ve gotten some feedback to indicate that people are finding cross posting here and there a little unnecessary…. so I just thought I’d ask what you think?
- If you’re interested in following the project, would you rather follow it here or at D7UX?
- Are you happy/comfortable to post your feedback over at D7UX or would you rather leave it here?
- Do you find it annoying/unnecessary to post in both places?
Do let me know and we’ll tweak our process accordingly!
Thanks in advance for your insight and support on this incredibly exciting yet ever evolving project!
Yes, it is very cumbersome! Non-usable too!
Best is use this places, as someone pointed elsewhere –
http://drupal.org/forum/6
http://groups.drupal.org/usability
You can easily redirect non Drupal users to this place by meta refresh tag.
BTW, things on the video are appearing too complex. May be because they are still in a mess.
Hi,
I am a user experience and interaction designer. I am new to Drupal. I would love to get involved in your project. I am located in Edmonton Canada.
Please contact me.
Bernard
Regarding process, there was an interesting discussion in #drupal (our development channel) the other night about the D7UX process. I’ll try to summarize, although it was a 4-hour conversation so this will be quite long. ;)
There was concern raised about the vast majority of this discussion happening on d7ux.org and not on a drupal.org property, such as groups.drupal.org. At first I kind of brushed this off as “Ok, seriously guys, can you please just get over the WordPress blog thing? :P” but as we discussed more, it became apparent that it wasn’t WordPress per se that was the problem, it was the communication paradigm that a tool like WordPress enforces.
d7ux.org is run by you and Mark, all primary content on it is by you and Mark, and the way people participate is by posting secondary content (comments on the blog postings) which may or (usually, since time is of the essence) may not get responded to individually. It feels a lot like the “Mark and Leisa show, with audience participation.”
On something like groups.drupal.org, everyone can be a content creator and make new posts which are equivalent to everyone else’s posts in “primaryness.” While we have tools like “sticky posts” to draw attention to particularly important things, everything else is open to everyone and has a real collaborative (if chaotic) vibe. This is more like “the Drupal community show, with special guests Mark and Leisa.”
Personally I find 100,000 avenues of information extremely daunting, and love that d7ux.org aggregates everything in one spot. I also think it NOT being on Drupal.org represents big opportunity for us to get perspectives from people who do not have drupal.org accounts, which is also extremely important.
But yet, the current model feels to certain members of the community like “shout it out into the darkness and hope someone’s listening” collaboration paradigm, when they’re used to much more direct interaction like pinging webchick on IRC and saying “Hey! I’m upset about something. Let’s talk.”
I know we don’t want to get mired down in yet more tool discussions, but I’d be interested in your thoughts about what, if anything, we could maybe do about this. I don’t have any immediate answers myself, but figured I’d bring it up since it was brought up to me.
The second theme of the evening was the lack of core developer participation in the process. Throughout the D7UX project so far, I’ve tried promoting, begging, pleading, guilt-tripping, bribing, and numerous other verbs to try and get more people (particularly core developers) over to d7ux.org and chiming in early and often. It’s been a struggle, and so I confronted a few individuals in the channel as to why it was that they weren’t over there. There were a number of reasons cited, but a few in particular stick out:
1. Some of them aren’t sold on this process at all, have a very cynical attitude about the entire affair, and are convinced it’s all going to be a huge disaster. As a general rule, programmers like to stay away from disasters and work on fun/interesting programming problems instead. ;) I’ll continue trying to reach these people, but some may simply sit out the entire process. And I guess that’s ok, as long as we have a wide enough swath of the development community taking their place.
2. Of those who genuinely do want to get involved, some feel like they don’t have expertise in this domain and are really intimidated to jump into the fray. They’re scared to say anything bad because they’re convinced that their opinions will get immediately shut down, and that they’ll offend you guys. I found this absolutely fascinating. We have no qualms whatsoever about ripping each others’ code to absolute shreds in the issue queues; but put us in front of paper prototypes and user experience experts and we regress right back to when we were first dipping our baby toe into the Drupal community and scared out of our mind that someone was going to bludgeon us over the head with a mackerel. ;)
3. “What’s in it for me?” Since developers are skilled ninjas, adept at transforming the Drupal interface into whatever the mockups for a particular client call for, some don’t really grasp why making Drupal easier to use helps them and doesn’t just get in their way. This mostly comes down to an education thing about both the direct (NOT having to do 20+ hours of theming work to make Drupal usable on your next project) and indirect (more users == more potential contributors) benefits of improving UX, but there’s still some disconnect here. I’ll try and work on this as well.
So.. yeah. There was way more than you asked for in terms of feedback on process. ;) Would love to kick around ideas on how we might address some of this stuff.
Now, to answer your questions:
* If you’re interested in following the project, would you rather follow it here or at D7UX?
D7UX.org, please. That way everything’s in one place. But I’m +1 to the idea of doing periodic summaries like this one over here to maybe attract some of your typical readership into looking at our wee project. :)
* Are you happy/comfortable to post your feedback over at D7UX or would you rather leave it here?
Centralization++. So D7UX.org. :)
* Do you find it annoying/unnecessary to post in both places?
Yes! ;) But I’ll do it for you. ;)
Thanks for your awesome work so far, Leisa!!
As one of the principal people involved in this marathon discussion I would like to clarify some of the positions I heard from others and offered myself.
1. The cynical people seem to be having a hard time getting over your lack of experience in Drupal.
Lets try to put ourselves in their shoes for a moment. As an analogy, lets pretend someone gave me a mountain bike and asked me to re-engineer it when I have never been mountain bike riding but only biking in the city. I wouldn’t appreciate the benefits or value of the complicated parts like the dérailleur/gears, knobby tires, or the suspension systems. I would only perceive how complicated they made it to test drive the bike around my studio. (Changing a setting on one end of the bike {shifting} to effect the other end {gear ratio}, the wasted efficiency of pedaling with suspension, these sound like familiar arguments no?)
As a result, I would probably engineer a fixed gear track bike in my efforts to improve its usability. While I would be 100% correct that it is more usable for MY scenario most of the value that was originally unique to the system was necessarily sacrificed for this to happen.
I believe that there are 2 factors that might be causing this disconnect. the first is your limited experience in implementing drupal sites of various types. While your limited experience CAN be a benefit to allowing you to think outside of the box (though certainly not a requirement and I don’t like that it is being presented as one by a lot of people) it also is a detriment for you being able to understand the complete ramifications of your actions or how they effect the diverse types of implementations that drupal as a framework is used to support.
IT is precisely this value that we think sets drupal apart and it is this value that we are seeking to preserve. WP is aided in its usability by the limited scope of its reasonable deployment as a publishing platform. Drupal is not encumbered by any such restrictions because it isn’t subject to the same limiting factors. This is a VERY important fact to us because we are precisely the ones who build these other sites.
The second area where this stems form in my opinion is that maybe our end users and Acquias end users NOT the same people. Acquias end users administer the site and change settings. Most of our end users simply create content and operate in the ecosystem we have created for them. Your willingness to sacrifice extensibility or function to aid the end users in your scenario is COMPLETELY understandable when this is taken into consideration and our unwillingness to do so as well.
Long story short is that you will find most of our our unwaivering support where we can improve the experience of our end users (aka content creators and normal users of a site) I think most of us we are willing to sacrifice some of our extensibility here (think WYSIWYG content areas, admin bar, etc) if necessary as we see this as a real problem.
2. It isn’t that these people are intimidated and don’t think they have something to offer. They don’t feel that their input is being granted the level of respect or consideration that they feel it deserves. Contributing to this process requires significant man hours and we are used to better returns on our investment. A black hole of comments hardly qualifies as a dialogue so i con forgive their reticence for further participation. This is a function of the “top down, broadcast our progress” communication methods and the lack of response to concerns raised. Yes I understand the time constraints for this engagement but there is a reason these things take time. That is so that we don’t waste our time with bad ideas that get implemented all the way until the point that they don’t actually fit into the ecosystem they were designed for.
By flattening the command and control structure as webchick hinted to above you can crowd-source the responses to the criticism to people who tow your line but don’t have the skills or maybe the time to be the primary implementor. You only have to respond to correct stray responses. This sounds VERY familiar to all of us open source people because it is exactly how OUR process works. The very smart/experienced people primarily talk to the kind of smart/experienced people who relay the information to the new people. Its all very grey and not strictly enforced but it is pretty well understood even by newcomers that you don’t bother chx for 3 hours asking him about menu callbacks if you haven’t exhausted lesser resources like the API or people who recently traveled your path before you first.
3. Most of the developers value improving the usability for their end users but their end users and “Drupals” end users aren’t always the same people as described above so you’ll get less traction on admin focused stuff, especially if it requires sacrificing existing functionality or extensibility.
I second the calls for unification of discussion but appreciate updates here occasionally to get your normal readerships input on our process and outcomes. If you want improved input from people who know and care about drupal instead of people who simply use drupal, we need to flatten the communication structure a little bit. Only through honest debate do we reach a consensus in OSS. Furthermore, instead of progress updates with lots of improvements give us easily digestible and discuss-able SINGLE item updates that allow for thorough cost analysis and value proposition consideration. The alternative feels more like running roughshod over the process to those of use who are used to 1 issue per commit :).
@Bernard: welcome to drupal. Your involvement is as welcome as it is needed. Please join IRC channel #drupal-usability on Freenode or continue your input in the limited fashion available to you on d7ux.org. Thank you for your interest.
@Michael: Honestly, I feel that mountain bike analogy is completely flawed. If you were tasked to redesign a bike and did it without ever talking to someone who knew something about bikes, that just makes you a lousy designer; it doesn’t mean the bike’s design can’t be improved and that redesigning it is a bad idea.
The analogy would perhaps be apt if Mark and Leisa were given the task “Go away into your ivory tower make Drupal easier to use, and come back in 6 months with something we can implement.” But that couldn’t be further from what’s happening. Mark and Leisa are taking their professional knowledge and experience and combining it with *our* knowledge and experience (the entire Drupal community, who /does/ know how rich and powerful Drupal is and /has/ collectively built hundreds of thousands of sites with it). Furthermore, they are providing feedback points at every step of the way on everything from the philosophical “What should Drupal’s voice be?” to “Here are some hard concepts we’re looking into, what do you think?” which is our opportunity to jump and provide our expertise and knowledge.
Think about it. Say NASA sent you a work inquiry to build a Drupal-powered, Flash-based shuttle simulator. Would you say, “I’m sorry. I’m not a rocket scientist, and therefore I can’t possibly use my skills as a web developer to complete this project.” Absolutely not! You’d work with the client to understand their needs and requirement, you’d develop a feature list and check to ensure it met their needs, you’d sketch down some interface ideas and show it to them and have them give it a thumbs up/thumbs down, you’d provide them with several iterations so that they could check in and make sure it was conforming to spec, etc.
This is exactly the same situation, except that instead of the client being NASA and these things being decided in board meetings somewhere, the entire Drupal community gets the opportunity to be part of the action and help shape the final product.
I am new to Drupal, know a lot about Joomla though, I heard Drupal is much more difficult. Should I just try, or maybe do I need some classes first?