Possible Usability projects?

Events happening in the community are now at Drupal community events on www.drupal.org.
bonobo's picture

This idea came out of a conversation Bevan and I were having at DrupalCon -- maybe it's crazy talk, but maybe it'll work.

Identify and isolate admin features; for example, creating forums, which currently requires a few steps, and knowledge of containers, etc. Analyze the workflow/mouse clicks required to build this functionality. Then, create a wireframe of the admin functionality that simplifies the task. Then, create a helper module that builds the streamlined, more intuitive UI

Ideally, we (and when I say "we" I mean interested members of the community) would identify areas that are in need of this type of streamlining. I think that by limiting our scope to functionality exposed in the core of D6 we could identify a series of what I'll call UI bottlenecks -- places where the number of mouse clicks/process/steps required to do something simple (like adding a new content type) feels onerous.

We could use the data from the recent usability work as a starting point.

Maybe we could also do this for CCK?

If we could pair two mentors -- one more design/UX oriented, one more code oriented -- with a student, we could ensure that we'd get a clean set of wireframes alongside any coding support needed to actually code the UI.

I recognize that this writeup is pretty scant, but I wanted to throw this out there as a possibility. If there is interest in going down this path, I'd be glad to flesh this out in more detail.

Thoughts?

Edit Added to Usability group

Comments

Bevan and I talked about a

boombatower's picture

Bevan and I talked about a usability API or framework of sorts with a pluggable backend. I believe he was going to type something up, so I'll wait for that, but I am definitely interested in working on that.

I have already created Click Heatmap module that would server as one of the first backends.

Just remember that it's "Summer of *Code*"

webchick's picture

So while the project could start with wireframes, at the end of the day they need something actually coded up and turned into Google. And I have a feeling that if the project was 80% design and 20% code it might not qualify.

Try fleshing this idea out a bit more (picking a specific area/areas and specific goals) and let's check again and see if it looks like a good project. :)

Plans

boombatower's picture

Bevan said he would write something up, so I'll wait to make sure that I understand everything correctly.

If we are on the same page then there will be a lot of coding to be done.

Jimmy, See

Bevan's picture

Jimmy, See http://groups.drupal.org/node/9661

Please take this over from here. I can chat with you to help you develop the project proposal, and will likely (not definitely) be available to mentor the project.

Bevan/

Other large usability issues

Bevan's picture

Other large usability issues that could possible be turned into GSoC pojects are:

  • Block configuration. Reaching consensus on the solution (discussion and wireframes/mockups) isn't too much work, but implementing it (code) is. so this is a good candidate
  • Module interface. Reaching consensus will be more difficult here, and code is less, so perhaps not such a great GSoC project
  • Separation of admin from 'what users see': Essentially this is an admin theme, but there is a considerable UI design and consideration that needs to go into this
  • Make help searchable. Not sure of GSoC worthiness
  • Add contextual help to FAPI. Not sure of GSoC worthiness
  • Fixing local_tasks; Splitting them into actions/operations (buttons) and navigational elements (tabs). This is a mighty task.
  • Better api and theme functions for managing objects in tables. See #5 in http://groups.drupal.org/node/7965
  • Bring back glossary in help. Not sure of GSoC worthiness

I don't have time to turn these into project ideas or proposals but would be likely be willing to be secondary mentor.

Bevan/

Can we also add this thread

Bevan's picture

Can we also add this thread to the Usability group?

Bevan/

Bill, we lost the GSoC group

Bevan's picture

Bill,

