[wrote this out of order, err hope it still makes sense] On Sun, 9 Apr 2006, Alan Horkan wrote:
> > > From: "[KOI8-R] ????? ?????" <[EMAIL PROTECTED]> > > > To: [email protected] > > > 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 [email protected] http://mail.gnome.org/mailman/listinfo/usability
