mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #127] [Suggestion] Improve tag display #86
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#86
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tminich on GitHub (Jun 12, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/127
Thanks again for adding the tags header, loving it =)
There's two small things I thought of while actually using it in regards to mailpit's frontend:
-- Basic: color by hashed name.
-- Manual color from name: A tag called something akin to
<#FF0000>I am redwould be colored red (and the color part stripped for displaying the name)@axllent commented on GitHub (Jun 13, 2023):
Nice suggestions @tminich, thanks.
Tag placement
I get your point, and yes, this could be done with relative ease and makes sense to me. I assume you mean something like this?
For the most part that won't add must additional space usage as most emails have at least two lines of from/to addresses. It's only when dealing with longer email subjects is there the potential of additional space being taken up, and of course mobile view (though I'm not too sure how many actually view Mailpit from their phones).
Tag colors
This is a more difficult one. A manual color as part of the tag name isn't an option as tags are physical stings stored in the database with every message, and grouped & filtered as such.
Setting a generated color based on their hash is possible however. Each tag color here is calculated via color-hash using the tag name. In my first test it was too (CPU) expensive to generate the hash for each tag displayed on-screen when receiving a stream of new messages, however I changed that to cache color results in an array and use the array to look up the tags - this was much faster (in fact similar to without any colours). See below for my first color test:
My concern here not everyone may appreciate the vibrant colors. Whilst they are (in my test above) limited to a certain darkness to ensure readability, still many of them are too light to pass accessibility standards.
I played a bit more with the colours to get them even darker which proved more successful, although the color differences between them are less:
I personally find these colors a bit too dominating int he UI to be honest. Ideally speaking this would be something that could be toggled on/off, but in order to achieve that I have to build an entire personalisation section to the Mailpit UI which wasn't in the planning, and which becomes a much larger task for (currently) just one feature. It is also worth mentioning that these tag colours are limited only to the message overview, not the tags listed down the side, nor the manual editing of tags in the message display. What are your thoughts about the tests above, and was this what you had in mind?
@tminich commented on GitHub (Jun 13, 2023):
Placement looks exactly as I imagined, perfect 👍
In regards to manual colors, to elaborate, the way I intended them was doing it the cheap way (from a programmers perspective). Internally the color tag would be, for all intents und purposes, be part of the name. Only the the displaying code would parse the tag and strip it from the (displayed) name.
Automated colors look fine by me. I personally don't mind more vibrant colors, but I agree that not everyone might agree. A user setting would of course be best to cover all bases. I don't think a whole system needs to be built around it. Mailpit is first and foremost (imo) a developer tool, so something simple like storing it in localStorage on browser level should (imo) be fine.
I fine with only the tags in the list having color, but in regards to the tag list something simple like this could work:
While I have never worked with go, Vue is the frontend framework I'm using for all our projects and thus am most familiar with. I'm happy to take a look once you settled on the basics if you want to =)
@axllent commented on GitHub (Jun 14, 2023):
Excellent. Thanks for the offer regarding Vue, but don't worry, I have it covered. You're right, I can just use browser storage to enable and retain and tag color preference, and your suggestion of the left border color is a great one. I already have a working prototype which needs just a little more testing before I merge it in. By default tag colors won't be on, however it can easily be toggled on/off (the "Tags" header above the tags on the left is now a dropdown).
@axllent commented on GitHub (Jun 14, 2023):
I've just released v1.6.18 which includes this optional color feature (plus of course the labels below the subject line). I'd say it's still "experimental" at this stage, mainly to get your feedback. Limiting colors wasn't as easy as I'd hoped, as they need to remain dark enough to read the tag text, but in the end this is more-or-less the type of colours it is generating:
The feature can be enabled/disabled here:
Please let me know what you think?
@tminich commented on GitHub (Jun 14, 2023):
Personally I wouldn't mind them being more vibrant, but I can see how others would disagree. All in all seems perfectly fine to me, great job 👍