Design UI

attachement?

Hey, Bevan

I understand that the usual approach in Drupal is to step away from a usual interview-flow, however in this case I don't see how any of this is more usable? Could you explain a few things :

How do you want to do the participant selection?
Why are tasks & questions grouped up together, can you ask questions related to each tasks after/before?
Why are there so many data captures? (Do I really have to select what kind of data I want to capture? - we are not going do many of them any time soon)
Functionally I don't see much difference between my wireframes, and yours. Is there a big difference?
Why is this flow, more usable then a interview flow?

On a more important note :

Whats up with all the text? (Less is more?)

Thanks for all the work you put into it, I hope you have some time left to explain all the things you thought of as I cant understand some of the choices you made.

Best Regards,

Bojhan

Bevan,

I am not a coder, some of the stuff you say, confuses me a bit. I will try to explain what I don't understand.

I probably missed the conversation about participant selection, to bad I couldn't get my word in at that point. To state clearly, we will do nothing to help them? You say the UTS, can and then you say it wont. So essentially it shouldn't be able to do it? I am confused. Wireframes are not going to fix communicating this issue, please say what the UTS will do on participant selection and what will be left to the UTE to decide.

Why are tasks & questions grouped up together, can you ask questions related to each tasks after/before?

What do you mean by questions related solely by context? Let me state really simple how many interview-based task analyses go :

Talk with the user (1), find out what kind of tasks he/she has (2), take about 15/30 minutes to create the tasks that are incontext with the user (3), set him out to do the tasks (4), and in the meanwhile I ask (follow up questions - 5).

The questions we try to create in the wirframes, are not in phase 1,2 So a distinction between the two :

1. Asking questions related to a task, as what do you expect (this happens before, not after) or why couldn't you finish the task within the 5 min max.
2. Asking questions related to a study, this is to deter main if the user is right one for the study audience.

I understand with the wireframes you focus on the 1st, correct? I think its very important for questions to be related to a task, as otherwise its to hard for most people to evaluate the results. I found follow up questions, after someone failed or succeeded more valuable then questions that you ask out of context. I am not sure how all of this fits into the relationship thinking, but I hope you can understand.

I don't really read E-R diagrams from the basic assumption, that I have no idea how to understand them. Sorry. It might be a waste of time, to focus on improving the E-R to discuss things, but essential to explain to boomba.

Why are there so many data captures? (Do I really have to select what kind of data I want to capture? - we are not going do many of them any time soon)

Will we have screen capture, webcam video or audio any time soon? I think its great, that you thought of all the scenario's however as most of the data we will capture at the moment, is default and doesn't need a change we don't have to display them.

I hope we wont be testing many participants at all, so lets eliminate that scenario for the time being - not realistic. As its practically not smart (in our context) to go for many participants and quite some usability folks advise to avoid testing many particpants, rather testing a lot.

Functionally I don't see much difference between my wireframes, and yours. Is there a big difference?

Inverview flow is what I wanted to do, form 1 (create study - set audience), form 2 (set tasks), form 3 (finalize running study). (Interview flow is acctually something different as interview-based tasks)

An interview flow has proven to be extremely valuable in web applications, yet Drupal is somewhat hesitant to apply it anywhere (not sure why?) I could see your main page, work after someone created a study, but not when he is starting it.

I understand you want to go more study centric, as I want to go more test-centric (bottom of this reply read about that). I am not sure what you mean with Forms API, but I guess that has to do with the look of things?

This main page is of essential essence, as its the starting step of an UTE. If it is to overwhelming, its more then likely that we scare people of. Interview-flow's avoid this, by sorting a big task into tiny comprehensive bits.

Whats up with all the text? (Less is more?)

I understand your completely what you try to focus on, but let me first state. No one is likely to read, bulks of texts, especially if they are themed they way its done in Drupal atm. ( The 37signals guys, acctually had a post up how making the color inconsistent (gray) of the labels(black) actually put more focus on the help text. - cant find a link)

The current eye-tracking studies show that although people read the descriptions (surprised me, maybe its the lab setting) that few really got understood them well. As we try to educate developers trough the UI with help texts, I don't think going for best fitting texts (which ultimately makes long texts - no one reads/understands) but to guide them with a bit of arrogance to the best input. An example would be : Try not to go above 8 participants.

I didn't really think empty, as in paragraphs of text for them to read. I thought as really conversational zero-content, so if there is not any study setup to have a short 2-5 minute movie on how to set it up, and what are the best choices to be made - as explaining Usability in audio I found easier then in text as you can more easily provide story.

Maybe more defensive design(37 signals) approach to supplying feedback text for "extraordinary" input, so drop the idea of lots of texts in place - bring in the idea of more zero-content - everywhere.

Study vs, Testing

Its much more important to do more rounds of testing than writing everything you can out of each round. Steve Krug

If you see a major usability problem, you want to attempt to fix it, and then test again to see the fix you preformed acctually worked. In Drupal we are quite unfamiliar to this concept. Recent usability reports gave us a list to work with, but most of these problems don't have an obvious way of fixing it (or there is, but no one wants to agree), so we need to test to get the best solution shown. If we approach all of this in a big ground breaking way by studying every module, having lots of results to work with, we might end up with lots of problems that don't have an obvious way of fixing (or, ect). Rather you want to break up huge studies, into tiny parts where you test, evaluate and test until you get the best solution, because finding problems is not really the problem with Drupal.

I want to address the Developers because they are best at determining when they want to do usability research, that they will acctually adjust there module to recommendations and allow testing to go on. Involving developers into the usability process they wont stand on their island developing solely for themselves and the geeks around them - they will be faced the usability problems. If they are active in this process (setting up the UTS) they are more likely to tackle the problems, because at that point they seem smaller and easier to fix then at the end of a big usability report. I disagree, that usability research don't supply solutions, most of the time you see ways of fixing it your just not sure its the best way (so test!).

