Archives

Category: Strategy

We’ve talked through the ‘strategy’ behind the proposed D7UX Information Architecture (IA), now let’s take a look at it in detail. What goes where.

Let’s go through each major section in turn:

Content

The ‘Find Content’ page, showing a searchable, sortable, filterable list of all the content on your site is the ‘landing page’ for the Content section of the site. From this page you can also choose to Add Content (although it is suggested that for Content Creators this also be shown as a Shortcut on the Toolbar).

Different types of content can be filtered into different tabs, as comments are, for example, on this page. You may also wish to provide separate tabs for content such as Products (if you have Ubercart running), or Events or Projects

Structure

This section of the IA groups together tools used to ‘build’ content for the website which both have and create a User Interface (UI), including:

Taxonomy

Content Types

Blocks

Forums

Books

Feed Aggregator

CCK (Contrib)

Panels (Contrib)

Views (Contrib)

Webform (Contrib)

Note that this page has not had a ‘visual design’ applied to it yet, the image above is wireframe only.

People

The People landing page uses the same content display and interaction patterns as the Find Content/Content landing page, providing a searchable, sortable and filterable list of ‘people’ on your website. As expected, this includes everyone with administrative privileges and registered users, however we also provide to extract lists of users from nodes and show them in this one location (with contextual links to/from the node of course), including even participants, group members etc.

So, for example, if your site was running a series of events you would be able to click on the ‘events’ tab and see a list of published events and an overview of participants (eg. 46/100 attendees) and communicate with attendees in this location rather than having to to the node to perform this function (as noted above, you will also be able to access this list via the node if you prefer).

Appearance

This page is still a work in progress but would show the currently active theme, other themes available for selection and theme configuration options. Any tasks associated with selecting or managing the theme live in this section. As noted in the ‘Strategies’ post, this is not a common task however it is very important in the evaluation and ‘getting started’ process and requires this primary position for wayfinding and positioning reasons.

Config & Modules

Config & Modules (renamed recently from Modules & Config) is a hard working section of the site that houses the less used (on a day to day basis) functionality of the site, but some of the most critical aspects for site administrators.

The first of the two pages in this section is the Config page. There is a ‘status’ message at the top for module updates but the majority of the site is dedicated to making the site administration tasks easily findable. We have approached this primarily by regrouping and sometimes renaming the individual items or their groups for clarity.

The propose content and grouping of the contents of this page are:

People Settings:

Roles

Permissions

Emails (extracted from admin/settings/user for findability)

Registration/Deactivation (extracted from admin/settings/user for findability)

Personalisation (extracted from admin/settings/user for findability)

Other Settings (because there were still a few odd settings left!)

Media

Image Toolkit

Image-Cache (example of contrib module placement in this IA)

Image Field (example of contrib module placement in this IA)

Image (example of contrib module placement in this IA)

Site Administration:

Site Information

File System Path (currently File System)

File Upload Restrictions (currently File Uploads)

IP Blocking

Maintenance

Maintenance Mode

Logging & Errors

Performance

Backup & Migrate (example of contrib module placement in this IA)

Update Status (example of contrib module placement in this IA)

Development

Testing

Search

Search settings

URLs

URL Path Settings (currently URL Aliases)

Clean URLs

Pathauto (example of contrib module placement in this IA)

RSS

RSS Publishing

Workflow

Triggers

Actions

External Publishing

Blog API

Internationalisation

Translate Interface

Regional Settings

Languages

This page will also house a ‘launch pad’ to access the interfaces for major modules that do have significant interface requirements, for example Ubercart, Organic Groups, Projects, and Storm (Project Management). For site that use these modules extensively, the toolbar and dashboard will also provide more direct access into the module interface & functionality.

Reports will become accessible from the dashboard interface.

The other page in this section is the modules page:

This page essentially provides access to add new modules to your Drupal site, and to manage/configure your currently installed modules. Grouping them in with the other configuration functionality removes any ambiguity about where to go for configuration tasks, however it is important to maintain the term ‘modules’ in the global navigation as this is a keyword that people will frequently be scanning for. This modules wireframe is fairly new – to discuss this page in detail pls head over to the Modules page in the Project Framework

In addition to all of this there is a Help section, a Profile Page for the user, a Log Out link and the customisable task bar and dashboard that we’ll talk about in more detail elsewhere. But otherwise, that’s about it.

I know from what I’ve seen of (particularly new) users interacting with Drupal this can make a significant positive difference. I hope you feel the same and, as ever, welcome your feedback.

Designing an Information Architecture (IA) for Drupal is an incredibly challenging project – essentially you are trying to design an IA that allows just about anyone to do just about anything. Flexibility is very often the enemy of good design – people make good and fast decisions with fewer options not more – but how do you choose the right options so that they work for as many people as possible? Tricky stuff.

To give you a sense of the breadth of the scope – we need to design for both:

people who use Drupal every day (efficiency & capability is key) and people who are brand new (evaluators & learners – does this make sense to me, does it appeal to me, will I be able to use it to do what I want?)

Verity, the content creator (ref: Who Is D7UX for, very limited set of tasks but very frequent use) through to existing power users/developers (know Drupal inside out and don’t want the UI to get in the way)

