jumping

[Andrew Abernathy]

Apologies for the length of this reply. It deals with a subject that  
has some fairly unique demands that I don't know have a perfect  
solution, so I'm afraid I ended up touching on a lot of the issues.


On Sep 17, 2005, at 12:20 PM, Trevor Harmon wrote:

> In OmniOutliner, if I hold the Down key, the contents of the window  
> will jump by half of the window height.
[...]
> This kind of jumping is apparently by design, because I've seen  
> other Mac OS X applications, such as TextEdit and Mail, do the same  
> thing. I would prefer to see the smoother BBEdit-type scrolling in  
> OmniOutliner, but I'm willing to live with it. That was the first  
> issue.

Right, I understand what you're talking about then. You're correct -  
the paging behavior is by design. The behavior is prompted by some  
somewhat conflicting goals:

1. Stability: don't shift the view, let the user control viewpoint.
2. Context: show context both before and after the current selection.
3. Comfort: not sure of the best way to describe this, but often  
people feel uncomfortable working at the bottom of the window.

The extreme of #1 would be to NEVER auto-scroll. If the user  
navigates to a hidden row, force them to manually scroll if they want  
to view the new selection. On occasion this could actually be  
desirable behavior: imagine writing a long note on a row while  
referring to the main topic. If you're a good touch-typist, you may  
not need to see what you're typing should it extend beyond the bottom  
of the window, but instead you prefer to see the topic text while you  
mentally compose and type. (This is one reason many people like point- 
to-focus windows vs click-to-focus, so they can type in a partially- 
obscured window while referring to whatever is obscuring it.) I can  
imagine providing some way to accommodate this, but I suspect we'll  
all agree that this behavior would far more often be extremely  
frustrating for most people, hence the (near-?)universal behavior of  
auto-scrolling the view to always show the current insertion point.

The extreme of #2 would be to never move the insertion point, but to  
instead constantly auto-scroll the view such that the insertion row  
remained in the middle of the window, or some other desirable  
location within the window. You can imagine this applying even  
horizontally, such that the insertion point remains anchored in the  
exact window of the screen. It's pretty obvious that in general this  
would drive most people (if not everyone) insane. But I think again  
there is some value in there - for instance, it could be desirable at  
times to keep the selected row or even line anchored in the middle of  
the screen, auto-scrolling the view whenever you navigated to a new row.


In any case, I think it's pretty obvious that neither extreme is  
desirable in general, at least for most people. Auto-scrolling the  
viewpoint to keep the insertion point visible is the common  
modification to #1 above. From there, the reasoning is "hey, we have  
to shift the view, so how about we go ahead and shift it more than  
the absolute minimum, so that the user can see more context, and so  
that the user doesn't feel pinned to the bottom of the window as they  
type?"

The latter is in fact a common complaint we receive - when people are  
typing at the end of their document, they do remain pinned to the  
bottom of the window, and they find this very uncomfortable. (#3  
above.) We don't yet have a solution for it, but it is something that  
we do want to address in the future. (The solution might be as simple  
as always providing a dead area at the end of the document. This is  
the common request, but it also has comfort issues.)


OmniOutliner arguably has it even more difficult than apps like  
TextEdit or BBEdit (which, as you point out, have different auto- 
scroll behavior - I believe, actually, that TextEdit gets its auto- 
scroll behavior from the Cocoa frameworks, hence it being common in  
Cocoa applications). We have very clearly defined row boundaries; the  
others have paragraphs, which could be equated in this context, but  
they aren't really defined as clearly as our rows. So for us a third  
option becomes prominent: scroll enough to reveal all of the newly- 
selected row, and no more than necessary to do that. If the row is  
only one line tall, that's the same as BBEdit's behavior, but if it's  
taller it's still jumpy, although not (typically) as much as  
scrolling the selection to the center of the window.


We're open to modifying our behavior, based on our experiences and on  
user feedback. Right now we know that lots of people hate being  
pinned to the bottom of the window (I'm one of those people), and it  
seems the lesser evil. But of course some people like yourself are  
fine with it, or would at least prefer the smaller auto-scroll.

I encourage everyone who dislikes the current behavior or who would  
prefer a different behavior to send their feedback to  
omnioutliner at omnigroup.com so that it will get filed and we will have  
a better appreciation of the demand when prioritizing future changes.  
Ideally, try to identify why you dislike the current behavior or why  
you prefer the alternate behavior, as that will improve our chances  
of coming up with an approach that satisfies more people, if people  
are suggesting different approaches but for the same underlying reasons.


> The second issue is far more serious. Here's what happens if I  
> change the keyboard repeat rate to maximum (my preferred setting)  
> and run the experiment again. As before, I am simply holding the  
> Down key.
> [...]
> Now that went pretty well. Still had the half-window jumping that I  
> don't like, although it's not too bad. But let's try that one more  
> time:

Eep! I haven't seen that behavior before. And I'm unable to replicate  
it in some simple testing. Any chance I could get you to send me that  
document, for us to test against? (My apologies if you've sent a  
sample document in previously; I can't currently check our bug system  
to look for it.)

-andrew