I suggest reverting scroll changes in AnkiMobile beta 20088.3

Anki Beta Testing
1

I feel like several changes regarding scroll made in the current AnkiMobile beta #20088.3 make scrolling act worse than before, where previously there was no problem.

  1. I do not know if this change, “Prevent elastic scrolling in editor/reviewer,” is made to try to resolve some problem, but if it is just a matter of preference, I suggest it should be reverted. The elastic effect is a standard part of the iOS interface, as it is everywhere: not just Safari, but Settings, Music, Contacts, Weather, Photos, and on and on, everywhere there is scroll. When I first noticed the change, it did feel a little clunky, and it makes AnkiMobile suddenly feel non-native. I never would have come up with the idea of elastic scroll myself, but now that I am used to it, it really makes sense, as though the page is responding to touch. The sudden stop at the end breaks the illusion of responding to touch. I also feel that apps should try to adhere to the design principles of the platform they are a part of when possible. AnkiMobile has done a better job of doing so than Anki on Mac, but this change does take some of that away.

  2. “Review screen no longer fades content in/out, or animates movement to question/answer.” The removal of the scroll animation between question and answer is a step backward. It is not just a pointless animation, but it helps the mind process what is happening. When the page just sort of pops into a new position, it takes the mind a brief moment to reorient to what the eyes are seeing, whereas the scroll animation, brief though it was, was sufficient to give the eyes a visual clue of what to follow so the mind can process the change move easily.

  3. Probably related to the above, I have now found that the scroll to answer now no longer scrolls far enough to reveal all of the answer content where it did before.

  4. When scrolling to the very bottom of a card, there now appears to be no extra bottom margin. On longer cards, the content just nearly touches the edge of the viewing area, and any content on the far right, with the lack of the extra margin and no longer any overscroll, has no way to clear the blue settings gear in the bottom right corner.

I see there are some nice goodies in this update in other respects. And these changes too, perhaps you are dealing with some other problem that is not apparent to me, so I can understand those things can happen. But without knowing what the positive tradeoffs may be, my current feedback is that these changes harm rather than help the app. I prefer using the release version for it.

Thanks for considering.

1 Like
2

The fact the majority of iOS performs this way is a good argument for keeping the elastic scrolling.

For background, AnkiMobile explicitly disabled the elastic behaviour in the past, and that appears to have stopped working at one point - so it was a regression rather than a deliberate switch. I seem to recall the primary reason for disabling it was for the review screen, as page movement when a user tries to trigger a swipe gesture is distracting. I also seem to recall that at the time the change was originally made, iOS screens like the settings screen were not elastic, and thus having the bouncing made things feel less native - but my memory is hazy here, and I could be remembering incorrectly.

The change was prompted by this post:

This brings the behaviour in line with the desktop version - do you find the behaviour suboptimal there too? The animation was originally added to cover up MathJax/image loading pop-in, but those issues should be reduced now by pre-loading. Would you be able to provide a small sample deck that demonstrates the answer scrolling not working correctly?

I’ll look into the bottom margin issue, thanks.

3

How annoying the bouncing is depends on how you use Anki.

Do you expect some of the text of the front side at the same place on the back side, or not?

For example, if you use clozes, you expect the text to be in the same place on the back side when you switch from front to back. You expect only the gaps to fill up and that shows you enough that you are on the back side. There is no need for irritating extra bouncing for me as a user to realize that I have just “slid” or “tapped” to really get to the back side.

This bouncing can easier be tolerated when I “tap” for the side change. But when I want to slide for the side change the bouncing is just annoying and nothing else. So I had to switch from slide to tap, but still cloze decks are less fun than those where I don’t expect text in the same place on the front and back.

4

Well said!

5

Thank you for the context regarding the motivation for breaking from the default iOS scroll behavior. I can see it from a certain angle. Depending on 1) the nature of the content of a card, 2) the design choice of the card template, and 3) the available screen space on the device, there are many instances where there is no scroll ever needed, sometimes even for a whole deck. In such cases, the mental model a person might adopt regarding the cards would be something more akin to slides rather than a scrollable page. If so, I can respect how the elastic scroll effect would feel out of place. However, I still argue that where scroll is needed, standard scroll behavior should not be overridden.

So what can be done to accommodate both situations? A couple of probably bad ideas come to mind: 1) just pick one or the other behavior, 2) add yet another preference, 3) silently override the behavior only when certain gestures are enabled which are not well compatible. None of them are great options in my mind, but perhaps this other option, the only remaining idea I have, is that either the elastic effect or the ability of scroll itself should be disabled if the entire content can fit in the current viewport.

I like the last idea best. So two questions: 1) Can it be reasonably accomplished from a technical point of view, and 2) Should it be done? I can’t answer the first question. Assuming that the answer to that question is that it is possible and would not be particularly difficult, then I wonder whether it is the right approach. I suggest that it can be a reasonable compromise, and I think the basic idea has a parallel in scroll bars on desktops. In the OSes of the ’90s, I remember that where scroll was possible, scroll bars appeared regardless of whether the entire page was currently in view. But in more modern systems, they now appear only when there is overflow. It seems to me to be a parallel situation that scroll behavior might only occur when scroll itself is possible.

Maybe that is also acceptable to Turmfunk, as I notice in the original post that first brought up the question, the issue was stated as being in regards to situations when the entire content was visible:

I’m relatively sure that in the past on iOS, you couldn’t move a page up or down (“scroll”) if the content didn’t extend beyond the visible page. Any page, no matter how full, can now be moved up and down, which is very irritating?
(emphasis mine)

