User request roadmap items are growing pretty long so this release aims to address a bunch of them.
Changes so far
- Add a setting to disable auto-linking IP addresses. Note that auto-linking IP addresses comes free with Android so enabling this feature will actually cause the app to strip them which is a bit slower.
- Add a new layout: full with cards. This layout is the full layout but each post is contained within a card instead of full bleed.
- Changed the UI for the post feed toolbar.
- Fixed a bug where sometimes expanding the context in the message screen would cause weird behavior.
- Fix locales being mixed together. (Attempt number 2)
Update
One of the roadmap items I am tackling is the addition of an optional post feed header. This one is challenging for a few reasons. The first is that because it’s supposed to be optional, the UI design needs to work with or without the headed. The second is that there’s a lot of moving parts with headers when the screen is this busy and complex already.
To tackle the first part I am redesigning the tool bar in the post feed screen so it will look good with or without the header.
Adding another request:
The ability to play loops in-app works generally great! However, there’s two things I’d like to see changed:
- Currently, it takes two clicks to get to playing a loops-video with sound from the post detail-screen. First a click on the link row to open the media player, then another one to unmute the video. Preferably, when a video gets opened with intent (i.e when clicking the link to open the video), I’d like it to default to the sound being on.
- Approaching the problem from another angle, I guess there’s an argument to be made that there should not be a click on the link to actually open the video player - the video player could perhaps be rendering in place of the image that shows in the post detail-screen today. In that scenario, it would be appropriate to default to muted playback, and no auto-play.
Thanks again for the great app!
The reason why Loop videos are not “inline” is because Loops support is sort of a hack at the moment as there doesn’t appear to be a public API yet. This feature is technically experimental and I would prefer to be light on integration until an API is made public (or if it’s made public).
As for the video volume request, this is a surprisingly complex topic. At first I was going to just add a way to persist video player volume but then I had deja vu and remembered I had done this previously but I removed it I believe because a user complained about it.
I think the issue stems from the fact videos are shown in a lot of different ways in the app. To simplify the problem we can group all the different places video players are used in the app into three groups:
- Feed screen, inline. Eg. post feed screen.
- Detail screen, inline. Eg. post screen.
- Video player
For feed screens I think the default should be that videos are always muted. This is because there can be many different video players on screen at the same time and also because videos can auto-play, thus video playing may be unintentional. In my opinion playing a video with audio should be an intentional action.
For inline videos on the detail screen, this is more of a grey area. On one hand you can argue that viewing a post is a very intentional action, on the other hand depending on the conditions that the user came to the details screen, playing the video may not be intentional. Eg. if a user opens the post from the history screen, there are no thumbnails so the playing of the video may not be intentional. I think my gut feeling is that videos should also always be muted by default on the detail screen as well.
Then we get to the video player screen. I think getting to this screen is pretty intentional. Eg. the user should almost always know they are playing a video if they got to the video player screen however there are some edge cases. Eg. when opening a Loops link it might not be obvious a user doesn’t know what loops are. However this is more of an edge case.
So from all of this I think the change I will make is:
- Always mute audio in any inline video player.
- Persist the volume for the full screen player and restore that volume anytime a video is open full screen.
Let me know how you feel about this.
Ok I just realizes there are some even more edge cases. Consider the following actions:
- User watches a video in the past in full screen mode and mutes the video. The app remembers this.
- User scrolls the post feed to an inline video.
- Video players but is muted by default.
- User unmutes the video.
- User taps to watch the video full screen.
Now what should happen?
Option 1. the video plays full screen but now it is muted because the app remembers from the previous session that full screen videos should play muted.
Option 2. the video plays with the same volume as when it was inline. The app remembers the volume so when the next video is played full screen it will be played with the same volume.
I think in this option 2 should happen. I think to resolve all of these edge cases it’s probably easier to consider the inline and full screen players as different “apps” with their own different states.
Inline should always obey one set of rules and full screen should always obey a different set of rules UNLESS an inline player is expanded. In the case where an inline player is expanded, the full screen player should take the settings from the inline player and also persist those settings.
Let’s try it out and see how it feels! UX is a very vibes-based thing.
You engagement with the community in building a roadmap, taking requests, and keeping us in the loop is amazing.
Even though I support open source apps, your app is amazing and I am loving it.
Thank you so much for the feedback. Open source continues to be a very complicated topic for me. On one hand it would be simple to over source the app, on the other it brings a lot of uncertainties. My current plans are to address this topic once and for all by the end of this year. It will give me more time to think about it.
Did you get around to the bug I reported on the localization quirks?
It’s still happening for me, fwiw.
Oh shoot. Sorry I never followed up with you on this. I did attempt a fix a few versions ago but it sounds like the fix did not work. I can take another look for this release.
That’s alright! I appreciate hearing you looking into it, both earlier and now.
