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 <[EMAIL PROTECTED]>: > > [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 >
_______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
