ECompEditor: Remove redundant buttons from a toolbar
Migrated from https://bugzilla.gnome.org/show_bug.cgi?id=795292. Still an issue on 3.40.1.
Stephen 2018-04-16 10:30:26 UTC
With the tabbed interface introduced to the appointment/meeting window a few versions ago, there are now several buttons that now just act like duplicates of the tab elements:
- Reminders
- Recurrence
- Attachments
- Schedule (for the "meeting" window)
These should just be removed from the button toolbar.
Additionally, it would make sense to remove the "all day event" button, since it duplicates the tickbox on the general tab, and makes less sense on the toolbar as it is divorced from the time display/selection UI.
Comment 1 Milan Crha 2018-04-16 11:14:16 UTC
Thanks for a bug report. I'm afraid this highly depends on each preference. You are right that these are "duplicated", but they help to access the function quickly and easily. It's like having a mail message action in toolbar, in the main menu and in the context menu of the message list and in the context menu of the message itself. They all do the same thing, still it makes sense to have them all. I know it's not exactly the same thing, especially when toolbar is just above the tabs, but there's no problem with it, there's plenty of free space there, thus no problem that it would hide anything important. It's just the opposite, because the toolbar contains 12 icons and you've like to drop 6 of them. It would make the toolbar pretty short, with a huge empty gap. Why not to use it for common things, easily accessible?
Comment 2 Stephen 2018-04-16 14:07:01 UTC
but they help to access the function quickly and easily
In this case they don't at all - each set of UI elements (tabs/buttons) for the listed actions are visible at the same times, exist in the same overall and fixed region, and the buttons are actually less keyboard-navigable than the tabs (which can be switched via Ctrl-PageDown regardless of caret position).
It's not the same as the other buttons - in the case of save, undo etc., those actions are not permanently visible otherwise - they're either hidden in context menus or the main menus.
They all do the same thing, still it makes sense to have them all.
It's not the same as your example of duplication in the main or context menus either - the former tends to be for "every available option", and is highly keyboard-friendly, and the latter provides only relevant (i.e. "contextual") actions for the right-clicked element, in a spatially local position.
Why not to use it for common things, easily accessible?
Because the tabs already do that now, and have other advantages:
- keyboard accessibility, as mentioned
- they are also actually a self-describing UI element in terms of click result - it's obvious that clicking a tab will change the current view - it's unsurpising UX. In contrast, a button can mean any of: immediate action, single state (e.g. paste); toggle (e.g. "toggle busy"); open new window (e.g. "print"). It almost never means "switch tab" anywhere however!
It would make the toolbar pretty short, with a huge empty gap.
It's a good thing not to have needless UI clutter - it makes finding things among the remaining buttons easier.
Why not to use it for common things, easily accessible?
If you really want to have the toolbar filled up, then other buttons for actions not entirely contextually duplicated can be put in their place. Example: attendees toggle; classification dropdown; print preview button; toggles from the view menu (tab-dependent maybe).
To be clear I think that trying to fill up a toolbar is a terrible idea, but if you really want that any of the above items would make better use of the space than the listed buttons.
Comment 3 Milan Crha 2018-04-16 14:18:07 UTC
No, I do not want to fill toolbar just to have it filled.
Those things seemed to be important and were part of the toolbar before the change to the multi-tab and I didn't see a reason to change anything on it.
I cannot speak whether they are used by other users at all. It's currently just your opinion against mine.
Comment 4 Stephen 2018-04-16 14:30:41 UTC
No, I do not want to fill toolbar just to have it filled.
It would make the toolbar pretty short, with a huge empty gap.
It's kind of implied that you don't like the idea of the toolbar having a big empty gap though.
Those things seemed to be important and were part of the toolbar before the change to the multi-tab
Absolutely - the buttons made sense before those functions were moved to tabbed pages.
I didn't see a reason to change anything on it.
At the time the tabbed interface was introduced, they became superfluous UI clutter occupying space that could at least be used for non-duplicated functions, if empty space is really undesirable. I understand of course that there could have been lots of good reasons that re-examination of the toolbar might not have happened at the same time as that UI change.
I cannot speak whether they are used by other users at all.
Unless Evolution takes a metrics-based approach to all UI changes, "maybe someone currently uses the existing UI" it's not a good reason to avoid changing it when there are good arguments for the change.
It's currently just your opinion against mine.
In terms of whether people use the buttons, or whether the UI should be changed? I'm not making any claims on the former, but for the latter, it's not a case of "I say/you say" - I've addressed every part of your original response ;)