[drupal-devel] [Fwd: Feedback from two usability sessions on CivicSpace 0.8.0.3]
Good read, valuable feedback. -------- Original Message -------- Subject: Feedback from two usability sessions on CivicSpace 0.8.0.3 Date: Fri, 18 Feb 2005 07:40:30 -0800 From: Kieran Lal <kieran@civicspacelabs.org> To: civicspace-community@civicspacelabs.org Hello, I managed to squeeze in two usability sessions yesterday to test the 0.8.0.3 release. I'll try to be brief, and when I get connected I'll file usability issues at CivicSpaceLabs.orb/project. First test: Scenario: Community organizer wants blogs, policies(Book), and contact information online. Their site has been professionally customized to do only those three things using 0.8.0.x Democratica theme Feedback: -After user logged on they didn't know what to do because there were no action words inviting them to do something. i.e. blogs instead of create a blog. -User did not know how to create content because the user doesn't think of the site as a content management site. They think of it as a site that has blogs, contact info,etc. Therefore, Create Content does not provide the cues to open the menu. -Messages on the create content page are too small to be read. "Might as well be in Swahili" -User is overwhelmed by the three boxes of options and twelve options altogether. The user does not know what a path alias is. The user has to scroll down the screen because content dropping of the options boxes pushes the preview button off the screen. Previewing is an unnecessary step. Second Test: Video capture installation of CivicSpace 0.8.0.3 and configuration of contacts, users, and an attempt to send an invitation email. Users were started at a firefox window with install.php screen in front of them. -Users found messages on first page overwhelmingly confusing. They just clicked ok and moved to the next screen. -Users had two errors. Both were write permissions to conf.php, and files directory. They were successful in getting to help pages. User had no command line experience. Did not know how to get into the includes directory on a unix host. i.e. (cd includes). User's proceeded to type what was in bold at the command line: localhost% chmod blah blah. I had to step in and tell them not to type localhost%. -Next they had to set permissions on the files directory. They thought they had to be in the files directory to set the permissions. But first they didn't know how to get out of the includes directory at the command line. -I didn't give them the database name and password, so I had to come in and give the wrong user name, database name, and wrong prefix. Eventually, firefox suggested the right answers from the last install I did using that browser. I'll have to clear the firefox browser cache for the next test. -Once the site was configured and running they added several users. They wanted to know where to add people so they could send them an invitation email. They tried to add email addresses. I ended up explaining that contacts is where they could add email addresses. I explained that contacts was like the address book in hotmail, and users was like the people who have email accounts at hotmail. -Once users were added, they went to contacts to try and send invitations. They were surprised that users information they just entered was not in contacts. -Next they tried to send out invitation emails. It was very clear that there were no cues as to where to configure mail. The entire interface is clearly functional in nature and not at all self-explanatory, or able to provide any useful cues. I directed them to mass mailer which left them with a large number of options. There was confusion about where to go to configure it. I directed them to admin and settings and there were so many options it was confusing. I directed them to set mail to work off a cron job to try and activate it by going to cron.php. Cron.php gave a completely blank page. At this point, the entire experience had plummeted into chaos. -Two notable additional experiences were watching two very well educated intelligent people stare and mouse hover at the "Queue message" button for a what felt like an eternity. Also, in an effort to customize the invite message, the users change the user% and added their name hoping that this would send the message. Whew! Deep breaths, deep breaths, breath directly into the paper bag. 3 days of usability training are just what the doctor ordered. Kieran --------------------------------------------------------------------- To unsubscribe, e-mail: civicspace-community-unsubscribe@civicspacelabs.org For additional commands, e-mail: civicspace-community-help@civicspacelabs.org -- Dries Buytaert :: http://www.buytaert.net/
LOL,that's is funny also. It goes much better when you use ISO 9000 guidelines to construct the UI. Then you have something rather than someone to blame. It is also easier to fix. Carl McDade Dries Buytaert wrote:
Good read, valuable feedback.
-------- Original Message -------- Subject: Feedback from two usability sessions on CivicSpace 0.8.0.3 Date: Fri, 18 Feb 2005 07:40:30 -0800 From: Kieran Lal <kieran@civicspacelabs.org> To: civicspace-community@civicspacelabs.org
Hello, I managed to squeeze in two usability sessions yesterday to test the 0.8.0.3 release. I'll try to be brief, and when I get connected I'll file usability issues at CivicSpaceLabs.orb/project.
First test: Scenario: Community organizer wants blogs, policies(Book), and contact information online. Their site has been professionally customized to do only those three things using 0.8.0.x Democratica theme Feedback: -After user logged on they didn't know what to do because there were no action words inviting them to do something. i.e. blogs instead of create a blog. -User did not know how to create content because the user doesn't think of the site as a content management site. They think of it as a site that has blogs, contact info,etc. Therefore, Create Content does not provide the cues to open the menu. -Messages on the create content page are too small to be read. "Might as well be in Swahili" -User is overwhelmed by the three boxes of options and twelve options altogether. The user does not know what a path alias is. The user has to scroll down the screen because content dropping of the options boxes pushes the preview button off the screen. Previewing is an unnecessary step.
Second Test: Video capture installation of CivicSpace 0.8.0.3 and configuration of contacts, users, and an attempt to send an invitation email. Users were started at a firefox window with install.php screen in front of them. -Users found messages on first page overwhelmingly confusing. They just clicked ok and moved to the next screen. -Users had two errors. Both were write permissions to conf.php, and files directory. They were successful in getting to help pages. User had no command line experience. Did not know how to get into the includes directory on a unix host. i.e. (cd includes). User's proceeded to type what was in bold at the command line: localhost% chmod blah blah. I had to step in and tell them not to type localhost%. -Next they had to set permissions on the files directory. They thought they had to be in the files directory to set the permissions. But first they didn't know how to get out of the includes directory at the command line. -I didn't give them the database name and password, so I had to come in and give the wrong user name, database name, and wrong prefix. Eventually, firefox suggested the right answers from the last install I did using that browser. I'll have to clear the firefox browser cache for the next test. -Once the site was configured and running they added several users. They wanted to know where to add people so they could send them an invitation email. They tried to add email addresses. I ended up explaining that contacts is where they could add email addresses. I explained that contacts was like the address book in hotmail, and users was like the people who have email accounts at hotmail. -Once users were added, they went to contacts to try and send invitations. They were surprised that users information they just entered was not in contacts. -Next they tried to send out invitation emails. It was very clear that there were no cues as to where to configure mail. The entire interface is clearly functional in nature and not at all self-explanatory, or able to provide any useful cues. I directed them to mass mailer which left them with a large number of options. There was confusion about where to go to configure it. I directed them to admin and settings and there were so many options it was confusing. I directed them to set mail to work off a cron job to try and activate it by going to cron.php. Cron.php gave a completely blank page. At this point, the entire experience had plummeted into chaos. -Two notable additional experiences were watching two very well educated intelligent people stare and mouse hover at the "Queue message" button for a what felt like an eternity. Also, in an effort to customize the invite message, the users change the user% and added their name hoping that this would send the message.
Whew! Deep breaths, deep breaths, breath directly into the paper bag. 3 days of usability training are just what the doctor ordered.
Kieran
--------------------------------------------------------------------- To unsubscribe, e-mail: civicspace-community-unsubscribe@civicspacelabs.org For additional commands, e-mail: civicspace-community-help@civicspacelabs.org
Alright, nice one, Kieran. I will try to boil this down from CS soup to Drupal Core. :) and will try to add some additional comments. Op vrijdag 18 februari 2005 20:02, schreef Dries Buytaert:
First test: Scenario: Community organizer wants blogs, policies(Book), and contact information online. Their site has been professionally customized to do only those three things using 0.8.0.x Democratica theme
Good scenario, allthough we should really avoid staring at blogs too much, we will loose focus of Drupals abilities to serve a huge width of cases! really!
Feedback: -After user logged on they didn't know what to do because there were no action words inviting them to do something. i.e. blogs instead of create a blog. If this is implmented, which I hope it is, we should make rules on when something is an actioin and when not. We should not add "create blog" and leave "comments". That latter should then "edit comments".
I have noted this and will spend some time on actions & terms on the HIG meetings.
-User did not know how to create content because the user doesn't think of the site as a content management site. They think of it as a site that has blogs, contact info,etc. Therefore, Create Content does not provide the cues to open the menu.
I have suggested a separate menu aimed at adding content before. See all the consistent.drupaldevs.org info. Will this issue be solved when "create content" is placed outside the adminstration menus, into its own edit or moderate block?
-Messages on the create content page are too small to be read. "Might as well be in Swahili" Is this not just a democratia problem?
-User is overwhelmed by the three boxes of options and twelve options altogether. The user does not know what a path alias is. The user has to scroll down the screen because content dropping of the options boxes pushes the preview button off the screen. Previewing is an unnecessary step. We will try to get to a **general** solution on this, soon. Allthough the fact you present your user with all the options indicates you have permissions and settings set wrong. Seeting these correctly is an art itslef, but very important. E.g. my GF has a personal weblog on Drupal, but she sees no of the admin clutter. Only an adminstrator should, that adminstrator should be clutter-proof anyway.
Second Test: Video capture installation of CivicSpace 0.8.0.3 and configuration of contacts, users, and an attempt to send an invitation email. Users were started at a firefox window with install.php screen in front of them. -Users found messages on first page overwhelmingly confusing. They just clicked ok and moved to the next screen. We should more often split content into *numbered* paragraphs. E.g. the default Drupal welcome msg is too long. should be split and numbered.
[snip CS specific] -Next they had to set permissions on the files directory. They thought they had to be in the files directory to set the permissions. But first they didn't know how to get out of the includes directory at the command line. Users should be held away from the CL at all costs. A commandline is powerfull, yes, but amoungst the most un-friendliest interfaces around. Give ppl either FTP access, or present a simple UI in HTML/Drupal to handle these folders. That goes much further that the problematic (yes a lot of hosts have problems with it) autogeneration of files directories and perms.
-I didn't give them the database name and password, so I had to come in and give the wrong user name, database name, and wrong prefix. Eventually, firefox suggested the right answers from the last install I did using that browser. I'll have to clear the firefox browser cache for the next test. Is not a Drupal Problem, IMO.
-Once [snip] -Next [snip] -Two [snip] Is not a Drupal Problem, IMO. CS and contact.module specific.
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
% > Second Test: Video capture installation of CivicSpace 0.8.0.3 and % > configuration of contacts, users, and an attempt to send an invitation % > email. % > Users were started at a firefox window with install.php screen in front % > of them. % > -Users found messages on first page overwhelmingly confusing. They % > just clicked ok and moved to the next screen. % We should more often split content into *numbered* paragraphs. E.g. the=20 % default Drupal welcome msg is too long. should be split and numbered.=20 I wonder if it makes sense to have the numbered paragraphs like the purple number effort from purplewiki? http://purplewiki.blueoxen.net having linkable paragraphs as an automatic feature seems interesting to me. And if you are going to stylistically number them, then linking them makes sense. ----- John Sechrest . Helping people use . computers and the Internet . more effectively . . Internet: sechrest@peak.org . . http://www.peak.org/~sechrest
participants (4)
-
Bèr Kessels -
Carl McDade -
Dries Buytaert -
John Sechrest