Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart
Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_3_0
Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_2_0
Description: A global header which would be shown when logged in to the site (for admin roles (site owners) but not site members (people who ‘sign up’ or ‘register’ to a site).
Global navigation is: Content, Structure, People, Appearance, Modules & Config, <Your Name – Profile>, Log out, Help
Current thinking/roadmap:
The top line of navigation is the global Information Architecture and navigation for the adminstration interface. The second line are a short selection of iconographical shortcuts that are customisable per role for fast access to most common tasks
Users are able to toggle the header to show only the top line navigation if preferred.
No use of javascript flyout menus, although admin menu module could be installed to override this if preferred.
The header will remain at top of screen all the time (even when scrolling)
Outstanding issues:
creation of library of icons. Need to define a short list of required icons and perhaps commission a designer to create custom icons for use in this theme (recommended re: GPL)
Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_1_0
To help facilitate the aggregation of discussion around the many and varied aspects of the D7UX project we’ve devised a bit of an infrastructure, which you’ll find below.
Each of the pages below includes an overview of the current state of play and a link to aggregation of discussion around related issues.
1.0 Header (#d7ux_1_0)
2.0 Dashboard (#d7ux_2_0)
(includes widgets for dashboard)
3.0 My Profile (#d7ux_3_0)
4.0 Content (#d7ux_4_0)
(includes Add/Find content and Comments)
5.0 Edit On Page (#d7ux_5_0)
(includes inline editing and other edit/manipulation interfaces on the web page itself)
6.0 Structure (Direct Manipulation Tool) (#d7ux_6_0)
(includes Build/Edit ‘page’, Editors for Block, Content Type, Navigation, Views, and Terms/Categories)
7.0 People (#d7ux_7_0)
(includes add/edit/delete users, roles & permissions, workflow <- moved to Modules & Config)
8.0 Modules & Configuration (#d7ux_8_0)
(all less frequently used config/setting functionality, site settings, module management)
9.0 Appearance (#d7ux_9_0)
(includes find theme, theme builder) 10.0 Configuration (#d7ux_10_0) amalgamated with modules
11.0 Help (#d7ux_11_0)
(includes in context help)
12.0 Palettes & Templates (#d7ux_12_0)
(refers to the palette tool used as an element esp. in Structure) retired this concept
13.0 Installation (#d7ux_13_0
14.0 Accessibility (#d7ux_14_0)
Get your thoughts here:
If you want your thoughts on any of there issues to be picked up, please tag your blogpost, flickr image, youtube video etc. with the tags above (there are also more granular tags for each section if you *really* want to be specific). You can tag your submission with multiple tags if appropriate.
The tagging isn’t particularly human-friendly, so sorry about that. We’ve gone with machine-friendly tags to assist with aggregation and to help encourage humans who are participating to be more precise than we tend to be with more semantic tags
We were really excited to learn of and see the work that the team at Lullabot with Karen McGrane from Bond Art + Science have been doing on their Buzzr project and thrilled that we’ll be able to talk with them about their experience on the project so far.
It’s particularly exciting that there are many similarities in our approaches to solving the user experience challenges for Drupal, and there are some differences as well which will be great to explore further.
We’re going to be comparing notes with the Buzzr crew in the coming weeks and we’ll be sharing some of the insights we gain from that with you here. Stay tuned!
We are really excited to share with you our initial concepts for a D7. Please take a look at the video above and there are LOTS of sketches and paper prototypes that you can explore over on the Flickr group as well.
In this video you’ll see the three key aspects of the D7UX interaction model we are proposing:
the ‘header’ which will be displayed to users who are logged into the site, comprising of a ‘global’ header allowing access to all functionality (permissions allowing), and a customisable/role based set of buttons allowing fast access to the most frequently used tasks (eg. add/edit) or views (eg. find content).the example shown in the video would be for a ‘content creator’ type role. We haven’t completely thought through the application of this header down to the level of ‘site member’ (eg. someone who adds discussions to the forum on the site you’ve built using Drupal), but we think as a concept it has legs.
the ‘overlay window’, the example of which shown is ‘add content’ (in a very sketchy and unfinished state, I hasten to add!). We see the overlay as a fantastic way to provide a clean interface for these tasks whilst keeping the user in the context of the site for which they are performing those tasks, rather than taking them away into an ‘admin section’. Obviously we would need to allow for users who are not using JavaScript (in which case they probably would have to go into more of an ‘admin section’).
the ‘in line editing’ which will allow you to ‘switch on’ edit mode and edit content in place (wouldn’t that be lovely!). Of course, not all content would be editable on the page so the edit view would also allow for a range of ‘editors’ to be launched into an overlay window. We’re imagining: block editors, content type editors, navigation editors, views editors as a start (some of these terms will probably only make sense to Drupallers – apologies for that, will try to translate in future versions)
In the video we also show another idea that we are quite excited about, although we have a long way to go before it is entirely thought through … we’re not entirely sure that it will work, but the problems we are facing with it seem to be getting easier not more difficult, which is a good sign… You could think of this as a Direct Manipulation Tool for Site and Page Structuring. It’s been inspired by some of the tools that we’ve used in the past to do Information Architecture work (hence the use of that word in the initial header that is currently being CrowdTested, yes, it will most likely change!).
The idea behind this tool is that we are able to make site building and page creation a much easier task for people who don’t know and don’t want to know the ins and outs of Drupal’s technical architecture. We’re really excited by the potential this has for achieving our objective of allowing users who are not developers to build complex sites using Drupal… would love to hear what you think of it, and stay tuned for much more work on this component.
We’re looking forward to pushing some of this out for more Crowd Testing very soon. I’d really encourage you, if you’re concerned about what people will make of this, to get involved in the user research – go put it in front of people and find out for real what people do and what’s usable or not. I’ll post another set of materials and scripts for CrowdSourcedUsabilityTesting very soon!
Ok. So, there you have it.
We’ll just wait here, nervously and excited, whilst you have a look…. then, please, tell us how you like it so far!
As we move through the design process for D7UX, every now and then something pops out that makes us think – ooh, that’s important. We should remember that. We’ve started collecting these things and calling them our Design Principles and we’re going to be using these to guide our decision making as we go.
Here’s what we have so far:
Map Drupal to the User not the User to Drupal – Drupal needs to learn how users work and shape it’s interface (although not it’s architecture!) to match user tasks not the other way around
If I need to do something to progress to the next step in my task, I should *never* have to go to a completely different place to do it. The experience should flow – this pretty much follows on from the first principle.
An admin should look like an admin and a website should look like a website. I should always know where I am and what I’m working with. I should be able to switch between the two clearly/cleanly and easily. (We know from user testing done by the Drupal Usability Group that for people newly encountering Drupal this can cause quite some confusion)
allow customisation but give smart defaults – we’ll allow customisation (of course!) but don’t push all the work to the end user. It’s our job, as designers, to take a stab at the best default settings.
wherever possible, help people make good design/UX decisions as they build their site using Drupal – for example, maybe ask them as they reach for their 6th font if they *really* want to do it and explain the implications, similarly as they create their 16th level of navigation…
you should be abe to get Drupal ‘out of the box’, go through the install process and immediately be able to do all the ‘content creator’ tasks without having to go into a section with a name like config/settings/tools
There may be more as we go along. I’d be interested to hear how you like what we’ve got so far and what others you might suggest.
We talked a little earlier about the process we think we’ll be working to for the D7UX project, and we thought you’d like a little more of an idea of what point we’re at with it now, and why we’re doing so much work on paper at the moment, and what we’ll end up with. Mark talks you through it in the video above. The key points are:
we’re moving on from learning/listening (although we’ll continue to do that throughout the project, of course) into ideation – coming up with piles of ideas, rejecting many of them, moving forward with some of them, until we get to the point where we think we have something we like, that works, and that is exciting both in its simplicity and its potential.
we work a LOT on paper at the moment. The main reasons for this are that it is:
a) fast – we can get a lot of ideas down quickly,b) we don’t get precious about our ideas, because we scribble them down so quickly, there’s no time to get overly attached to a bad idea (unlike if we’d photoshopped it up beautifully, or started coding it), bad ideas get thrown away fairly painlessly, and
c) they’re great for user research – at this early point in the project we want to get really honest feedback from people who are looking at our concepts. It’s generally accepted (and certainly has been true in our experience) that if you use low-fidelity prototypes at this stage people are much happier to tell you if they think your idea is rubbish. With a higher fidelity prototype people are more reticent to do this because they assume that you’ve put a lot of thought and work into the concept, this does two things – it makes them not want to offend you, and it also makes them think you must have thought of things that they haven’t yet, so you must be right and their initial reaction must be wrong.
We’re going to be posting our initial concept/direction for you to take a look at very soon, and look forward to hearing what you think of it! We’ll be talking your feedback, the results that flow in from CrowdSourced Usability Testing and our own user research and testing and continuing to iterate the prototype and solve lots and lots of complicated problems as we move through all the requirements that Drupal places on it’s UI.
At the end of the process we are *really* hoping to be able to hand over a ‘library’ of interaction patterns and rules that can be applied by the community as Drupal continues to grow, allowing the intergrity of the User Experience to be maintained within such an organic environment.
So, today is supposed to be our first day of Crowd Sourced Usability Testing – you might have noticed that we’re running a little behind on this, so to make up for the delay and lack of notice – and also because this is our very first go at such an activity, we’ve decided to try to make it a fairly simple task. You should be able to conduct this test in around 15-20 minutes. Please test as many or as few people as you can find the time (remember that you’ll need to allow some time for each person to share your results, which might take as much time again as your test!)
What are we testing:
If you have looked at some of the sketches that we have been working on over the past few weeks (some posted on this site and a lot on Flickr), you may have noticed that a ‘header’ has been quite a persistent feature. This is a concept that we are pursuing. We have a first draft of an ‘Information Architecture’ or navigation for that header. We would like you to help us test how well that navigation is working and where we need to make amendments. Based on these findings we will be able to further refine the navigation.
I have created a PDF document that includes the Header design we’ll be testing as well as a copy of the suggested script for your interview - you can download that here.
When are we testing: I’m going out to do my first round of testing this afternoon, but if you can find any time this week to do a test and submit your findings that would be great (that is by end of Friday 10 April) – we’ll have another task ready for you shortly after then!
Who are we testing:
For this round of testing your interview participants should have some familarity with Web Content Publishing Systems. They do not have to be familiar with Drupal, nor do they have to be Drupal developers. Anyone who publishes content to the web using some kind of content management system is appropriate for this round of testing.
Sample script for your interview:
Your interview should be divided into five parts:
Your introduction
- Start by thanking the interview participant for being involved in the project and telling them how much we appreciate their time.
- Explain to them that we are sharing the results of testing publicly, ask them for permission to record the session on video and to publish the video to the web. (Allow them to be unidentifiable/off camera if they prefer)
- Give them a brief overview of the project (we are trying to find a way to make Drupal a better user experience, especially for people who are not developers). Tell them it is very early in the process and that their feedback will play a big role in helping us get the design right.
- Reassure them that it is the design that is being tested, not them – if they don’t understand something, if something is unclear, if they don’t know the answer or feel they have made a mistake that is a problem with the design that we need to fix, not a problem with them as users!
- Encourage your participant to ‘think aloud’ – if they are considering the answer to one of your questions, to talk you through the how they are making the decision (this is what is most interesting to us – *why* people get to the decision they do, not necessarily which decision they make).
Background information of your participant – start with a simple question about your participant (if you know these already you don’t have to ask them, although it is a nice way to ease into the interview).
- What is your experience with managing content on the web?
- Do you have any experience with Drupal? (if no, what do you know about Drupal, if yes, describe experience)
- (If appropriate, Are you a Drupal developer?)
‘What If’ questions
We are going to work through the top line of the header navigation one item at a time and ask:
‘If you were to click on ‘Content’, what do you think would happen? What would you see?’
‘If you were to click on ‘Information Architecture’ what do you think would happen? What would you see?’
and so on. For each of the items, if your participant seems unclear as to what the navigation item means or refers to, be sure to ask them what the *think* it might mean, and why they think that. For example, we suspect the vast majority of people have never heard of ‘Information Architecture’ but we wonder whether they can make a reasonable guess as to what that section contains.
Tasks Now we are going to run through six quick tasks. Again, pay as much attention to *why* your participant is doing / saying what they are saying as what they actually do and ask questions along the way, encourage them to think aloud. These tasks ask the participant to imagine that they have a company website that they are administering.
- Task 1. – You need to add a new staff biography to your website
- Task 2. – You need to remove an old staff biography from your website
- Task 3. – You want to add a Contact Us form to your website
- Task 4. – You want to give your new staff member access to publish content on your website.
- Task 5. – You need to make revisions to an article you published on the website this time last year.
- Task 6. – You need to make a new product category for the products listed on your website
Final feedback and thank you Finish by asking your participant to give you and further feedback they would like to on what they have seen today, then thank them again for their assistance with the project.
Some Tips for Interviewing
The best way to get good feedback from your participant is if they are relaxed and focused. It is always worth spending some time chatting at the beginning of the interview to build some rapport with the participant (that is, if you’re not already friends!), so that they feel comfortable. Even if they *are* your friend, you should make sure that they know that it is not them being tested, it is the design – never allow your participant to feel ‘stupid’ during an interview. If they are having trouble, ask them to explain what is troubling them, then help them out or move on.
Remember that the most important information we can get from these sessions is *why* people do and think the way they do, not necessarily what they do – continue to prompt them to think aloud and ask questions whenever you see them do something interesting or unusual, or if they are stuck or unsure – ask them *why* they aren’t sure what to do, and to explain what is troubling them and how they are trying to work it out. This information is gold!
Sharing and reporting your findings:
I’ve created a webform where you can submit your findings for each interview you do. You can find it here. (I had hoped to use Google Forms for this, but it turned out easier and faster to do using Survey Monkey. Hopefully in the future we can switch to Google so that the data can be shared with you all more easily.)
You will need to complete one form for each participant, although you’re welcome to just email me your findings if that is easier.
If you are able to video your interview, it would be great if you can post it to our YouTube group (or otherwise, let me know where you have posted it!). Note that YouTube only allows videos of 10mins or less, so you may have to edit your video or, easier still, break it in two as you record it.
This is experimental – your feedback welcome!
As mentioned above, this is the first time we’ve run an exercise quite like this, so there are probably a million ways we can do it better. Rather than labour over trying to get it perfect the first time (which we would never be able to do anyway!) we’re going to go for it, have a go, and see what we learn. You are our guineapigs and we appreciate no end your participation, but as a result, there may be something that don’t work as well as they should. To that end, please let us know what works well and what could be better, and how we might do things differently, and we’ll iterate our process so that the next time and the next time after that are continually improved!
Thank you again for your participation, and do let me know if you have any questions!
Leisa
Recent Comments