Compare list-to-reader transitions

[NateEaton]

Stefan,

Mind taking a look at a couple of recent builds for me?

• Option A: (Build #584) This has a significant number of changes from 0.10.0 (that I'll go into elsewhere) but the focus here is the transition when selecting a bookmark from the list view and opening for reading. I've had plans to work on making it a smoother transition but it came to a head when I added the fav and archive buttons at bottom of the content (aligns with Readeck and personally for me is the perfect place to be reminded to decide on whether the bookmark is a favorite and/or should be archived). The initial pass at adding them left them appearing before the rest of the content loaded. This build represents fixing that and basically revamping the entire transition. This solution is aligned to Material Design.
• Option B: (Build #583) this adds a subtle transition animation. Originally the transition was one where the selected card transformed into the reader view pane but that turned out to be fundamentally flawed so this was the alternative animation solution that is architecturally sound and works.

Option A is the baseline for me next wave of changes. I'd like to get your input on whether it is worth adopting Option B.

Thanks,
Nate

@Alanon202

[Alanon202]

Hi @NateEaton!

I've been going back and fourth between options A and B, I'd perhaps give option B a slight edge. Regardless of the option, one thing that could do with a bit of work is the consistency of the animations. Not all of the transitions result in a smooth animation, which can be quite jarring.

Now, to be clear, these two A/B transition animations aren’t the only ones, there are also tiny jitters when scrolling vertically, both in the lists and the article views, I just never thought to report it this early in the game, but I might as well now we’re discussing it. I know these things are notoriously difficult to reproduce and sometimes even notice. In my defence, I have a 120Hz screen, and probably one of the smoothest Android UI experiences I’ve ever had with my Pixel 9, so to me it’s become very jarring whenever the movement is no longer glass-smooth, as it breaks with what I’m used to seeing day-to-day, if this makes sense.

To test this sort of thing I usually go through an article or list a few times to make sure everything preloads/caches, and give the app the best shot at it. Then, once I feel things are nicely settled, I flick the text or list with my finger with a fair bit of speed, and let the animation slowly decelerate and come to a stop. What sometimes happens, there’s a myriad of tiny hang-ups, stutters etc. in the deceleration that become obvious as they break with the smoothness. This is much more apparent in the article list than the article text itself, the text seems to settle in after a while and is glass-smooth more often. Granted, sometimes there are more stutters, sometimes less, depending on who-knows-what, but that’s the best way I’ve found to make these intermittent issues apparent.

I do it like this is because the issues are compounded if photos are being loaded while scrolling, and many more apps struggle with this particular challenge, hitching badly at points where images should appear, MyDeck included. That being said, there are great apps like ReadYou I’ve mentioned before, that somehow manage this challenge and others without fail and achieve a consistently smooth experience. To me it indicates this isn’t an issue with things like phone processing power, or the specific challenges of retrieving text and images from servers, etc. It might be due to debug parameters, build processes, compilers, or some other pipeline magic, or simply due to highly optimised code.

I realise this may be an impossible bar to reach with the AI tooling available, I’m not sure, and I’m not complaining about what we already have, I just thought I’d mention this aspect of the issue, since it seems you spent some time thinking about the flow of animations and the UX implications of it.

Let me know whenever you need me to look at anything else, I’ll try my best to give you a quick answer!

My best,
Stefan.

[NateEaton]

Stefan,

Thanks for the feedback. I also have a Pixel 9 and although I do some testing in the Android Studio emulator, I do at least a final test of any change on my Pixel so I know the type of issues you're talking about. That is in part what led me to this latest set of changes.

One thing I did was have one of the AI tools do an architectural comparison of MyDeck list and reading views and transitions between them vs. ReadYou. What I learned is that one of the structural differences has to do with the different purposes of the two apps. As an RSS reader, ReadYou is optimized for quickly scanning and quickly moving between articles, whereas MyDeck is architected for what it's intended, a deeply immersive reading experience for each individual article. The bottom line was that adopting the architecture used in ReadYou would not improve the immersive reading experience in MyDeck and in fact could cause more issues than it solves. Of course, I'm having to take that on faith and trust in the tool, but I did do a follow-up inquiry with a different tool and got a confirmation.

Anyway, I do plan on doing more work on the smoothness of the app. As far as scrolling, I think one of the challenges is that the app is built around Compose with lazyloading of content and images. This can work beautifully but I think it can also cause some of the things you're seeing. One of the things I have planned is to research whether there are knobs and dials around pre-caching of assets that this architecture supports that could improve the experience.

Your comment about debug code got me thinking. Would you mind going back and installing the 0.10.0 release and looking specifically at the behavior you're talking about in terms of scrolling in the list and scrolling in an article with images? If it seems better there than it does in the latest builds, then perhaps part of it is the overhead of all the debug code in those builds.

There is one other thing you could help take a look at. Try build #587. In it, I have completely redone how labels are added. Instead of an auto-complete model similar to the native Readeck UI, I shifted to a sheet showing existing labels to select from, similar to the way Pocket worked (as best I can recall) and similar to the way that Instapaper and Keep work with their tags. The mental model is basically picking from your existing labels when adding them to a new bookmark or editing them on an existing bookmark via the details page. To add a new one, typing a name into the search field will search for existing ones matching that string, but if there is no match, it provides an option to create a new one. Just hit enter or click on the create label line to add the new one and hand it selected. Editing label names and deleting label names is still handled through the label filter sheet either by long pressing on a label there to edit or delete or filtering the main list on a label and using the overflow menu options for edit or delete. Chips showing selected labels on the add bookmark dialog and on the bookmark detail page are still there and you can remove a label by clicking on the chip. I wasn't really satisfied with the autocomplete solution to begin with and had only started with that based on following Readeck pattern. I actually like this much better. I'm interested in getting your feedback on it.

One other thing about the label sheet I'd like to get your take on is canceling and accepting. Right now the back arrow cancels any changes made in the sheet and the done button at the top right. Saves them. An alternative I considered were just having any changes automatically saved when you hit the back button and not having a done button. The way it works now makes sense to me but I am concerned that somebody might miss the back button and hit back and then be confused about why the things they selected don't show up. I just had that same experience this morning in the ecobee app. When I changed which room sensors were assigned to a schedule and later went back and looked and they weren't in use. I should have hit the Save button at the top right but I had just hit the back button to exit back out to the prior page.

Regards,
Nate

@alanon222

[NateEaton]

By the way, there's one bug you'll see in build. 587... The label lists are not sorted. I intentionally had the labels that are selected that show at the top of the sheet in the ascending order they are added but that change apparently broke. Keeping the main list in alphabetical order so that also affects the single select label filter sheet. Once I have your feedback on this approach in general, I'll deal with fixing that.

[Alanon202]

Hi @NateEaton!

Stefan,

Thanks for the feedback. I also have a Pixel 9 and although I do some testing in the Android Studio emulator, I do at least a final test of any change on my Pixel so I know the type of issues you're talking about. That is in part what led me to this latest set of changes.

One thing I did was have one of the AI tools do an architectural comparison of MyDeck list and reading views and transitions between them vs. ReadYou. What I learned is that one of the structural differences has to do with the different purposes of the two apps. As an RSS reader, ReadYou is optimized for quickly scanning and quickly moving between articles, whereas MyDeck is architected for what it's intended, a deeply immersive reading experience for each individual article. The bottom line was that adopting the architecture used in ReadYou would not improve the immersive reading experience in MyDeck and in fact could cause more issues than it solves. Of course, I'm having to take that on faith and trust in the tool, but I did do a follow-up inquiry with a different tool and got a confirmation.

Indeed, it stands to reason that it might prove more beneficial to look at other read-it-later apps and the way they came at various issues rather than an app with a different purpose.

Anyway, I do plan on doing more work on the smoothness of the app. As far as scrolling, I think one of the challenges is that the app is built around Compose with lazyloading of content and images. This can work beautifully but I think it can also cause some of the things you're seeing. One of the things I have planned is to research whether there are knobs and dials around pre-caching of assets that this architecture supports that could improve the experience.

Your comment about debug code got me thinking. Would you mind going back and installing the 0.10.0 release and looking specifically at the behavior you're talking about in terms of scrolling in the list and scrolling in an article with images? If it seems better there than it does in the latest builds, then perhaps part of it is the overhead of all the debug code in those builds.

Tried it and it was much much better! It could very well be the debug code!

Of course it could have been placebo or a fluke, but I just barely waited until the articles all synced up before flicking through the reading list, and it didn’t seem to stutter once. So no warmup, no caching, nothing.

Then I installed a debug build to test the labels, but I didn’t look carefully and installed build 589, and the stuttering returned with a vengeance.

Then finally I installed build 588 with the label fixes and it feels substantially better than 589 or the version I tested previously and gave the feedback on. Not perfect, but again, it feels substantially smoother. There are stutters but microstutters only, if this makes sense.

This leads me to suspect the possibility that there is an issue introduced in the debug builds with the transition comparison, which then may be exacerbated further by the debug code? If that’s correct then once the label redesign is merged in main and a release apk built there should once again be no stuttering.

Of course I could be wrong and this could all be placebo... We can’t really know without more tests, but it’s definitely something to keep an eye out for.

There is one other thing you could help take a look at. Try build #587. In it, I have completely redone how labels are added. Instead of an auto-complete model similar to the native Readeck UI, I shifted to a sheet showing existing labels to select from, similar to the way Pocket worked (as best I can recall) and similar to the way that Instapaper and Keep work with their tags. The mental model is basically picking from your existing labels when adding them to a new bookmark or editing them on an existing bookmark via the details page. To add a new one, typing a name into the search field will search for existing ones matching that string, but if there is no match, it provides an option to create a new one. Just hit enter or click on the create label line to add the new one and hand it selected. Editing label names and deleting label names is still handled through the label filter sheet either by long pressing on a label there to edit or delete or filtering the main list on a label and using the overflow menu options for edit or delete. Chips showing selected labels on the add bookmark dialog and on the bookmark detail page are still there and you can remove a label by clicking on the chip. I wasn't really satisfied with the autocomplete solution to begin with and had only started with that based on following Readeck pattern. I actually like this much better. I'm interested in getting your feedback on it.

This is a great solution, one that I completely forgot about. My old read-it-later service Wallabag uses this exact model. Readwise Reader uses it too, and apparently so does Instapaper, so there's ample reason to not reinvent the wheel here. I tried using it and it was familiar instantly.

One other thing about the label sheet I'd like to get your take on is canceling and accepting. Right now the back arrow cancels any changes made in the sheet and the done button at the top right. Saves them. An alternative I considered were just having any changes automatically saved when you hit the back button and not having a done button. The way it works now makes sense to me but I am concerned that somebody might miss the back button and hit back and then be confused about why the things they selected don't show up. I just had that same experience this morning in the ecobee app. When I changed which room sensors were assigned to a schedule and later went back and looked and they weren't in use. I should have hit the Save button at the top right but I had just hit the back button to exit back out to the prior page.

The back button behaviour is exactly right to me. I also checked Wallabag and Readwise and they both do it the exact same way, with the Done button in the exact same position. So again, I feel like this is exactly right and any user would instantly feel at home with this approach.

Regards!