Designing a big system like Drupal is no easy task, we all know that. Part of what is not easy about it is that you have to design both little chunks and also big stories. Getting these to come together in a coherent way is not easy to design but even more difficult to communicate.
We know that there are people out there who are worried about how the D7UX design will work. We’d also really appreciate it being put to the test. So, here’s a forum where we can do that.
If you have a concern about how D7UX will work, post it here. In order for us to be able to respond to it, you need to make it as specific as possible. The best way to do this is to tell it as a bit of a user story (and try to use as little Drupal speak as possible so we can all play along).
For example, your concern may be that there is no place in the Information Architecture for the people who have signed up to an event to be managed. Your user story would be something like: If I create an event and then I want to see the list of all the people who have registered, how would I do that?
Please feel free to post ANY concern you have here. We will endeavour to answer every single one of your concerns as best we can and as quickly as we can. That way we can *all* start feeling as though the design is robust, get a sense of how it will play out in a range of user scenarios, and we can identify and correct any weaknesses as required.
There’s been a lot of talk about Open Source Design & User Experience lately. Here is a great opportunity to dip your toe in Open Source Design, see what it’s like and work on a small but important project for the Drupal 7 User Experience Project (D7UX).
What is this?
An opportunity for UX people to work with Drupal developers to solve specific, finite and modular user interface issues. No previous experience or knowledge of Drupal is required.
A UX volunteer will be paired with module developer(s) to work on the interface and UX aspects of a module, create wireframes that capture UX recommendations which may then be implemented by the developer(s).
A Drupal UX Mentor will provide guidance and support as required. We’re estimating that each microproject will require no more than 12 hours of a UX Volunteer’s time and those hours can be spread, flexibly, over a 3 week period.
Why are we doing this?
to give UX professionals an opportunity to ‘try out’ designing in an Open Source Community (and hopefully love it so much they stay!)
to give developers the opportunity and framework to engage with designers/UX professionals to maximise the usability of their module
to get feedback and insight into how we can help designers and developers to engage in a much more holistic way on an ongoing basis
to spread the UX workload and maximise the improvements available for inclusion in D7
to help make Drupal 7 an amazing user experience!
How will it work?
This is a brand new and somewhat experimental initiative so your involvement will be instrumental in shaping the way the process works, but this is what we have in mind:
26 May – 1 June 09 – Call for participation: see ‘Get Involved’ below.
2 – 10 June 09 – Cross Matching: We’ll assign UX volunteers to modules and introduce the teams!
10 June – 1 July 09 – Engagement
A three week period will be assigned for the participants to work together to improve the UX of their assigned module.The work involves
o Developers briefing the UX people on how the module works and anything they need to know about how Drupal works
o UX people creating wireframes or prototypes (your call!)
o UX people and developers collaborate to finetune the user interface and perhaps do a little guerilla usability testing (if possible/appropriate).
1 – 8 July 09 – Evaluation
Each participant will be asked to submit a brief evaluation of their experience (what was good, what was challenging, how they’d do things differently next time, how things could be better) so that we can learn more about how to foster the engagement between Designers/UX people and Module Developers throughout the open source development lifecycle.
What kind of projects?
We would love to sign up around half a dozen microprojects. Here are some examples of projects we think would be perfect as a microproject:
design a great WYSIWIG Editor interface for Drupal 7
design the interface for a great media library for Drupal 7
design some great dashboard widgets for Drupal 7
There will be opportunities to get involved in more complex UI projects for D7UX and we’re working closely with the Drupal Usability team to define and collaborate on these.
Want to get involved? Yay! We’d love to have you aboard!
If you’re a UX person who’s interested in participating, leave a note in the comments below (and use your real email address in the comment form so we can contact you!)
If you’re a Drupal developer and you’d like some UX love for your module, add a link to your module project page or even the specific issue if there is one and give a quick summary of what the module does and what the main user interface challenges are.
If you’ve got some ideas for what needs UX attention (task ideas) even if you’re not a designer or developer – feel free to post your suggestions in the comments below
We’re really looking forward to working with you all on these projects and seeing what we can achieve in the coming weeks!
ps. want to find out more about how you can get involved in the Drupal Usability Community? Come say hello here and see what we’re up to!
As we start to get some outputs that are getting higher and higher in fidelity (that is, more like what they’ll be when they’re done), it becomes easier and easier for more people to take a look and give their feedback. This is great, but it’s also a challenge. Why so? Well, because, D7UX isn’t for everyone – and if it’s not for you, then in order to give feedback we can work with you need to be able to put yourselves in the shoes of someone it *is* meant for, or better still – find one of these people and try it out on them.
A well designed interface doesn’t work for everyone all the time, that’s just an impossible dream. It should work for it’s defined target audience most of the time though, and that’s what we’re aiming for.
So, who is D7UX designed for?
There are two main audiences that we’ve had in mind as we’ve designed this interface for D7.
Our ‘Clients’, the Content Creators - the first group we’ve broadly named ‘our clients’ because for many of the community who make sites with Drupal, these sites are then turned over to another person or group of people who use Drupal to add and maintain content on the website.Often these people share the following characteristics:
- They’re not developers. They don’t know much about code and how it works,
- They’re not in the Drupal community, they don’t love Drupal as much as we do, they don’t speak Drupal-ese,
- Updating the website is probably just one of many jobs they have to do,
- They’ve probably used other Web Content Management Tools than Drupal in the past.
These people tend to have a small number of tasks they need to do on the website, and those tasks tend to be repetitive.
The best thing we can do for these people is to make those tasks as simple, question free, and error free as possible.
Non-technical Site Builders – these guys are a whole other kettle of fish. They have a more advanced understanding of what technology can do and how code works, but they’re not developers. They are, however, considered technology or web experts in their field, which may be something like academia, or ‘social software’ or they may just be the person at their tennis club or church who ‘understands the web’. People expect them to be able to build fairly sophisticated websites and they’d rather like to be able to do it themselves too, except without the technical skills, it can be hard. You’ll probably find a bunch of these people currently using Ning.Often these people share the following characteristics:
- They’re not developers but they do understand quite a bit about how code works and may be able to write and understand a little code themselves
- They find themselves needing to create websites (often for others) that have fairly sophisticated requirements, including forms, community tools, online stores, and content publishing using a range of page templates.
- They have experience with a range of online content publishing tools.
- They have probably heard of Drupal but had little experience with it before and certainly don’t speak Drupal-ese
If you know anyone who fits one of these two descriptions then these people will be idea test candidates for the D7UX interfaces as they emerge. If you don’t then here are a couple of very sketchy ‘personas’ you should consider when evaluating the usability of D7UX.
Verity (our client, the content creator)
Verity is a part time administration assistant for a cancer support charity. She is working part time while she completes her Social Care Diploma. Before she left work to study, Verity was a Personal Assistant in the Finance Sector. Verity is in her late twenties. She is quite proficient with the MS Office Suite (Word, Excel etc.), and she uses Facebook and email but she doesn’t consider herself very good with technology.
One of many tasks Verity has to complete each week is to update the ‘news’ section of the website and any other small content updates that are given to her to make by more senior staff. She doesn’t mind this job but she is often interrupted by the phone and other staff while she is updating the website, which can make it tricky for her to remember where she is up to in the process. If she has any trouble with the website updating there is an IT consultant Verity can call, but she likes to avoid doing this unless something is very broken as the consultant is both very busy and expensive!
What Verity Wants: to be able to complete her website updates quickly, without getting confused, and feeling confident that she’s knows where she is and what she’s doing at all times.
Jeremy (non-technical site builder)
Jeremy is a social software consultant (no, he doesn’t like that job title either). He works with medium to large organisations to help them understand how social tools could help their businesses be more successful and he recommends tools that they should use and how they should be implemented.
Jeremy is often frustrated because it is difficult to customise existing tools to suit his clients. Also, he often has to use tools from many different places to put together the solution they require. He would love to have the ability to ‘build’ a site that would meet his client’s requirements, however his technical skills are not great – for example, he can edit some PHP code to get it to do what he wants, sometimes, but he can’t write much from scratch. He understands what CSS is and what it can do, but he’s never written much himself.
Jeremy has friends who are developers and professional designers and he can call on them for some assistance. He heard of Drupal a few years ago at a social networking event and tried downloading and installing it but didn’t get very far and his general reaction to Drupal now is ‘it’s scary’.
What Jeremy Wants: the ability to build sites with rich functionality and flexibility without have to write code.
Note: these are not formal personas, they are just quick ‘sketches’ drawn from the research we’ve done to date (since August 08) that we hope will assist you to evaluate D7UX interface design.
What about the developers?
Good question. We do care very much about the Developer Experience (DX) but we also know that many developers are perfectly happy with Drupal the way that is is (as long as they have the Admin menu installed) and that they, of all people, know that essentially all Mark & I are doing is ‘theming’ the admin and that they can override this with ease. We’re not doing anything to The Way Drupal Works that will inhibit their ability to do all the amazing things they do now, and more in the future. Having said that, we hope that they are pleasantly surprised by the interface and might even consider keeping it. Or, perhaps, at least part of it. And in particular, we hope this buys them more time to do what they’re great at – development work – rather than spending that time training and supporting people who know (and need to know) Drupal less well.
Here’s a rough transcript of the video content, if you read this you won’t miss out on any content covered in the video:
It’s been a little while since our last ‘update’ so we wanted to check in and let you know what we’ve been up to on the project in the past couple of weeks.
We’ve been moving through a transition in the project from the high level, strategic ‘iteration zero’ (in Agile terms) phase of the project to a much more detailed, tactical, concrete phase. Until now there’s been lots of thinking and communicating ideas, now we’re moving into a phase where we need to get our heads down and plough through a lot of detailed work, and we’re finding it harder to get the time to give updates. Part of the way to address this was the creation of the Project Framework and there have been lots of little discussions going on in those threads, but we do need to find a better way to communicate regularly these more granular pieces of work – stay tuned as we figure out the best way to do that (and we welcome suggestions of course!)
Mark describes this phase with a diagram (of course), that show the communication decreasing as the fidelity increases (and us at the cross roads) – it’s not something we’re happy with, so we’re working on it.
There has been work a-plenty though, starting with a great workshop we had over two days in London in late April – Jeff Noyes and Jason Reed (the Acquia designers), Roy Scholten (yoroy) and Dries gather round a table with Mark & I to work on the D7UX design work and see if we could break it. Jeff has a great write up of the workshop here and I managed to grab a tiny bit of video for you (of course!)
Since then, I’ve been working on defining the interfaces and interactions in some wireframes and Mark has been working up the visual language, and we’ve started working with the engineering team at Acquia to start getting this built. We hope to have something that you can touch and feel in the not too distant future (how exciting!) This is just the beginning of the journey and we still have a lot of refinement to do, and the whole system will continue to evolve as we work through more challenges and learn more and more.
In the wireframes we’re identifying a whole stack of ‘needs attention’ issues – these are things like ‘the WYSIWIG menu needs special UX attention’, ‘the idea of a media library needs special UX attention’ – they are kind of smallish chucks and fairly modular and we’re hoping that we might be able to throw these out into the community and ask for your help to take the lead in working through the details of these kinds of challenges. We’re not sure of the best way to engage/manage this – your thoughts and guidance would be appreciated (issue list seems the logical place, but is it?)
In the next couple of weeks we’re going to get back to focusing on usability testing and user research in a much more regular way. We’ve kind of dropped the ball on Crowd Sourced Usability Testing in the past few weeks (and in retrospect our schedule was pretty aggressive) but once we have a working prototype it will be much, much easier for us (and you) to be much more active in continuing to test and gain insight into what is working and what needs refinement in the interface and overall User Experience (UX). (by the way, did you see that WordPress have just opened up usability testing to their community as well? interesting huh?)
So, that’s about it for now. Expect plenty more from us in the coming weeks. And, as ever, let us know what you’re thinking and don’t forget to keep track of what you’re most interested in through the comments and content in the Project Framework.
We’ve said lots of times that we’re really interested in accessibility and that we’ll be keeping accessibility issues and guidelines in mind as a part of our user experience design process for D7UX, well, I’m happy to report that we are really kicking that into gear, and we’re starting by having a big pow-wow with a really expert in the field. We’re going to be spending We spent the day on Wednesday (13 May) with Ann McMeekin, an Accessibility Expert who is also an invited expert on the Authoring Tools Accessibility Guideline Working Group (AUWG). Ann is going to give us some advice on how we can contribute to making Drupal7 compliant with the impending Authoring Tool Accessibility Guidelines (ATAG) 2.0
We’re going to open up this thread to discussions around Accessibility, but first up I’d like to ‘open the floor’ to you all and give you the chance to your thoughts/issues/ideas/questions through to Ann for her consideration.
So, if there’s anything you think that you’d like us to ask Ann, or to draw her attention to, the please let us know in the comments below and we’ll include it in our discussions on Wednesday and be back here with some feedback! Ann can take a look and give you her feedback or make sure it’s being taken into account where appropriate.
Rough transcript of the video (so that you don’t have watch it if you’re not so inclined):
introducing Ann, a freelance accessibility consultant with about 5yrs experience, previously at RNIB . She helps people make websites better for people with disabilities and in turn for everyone
Why get Ann involved so early? Accessibility like Usability quite often comes to the table far too late. Ann thinks it is a great opportunity to get involved so early so that she can direct the design and production effort rather than having to ‘audit’ and require ‘rework’. Ann is able to pick out things that look like they might be problem areas so that we can design things in the best way to support good accessibility.
Ann has reviewed a lot of the work done to date – her initial feedback is that so far there is nothing she’s seen that has made her throw her hands up in horror. She thinks there are some really interesting things going on in what we’re doing to try to create a rich experience, but this can be challenging, but the work she’s seen so far has scope for the implementation to work for everyone – she’s confident we’ll be able to create a good UX for everyone.
Authoring Tools Accessibility isn’t just about having a system that is accessible, it’s also about designing a system that helps people make good decisions about accessibility as they are building sites using Drupal. (Which is v familar to our design principle of helping people make good design/UX decisions when making sites with Drupal).