we lost the GSoC group there. :(

Bevan/

Currently in two groups

bonobo's picture

Hello, Bevan,

The post is currently in two groups; usability and SoC 2008 -- is there another group where I should add this?

Cheers,

Bill


FunnyMonkey
Tools for Teachers

Desperately seeking proposal...

webchick's picture

I'd love to add this to our official ideas list, but we need a plan. Anyone willing to write this up in proposal form?

alex_b's picture

I am really thrilled by the recent pushes in improving Drupal's UI - one thing that I am concerned by though is that a lot of the UI improvement discussion focusses on the 'site builder end' of Drupal - with site builder end I mean specifically whatever's under /admin : module page, block page, content construction, etc.

While this is an important part to improve (I am having some blatant shortcomings presented at DrupalCon Boston UI session in mind), I am much more worried about those parts of Drupal that I, as a site builder, need to expose to editors and contributors of the site: the node form, the help pages, contact form, user sign up forms, emails that get sent out etc.

I am usually more working in system architecture and planning, but this weekend I built a D6 site for my building's Tenant Association and while I found a frickin awesome theme (marinelli :) and the install process of D6 looks pretty slick, explaining the node form to my neighbors made me sad and improving it had cost more time than I had available :(

Alex

http://drupal.org/project/nod

stevebayerin's picture

http://drupal.org/project/nodeform could have helped with that. What solution/improvement did you end up using?

Although we'd all like to

catch's picture

Although we'd all like to see the node/add/edit form improved, I think that'd make for a beast of a GSoC project. There's a lot of opinions on how it should be fixed (see the Usability group for some) which is good, but not necessarily for a student.

Also, a big part of fixing it (IMO) is going to be fields in core - which I hope is going to unify things like menu and taxonomy widgets and the rest - at the moment there's at least three ways to add something to the node form, which makes it pretty unpredictable.

agree with alex

benc's picture

Alex, I agree with you.

What's important for me is to improve usability for the "end users" -- the content contributors, forum members, etc.

However, there are also some features of Drupal that, if we make them easier to use, will result to empowering end users more. For instance, if we make cck easier to use, then administrators (or site builders) may be able to delegate this task to ordinary users. More importantly, even non-techies will then be able to use cck more easily :)


The Power of Drupal Categories
A Podcast for Mac Switchers

How about this

beeradb's picture

Sooo, I was brainstorming the other night and came up with what I think would be a really helpful tool in being able to assess usability.

I'd like to see a web interface in which a group of privileged users have the ability to quickly and easily set up a environment to conduct usability testing in, and have all the data automatically captured in some useful way. Here's a basic walkthrough of how I would (hopeful) see this working:

I'd like to see some sort of a control panel where a test administrator can select the version of drupal they'd like to conduct usability testing on, and have it spawn a virtualhost instance, with the selected version of drupal installed along with a module set which helps capture data (clickheat it the main one i'm thinking of here, but i'm sure there are other candidates). The site would then being capturing data as the test administrator conducted testing, allowing for a method to easily reset to the default state between users. At the end of testing the testing site would generate the clickheat results and partitioned server logs for each user, and then wipe itself from the file system/apache.

Ideally the testing tool would be able to grab head from CVS and apply patches as well, so we can easily conduct usability testing on patches which we think will effect usability. However I don't know what the feasibility of having testers using HEAD really is, hopefully 100% testing coverage would make things stable enough during the development cycle that we could give it a try, but the current state of HEAD isn't such that you could put a novice user in there and ask them to perform tasks, because things would be broken. It may be a pipe dream, but it's at least a good goal.

Anyway, just a thought, certainly details need to be flushed out, but the general idea it to be able to REALLY quickly set up a testing environment, so we can concentrate on the problem of getting testers, and not on all the details of setting up the environment etc. I think this would go a long way towards making usability testing a constant process.

sounds like this:

catch's picture

Which is already a GSoC project proposal: http://groups.drupal.org/node/9661

UI tweaks without a module

wfx's picture

Is anyone aware of a list of UI tweaks site builders can do for "end users" right out of the box? Without using a special module I would like to know simple things some of you have improved usability. I'm sure this will be as simple as "hide this field for this user role" but I'm sure there are common things you're disabling for your basic joe-schmoe content contributer with each new website. Thanks in advance for any useful tips.

Hi, the first thing I would

juliavdw's picture

Hi, the first thing I would do is hide the admin menu and build a custom dashboard so your clients only have access to certain tasks. this can be configured per role if there are multiple roles. As for which things to hide, it really depends on your client and what they require. Some may only want to edit and create new content, where others may want to move menus around and stuff.
I also like having an admin theme which is distinct from the front end theme, so users know they are "behind the scenes".
Of course, as a custom site developer, each site is different, so for me it all depends on the client's specific needs.
If you find that you are doing the same thing for all your sites, you may want to put your admin changes into a module or maybe a feature.

Thanks

wfx's picture

Thanks for your suggestions, I always like to get different perspectives. It's interesting that you go with the "behind the scenes" admin theme approach. I do that as well. Our department will be moving to Sharepoint 2010 for our intranet solution and at a training the Microsoft rep was talking about how fluid it was and how you can't tell when you're in editing mode. It wasn't bad but personally I like having some division between "normal" and "edit" mode.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: