Many thanks to everyone who participated in this project.]]>
Maarten Verbaarschot volunteered to take on a Microproject (thanks Maarten!) and for the past few weeks he has been working on interface design for a Media Library for Drupal. There is a great discussion going on in the Drupal.org issue queue that you might want to take a look at.
Maarten is currently working on the third iteration of these wireframes but he’d really love it if you can take a look and give him some feedback – anyone who has ever added an image to a web page should be able to have a say on this interface, so don’t hold back!
In particular, Maarten is looking for some user stories where users would be uploading content using this Media Library interface rather than uploading whilst in the process of creating a ‘node’ (story, article, post etc.). I know I have a couple but if you do also perhaps you can share them in the comments below or on the issue queue thread (if you’re a member of Drupal.org or would like to be!)
You can see the work that Maarten has done so far here:
* Iteration 1: http://www.flickr.com/photos/mverbaar/sets/72157620755726297/
* Iteration 2: http://www.flickr.com/photos/mverbaar/sets/72157620894822174/
* Iteration 3: http://www.flickr.com/photos/mverbaar/sets/72157620894824094/ (in progress)
We really look forward to your feedback (here, on the flickr photos, on the issue queue, wherever is most comfortable for you).
Thank you Maarten for all your hard work so far! You rock!
And thank you to Maarten’s employers, Merge, for sponsoring a week of his time to work on this project. You rock too!]]>
Let’s go through each major section in turn:
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
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:
Note that this page has not had a ‘visual design’ applied to it yet, the image above is wireframe only.
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).
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:
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.]]>
To give you a sense of the breadth of the scope – we need to design for both:
In devising the proposed information architecture we have applied the following principles/philosophies/guidelines:
Walking through the top level navigation:
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.]]>
Before You Begin
Structure and Markup
Orientation and Way-finding
To kick there projects off I’m creating a home for them over in the Issue Queue on Drupal.org, but I’ll create an index of them for you here so you can dip in and out as you please
Please also feel free to leave any general feedback about the overall Microproject concept/framework as a comment to this post.
Active Microprojects: (in no particular order)
Note – there are still quite a few more waiting to come online, as time permits – I’ll update the comments below as more are added.]]>
Thank you to everyone who participated in the Summit on Sunday – there were several dozen people in attendance and it was a very productive session.
A transcript of proceedings can be downloaded here PDF (note: it’s about 150 pages of Skype chat, so only do this if you’re feeling brave/bored/exceptionally curious). We also tried to keep a document of record showing our agenda, some outputs and an incomplete list of participants, which you can see here. It is not entirely comprehensive and should be considered a working document only.
The discussion around the overall outcome for Structure continues and we will post an update soon.
The essential information Our mission: to come to an agreement on whether the Site Building Tool should be included in D7 and if so, how we can best make it work for both the Drupal technical architecture and existing Drupal users AND for it’s primary target audience.
Should you choose to accept this mission:
I’m really excited to report that Ivanka Majic, Head of Design at Canonical, will be moderating our Summit on Sunday. Ivanka has a great appreciation for the challenges of designing for open source projects and a vested interested in D7UX being a good user experience, because the Canonical site is running on Drupal! She’s also a great moderator and I’m confident she’ll help us to ensure that we get to some firm and actionable outcomes on Sunday. Thanks Ivanka!
If you have the chance beforehand it would be great if you can check out the two most recent ‘prototype’ walkthroughs that we’ve posted (video see below), as well as the Project Framework Page for Structure.
A little background. If you’ve been playing along at home you have no doubt come across the Site Building Tool that we have proposed to live in the Structure section of the D7UX interface. We believe that the design and implementation of this tool can make the most significant difference in making it possible for non-technical users to make a reasonably sophisticated site using Drupal within a matter of hours, not the weeks or months that it often requires of new players at the moment.
The more time I spend talking to people who *should* be able to use Drupal but who can’t, and people who have had brief experiences with Drupal then ran away screaming in either frustration of fear, the more convinced I am of this. As recently as yesterday I took our latest prototype out to show some people, and despite the fact that it is still very rough and confusing, it’s potential was obvious.
We’ve been talking about this tool since early April – time is passing rapidly and if we want to make this happen we need to get on board with the concept and start working out how we can make it work. We need to do this as a matter of urgency. Our current channels are not moving us forward quickly enough, so I’m going to propose that we try something a little different.
Structure Summit Sunday
The absolute best way to get to the bottom of these complex issues is to get everyone in a room to thrash it out. Of course, we can’t all get in the same physical space together, so let’s try the next best thing and all meet this Sunday with the express purpose of coming to an agreement on what this tool can be and how we can make it happen.
I want to walk away from this session on Sunday with a clear vision for the tool and a feeling that the people who participated share this vision and our enthusiasm for the challenge ahead. (Of course, the flip side is that we decide that we can’t do it… which would be unfortunate, but I guess we have to consider it as an outcome).
I considered a bunch of ways to approach this, originally thinking that we’d do it in IRC, but with some more thought I’ve decided to create a public Skype chat that we can all join. This is a less intimidating environment for non-techy, non-Drupally people (and I’d really like to have a good mix of all of us in the discussion).
You can join the public chatroom on Skype using that link but we’re not really going to get the Summit going until 16:00 GMT on Sunday 7 June.
Why should I get involved if I’m not a Drupal developer?
Please, please, please come join us and help make this happen. The saddest thing of all would be if a good idea died because we didn’t act on it quickly and decisively enough.]]>
People have asked about who will see the proposed D7UX Admin header. I wanted to take a moment to talk about that and about Drupal default ‘roles’ and get your thoughts.
For those who aren’t familiar with Drupal here’s a quick overview that I copied from a Drupal 6 installation:
Roles allow you to fine tune the security and administration of Drupal. A role defines a group of users that have certain privileges as defined in user permissions. Examples of roles include: anonymous user, authenticated user, moderator, administrator and so on. ….
By default, Drupal comes with two user roles:
* Anonymous user: this role is used for users that don’t have a user account or that are not authenticated.
* Authenticated user: this role is automatically granted to all logged in users.
Clearly, to begin with, we’d be proposing that the Admin header is shown only authenticated users – that’s obvious enough!
I’d now like to introduce another concept that seems natural to me and to many others that I’ve spoken to about this (although perhaps not so much to experienced Drupal users) and that is a default differentiation between ‘Member’ and ‘Admin’.
The idea being that the Member role or roles based on the Member default are for people who have ‘signed up to’ or ‘registered with’ the website (as a member) in order to participate more fully either by creating content (submitting a session idea for a conference, a discussion post to a forum, that kind of thing). The Admin role and roles based on the Admin default are for users who have a closer association with the website – the website ‘owners’ or ‘managers’, the people to whom we’re happy to show the ‘underwear’ of the website. Admins would see the Admin Header but Members would see their tools and admin menu in the page context.
Now, of course there are many, many variations on roles that need to be created and sometimes the differentiation between whether or not a role should be a ‘member’ or an ‘admin’ is not clear. I think there is an inherent guide in the name ‘member’ that should be helpful – a member has a particular kind of relationship to a site and there are kinds of content and functionality that is less appropriate to a ‘member’ and more appropriate to an ‘admin’. There is sufficient flexibility in the system that means you can make a call whichever way you think is appropriate to your particular scenario, and to change your mind later if you like!
This is not dramatically different to the way that many Drupal sites work already and almost all of the infrastructure required already exists and just needs a little spit and polish. No architectural changes are required to achieve this – it is really a tiny and superficial, but from a user experience perspective I think this will make a significant difference in helping people understand Drupal roles and how to best implement them.
What do you think? Any questions?]]>