6 ms·
The window animations are really nice: https://github.com/rohit-px2/nvui/blob/main/assets/display/videos/windows.gif https://github.com/rohit-px2/nvui/blob/main
by lambdaba 5y ago
The window animations are really nice: https://github.com/rohit-px2/nvui/blob/main/assets/display/videos/windows.gif https://github.com/rohit-px2/nvui/blob/main/assets/display/v...
I wonder if it's possible to reduce duration slightly. Personally I find animations useful and a great improvement to UX but I prefer as short durations as possible. I also set 0.5x animation duration / scale on Android and it makes it feel much snappier, but don't like outright disabling them.
- systemvoltage 5y agoYes, if they're less than 100ms, sure - animations provide context to what's happening on the screen (human vision system likes to persist objects). Any longer, and I want to throw the computer out of the window.
- RayVR 5y agoI’m not a UI/UX expert but here’s my 2¢ from limited work in this area. It depends on the type of animation and the platform. A fade in that’s 250 or even 500ms can be a nice effect on mobile when it’s not blocking other interactions. 100ms is too short to be noticeable for many things and depending on the screen refresh rate and distance for motion animations you will end up with large jumps.
- systemvoltage 5y agoI disagree. This is exactly what’s wrong with modern UX/UI. I abhor fading animations, they’re just decorations.
- chrismorgan 5y agoEww, a 20MB GIF with harsh dithering artefacts. And then another 22MB in two more GIFs. All in the repository. (a) GIF is not the right format here, use a video format because it’ll produce a visually superior result (proper colour, no dithering needed—not that it actually is even with animated GIFs) and much more usable result (not autoplaying if the user agent’s configuration says not to, allowing scrubbing, showing how long the video is rather than you having to guess “is it still going, or did it start again?”, that kind of thing) in significantly less space. (b) Things like this emphatically do not belong in the code repository, because they bloat things forever despite being for demonstration only. A repository that would have been 1.0MB and cloned in well under a second is instead 46.2MB (43.8MB of GIFs and 2MB of PNGs) and took me about fifteen seconds to clone (cloning repositories from GitHub is always slower than you’d expect when you’re on the other side if the world, in AU/NZ).
- cmitsakis 5y agoI believe the best practice is to use a dedicated "media" branch for screenshots/gifs/webp. Then you can use them on your readme like this . You can rewrite history on the media branch so the files don't accumulate whenever you update them. I found this idea here: https://medium.com/@minamimunakata/how-to-store-images-for-use-in-readme-md-on-github-9fb54256e951 https://medium.com/@minamimunakata/how-to-store-images-for-u...
- chrismorgan 5y agoThat’s still going to be included in a standard clone, though at least it makes it possible to do a partial clone and exclude that branch. rjzzleep is right to point out the wiki repository as a good place to store such things, still being a Git repository so that it need not be tied to GitHub, but there’s also the option these days of editing the README in GitHub’s web interface and uploading the images or videos through that, which stores it on GitHub servers outside the repository.
- rohit-px2 5y agoHey, I'm the developer for nvui. I definitely messed up a bit putting the GIFs in the repo, I noticed it when the actions' build size increased by about 40MB (the display assets get removed now in the build). I don't know if there's a way to remove them now without removing a lot of the git history. Also about the dithering, I'm aware that the GIFs look horrible, but that was not how they looked when I recorded them, I don't know if it was Github's compression but they look a lot worse when uploaded.
- slavik81 5y agoYou can use BFG [1] or git-filter-branch to remove individual files from the history, though doing so will change the hash of every commit since the files were introduced. Whether it's worth the disruption or not is up to you. [1]: https://rtyley.github.io/bfg-repo-cleaner/ https://rtyley.github.io/bfg-repo-cleaner/
- rohit-px2 5y agoHi! I'm the developer for nvui (didn't realize this post was made, never used this forum before). The animation durations and a few other things about them are customizable if you look into :h nvui-multigrid and :h nvui-cursor. As for the GIFs, I didn't expect them to come out badly (don't know if it was compression, but they didn't look that bad when I uploaded them. I'll look into making a "media" branch.
- cmitsakis 5y agoI recommend that you try webp instead of gifs. they will probably look better.
- lambdaba 5y agoHi and thanks! I'm a NixOS user and sloppily created a package but when I run I get "qt.qpa.wayland: EGL not available", probably an issue with my build. Anyway, the default animation durations are IMO too long, at least the cursor animation, I couldn't make the window animations work, wonder if it's related to that error message. [edit] nevermind, I see there's a released build so I'll just use that and go the patchelf route
- rohit-px2 5y agoHi! If the animations are too long, you can shorten them. So for the cursor animation, the default is 0.3 seconds. You can shorten it to, let's say, 0.1 seconds by using the command :NvuiCursorAnimationDuration 0.1 That'll reduce the duration to 0.1 seconds. The animation also runs at a specified frametime in ms (divide 1000 by FPS), default frametime is 10ms (so 100FPS). You can modify this using :NvuiCursorFrametime 5, for example, for a 5ms frametime (200FPS).