[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:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2002-08-28 22:00:15
[Download RAW message or body]

Matt Bonyak wrote:
> 
[snip]
> > 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.

No, you missed they point: Do you always return to your home to check
whether you turned of the oven? Do you always return to check if you
closed your car by key? A simple return might prevent you from otherwise
something bad, also. 
People are lazy. They should be allowed to. A user interface should
help. The simple click was not done because of laziness, because it
looked okay! Is this really a bad example?
 
> > > > 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.

Please, gimme another definition: What do _you_ mean by getting ready?
See mine below...

> 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.  

Well... in some ui the scrollbar is also shown when the content fits in
the view. _Then_ it is not usable so it is... right, greyed out. The
browser from MS for example IIRC. And I don't know if this is bad.

> 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 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.

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

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? 

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. 
 
> 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.

Cannot give you measured timings, but you may have read above that I
differ strongly here.
 
> > 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.

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

For me "simpler to use" seems to be different...

What about this: In what situation is someone going to use the scroll
bar? If I get my usage right I use the scrollbar 
a) to find out how long the actual content is (by eyes)
b) where I am right now in the document (by eyes)
c) to get the prior/next part of the content (by key -> no eyes, by
mouse -> with eyes)
d) to get to a specific part of the content (by mouse -> with eyes)

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 ;)

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