Anything that seems big to tackle, is usually avoided. So make it seem smaller, good!

If we have a testing culture, instead of a study culture we might end up with way more fixes to Drupal, instead of having to wait for a big study to end to find out the tiny improvement we made, didn't acctually work. I know, I coined the idea to call it study, observing the issue ques and groups I see that there is not a lack of discussion, rather a lack of testing.

This means the UTS should allow for easy, and fast testing.

Regards,

Bojhan

If we have a testing culture, instead of a study culture we might end up with way more fixes to Drupal, instead of having to wait for a big study to end to find out the tiny improvement we made, didn't actually work.

I agree with 300% Bojhan here.

Anyone interested in serious, professional, formal usability testing will not be using this module and will instead be using a software like Morae or proprietary tools like we used at UMN. Where I believe this module has its niche is in quick "field tests" of modules/functionality/navigation by developers and web site implementors, people at Drupal user groups/Drupalcamps, something like usability.drupal.org, etc.

We're getting off-track here with the project scope, which is *very* dangerous since there are only 8 weeks of SoC left to do development, QA, documentation, and testing, and so far we've yet to move past the initial "gateway" into the actually interesting (and challenging) part of gathering data during a test. If this project ends up with a nice form that asks lots of questions but doesn't do anything once you fill it out, then this project will have been a failure.

Jimmy, maybe you should start working on that stuff so you're not held up by lack of agreement on target audience. Regardless of who takes part in the study or what types of tasks they end up doing, we still need to track and store data about their session, and the type of data we should store is likely a much easier thing to come to a consensus about.

A small note, boombatower can do most of the work of the logging already. We have agreed upon, that we will macro record (http://www.bojhan.nl/Drupal/TaskRecording.html). This should take quite some time. I hope Bevan, that you can see what I am trying to point out with the audience, I understand your hesitant to see a developer as UTE but most code centric people are acctually interesting in making it work for humans, just have no idea how. Its difficult that we start all of these discussions after summer of code started, however to get things done with UTS we do need to approach it wisely - although if we with our discussions are slowing down boombatower to much, it might still be good to sit together on irc for an hour to talk things out.

It was very hard for me to get any idea at all about what this UTS might be. After reading most of this and talking with Bojhan in IRC (we're both dutch, which helps :) this is what I can make of this now:

A simple toolkit that generates limited but useful data in an online test-situation. I agree with Bohjan that actually yes, developers are the primary target group here.

- Create studies with tasks.
- Create a recorder to track participants' click-behavior.
- Publish the test, run it with the participants.
- Present the results.

What I imagine is that a developer can set up a study (or maybe even just one task), dive into #drupal and/or #drupal-support, recruit some volunteer testers and have them try and complete the task. Quick and easy.

Especially if we really want to promote the rinse, repeat aspect of testing UI stuff, the barrier of entry should be as low as possible.

Imo the limitations of the test being an online event and of the developer being the main target group are good guidelines for scoping this down to a workable gsoc project. It'd be better to end up with the simple yet usable 'minimal' version than the promising, ambitious but unfi…

Boombatower, how much if this is rapid-prototypable into a module that non-devs like Bojhan and me could evalutate?
Would that make sense in this timeframe or be too much?
Where you will start your coding? (building the logger sounds sensible)

I have a basic interface almost completed from early wrireframes, changes to make it fit into Drupal's APIs and such. I will finish that up and then move on to my next phase: "Create user testing environment and event capture interface."

That being the logging stuff. :)

If you would like to check it out and give feedback download the dev release or CVS up.

I think the basic UI is completed for now. It has all the necessary features (to my understanding) and fits into the Drupal schema of things. The only thing that is not complete is the form redirections after editing a study/task. Seems to be an issue with Drupal node API, I'll look into it.

If anyone interested would take a look and give me feedback that would be great. Unless any critical issues are brought up I think I will move on to the next stage of development.

How can I associate tasks with a study? I encountered a few errors, but I think that's only me, as yoroy isnt having them.

I will post them, I am not sure if they are useful to know :

* user warning: Unknown column 'study_nid' in 'field list' query: SELECT study_nid, max_time, weight FROM usability_suite_task WHERE vid = 9 in /bojhan.com/public_html/drupal6/modules/usability_suite/usability_suite.node.inc on line 291.
* user warning: Unknown column 'study_type' in 'field list' query: SELECT study_type, participant_count, audience_role, audience_level FROM usability_suite_study WHERE vid = 8 in /bojhan.com/public_html/drupal6/modules/usability_suite/usability_suite.node.inc on line 283.
* user warning: Unknown column 'study_type' in 'field list' query: SELECT study_type, participant_count, audience_role, audience_level FROM usability_suite_study WHERE vid = 7 in /bojhan.com/public_html/drupal6/modules/usability_suite/usability_suite.node.inc on line 283.

I would appear you don't have the update database schema. I would recommend disabling the module, then goto unistall tab and uninstall it, then re-enable it.

Not sure about wording, but if you goto studies then click "view tasks" then you can "Import" or "Add" them. Part of the confusion is probably due to the lack of redirects working. It should take you to that page after you first create a study, but doesn't seem to work for some reason.

Ahh oke, well maybe webchick or bevan can shoot at why the redirect isnt working.

It seems that somehow I havnt installed it porpperly as I cant uninstall it either, I will just go ahead and put it on a diffrent site.

For now this has been implemented and is sufficient. This issue can be re-opened if necessary.