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



Well, thank you for all the explanations! And yes, I'm releasing this
under GPL in a week or two :)

2006/4/10, 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
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]