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.
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.
