this post was submitted on 17 Feb 2025
16 points (100.0% liked)

Summit

801 readers
7 users here now

Community to discuss Summit, a Lemmy reader for Android.

App (Play Store): https://play.google.com/store/apps/details?id=com.idunnololz.summit

APK: https://github.com/idunnololz/summit-for-lemmy/releases

Support the app

Support me on Patreon

Website: https://summit.idunnololz.com/

founded 2 years ago
MODERATORS
idunnololz@lemmy.world
16
[WIP][v1.55.0] Fulfilling more user requests (lemmy.world)
submitted 6 days ago* (last edited 4 days ago) by idunnololz@lemmy.world to c/summit@lemmy.world
9 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] GissaMittJobb@lemmy.ml 2 points 3 days ago (1 children)

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!

[–] idunnololz@lemmy.world 2 points 1 hour ago (2 children)

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.

[–] idunnololz@lemmy.world 1 points 57 minutes ago* (last edited 57 minutes ago)

Ok I just realizes there are some even more edge cases. Consider the following actions:

  1. User watches a video in the past in full screen mode and mutes the video. The app remembers this.
  2. User scrolls the post feed to an inline video.
  3. Video players but is muted by default.
  4. User unmutes the video.
  5. 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.

[–] GissaMittJobb@lemmy.ml 1 points 58 minutes ago

Let's try it out and see how it feels! UX is a very vibes-based thing.