In devising the proposed information architecture we have applied the following principles/philosophies/guidelines:

less clicks is not necessarily better: some of the early feedback we have had to the IA has been along the lines of ‘but I can get to this in one click using the Admin header now – this means I’ll have to make 3 clicks, therefore the IA is not as good’. The number of clicks to content is actually a poor metric of information architecture usability. Much better is the number of mistakes made – people don’t mind clicks if they are not lost, if they are confident that they are getting closer to the content/functionality they seek. Our information architecture is designed to support wayfinding and reduce errors in a system that can grow incredibly large.

few options shown = more decisions made: at the moment, Drupal tends to show all of its options all of the time, this is incredibly overwhelming for many users. Generally speaking, as humans we do really well at choosing between say 3-4 options, and very badly at choosing between 24 options. We want to ‘break down’ the decision making as much as possible by grouping things together well and using good (human friendly) labels.

group & order by frequency of use & complexity – tasks that are performed with high frequency/repetition are very different to tasks that you do only occasionally, especially in Drupal.There are many differences between ‘adding content’ and changing the file path for uploaded files.The more frequently I perform a task the more familiar I become with it, the more I become interested in efficiency (being able to do it more quickly), the more skilled I am at performing that task. So, for adding content, what we want to do is move anything out of the way that will impact on efficiency. If I make a mistake adding an article I can very quickly recover that mistake without significant systemwide impact.Tasks that I perform infrequently (like setting the filepath for uploaded documents) are very different. I am going to have to find the location of this task again (as I won’t ‘remember’ where it lives most likely), if I get it wrong it could have a significant impact systemwide. Accuracy is very important.We have placed the very frequently accessed tasks at one end of the IA (Content) and the less frequently at the other end (Config & Modules) to aid both findability and to support the different ‘postures’ that users have for these different tasks.

Walking through the top level navigation:

Content: This is where you Add/Edit and Find content, including comments.

Structure: This is where the ‘builder’ tools live – things that both have and create UIs, for example Blocks, Menus, and contrib modules like Panels and Views will live here.

People: Similar to Content, this section allows you to Add/Edit and Find People on the site. People includes registered users and admins, but also lists of people extracted from content types (event participants, group members) – this is a kind of new concept so stay tuned for more details to follow.

Appearance: Themes & Theme Config. This link is largely designed for ‘evaulators’ and new people to Drupal, as we know that Theme management is not a regularly accessed but is one of the first things that people look for and explore when ‘getting started’ with a content management system so we need to make it very findable (and also to send the right messages about Drupal and our attitude to design)

Config & Modules: This is where you’ll find the configuration functionality that you access once in a blue moon (or possibly only the once when you set up the site) – we’re going to pull things like ‘roles’ and ‘permissions’ out of ‘people’ and put it over here (this is an example of the group & order by frequency of use & complexity principle). You’ll also get a full list of the currently installed modules, link to install new modules and ability to update/configure modules as well as a jumping off point for some of the major modules that require their own signficant interface, for example Ubercart.

Hack Your Own Experience:

There are so many different kinds of Drupal end users and Drupal sites that we need to provide an easy way to configure the interface to support your particular use case, and the way we are doing this is by allowing you to configure a set of ‘shortcuts’ on the taskbar (the icons below the header) and to configure a set of widgets for your dashboard (the first screen you see when you log in and accessible from the dashboard). So, for example, if your site was an online store, you might have dashboard widgets showing your latest orders, and a taskbar shortcut to your catalogue.

Next: I’ll be posting a detailed section by section analysis of the information architect and what goes where.

This is the first in a series of posts discussing the proposed information architecture (IA) for D7UX.

Before we get into too much detail, be sure to check out this great video that Roy Scholten (Yoroy) posted recently that helps explain some of the key features and rationale of the IA and how it relates to the current Drupal information architecture.

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.

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.

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.

TasksNow 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 youFinish 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

A big thank you to everyone who provided feedback on the first draft of the experience strategy – your input was very thoughtful and insightful and we have made great use of it to draft this second version of the strategy.

We think this is getting very close to a strong and workable experience strategy. Please take a moment to read through it and let me know what you think!

Drupal7 Experience Strategy & Goals V2

our objective:

To make Drupal a tool that is powerful and flexible for content creation and management even for people who don’t write code or speak Drupal-speak without compromising the ability for developers to do their work. Drupal will allow anyone to create complex websites without developer knowledge.

our design principles:

Make the most frequent tasks easy and less frequent tasks achievable.

Design for the 80% of current and potential Drupal admin users – 80% of users will only use 20% of the functionality. (Hat tip to Pareto and his Principle)

Privilege the Content Creator

Allow for customisation but don’t make the end user do all the work, make informed and thoughtful decisions about the good default settings

our goals:

non-coding, non-Drupal experienced users should be able to add/edit and otherwise manage content without confusion, errors or extensive training.

people should be able set up a site and publish content without having to go into a ‘configuration/setting/options’ type section

the interface should not get in the way of the developers doing developing (and configuring and other administering) work.

Mark & Leisa’s Personal Goals:

be so in love with Drupal UX that it becomes our tool of choice for content publishing