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.

  • idunnololzOPM
    2•6 hours ago

    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.

    • idunnololzOPM
      1•6 hours 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.