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

List:       kde-look
Subject:    Re: Grey out scrollbar button when border reached?
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2002-08-28 19:23:11
[Download RAW message or body]

Matt Bonyak wrote:
> 
> On Wednesday 28 August 2002 12:36 pm, Friedrich W. H. Kossebau wrote:
> > I remember someone claiming on a kde-ml about no visual feedback whether
> > in huge lists one already scrolled at the end or just misses one,two
> > lines (searched for a reference, but failed). I then already agreed with
> > him nodding my head, but being made sensible about this I since then
> > over and over again have met this problem.
> 
> This is a peeve no doubt, but is it a serious problem?

Define serious problem ;) 

For me it is something that annoys me (as I don't handle much important
data these days). It hit me right now reading kde-ml in my email client.
When the bunch of new emails comes in in the evening I scan through the
list to find interesting topics, then dive in. But when around the
latest emails I never exactly can say whether the actual view shows
_all_ the latest, or if I miss one or two as I have no unmistakable
visual feedback by the position of the bar (BTW: what is the name of
this bar representing the view?).

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 :/

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

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. 
 
> > Would be consistent with the rest of the user interface, and signal
> > whether you are or are not at the end of the view. I still have trouble
> > whether this would be acceptable from an aesthetic(word surely
> > mispelled, where is my dictionary) POV. But might be a question of
> > usage...
> >
> > What do you think?
> 
> 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?

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

Friedrich

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