Beta 2.9.0.24 - when I am in Scrivenings mode and scroll through the documents in the editor, the cursor automatically moves to whatever document is currently in view. I often scroll up and down through Scrivenings and then just press the arrow key to get back to where I was working, but that no longer works - the cursor now shows up in whatever document is displayed on the screen. If I scroll back to view the document where I was working, the cursor is back in the right place in that document. But that means I have to carefully scroll back to that document, rather than getting there just by pressing the arrow key.
I’m not sure if this is a bug or intended, but it seems to me to reduce functionality. If I want to edit in the document I’ve scrolled to, I’m going to click in that document at the point I want to edit, so having the cursor go there automatically doesn’t help.
This is by design, and funny enough the old behavior was also reported as a bug and the current behavior was requested. The current behavior is also the MAC and Scrivener v1 behavior.
So far as all is OK with cursor behavior in a single document, the matter is hardly worth further discussion. Even though some switcher (i.e. option) for this behavior could possibly be a great decision—say, in v.3.6 or 4.1. )
I find the “correct” behaviour baffling since the focus is jumping all over the place based solely on scrolling without much visible indication of where the cursor is now located (no other software that I know of does that). I use to scroll a lot and find it useful for the cursor to stay put in one place, since the page will scroll back to that place as soon as you start typing again.
The “correct” behaviour is also very annoying when working near the split between two files, because Scrivener always wants to move the cursor to the file visible at the top of the window at the slightest scroll.
I couldn’t believe this was behaviour in v1, but it is so. I got so used to the “buggy” way of v3 betas I guess. To me, it just makes sense that the cursor position doesn’t change unless you click somewhere or move it using keyboard keys.
I understand that now there would be people entrenched on both sides adoring both behaviours, and the only real solution is to provide a toggle mode option (as biblioman suggested) to switch between “correct” and “buggy” behaviours.
Frankly speaking, I am not sure such a problem could be solved by a switcher—just because it is about some fundamental principle, not an option. Even thoug I find the point you framed totally right: «the cursor position should not change unless you click somewhere or move it using keyboard keys». What is more, yes, it is this behaviour (cursor does not move with page scrolling) that seems common practice.
Why would you say it can’t be solved by a mode? I don’t think this is a difficult problem technically speaking. There was a bug altering the behaviour, so it doesn’t seem to me that some fundamental change is required. Just bring up that bug back and make that behaviour optional.
To further the argument for the behaviour that keeps the cursor is place, I would like to cite the WCGA 3.2.1 Criterion (I know Scrivener is not a web-page, but accessibility guidelines are pretty universal):
It’s not an exact match to the current situation, but it boils down to “reducing the chance that a change of context will occur unexpectedly”. And I think changing focus on a simple window scroll is unexpected.
Here, I type on one file, then scroll down a single line, and the cursor jumps into a different file altogether. If this is not unexpected, I don’t know what is:
Also, Microsoft has written extensive interaction guidelines for Windows applications and there is section on Mouse and Pointers and specifically on Mouse Wheel, and it says:
So, to recap. I think the behaviour when the cursor position is changed when scrolling in Scrivenings mode is wrong on three accounts:
This behaviour does not seem to be a common practice among text-editing or other software, and most users would be unfamiliar with it.
This behaviour is arguably breaks accessibility guidelines by introducing unexpected focus changes without an explicit user intention to move the focus.
This behaviour breaks Microsoft guidelines for Windows application on not changing input focus when using the mouse wheel.
The best outcome, as I see it, would be to return to the “buggy” behaviour for the Windows version of Scrivener when the cursor doesn’t move on scrolling. If that is not entirely possible, since it would be a big change for the Scrivener user base who came to rely on this behaviour, a switch that toggles the behaviour between moving and not moving the cursor would be the second best solution.
Virescent, I just love your last reply—both the approach and, especially, arguments. If I were the delelopers, I would definitely follow you proposal. But as long as I am not, I can only express some doubts. Of course, I do not think getting back to the ‘correct’ behaviour is a fundamental technical problem. What I meant (and I would be happy to be wrong), there is hardly possible to have both versions available for the customers (i.e. to permit toggling between them in Options). If so, it is a fundamental choice point for the developers, bearing in mind not only the party of ‘happy users’, but the expected concordance with the OS version interface.
Again, from my point of view, the concordance with the vast majority of text editing apps for Windows (from text-editors and word-processors to big layout systems like InDesign) should be the highest priority in this case. But there are probably some other priorities that make the decision not so easy. An extra option (in Options )) could be great, but, as I said, I doubt this is optional. )
The devs have already stated that the bug has been fixed so that its behavior matches the Mac behavior. THAT IS SPEC. The Windows version is not supposed to be adding differences in if not absolutely necessary.
If you want to argue that both versions should do it differently, Wish List is the right place to have the argument.
(1) I don’t think anybody in this thread is in a position to argue with the devs, except the devs; (2) I do not think reasonable comments about buggy or seemingly buggy (in any case, not standard), behaviour are related to the wish list. Moreover, some further important details were added above after the devs’ statement. And this is just a position of a few (or possibly more than a few) customers on the specific theme for the devs to hear—just what this section of the forum is intended for.
This is unusable like this. I can’t predict where the cursor will end up and I change things that I did not intend to change. The scrolling and focus seems to be flying all over the place and if this is not resolved I will have to discontinue using Scrivener.
EMPisek, I am afraid the point of this discussion is not a bug (which is to be eliminated in the relise), but rather a conceptual problem—see Virescent’s posts above (and Tiho’s official statement )).
I have only just begun using WinScriv, and hadn’t noticed this behaviour until now.
I have Scrivener open on my Mac (3.1.4) and Windows (1.9.14) at the moment - I can confirm that, on the Mac, scrolling through a Scrivenings session with the Trackpad/Mouse does not move the cursor focus. Nor would I want it to - what if I’m typing and want to check something just a few lines lower, scroll down and then start typing, only to discover that by shifting my screen a few pixels lower the cursor has jumped to a new position? @Virescent’s example illustrates this perfectly. Makes no sense to me at all!
As I said, the Mac behaviour is that the cursor is not moved until the user moves it. Which is surely how it should be, and I hope the behaviour that is incorporated into WinScriv.
I appreciate tiho_d mentioned that this was a requested feature - but those people were clearly crazy
I am using the non beta. The behaviour is the same.
The specs are not sacrosanct. If something is in the specs it doesn’t mean it’s correct or proper. The specs can and do hold (often yet undiscovered) errors.
In my opinion, this thread does not belong in the Wish List, since it involves changes to the existing functionality, not new functionality.
However, I’m not arguing that the specs are wrong, or that something needs to be added to both versions, or that the devs must implement this or that, I’m simply arguing that this behaviour (jumping cursor when scrolling) should be considered a bug, since it disrupts the workflow (as I shown above). What the devs ultimately do (if they decide to fix it or re-assess their previous statement that this is an intended feature), I’m not in the position to influence.
I stated my points on why I think this behaviour is buggy and would love to hear from devs if they agree with me.
Also, to further my arguments above, I came up with a fourth (somewhat anecdotal) point:
In a neighboring thread (can’t remember which one) I’ve read that one of the pillars of Scrivener’s design philosophy is the goal that software should fade away and writers can lose themselves in their work, writing. The issue with the jumping cursor directly contradicts this principle – I’m required to keep track of the cursor’s position and can’t fully concentrate on writing.
Which release do you mean? There was a line in the Beta 25 release notes which seemed to refer to the bug we are discussing:
However, the cursor was still jumping in Beta 25 (and 26 for that matter), and I’m not sure if the release notes were wrong, or the issue fixed was something else entirely.
Not crazy, not at all. A habit can be a very strong force. If some users got accustomed to the cursor-jumping behaviour and habituated to always tracking where their mouse cursor is positioned when scrolling, they would find the other behaviour (which we argue is proper), jarring and confusing. If you are used to doing something in a certain way (no matter how many contortions you need to go through), changing the pattern will cause discordance and an understandable desire to go back to the learned behaviour.
I would agree, though, that those people were too eager to request the jumping behaviour back, without trying it out first to see if the new behaviour makes their workflow better even if it seemed liked a bug at the first glance (lessens the cognitive load since there is no need to consciously track the position of the cursor).
I meant Beta 25 indeed when I was writing that. But in fact what I meant is that the developers have already stated they regarded the behaviour in question as normal, that is why:
(1) starting from tiho_d’s statement this discussion is no more about a bug, but about some strategy/conceptual matter. Say, about need for Scrivener to meet any general Windows interface convention in each specific case—and cases where the developers prefer not to;
(2) I did not expect any change in Beta 26.
Once again, I agree with you and the people who have written (above) that the dev’s current choice doesn’t seem grounded enough—at least, some very serious arguments seem not to be taken into account. Hopefully, this important discussion will be started again—maybe, after the v3 for Win official release. By the way, I visited their Wishlist recently—it seems—quite unexpectedly—an appropriate place for such a discussion, even though it is not about a ‘wish’. ))
Thank you for clarifying. However, I’m confused now – if the developers stated this is a normal behaviour, what did that line from Beta 25 release notes refer to? That description matches nicely with the jumping cursor (auto-switching to a new document moves the cursor). However, the auto-switching still happens when you scroll, so it wasn’t really fixed.
Also, Kinsey states that on Mac, scrolling does not move the cursor between the documents, and this contradicts what tiho_d said (that the default Mac behaviour is to move the cursor).
Interesting. Can we move this thread there or should we start a new one then?
The current behavior is also the MAC and Scrivener v1 behavior.
,