For my part, I would not likely even notice the lack of the bounce when the content does not extend beyond the visible page. I really notice it when scrolling and then the scrolling abruptly terminates at a hard stop.

I brought up several related issues in my first post, and I have not yet responded to all of Dae’s questions. I have run out of time now, but I will come back to it later for the other matters, particularly the smooth animation when scrolling to the answer rather than the sudden pop as in the current beta.

1 Like
6

Oh yes, of course, it would be a great solution to have an option, to disable the bouncing in the settings for a collection, where I use clozes or slides or only short content.

This way, the bouncing could remain default apple standard behaviour for all, who don’t have these use cases with Anki and therefore see no need to disable it or simply don’t bother to tolerate the irritations when processing a huge number of cards in their daily learning process.

Otherwise the “general standard argument” doesn’t make sense to me with any software, when the standard conflicts with certain use cases.

7

Since elastic scrolling seems to mainly be an issue when reviewing/using gestures, I’ve enabled it again in the other screens, but left it off for the review screen, which is hopefully an acceptable compromise. The change should hopefully fix the bottom margin of the review screen as well.

8

With all respect, this sounds really inconsistent even for me. If this is the only solution (no option to enable and disable it globally), even I as a proponent for no bouncing would recommend to use elastic bouncing everywhere.

With this compromise when you slide would the front page bounce anyway and the text had to fall back in place, I assume.

People like me, who use clozes a lot, will have to change von slides to taps for going from front to back and adopt the bouncing anyhow.

Not convenient, but better as inconsistency, if you ask me.

9

I really do appreciate the effort. I am really sorry to say that it doesn’t help much. Although my opening comments are given as generally true, in practice it is in reviewing where they are noticeable, as that is where the very great majority of our time is spent. I don’t think I have even seen the settings screen in months.

Edit: I am seeing the elastic scroll even in review in build 20088.5. I triple checked the version I am running, because that seems to be different than what you said about reverting except in review. Could it be that I have misunderstood what “review” means? I thought it meant the main studying part of the app. If so, this means 20088.5 is doing as I believe it should.

I still owe you some answers from your first response to me. I am testing out 20088.5 to make sure my remarks are up to date.

10

This bottom margin issue (my #4) appears to be resolved in betta 20088.5.

I would have guessed this issue (my #3) would have been related, but it is not fixed in 20088.5, so here is an example. Both of these screenshots show where the automatic scroll to answer landed for the same card, first on release (ideal) and then on beta 20088.5. The dark blue box is the answer for this card.

Release App:

release
release750×1334 52.5 KB

Beta 20088.5:

20088.5
20088.5750×1334 56.6 KB

If you wish to look into this particular example, it is card ID 1643635789794. Or do you prefer I upload an export of this one card?

11

Lastly, this regards to the change of scroll animation, you asked:

I actually have never used desktop Anki for a review session of my own. But as a guess, I expect I may never have noticed it there, for the simple reason that I don’t think any of my cards would require scroll on desktop with its ample space, compared to a not-insignificant minority of my cards that need scroll when I am on my iPhone—my main study device. On that note, this iPhone is an SE, the smallest of the current form factors on offer by Apple.

As the changelog notes a change both to the fade animation and to the scroll animation, I should clarify that it is only the scroll animation that I am talking about. I am ambivalent about the fade animation. I was under the impression that it was particularly the fade animation that was added to reduce the pop-in, and it was likewise that same animation that was causing some issues for another user’s JavaScript needs. I am fine with the change for fade.

I am only talking about the automatic scroll to #answer. The scroll previously would quickly but smoothly move to its new position, while now it simply pops into new position. Unlike the fade, which is nothing more than an aesthetic preference (now that the MathJax pop-in issue is resolved), the smooth scroll helps the brain process the changed position.

12

The report that prompted the scrolling change:

Perhaps the solution here is to animate question->answer, but not answer->next question?

Will try to reproduce the answer position issue with that card id, thanks.

13

Yes, I expect that should work well. Unlike question to answer, I do not necessarily see a benefit to animating from an answer to the next question. After years of browsing on the Internet, we are accustomed to clicking a link and it always starting at the top.

14

Hello,

I was the guy posting that issue. So I’ve updated via testflight and now there is another problem. I’m still referring to the iPadOS Version. The problem now “altered” but is not resolved. There is now a “bump” when flipping to the answer side an somehow the font-size changes (which was previously not the case).

(Please ignore the content itself)

The Problem does not occur on iOS. All Systems have the latest OS versions.

15

Did you check if this issue occurs on the basic notetype too? Otherwise I’d assume it’s caused by your template.

16

I checked. The bump still occurs with Anki’s default cloze and front/back template. But the font size seems to be a template issue which is rather frustrating, because it wasn’t there before lol.

17

I’ve made a note to try to reproduce this. To confirm, you see the same bouncing when creating a new profile in AnkiMobile and adding a few sample cards manually, then studying them?

18

Are you using a keyboard? You can scroll with spacebar in websites for example. If the template is bigger than the screen hitting spacebar may trigger scrolling. I’ve had that happen all the time when using cards that have more information on them than the screen can fit.

19

Sorry for the delay. The animated scrolling to answer should be back in the next beta.

@CUB_Luke your card templates appear to contain a lot of Javascript. Can you reproduce the issue in one of the stock Anki templates?

1 Like
20

Is that still the case on the latest build? I can’t seem to reproduce this - scrolling in the review screen stops abruptly when you reach the top or bottom of the page.

I can’t seem to reproduce this either. How about you?