Ty for the kind words! I completely agree with you too. Compose added a Crossfade modifier that makes it super easy to apply the animation to a content switch but it's often applied in the lazy way you mentioned.
Appreciate heads-up! I just checked Chrome on my Android device and it's all working fine for me. I don't know if I set the page up weirdly but I have to refresh the page sometimes for the videos to show up.
I've seen a few comments along the lines of wishing that the author had included examples of solutions. I wrote a very similar post recently that details both the issues with the animations, very similar to this article, as well as how I improved them.
Artists benefit hugely from the extra horsepower. My brother works in the animation industry and uses an ipad as his primary work device when travelling.
You realize of course that you are also on HN and thus this apparent dichotomous behaviour applies to you as well? I imagine you have some reason for why it doesn't and I think you'll find that it can just as easily apply to everyone else.
From what I've seen,the refractions happen in predictable contexts so I suspect that they'll be able to create shaders, etc that will limit the performance hit
I was glad to see the discussion as well but it feels like the downsides were also very understated. Working on an RN app as a native dev requires a lot of cross-domain knowledge that isn't typical for a native dev.
Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".
For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)
Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.
I wrote an app to log mileage while doing deliveries, etc for my small business. It gives me a small tax benefit at the end of the year. To make it more fun, I gave the UI a "terminal" flair.
I wrote it over the course of a week or so and I use it frequently.
It's not that it won't see the light of day for anyone else but it's a very specific niche so I doubt anyone would even find it on the app store
No hate but saying that collectors simply gather things that others made is rather dismissive. It may certainly be true in some cases but it's also very possible that true, potentially even ingenious, effort was required on the part of the collector to build, maintain, and be knowledgeable about the collection.
I had a similar thought a few years ago when trying to think of "useful" uses of NFTs. It could be great if I could buy music, etc and then play it on any streaming service via some sort of proof-of-right-to-play mechanism.
I'd like to introduce Trtl, a mobile app I'm working on with a terminal-like UI.
I don't see many mobile apps on HN but this one has a twist that I thought might be interesting to the HN community.
I recently sat down to write myself an app to record business trips in my personal vehicle and the simple use-case was an excellent opportunity to explore an old thought that a terminal interface could be a good fit for mobile.
There's a concept in the UX world loosely called "Reachability" which refers to how much of the screen the user can comfortably reach with their thumb. The idea behind it being that frequently used elements should be located within that convenience zone. A terminal-like interface, with it's keyboard-first interactive model, is very compatible with this.
Further, our fingers are also the mouse in the mobile context so mouse-centric design patterns like buttons can still be useful. One example of this in Trtl is the custom odometer entry control. It uses the keyboard for entry but you can also change the currently selected digit by tapping the UI element. The actions presented in the command lines are also tappable!
It's definitely not perfect. There are some notable UX issues to iron out, touch target sizes, discoverability, etc. Still though, I'm personally surprised and impressed by how well a terminal-like concept works in a mobile app.
1 line barely acknowledging the criticism, 4 lines defending the car whose feelings I can assume have been mortally wounded. The defensiveness around the car is ironic given how casually you threw out your needlessly negative hot-take.
I was right there with you. I was very supportive of the improving app UI standards at the time but it started to feel like a contest of whose design has more visual complexity and nuance vs the real usability.
Windows Phone in particular was a huge breath of fresh air for me (rip) and Material Design a welcome evolution that I still feel strikes a decent balance.
The saddest thing about this dismal comment is that you likely judge others negatively based on shallow opinions like this. I sincerely hope you are not in any position of authority over anyone.