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

Breaking the silence – what we’ve been up to!

Posted: May 13th, 2009 | Author: | Filed under: Process | 7 Comments »

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.
Fidelity Vs Communication

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?)

Finally, we’ve started working with an awesome authoring tools accessibility expert  Ann McMeekin, to help ensure that we’re making Drupal7 an amazing user experience for *everyone* – especially given some of the more ‘fancy’ interactions that we’ve been proposing – there’s a new section of the Framework for Accessibility and I’m pleased to report that Ann is pretty happy with the approach we’ve taken so far and working with us to help take advantage of some of the newer interface options available to us thanks to ajax and JavaScript without negatively impacting the UX for those of us with special needs.

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.


7 Comments on “Breaking the silence – what we’ve been up to!”

  1. 1 sun said at 8:09 pm on May 13th, 2009:

    HEADER

    2.0: “Show to all, some items may be disabled for particular user types.”: Not possible, information disclosure. If you only grant your users permissions to something, you don’t want them to see more.

    5.0: “closes the lower layer (shortcuts) of the header”: Where is it opened then?

    ADD CONTENT

    1.0: Bear in mind that we don’t want to preload all available contents that can be added on every page. On hover/click will have to load available contents first.

    That said, 20 is a nice “attention” warning. ;) The reality can quickly be 200+ available contents. More and more Drupal modules are exposing their content as re-usable and configurable contents/”panes”.

    ADD CONTENT OVERLAY WINDOW:

    Major issue: Note that overlay windows (proper name: modal dialog) can only use 100% of the available browser window height. There can be more content fields than in this simple mockup. So, when using a modal dialog, it needs own scrollbars. Content can overflow both in width and height.

    ADD CONTENT OVERLAY WINDOW – META PAGE

    4.0: Layout/Design of meta stuff should use the new and shiny “Vertical Tabs” that have been added to core recently.

    VIEW/FIND CONTENT

    5.0: Select all: Addition: Should insert a new data row at the top of the table to allow to “select all items/results”, meaning: not just those that are visible, but *all* content the current filters apply to.

  2. 2 eigentor said at 2:20 am on May 14th, 2009:

    The best way to engage/manage the community in the “needs special UX attention”: look out for initiatives already alive and kicking.

    What instantly to my mind is the media module http://drupal.org/project/media http://groups.drupal.org/media which takes care of unified media handling and has got serious developer power behind it. Though they could need some nicer wireframes… ;)

    And there is more…

  3. 3 Leisa Reichelt said at 4:25 am on May 14th, 2009:

    Brilliant! This is exactly the kind of feedback/direction we’re after and, you’re right – the media module looks like everything we were thinking of and then some added goodness.

    Any more suggestions like these gratefully received :) (perhaps I should surface all the ‘attention required’ issues in the wireframe and tackle it that way).

    To the second issue of recruiting UX people to help work on wireframes for modules like this – I don’t really see much of that happening now. Any ideas around how we can better support it?

  4. 4 Hilde Austlid (zirvap on drupal.org) said at 5:41 pm on May 14th, 2009:

    I like the header. I hope site builders will be able to customise it, and to have different versions (with different default sets of bookmarks/shortcuts) for different roles. Preferably, it should also be possible to turn it completely off for some roles.

    I don’t like the content creation wireframe so much. Some comments:

    I agree with Sun: Vertical tabs looks a lot more useful than a separate meta page for these settings.

    Categories/taxonomy should be on the main content creation page. In most use cases I can think of, tags/categories is something users want to add almost every time when adding new content, for content types where taxonomy is enabled. So going to a separate page for this seems clumsy.

    The “add content type” link doesn’t belong here, in my opinion. For most use cases, content types are created by the site builder, after (hopefully!) thinking deep thoughts about the types of information on the site, and how to show them. It’s something that’s done much much more seldom than creating content. So a prominent link to a little used function is likely to add confusion, and result in lots of extra content types.
    This can, of course, be solved by not giving most users permission to create content types. But I make sites for small clubs and festivals in my spare time, and then I need to hand over the reins, and the full admin power, to people who don’t have very much Drupal experience. I handle this by:
    - making blocks for them with customised admin menu for the most usual tasks
    - giving them full permissions to do (almost) everything
    - giving them a test copy of the site where they can go bananas with their admin super powers
    When doing their usual tasks, like posting content, I want them to only see what they need for that. Advanced site builder options like content type creation is something I’d rather not shove into their faces — that’s something they can find when (if) they feel adventurous and go exploring.

  5. 5 Leisa Reichelt said at 5:11 pm on May 19th, 2009:

    Sun, thanks so much for this feedback, it’s great. I really appreciate you taking the time to look through the wireframes and give your thoughts. A few thoughts in response.

    Header
    2.o Show to all disabled to some – are you saying that it’s not possible to do this in Drupal? The idea would be that you could see the menu item (so you know it exists) but that it is greyed out (so you know you don’t have access to it, need to find someone with greater access levels than you to get it done). I’m not convinced it’s a great idea from a UX perspective… would welcome more thoughts on that.

    5.0 where is it closed? an excellent question – the open will turn into a close switch – stay tuned in the next release.

    CONTENT
    1.0 I’m actually not a great fan of the ‘on hover’ menu, but others are so I’ve got it in there to be usability tested and we’ll see how it goes. Good point re: scalability tho’. I’d be interested to know what the average number of content types per Drupal site is… (in fact, I might ask that to the world!)

    ADD CONTENT OVERLAY WINDOW
    Actually, these are really more ‘overlay windows’ than ‘modal dialog’ windows, and we plan to implement them so that the overlay will set the length of the page, so I don’t think this will be a problem. It’s a good pick up re: considerations for this approach tho’, and again, important to consider scalability.

    ADD CONTENT – META
    We’re looking for the right way to use Vertical Tabs. Personally, I don’t think the Meta page is the best place to do that, as we’re really working to improve the scalability of what can be a pretty intimidating set of options… I think there is a chance you’ll see some vertical tabs action in coming wireframes or page designs soon.

    VIEW/FIND CONTENT
    Select all items not just those visible. This is another good point. I wonder if this should be the only setting available… is there a strong use case for only selecting the visible results do you think?

  6. 6 Leisa Reichelt said at 5:14 pm on May 19th, 2009:

    hi Hilde, thanks for your feedback. A few thoughts in response.

    - my thoughts on Vertical Tabs are above (in response to Sun’s feedback).
    - I think I agree that tags/categories can go on the main content creation page – the process we’re going through is to pare things back as much as we can and then gradually add things back in – it strikes me that this is a logical add.
    - I also agree re: add content type link. It’s coming out

  7. 7 sun said at 2:24 pm on June 2nd, 2009:

    HEADER

    2.0 Disable but display inaccessible links: As of now, Drupal does not know and support this concept. We have to bear in mind that this would have to work globally. So users would see all kind of menu items and links that are disabled. I see your point though. However, from a technical perspective, it is a major security issue — most often, you do not want your users to see things they are not allowed to see. That’s the purpose of permissions. If the system starts to display stuff a user should not be able to see, access, or view, we are in deep trouble. On top of that, it is also a design/theming issue: Such disabled links could not be links at all.

    CONTENT

    1.0 Number of contents: I think there is a discrepancy in what we call “content”. The mockups I can see here make me assume that “Add content” will allow me to add content on the very same page I am looking at. (Why should that link be displayed that highlighted in the header otherwise?) So, content of a certain content-type is not the only thing I can add to a page. I can add blocks, views, etc. That’s why I referred to “panes”, which is a term of the Panels module, and describes a piece of content one can add to a region on the page. While you can have 10-20+ regular content-types, you can easily have 200+ of re-usable panes that can be added to pages.

    If those “Add content” / “Edit content” links are not supposed to add/edit content on the currently displayed page, then I highly believe that they are placed wrongly. The suggested location implies that the user can add/edit content within the context of what he/she currently sees.

    VIEW/FIND CONTENT

    Yes, there is a difference between selecting all visible and all possible items in a view. The first is what a user expects to happen if “Select all” is ticked, and the user then goes on to “Delete all”. A major “WTF” if the user suddenly finds out that ALL content of the selected criteria has been deleted. However, there are also many cases in which you really want to select all (ANY) items that match the current criteria.

price of yellow sapphire | college essays | help essay