[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: User Interface.. If you ever wrote or will write a software GUI, then READ THIS!
From:       Philippe Fremy <pfremy () chez ! com>
Date:       2001-03-09 16:47:07
[Download RAW message or body]

On Friday 09 March 2001 16:01, Michael Jarrett wrote:
> Dawit Alemayehu wrote:
> > On Thursday 08 March 2001 20:58, Christian A Str¸mmen [Number1/NumeroUno]
> >
> > > 4) A dropdown combobox should show ALL of the entries, it SHOULD NOT
> > > CONTAIN A scrollbar!!! (page 7)
> >
> > Huh ? You are kidding right ?  If I have 100 entries in a dropdown box I
> > am supposed to show all the 100 enteries ?  This is absolutely wrong
> > IMHO. What about the combobox scrolling off screen ?  How would you
> > select an item if you cannot scroll down to it ??
>
> Agreed - this was a BIG problem, especially in things like webpages.
> Nutscrape 4.7 had this issue - where there were huge comboboxes that
> couldn't scroll. You'd fill up the screen, then you'd have to play the
> 'lets see how fast we can click on More... game' to try and get the
> correct page of entries.
>
> That was UI HELL!!! You can't always control the contents of a control,
> but you can make them behave well for most content.

But this problem only happens if there are too many items, so that the item 
list does not fit on screen. I agree that in this case, you _should_ use 
scrolling and I am glad konqueror does it. 

However, if your item list fits on the screen, why not display all the items 
? You will save the user a lot of time. Example, the user is in kword and 
uses only two fonts, Arial and Zoubloublou (invented name) and switch them 
every two lines of a 200 pages document. Imagine how much time and hassle you 
can save him if you can display all fonts in one screen ?
I remember losing tons of time with word because I just wanted to test 
various fonts it was such a pain to select one in the combo.

Take also in account that if the user can see more choices, he has more 
chances to make a better choice. Imagine he doesn't know the exact item he 
wants in a list of 40 items, but when he sees it, he knows that item 17 is 
not too bad, and item 33 is an excellent choice. If the combo presents 10 
items at a time, he will scroll until he sees items 17 and very probably 
click Ok. You can always say that he should have scrolled until item 33, the 
fact is that he won't do it, because he wants his task done quickly. At this 
moment he is focus on something else and doesn't have the time to look 
carefully into a small box presenting small items. 

Eventhough I like to make careful choices, I do that sometimes, because I 
find combo box to be too small to present a long list of items and a bit 
painful to use. 

This is the kind of things which make a desktop just usable or a pleasure to 
use. But it is hard to tell a developer that the combo box should be improved 
although it does already what it is intended for. Developers are 
unfortunately hardly aware of usability issues. Eventhough usability benefits 
to both basic user and enhanced user, it is only noticed when the basic user 
fail to acomplish a task because of usability issues.

I must say that Kde 2 has improved a _lot_ in this area, comparing to Kde 1.2 
and it is a pleasure to use it, most of the time. But there is room for 
improvement, always!

	Philippe
--
Free the mallocs!

[prev in list] [next in list] [prev in thread] [next in thread]