Posted by narres on June 4, 2006 at 7:03pm
Once upon a time ... there was an idea to do it here: http://openusability.org/projects/drupal/
What's about these plans?
OpenUsability
Group categories
UX topics
- contrib-ui (41)
- core-ui (96)
- d8ux (18)
- d9ux (6)
- Help system (9)
- nodeform (12)
- Process (18)
- Resources (15)
- taxonomy (3)
- Welcome page (1)
Comments
Hmmmm.... but why not do it
Hmmmm.... but why not do it here? Between mailing lists, wikis, groups, and offsite projects we run the risk of diffusing our efforts. That said, if this location provides something that groups.drupal.org does not, than I'm all ears. Otherwise, I like a drupal.org location -- its an open-source "nationalist" thing.
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
http://www.nicklewis.org
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
The problem is:
A short time before discussing usability at Drupal conference, Amsterdam, 2005 ( http://drupal.org/conference-amsterdam-2005 ), the OpenUsability project was founded.
But it seems, that the progress doesn't go further on.
Although this site is a very central developers ressource and has a real worthy value, it has some disadvantages. Currently we have "only" the possibility to create polls, stories or events.
Well done usability-studies are not only done by discussion and opinions. They need to be verified by evaluation like "user cases", "card sorting", "design guidelines", "interface design patterns". In most cases the improvements are not solved by details (like autofill) - they are solved at a very global level (like site structure).
E.g. module configuration is done at following locations:
- admin/modules
- admin/access/permissions
- admin/settings/throttle
- admin/$module
- admin/settings/$module
- admin/block
- admin/block/configure/$module
So, you have to visit 3-7 menus to configure 1 module completely. That there are so much screens to visit is not the problem. That they are not near together is the disadvantage. If a module has submodules to be activated at admin/modules the number of steps increase.
But be aware: I don't want to discuss the menu-structure here.
What's important is to have an environment where the usability can be measured.
Don't worry about my snippet of thoughts. I know that Drupal is in detail much more better than the rest of the world ;)
That's why I'm discussing here.
Hmmmm... well, clearly, we
Hmmmm... well, clearly, we need, working sites, and test sites.
Perhaps the sites could be setup to first ask for info such as (we'd want very inexperienced volunteers, IMHO... with experienced drupal users, better interfaces seem likely to temporarily result in lower usability ratings, simply because they aren't used to them) "how long have you used drupal", "how often do you use a computer", and then direct the volunteer to either the control group site (drupal's default interface), or the experiemental interface. Once at the site, the use would be asked to complete a task, such as set the default input filter from "filtered HTML", "to full html". Then, the users are set loose to complete the task. Using existing data gathered by the tracker we could measure:
From that data we could compare the control, and the experiemental sites.
However, do we need to study user behavior in order to come to the conclusion that renaming "input formats", to "filters", or "text filters" will result in a lower number of mistakes, and less time to complete the task?
Moreover, with a low, to zero budget, I can't imagine finding enough volunteers to effectively do this, given the number of areas that need improvement.
I think we run the risk of creating too big of a challenge to every start, if we begin with experiements and measurements. Drupal is different, and unique -- but best practices for user friendly interfaces are universal -- and moreover, I think some of drupal's biggest usability problems are so blatent, that any improvement -- even a non measured improvement, is still an improvement.
If the group wants me to, I'd be happy to setup a test site and give interested parties whatever permissions they need (mysql, shell, and ftp if necessary, and appropriate). Or, I'd be happy to speed up any other steps I can take to speed up the process of getting started. It might be useful just to start with a book page with revisions and discussion that also included a mocked up menu structure.
I'm not anti-measurement -- but, I think we should build it first, than measure successs.
Onward,
Nick
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
http://www.nicklewis.org
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
You don't really need volunteers, cause
if you are able to analyse logfiles and read forum entries you have non paid employees ;)
"Build it first, than measure success" doesn't work successfully, you are able to see it at the not well working usability. It will only work if you are discussing core.modules. In case of user contributed modules you will need something like a quality-staging-process. To make these developers life easier you will need some documentation and that is verified with measured knowledge.
The first thing we have to do is usual collecting data. Therefore this site can be used and set up for a working environment.
Indeed we are discussing about the V in Model-View-Controller. Model and Controller are already well done in Drupal.
"if you are able to analyse
"if you are able to analyse logfiles and read forum entries you have non paid employees ;)"
This is especially true for tasks like signing in, configuring account options, creating content, and navigating a site's content.
For administration tasks, however, its more difficult to get at enough of those log files entries.
And again, there's the problem of gathering data from experienced users or site admins: they will have figured out how to "use" drupal inspite of its usability problems. Really, I think the most valuable numbers would be gathered from users who are using drupal for the first time. Have you read blink by any chance?
And with that, I will no proceed to get signed up at your site. Thanks for getting things rolling!
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
http://www.nicklewis.org
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
Looks like only berkes used
Looks like only berkes used this and it didn't catch on. Since there are 51 people here and 6 there, I don't see much reason to use the older site which appears to only have undone todos. Either way it will take some motivated people.
Work simply
May I suggest that you work simply? A few years ago I headed up an effort to try to improve some of the Drupal 4.5 user experience by doing a report of 4.4 usability. We used heuristic evaluation, a discount usability method, as our method for identifying critical areas of the user interface that needed attention. Then, presumably, some of those areas were worked on. The effort was time-consuming to tend to on the wiki, but well worth it for helping to clarify those nebulous areas that seemed to be the source of Drupal users' pain.
You can see the archive of this work at http://www.urlgreyhot.com/files/drupaldev/4.4-usability-report/.
A similar methodology might be very productive if you want to spearhead 4.7 usability. I'm in agreement that this is the right place to do it. Groups.Drupal has gotten some very good traction and is very usable as a collaborative work area.