[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 21:32:16
[Download RAW message or body]

> > 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.
>
> You know this rotating symbol at the right of a file manager /browser?
> Ever noticed when it does rotate? ;) (Man, am I cynical today, excuse me
> please.) Now, there is the instant feedback of the file manager for the
> back button. No rotation, no other content, no need to wait. I fear your
> respond fails.

I almost always notice it rotating, it's almost hypnotic!  ;)

As I responded to Aaron's latest message, as long as the change is subtle, and 
most users preferred it, it would be okay.  I've thought more on it, and I 
guess I was taking it a bit too far.

> Come on. Watch yourself. Scroll this email view to the end, now!

My personal clicking habits (which after this discourse I now suspect are much 
different than most) and what goes through my mind when I'm doing it support 
my statements.

> And, what did you do? Didn't you start with moving your eyes to search
> the position of the bar handle? And by the same watch of the bar didn't
> you get the down button in your view?

The first thing I did was move my mouse to the area out of the corner of my 
eye where I knew the button was (if it is of any consequence, my monitor is 
really big and really close), not look at the button.  Perhaps this is 
different from most...

> What I want to say: the verify in a) is also done in b) Or do you do
> handle it blindly? ;) You always have to use your eyes to prepare the
> aim for your mouse action. So you anyway check for the state of the
> scrollbar. You don't loose anything, only gain.

By my habits, you would lose more often than you gained under the proposed 
system.

> Can somebody stop me from writing "So they should stay with
> windows(tm)?"? Oh, nobody did... ;)

I had a feeling somebody would bring that up, and it's not what I meant at 
all.  I was referring to the fact that as of present, even KDE has helped to 
instill this behaviour which, to many, is slightly speedier in most cases (no 
visual confirmation first).

> In b) I often want to check whether I am at the end. I would do this by
> <pagedown> when I have the focus and my hands at the keyboard. But if
> this is not the case I point my eyes to the scrollbar...
>
> Okay, I fear this is all theoretic. As long as I do not code something
> to experience the usability we won't know what is better :/
>
> So anyway thanks for your comment although I don't agree ;)

By all means, code it; I'd certainly give it a chance.  As for situation b, 
that falls under my personal habits -- mouse over scrollbar and fingers on 
keyboard at all times, to the point of obsession-compulsion -- so it would be 
easier for me as-is.  But I guess it wouldn't be any more difficult, either.  
Like I said, I'll give it a chance.

 - Matthew
_______________________________________________
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]