[Feature Request] Side-by-Side Interface for Email List and Email Details

[no-operation]

Currently, the Mailpit interface requires users to switch between different views to navigate emails and read their contents. While this works, it can be less efficient for users who need to manage and read multiple emails quickly.

I propose the following enhancements:

1.	Sidebar Email List: A vertical list of received emails on the left side of the screen, displaying basic information such as sender, subject, and timestamp.
2.	Detail View Pane: A detailed view of the selected email on the right side, allowing users to read the email content without leaving the email list view.

If there are any specific technical considerations or limitations that need to be taken into account for implementing this feature, please let me know. I am open to providing further details or assisting with testing and feedback.

Thank you for considering this feature request. I believe it will significantly improve the user experience for Mailpit users.

[axllent]

Thank you for your suggestions / feedback @no-operation. Whilst I think your proposal sounds like an improvement on larger desktop views, it unfortunately has significant limitations for mobile (or smaller screen) use, ie: it would not work, and would also mean less information in the overview on desktop which would also upset some users.

Mailpit is designed to cater for desktop, tablet and mobile viewing, and a lot of consideration was taken when choosing the current UI to handle all of them (as best as possible). The messages overview already has two columns - one for the mailbox & tags, and another the the message summaries. The message summaries include sender & recipients, subject, excerpt, size, relative received time, and message tags. Reducing this into a narrow column would mean we'd have to loose several of those fields, or it would either be extremely cramped or take up 4-6 lines per message.

The alternative is having two completely separate layouts (ie: selectable by the user) which sounds like a great idea until one realises just how much work goes into developing and maintaining two side-by-side interfaces (hint: a LOT).

Had Mailpit been originally written with this in mind then having a selectable interface may have been significantly easier, but that's not the case unfortunately. To now add support for this would take a significant amount of time, and is something I am not willing to spend my time on in the foreseeable future.

So I again thank you again for your suggestion, but I do not see this happening. I hope you understand?

[fabiomlferreira]

I think this is a great tip. It should be like Mailtrap, working on both mobile and desktop. Currently, when we are inside an email, the left sidebar shows the “Message date” and “Size.” These can be moved to the message header, and the sidebar can display the list of messages. On mobile, this list can be hidden. This change will make it much easier to navigate between messages.

Many mail clients, such as Outlook or the Mac Mail app, work like this.

@axllent, adding this list to the current email detail page won’t be a big change and can improve the usability of Mailtip. You already have that sidebar, it’s just a matter of changing what is displayed there.

[axllent]

That's actually a very good suggestion/idea @fabiomlferreira, and not one that includes either dual interfaces. There is still a lot to consider and a fair bit of work to do in order to make that work, but I think that's feasible.

@no-operation What do you think of this idea?

[no-operation]

@axllent I think it's a great solution, will be very useful

[axllent]

@no-operation & @fabiomlferreira - I have just pushed a huge update to add this feature. It has not officially been released yet, however it is available if you use the Docker images (using the axllent/mailpit:edge tag). Assuming either (or both) of you use Docker, please could you pull the edge version and give me some feedback?

This change was much, much bigger than I had originally planned, mainly because it ended up also requiring "live" message state changes (ie: read/unraed/deleted/tags), which resulted in a significant internal change as to how the UI communicates with websockets. The upside of this is that two separate browsers viewing the same mailbox get immediate updates when the other makes changes.

I have some more testing as well as some other unrelated changes to make, so it'll still be a couple of days before this can get released, but I'd appreciate some feedback if possible (and you use Docker) before I release anything. Thanks.

[fabiomlferreira]

Amazing work @axllent for me this is a huge improvement its way easier to navigate between emails.

[axllent]

Thanks for the feedback @fabiomlferreira - very helpful.

[axllent]

This feature has been released in v1.20.0. Given the feedback you already provided @fabiomlferreira, I will mark this issue as closed. Please feel free to leave a comment if there are issues.

[no-operation]

Perfect @axllent, this is working exactly like mailtrap, well done...

[no-operation]

I noticed a potential improvement for the message details page. When a new email arrives, the side menu list doesn't update. I'm not sure how complex it would be to implement, but adding this feature would significantly enhance the user experience.

[axllent]

I agree, but it is complicated.

Only the "inbox" view supports "live messages" because it shows all messages, and the filtered views (ie: searches) are only a subset of results so these can't be "re-filtered for every incoming message ~ so I have some thinking & work to do here.

Another issue is that in the main inbox the results are paginated, so if 10,000 messages arrive while the inbox is open, then only 50 (or whatever the user selected in the view) are shown at any time which isn't a problem for the browser. But the side navigation on the other hand does not paginate, meaning there would be 10,000 messages pushed to the top of the sidebar which would eventually crash the browser. I have to think of a way to try handle this and will need to implement some limits. I realise that 99.9% of users won't have 10k messages arriving while they are in the message view, but I have to consider (and deal with) this before I can add that feature.

[axllent]

@no-operation - This has feature been released as part of v1.20.1 👍 Note that it has two limitations (as previously outlined):

1. It will only automatically show new messages when viewing a message via the inbox
2. It will only display up to 100 new messages, after which a notification is shown prompting the user to reload the window to load more.

Please confirm his works for you?