-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excessive amount of toolbar buttons in webmail message view, causing toolbar wrapping across multiple lines #117
Comments
There are some settings on the Preferences page that can turn off these spam / ham reporting buttons, which should help. Also I agree that Compose doesn't need to be on that page! |
I think the spam/ham buttons can arguably make sense to keep as toplevel buttons by default, but my suggestion is regarding the allow/deny sender buttons, those might be worth relocating to within the row of the "From" sender header maybe? i.e. they are sender-contextual rather than message-contextual. They could be a single "Block" / "Unblock" button depending on the state of that sender. |
Well that's still for the "spam/ham" message buttons, not the "allow/deny" sender buttons... (that said, in all cases, I do not think it would be truly necessary for preference toggles to exist for those (see this article), I think they should just be shown in a way that is more space-efficient by default.) Alternatively, maybe you would want to regroup some of those more niche actions into a "..." extra actions menubutton like you are doing in the messages list: |
To be clear, it’s all doable, but our time is limited right now. Once we’ve cleared some space after completing the upcoming goals, we’ll revisit less critical issues like this one. Thanks for the heads up! |
I checked the code, and the option to control spam/ham reporting buttons also controls block/allow buttons respectively in the same places. |
Testing with my personal email account's usermin 2.102 webmail interface (authentic theme 21.20.7) from your Debian repositories, I noticed that the toolbars when viewing a message are very crowded and not really adapted to most computer resolutions, whether sub-HD laptops or de-maximized windows. As you can see, the multitude of toolbar buttons are wrapping onto multiple lines, and they just look & feel "broken" from a UX standpoint:
This is not mobile-friendly either, but I'm mostly focused on at least having this look nice on laptops, for starters.
Here are a handful of suggestions to make this situation less likely to occur:
Remove the "+ Compose" button?
This is essentially a duplicate of the "New message" action visible in the sidebar.
The individual message view doesn't seem like the right context for the "Compose" action at all, especially when there is already "Reply", "Reply to all" and "Forward" that are more relevant.
"Copy" and "Move" have a folders list dropdown widget next to them. Instead, those two buttons could be a dropdown button list widget (searchable, ideally) so that you can eliminate the dedicated folders list widget; you would click one of those buttons and it would pop the list for you to choose which folder to copy/move to.
Deny/Allow sender could be put direcly next to the sender in the mail headers "From" field line, as smaller buttons or hyperlinks?
Why is Print a prime action at the top in this day and age? It seems to do nothing more than to tell the browser to Print; in that case, I would recommend just getting rid of that button, and letting the users use their web browser's regular Print action (whether using the keyboard shortcut, or their browser's main menu) instead. Most people nowadays don't even have a printer, or if they have one, they're probably the kind of folks using Outlook in a big office, I would think.
If for some reason you really want to keep it, I would suggest moving it to the bottom toolbar in the page's footer (ex.: bottom-right corner?).
By implementing those suggestions, the simplified multi-line toolbar above would all fit on a single line (from what I can see by removing the excess widgets using the web browser's inspector).
The text was updated successfully, but these errors were encountered: