Improve UI for Participating User
eigentor - September 9, 2008 - 03:39
| Project: | Usability Testing Suite |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | boombatower |
| Status: | closed |
Description
Having seen Webchick fail on participating in a study (in the presentation), It might be time to improve the interface for the user ;)
It should be near to foolproof for the user to choose a study and start the tasks. I created a mockup of a wizard-like interface to ensure this. Though it is more work for us to do a wizard, it holds several advantages:
- User never overwhelmed, instead guided
- We can distribute messages across screens and thus make sure it is read
Also I removed any messages that are not crucial for the participating user. User and test admin should be adressed completely seperate.
Marked as code needs review as there is no "Mockups need review ;)"
| Attachment | Size |
|---|---|
| UTS-Test-Participant-Interface.pdf | 458.06 KB |

#1
#2
Review
Nice work Thomas, I'll try to address each page with some questions which you might not intermediately be able to answer. Though we should be able to work out most of them.
1. I don't think we would have to include a more link, if someone needs more information to do a study he usually is filtering to much on what he can and can't do.
2. I have been thinking about this one, wouldn't it make more sense to e-mail the code when the user abruptly stops a study by either quitting or clicking stop? And the Javascript enabled, is that really necessary? (Can't we just detect that?)
3,4,5 : What I am wondering, wouldn't it be more clear (by visuals) to the user if the screen gets over layed by a black screen, with the start button, creating environment ect. Which puts the user out the mindset that he is working on the same Drupal.
6 : Does this page always exist?
7 : Task description in overlaying black screen? Then when clicked to start, to animate to the bar given in the pdf?
That's all what I had to review, I like what you removed it was definitely not necessary information and made the interface more clear.
#3
Thanks for your review, Bojhan, my comments on your comments:
1. More link is just to keep the study descriptions short, so you make sure people see everything on one glance if there are several studies. A test administrator might make a looong description...
2. Javascript: right, it should only say "Please activate Javascript" if it is deactivated. And because UTS does not work without, it would also have to be "Setup quitted. Please come back when Jscript is enabled".
With the code: am unsure. People are used to be presented to similar things: keep your account number, save your password... But this might be a thing to run a quick user test on to decide...
3,4,5 Overlaying black screen: we might do this. Don't know. Javascript is needed anyway, so technically no problem. Personally I don't need it and I like to keep overlays rare. But actually - if the overlay also contains the progress bar, this might indeed even more clarify the user has got to wait.
6. Depends. If someone is already logged in, it does not.
7. Here the black screen would indeed be good - so user knows "read this first". But we should make sure the overlay contains the entire text - it does not now.
The flashing of the top bar would also be good - even better IMHO if only the "Start" Button flashes, so the user is very much guided...
So how do we get more feedback on this - Emailed to Philip Vergunst to have a look, if you speak to him maybe ask him to have a look. Also would like to know what Boomba and maybe Yoroy think - and if we settle to something it should be coded right away. The "starting a task" workflow has quite many steps right now, and it is hard for the user. But the user might be a total beginner to Drupal, so this must be easy.
I'd like very much to get UTS used by UX people over at g.d.o...
#4
3,4,5: Well I think if we do the visual emphasis right, we should do it right. Looking at how webchick used it, having the whole drupal interface there when you read the task is a bit to much. Where as we can just put a black screen every new task / start of study.
As I imagine this : I get a link to start a study, I click it. I read the Study information (on a black screen - didn't see the interface yet) I decide I want to start the study, click on start, I get a progress bar so I see I will not work on the real site(on black screen), then I get to the first task description (on a black screen- still haven't seen the interface) then I click start task, then the screen flows into a upper bar and I see the site. which makes me aware that I can look for the task description in the upper bar or actions as stop/skip.
On the note of getting it used at g.d.o I agree, there is just a bit of work on the interface and code to be done for it to happen. If you want to hop in as actively as you can with this, it would be greatly appreciated.
#5
Ah, in coherence of the workflow your idea sounds good.
So maybe I make another mockup with your suggestions - and then we do "new style" and test it: show it to some people (best non-drupalists) and ask what they think. (I mainly wanna find out if they like or not the black screen. But maybe it does not have to be too black - could as well be in a different color).
Would this be a way to go?
#6
That would be the way to go.
#7
Also would like to hear what Boomba thinks...
The issue queue has died down a bit. To get this thing rolling, we need to be active. I still see it as a major tool, if we make it work.
#8
O.K., Here we go. Everybody is happily mocking up, so I do not want to stand back...
After Feedback from Bojhan, Yoroy and Bevan I have tried to leave out everything that is not needed.
Note the very much shortened version at the end of the PDF... :)
#9
Can you post your production files?
#10
Are we requiring that the user login to the site and eliminating anonymous participation?
#11
boombatower: Not sure, however in the current setup we do require them to have them logged in.
#12
Actually no. There is a permission 'participate in study' that simply needs to be granted to anonymous users.
I'll work on the rest and add the login requirement if confirmed.
#13
starting...
#14
I'm wondering if we should remove the "code" input entirely and just send the participants an e-mail with a link to resume (I think it already does something like that). That way they just press "create environment" then "start".
So if they use e-mail link it takes them directly to the "start" page.
#15
Due to the significant re-factoring I have created: #352389: Update e-mail sent when new environment is created
I believe this is what we need for the time being and looks significantly simpler.
Then the session is opened and the normal proctor interface is displayed.
#16
Committed.
#17
#18
Hey, this looks good :)
I applied the patch to the latest dev version and all ran smoothly. But when trying the module it does not work anymore.
Do I also need to apply all the other patches?
A Dev Version that has all the latest patches in it would be much welcome...
How about the batch-creation of environments I sugguested? I am finding this step should not be done by the user - and it takes quite long, though a progress bar sure amends things.
Also the starting of the study takes very long - what is happening programmatically at this step?
#19
I agree with eigentor, step 2 is a bit useless - since it is not neccairy a step a user should have to make. The way it was intended to show, that the user is not working on the real site.
Ohh, don't mention the word test! :)
#20
Adding batch generation of environments is a different matter and would require a bit of additional code, so I figured I'd save that for a 1.1.
Also as a note the dev version is re-rolled nightly (automatically) so it should have all the latest patches by now. Please post bug reports if things don't work. I'm only aware of one thing and I already have an issue for that.
#21
Oke, can you automaticly create it? So the user doesn't have to click creates. But does get the text :
Creating a site for you...
A site where you can work in.
This to leave all the test environment, and other terminology that might confuse a beginner.
#22
#23
Keep the status bar, hoping that it isn't a one second progress bar, so they can't even read it :) - Happy new years!
#24
Sure, I was already wondering how much effort it would be to do the batch creation.
So how about recommending strongly on the study creation pages to the Test Administrator to create sufficient Test environments for the participants, be it batch or not.
And if there are sufficent environments, could we make the login the first step for the participant, which I find much more logical workflow-wise? (Well I see the problem that the study selection does not exist inside the testing environment, might be not that easy). But if it is possible without too much effort, I would very much appreciate. If there are no environments ready, the login could be the last step before starting just as now.
And if there are sufficient unused environments, how about doint the following: merging the two steps (environment creation and starting of the study) into one for the user, so he only clicks the start button once. This will take even longer than now, but we got a progress bar. One could give feedback messages below the progress bar during the process: "The system to work in is created" and when this is done, changing to: "The system is prepared and the study is started"
This would even more reduce complexity for the participant, which should be a primary target.
Maybe you can put any of these ideas that you approve of but that are too much effort now, into the bin for later. :)
#25
#357483: Allow for batch create of environments ahead of time
#26
Now that is the kind of wizard we can give to the user.
Great. Simple, no choices, just click start two times. Though it feels like the progress bar is rambling for hours (well, we can cut it in half if the test administrator graciously performs that task for the participant), one at least has progress bars and always knows what is happening. Great.
Now we get them to start the study in a near to foolproof way.
Next would be now thinking about the logic that applies when logging in and actually starting a task. some of it is just styling - the grey buttons in the top don't stand out enough. I could create a patch for that.
Though it is clear the user has to login, this is not good enough. It should be foolproof and convenient. So how about displaying a big message: "Please log in and start the first task" in the middle of the content area?
Also it would make sense to display the login form in the content area and the message above that. This could only be overseen by someone that won't be of any value for the testing anyway ;)
As there is a message box to explain the task anyway, it could just the same explain once more what the red ribbon in the bottom right corner is for (Feedback box I mean). Once we have a message box, we can use it. This would only have to be displayed in the first task box, the user only needs it once.
#27
Eigentor can you supply some images, of the interface how it looks now? You are right that, those elements need to stand out.
#28
The participant may not always need to login, it will depend on the task? You could have the testing some module which does things specifically for anonymous users.
The study/task should be clear through its description. I don't think it is a core UTS issue.
#29
Automatically closed -- issue fixed for 2 weeks with no activity.