emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scrolling very buggy (slider, arrows) under OS X


From: David Reitter
Subject: Re: scrolling very buggy (slider, arrows) under OS X
Date: Sat, 13 Mar 2004 11:34:47 +0100


On 12 Mar 2004, at 00:23, Miles Bader wrote:

On Thu, Mar 11, 2004 at 10:03:39PM +0000, David Reitter wrote:
Doesn't that violate the basic principle of UI design that you shouldn't do
things that reduce 'perceived stability' of the UI?

I've never heard of such a `basic principle of UI design', but then people
often seem to make those things up on the spot anyway.

For a discussion of 'perceived stability', I believe a good article would be

 @incollection{woods88cognitive,
  AUTHOR = {David Woods and Emilie Roth},
  TITLE = {Cognitive Systems Engineering},
  YEAR = 1988,
  BOOKTITLE = {Handbook of HumanComputer Interaction},
  EDITOR = {M. Helander},
  publisher = {Elsevier},
  address = {North Holland},
  PAGES = {1-43},
  KEYWORDS = {}}

You will also find information in the writings of Jakob Nielsen (www.useit.com) -- he has a whole lot, and certainly some things controversial.


The user need not be aware of the reason behind every detail of behavior.


No, not consciously aware. Behavior should be intuitively understandable.

_Scrolling_ in emacs is typically line-based, it's just _scrollbar-sizing_ (and other operations that display buffer-positioning, e.g., the mode-line
percentage display) that is character-based.


Well, then either the scrolling or the scrollbar-sizing is inconsistent behavior.

Line-based scrollbar sizing would be _really hard_ in emacs, because although it knows the number of displayed lines, emacs has _no idea_ how many lines are in the buffer (much less their `displayed size'), and calculating it is
computationally very expensive.

IMHO this seems to be the real problem.

However, given that the scrollbar / slider size give an intuitive guess of the size of the document, wouldn't it suffice to calculate how many average lines fit into the window, and how many lines a document has? And then, unless the number of lines or the size of the window changes, this wouldn't have to be updated?

I mean, most editors I know do this, even editors that come as UI widgets (such as the one I am using right now to compose this message), so calculating the slider size doesn't have to be computationally expensive.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]