On Sat, 8 Apr 2006, [KOI8-R] ????? ????? wrote: > Date: Sat, 8 Apr 2006 08:44:06 +0700 > 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? 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. > 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). > 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. > 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. > 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. 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. 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. > "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. > 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. > My primary concern is the "correctness" of the layout :) Thanks. --Artem Test with real users and then "correct" will be a whole different question. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
