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

List:       kde-usability
Subject:    Re: Grey out scrollbar button when border reached?
From:       Matt Bonyak <dingodonkey () stny ! rr ! com>
Date:       2002-08-28 16:36:32
[Download RAW message or body]

On Wednesday 28 August 2002 07:23 pm, Friedrich W. H. Kossebau wrote:
> Matt Bonyak wrote:
> > This is a peeve no doubt, but is it a serious problem?
>
> Define serious problem ;)

I think I covered that in my response to Aaron's reply.

> But I can imagine bigger problems of this kind: Have a big list of
> items. You sort it by the important factor. You jump through the list to
> get an overview, then scroll up to the top. By some accident you are
> close to but not at the end. But a quick view at the scrollbar looks
> like you are so you say, okay, we gonna buy this. Two days later your
> boss makes you having a good time :/

And a simple click could've prevented that.

> > > Today it just struck me: Why is the corresponding scroll bar button not
> > > simply greyed out when the view has reached the corresponding end?
> >
> > At first, I read this as "gray out the scroll bar" instead of "gray out
> > the scroll bar button" -- Had you meant the entire scrollbar, a huge can
> > of inconsistency worms would have been opened.  However, by merely
> > graying out the corresponding button, no harm is done.  Except to make
> > the user think more.
>
> Only if he looks at it. And when he does he mostly might have a reason
>
> :) At least I do. And then he has to think less because he immediatly
>
> knows what's up.

Consider it this way:
	The user wants to scroll down.
	The user readies himself to scroll down.
a)
	The user clicks down, as he was already prepared to do.
	1)	Nothing happens, user understands.
	2)	The user scrolls down, the user is happy.
b)
	The user sees the scroll buttons
	1)	They are gray, the user got ready for nothing.
	2)	They are coloured, the user wasted time looking, as he'd have clicked 
anyway under the current system.

> > There are enough components in every window for the user to pay attention
> > to as it is, the last thing we need is yet another providing feedback. 
> > As it is, sure, you may not know if you're at the end or not.  So you
> > click the button to find out.  If you are, nothing happens, no harm is
> > done.  If you're not, you scroll down as you wanted to.  This system
> > works fine and requires less feedback interpretation.  I think it's best
> > left as it is.
>
> Pardon. This argument would be the same against the greying of the
> toolbar buttons.
> No clipboard content? Simply try out!
> No page to go back? Simply try out!
> No more upsizing possible? Simply try out!
> No harm is done... ;)

Ouch.  Brutal, but not quite.  We all know that the options you listed are 
used in a different manner than the scrollbar, and are used less often, in 
general.  It's a matter of priorities.  Those buttons all perform a specific 
function, and are all grouped together.  When that function is not available, 
they are grayed.  At first, it sounds the same with the scrollbar, but I 
don't think we can look at it that way.  The scrollbar is something that is 
always useable.  The scrollbar is something that is used very often, very 
quickly, and very _habitually_.  It is also one of the few buttons that can 
respond by doing nothing, and still be understood -- if you click, and 
nothing happens, you know that you're at the top/bottom, and can't go any 
up/down any more.  This is different from the back button, for example, 
because when you click that, and nothing happens, you habitually continue to 
wait to see if something WILL happen.  The scrollbar provides instant 
feedback.

> My proposal would not lead to use of more screen area. It simply
> enhances a button that is already there. That only changes when a
> certain state is reached. And does it meanfully.

True, but again, I don't think the user needs constant feedback from something 
that is used all the time, when he can gain it by his clicking -- the 
clicking that he would otherwise pause to see if he could do, thus (slighly) 
impeding progress for a majority of situations.

> > I think the current "if you need to scroll, click.  if you're at the
> > bottom, nothing happens" method is fine.  Yours is certainly an
> > alternative, but I think the current system is simpler, which is what we
> > want.
>
> Simpler perhaps, but less _usable_ IMO. This extra test click takes time
> and is annoying. Especially if you work a lot in widgets that have to
> handle the view via scrollbars. Editing of sound files: want to copy
> part of the start. Browsing emails: all the newest read? Editing source
> code: no more dirt in the last lines?

Which takes more time?
	a) Verify.  Click.  Scroll Down.
	b) Click. Scroll Down.

And when you can't go down more, it only serves to impair the speed of 
clicking down for a person when they CAN, as it instills a "check, even 
though most of the time this isn't necessary" step into their minds.

> Do you think we want a simpler system, or a more usable system? How do
> you define simpler?

Simpler as in simpler to use.  The less unnecessary functions and 
environmental changes, the better.
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]