Making this post to track progress on the next release. Will decide on a title later.

Changes so far:

  • Fixed a bug where the navigation bar does not highlight the correct item in certain cases.
  • Fixed a bug where the open link button is visible when no image is shown in the post list.
  • Changed messages in the inbox. Messages sent by you will no longer show up in inbox.
  • Fixed some bugs that occur when viewing a link to a Lemmy post of another instance.
  • Make it more obvious when loading in the inbox screen(s)
  • Changed the “Mark as read” gesture to toggle the read state of the post. Eg. if a post is read and the gesture “Mark as read” is performed, the post will be marked as unread.
  • Added a fade effect to the bottom screen when screens are stacked together. Eg. when viewing a post from the community feed.
  • Fixed some minor bugs with people search.
  • When viewing a reply message in the inbox, added a button in the context section to make it easier to see the post of the reply.
  • Redesigned the DM system in the app completely.

Update

With how the release is going it’s seeming very likely this release will focus on cleaning up the DM experience.

The current DM experience is pretty bad. Messages are littered everywhere and it’s very difficult to follow a message chain. This wasn’t high priority since it was assumed most users are not using DMs. However as other parts of the app becomes polished, DMs are suddenly the weakest part of the app.

The current minimum plan is to group DMs with individuals together into chains at the very least. Other improvements are still up in the air.

Unfortunately, designs of the DMs will probably be limited to what the Lemmy API can provide. For instance, I was exploring an email like approach where one item is shown per message thread however there is currently no API that returns only top level message threads. Instead you can only get individual messages. Of course we can still implement this on the client however it can lead to an excessive amount of network calls.

As an example, imagine a scenario where user A and B exchange a lot of message. Let’s say they exchanged 1000 messages. Let’s say the client is configured to fetch 50 messages at a time. Given this, if the user navigates to the messages screen the client will fetch 50 messages. The client will then group all 50 messages as a conversation between A and B. However since this is just one conversation, the client will need to fetch more messages to make sure there aren’t any other conversations. This will repeat until all 1000 messages have been fetched. At this point the client is finally sure there are no other conversations and it will stop. This means that the client will need to make 20 network calls in order to load the messages screen which is pretty costly.

There are some solutions but they all vary in effort or usability. The easiest solution is to not collapse conversations in the messages screen. The downside here is usability as it would be difficult to look for specific conversations. The highest effort solution would be to group all messages on the messages screen and build a database on the client side that tracks all messages. By doing so, the first time messages are loaded might still be costly but subsequent refreshes should be relatively fast.

I’m still mulling over what to do here.

Update 2

I love you guys so I’m going to implement the best possible DM experience with no cut corners. It’s going to take some time though.

Update 3

I think I can wrap this update up sometime this weekend. I think a release is possible by Monday (Aug, 19) if not earlier.

  • mryessir@lemmy.sdf.org
    2·
    3 months ago

    Awesome dude.

    Some opinionated things just for input. Disclaimer - I have not read the signatures of messages (in terms of available attributes).

    • We may receive attributes from lemmy to group messages where one reply referes to a parent. So maybe cutting corners on some sides would be good for future efforts depending on your implementation.
    • Chained messages are nice but other clients may not have the same capability. Therefore I assume reading the prior message is enoguh context if this is more convenient implementation wise. Users of lemmy are already kind of familiar with plain email etiquette and quoting.
    • When fetching messages lazily you can end fetching more messages once the date of the last fetched message is <= last known message.
    • You do not have to stick to a magic number of 50 when fetching messages. You could start with 8 and increase the amount with each fetch. You could even allow to stop at a configurable threshold. Though if some conversation between two participants exceeds a certain amount - they should switch to a community to open up the discussion or pick a messenger. But pointing thisnout on the client would feel intrusive 😄.
    • If you have already managed to implement all these wholesome features I salute.

    Thank you for your efforts.

    • idunnololz@lemmy.worldOPM
      2·
      3 months ago

      Most of these have already been implemented. There are some edge cases I need to handle but it’s done for the most part.