As the functional parts of UTS start to role out we can now jump into acctually designing the UTS for use by our audience, we will avoid talking about the analytics part of the UTS here as that is a different discussion. We have postponed quite some important parts of UTS so lets address these here.

We have different approaches to what the work flow should be, I wrote down a scenario of what my idea of the user experience is. I cant assume much of the workflow on participant selection as we haven't spoken much about that. Below I posted a scenario, of how

Scenario:
A programmer wants to test his module, he logs onto usability.drupal.org or his own server and installs UTS. From this point, he will go to the UTS module. This will be an initial overview page (UTS home page/Dashboard) where he has the obvious button to start a study and basic information on how to setup a good task analyses (small flash movie?).

He presses start a study, and starts on form 1 out of four where he can puts in basic information about his study. On the second page he selects the audience he wishes to reach in his study (very basic - as we haven't gone far into this yet) and on the third page he creates the tasks. After this page, he will go to the end form in which he will be presented with the ability to preform a dry run (new window), allowing him to go back in his forms to adjust certain elements.

When he is done with all of this, he will be presented with a link that allows him to give to participants (for example to be placed above a module, in beta) and in the future this might also allow them to select participants from a already set-up database of participants.

His overview(UTS Home page/Dashboard) will change listing his study, where, as he clicks upon it will get them to the analyse screen which updates while the data comes flowing in.

Listed workflow

  1. UTS Dashboard
  2. Create study
  3. Create participant Requirements
  4. Create tasks
  5. Dry Run
  6. Get a link to give to particpants

Especially the UTS Dashboard I consider valuable as you can update it to contain new information when you plant in a new feature or when a user enables a plugin.

I know Bevan, had a slightly different approach to the workflow, however I consider an interview kind of workflow far more usable then saying in text what steps a user has to take.

P.S for the sake of simplicity, I imagined a "man" would be doing the test as until this day I haven't found a usable and friendly word to describe he/she.

Comments

Bevan’s picture

Bevan commented

The main difference is that we cannot easily consider providing this as a hosted service on usability.d.o for any developer to use. There are a whole range of really difficult problems to overcome before we can consider that.

The UTS can be used by the individual contrib developer ('programer') to set up his own live sandbox on his own site, like at test.some-blog.com and ask his colleagues or friends to come test. When the UTS is ready, the drupal community / usability group might like to do this for drupal core, and it may result that usability.d.o is an appropriate location for that. But the test administrators will be individuals with exceptional priveleges -- and not just any drupal contrib developer who wishes to use it.

Bojhan’s picture

Bojhan commented

Oke, but I dont see how this is related to the workflow? As whether they test it on usability.d.o or on their own site it will still need to have a friendly interface? So remove, usability.drupal.org or from my text and respond again, please.

On your issue, I suggest opening up a issue regarding your interpretation of what usability.d.o should be.

boombatower’s picture

boombatower commented
Status: Active » Postponed (maintainer needs more info)

What needs to be implemented as of now?