Re: [Usability] Re: Primary window decorated as a dialog in an utility application (real world example)

[Alan Horkan <horkana maths tcd ie>]

On Sat, 8 Apr 2006, [KOI8-R] áÒÔ£Í ðÏÐÏ× wrote:

> Date: Sat, 8 Apr 2006 08:44:06 +0700
> From: "[KOI8-R] áÒÔ£Í ðÏÐÏ×" <artfwo gmail com>
> To: usability gnome org
> Subject: [Usability] Re: Primary window decorated as a dialog in an
>     utility application (real world example)
>
> Oops, sorry for double posting!!! Here's a screenshot of the app, an

The layout is very tightly packed, are you trying to fit this on a small
screen portable device?  This is not a dialog/plugin for another larger
application is it?

If there is no reason forcing you to use a dialog style layout I would
encourage you to try and use a conventional menued application design
which would leave you with more flexibility.

> ABX comparator,

the title does not make it immediately obvious what the program is for.

(I wonder if "comparator" is a valid English word.  It might be but it
is not a great choice).

> an app commonly used to compare compressed audio such
> as mp3 and vorbis vs. the original (cdda).

A Golden Ear test?  Understanding the underlying purpose or task is
essential otherwise the details can overwhelm the design.

> The is going to load A (the reference) and B (the challenger) by
> either clicking on filechooser buttons

Not sure this is an appropriate use of a file chooser button, they are
only really intended for infrequently changed value like setting a default
path to pick up resources.  Hard for developer to know but I'd avoid file
chooser buttons most of the time.

> or by drag-n-dropping from a file manager or an audio player.

> The user will listen to audio files A and B and X (assigned randomly
> from A or B) as many times as he wants. Then he guesses which stream,
> A or B was hiding behind X?

Guessing makes this a game not a general utitlity.  Designing a game
requires a slightly different approach.

Guessing is annoying when an application could test for you or provide you
with the necessary data to make a fair comparison (or choose different
encoding options if for example the loss of quality is too much.

Gameplay is related to usability but it is about making something
challenging without being too annoying or frustrating.

> A and B buttons are initially disabled, and they're enabled as soon as
> appropriate audio files are loaded. X button is enabled when both A &
> B are available.

Unless you specifically need to conserver space I would recommend you use
proper lables.  Instead of X you could use a lable like Audio Source,
or Original Audio.  Audio Sample A and Audio Sample B might not be a big
improvement over just A and B but it could make things clearer to new
users.

> "Play X" for the second trial, and so on...
>
> The results are hidden, until the user decides that he had enough
> tries. Then he can see, how many times he guessed right. He can also
> see the P-value, the calculated guessing probability.

Without a better understanding of the problem you are trying to solve
I am not sure I can give accurate advice.

Would probably be better to hide the results behind a disclosure
triangle or some other way rather than what you are currently using.

> The sample selector is a quick and dirty custom widget, which I'll
> rewrite ASAP. As well as "loop" toggle button.

Checkboxes are usually a better bet than toggle buttons.

Changing the lable of a button when it toggles is generally unpredictable
and is a bigger problem in terms of accessibility where screen readers
cannot know the button lable will change.

> My primary concern is the "correctness" of the layout :) Thanks. --Artem

Test with real users and then "correct" will be a whole different
question.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/