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

[Alan Horkan <horkana maths tcd ie>]

I assume you sent the following message offlist by accdent.

I'll reply to it seperately.

On Sun, 9 Apr 2006, [KOI8-R] Артём Попов wrote:

> Date: Sun, 9 Apr 2006 11:21:32 +0700
> From: "[KOI8-R] Артём Попов" <artfwo gmail com>
> To: Alan Horkan <horkana maths tcd ie>
> Subject: Re: [Usability] Re: Primary window decorated as a dialog in an
>     utility application (real world example)
>
> Hi!

2006/4/8, 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?

Currently not, but it could be used as a plugin to an audio player.
Running this on a PDA? Cool idea, didn't even think of it! :) The
layout is rather tight, because it's convenient to keep an ABX
comparator side-by-side with a file manager with an open folder full
of some encoded files.

>
> 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.

Hmm, that's my problem. I started this discussion because I couldn't
decide, should I have a "proper app with a menu" or something like a
simple dialog (like gfloppy)... If a menu will be used, it will
contain only "Quit" and "About" actions. Files are opened with a
FilechooserButton because the user will want to frequently change both
A and B (and the desired segment as well). Menus make this action
2-click, while with FileChooserButton it takes only 1-click.

>
> > 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).

Well, I think such an app will be mostly used by audiophiles who will
certainly know what's ABX testing, but you're right. I'll have to
think of a better title.

>
> > 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.

No, no. ABX comparator is used to determine how well the certain user
can hear the difference between 2 certain files with certain equipment
(including his own ears):
http://wiki.hydrogenaudio.org/index.php?title=ABX
The only way to test if difference is audible, is the ABX test,
because it's a blind test and implies a large number of trials to make
sure, that the result was not a random guess.

>
> > 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.

Well, they're faster than doing "File -> Open" and you can drag-n-drop
on them from anywhere, right?

>
> > 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.

Hmm, it's surely not a game for the reasons I described above.

>
> 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.

The fair comparison is achieved by a large number of trials (15-20).
Application can not test by itself, because the whole nature of the
ABX test is listening and guessing. Audio codecs are all different by
design and there's no way to determine their perfection
programmatically other than listening. an ABX comparator is a good
helper in such a task.

>
> 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.

There's a reason behind such naming as well. Although A is often the
reference (the original), sometimes an ABX test could be performed
with 2 encoded files, so people use just "A" and "B".

>
> > "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.

What's a disclosure triangle? Did you mean the Expander widget?

>
> > 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.

No labels are changed during the whole app cycle. Both "Repeat
playback" and "Show results" buttons are toggle buttons, but their
labels are unchanged.

>
> > My primary concern is the "correctness" of the layout :) Thanks. --Artem
>
> Test with real users and then "correct" will be a whole different
> question.

Well, the real users here think my app is a lot better than PCABX or
WinABX (both are Windows apps) :) The reason I posted my message here,
is that I want to learn more of designing usable UIs. Sorry if I
bother people for the sake of such a small app :) Thank you for your
answers. --Artem