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

[Alan Horkan <horkana maths tcd ie>]

[wrote this out of order, err hope it still makes sense]

On Sun, 9 Apr 2006, Alan Horkan wrote:

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

I'd adjust the design and not use a QUIT button if you plan to do
something like that.  (Maybe try adding it as a tool/plugin for the Gnome
sound recorder?)

> Running this on a PDA?

GPE, Gnome Palmtop Enviroment
http://gpe.handhelds.org/

I like the idea of taking small fast applications with a clear purpose and
running them on a full fledged Gnome Desktop and so I have played around
with GPE and Matchbox a bit.  The discipline of a small screen can help
avoid designing interfaces that look like the inside of an airplane
cockpit (which is fine for a trained pilot but disasterous for beginners
who haven't put in all the learning).

I wouldnt recommend a cramped interface unless you had a deliberate reason
for it, I was hoping you had done it intentionally.

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

The file chooser widgets are not great for repeated regular use (aside
from having a built in drag and drop target which I had not realised).

A text entry and a "Browse..." button might be a better choice if you are
using it on a regular basis, although it would probably be more hassle to
write.

> > > ABX comparator,

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

Many programs have terrible names, don't worry about it.  I'm thankful you
didn't try to stick a G or GNU or GTK in there.  Trying to turn the
acronym into a pronouncable word might work (SMB -> Samba;  ABX ->
AudioBoX???  Crap example but you get idea.)

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

Other items can be made into drop targets and a list widget might be
better if you were taking an entirely different approach.

The analysis we are doing at the moment is only really a superfical
heuristic evaluation which might result in small tweaks to what you have
got.  A more rigourous evaluation would look directly at problems you were
trying to solve rather than just trying to improve the interface you
already have.

I'm just outlining the possibilities and trying to cover the fact that my
suggestions are only a best guess.

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

The guesssing and intentionally hiding information and testing users is
a bit unusual.  The way I see it the task is a guessing game, but it
isn't important.

Would it be any use to have a single play button and not even tell the
users which file they are listening to?  (No pun intended but make it a
blind test?)

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

ABX comparisons are a useful part of the puzzle.  Perhaps a graph of some
kind could help users determine if a CODEC is suitable and evaluate the
pros and cons.  In some cases the problem is education, as there is no
perfection only best suited to the task and the target audience.

There is the bigger question of lossey versus lossless codecs (and the
more complicated matter of knowing when MIDI would actually be the right
answer).  Other questions like disk space required, wide availability of
the codec, or even more complicated issues like the kind of preccessing
power required to decode the sound without slowdown.

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

Yeah, I forget what the technical name for it is.

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

There is more than one answer to the question of usability.

I tend to be interestd in giving users what they expect, usually that
means encouraging applications to follow the Gnome Human Interface
guidelines but other times it means asking developers to do the same as
well known existing applicatoins unless they have a good reason to do
things better (not just differently).

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

Looking to existing applications is not a bad place to start.

> is that I want to learn more of designing usable UIs.

Given the very specific task and audience youy have in mind usability in
you case might put more emphasis on efficiency rather than easier to
learn.

> Sorry if I bother people for the sake of such a small app :) Thank you

I am assuming this application is being developer for Gnome/GTK and will
be under some kind of GPL/LGPL/MIT or other license where the code will be
availble.

--
Alan


References:
PC ABX  http://www.pcabx.com/
Win ABX http://www.kikeg.arrakis.es/winabx/
Lin ABX  http://beryllium.net/~remco/linabx/#screenshot