See www.zabbix.com for the official Zabbix site.
Death to the dropdowns
Zabbix frontend usability has been discussed a lot. While many thing can be improved, one longstanding trend has been massive overuse of dropdowns for navigation, initiating actions and multiselects. This page summarises the good, the bad and the regression.
- 1 Dropdowns as yes/no choices
- 2 Dropdowns as navigation
- 3 Activity dropdowns
Dropdowns as yes/no choices
As these are being eliminated, this is "the good" (trend).
In some places in the Zabbix frontend, dropdowns have been used to mark yes/no choices. An example screenshot from Zabbix 1.6, allowing to enable/disable users in a group:
Luckily, several of these have been replaced by checkboxes - user enabling/disabling in Zabbix 2.2:
Similarly, in 1.6, choosing IP or DNS for host monitoring was done by a dropdown:
This has been replaced by a fancy multiselect - example screenshot from 2.2:
These are not being eliminated and there does not seem to be an easy solution. Thus this is "the bad".
In several locations, dropdowns are used as navigation tools. Users very often overlook them, even up to the point of not knowing of some useful feature for years. Examples:
Administration -> General
Administration -> General -> Images
Administration -> Audit
(removed in 2.4)
Administration -> DM
Administration -> Users
Administration -> Queue
Configuration -> Actions
Monitoring -> Events
Monitoring -> Screens
Additionally, these dropdowns act immediately upon choosing an entry and navigate to another page/location - this is counterintuitive to standard dropdowns that normally allow to make a choice, but do not redirect to another place immediately.
In this regard, they are also not consistent with activity dropdowns. Navigation dropdowns act immediately after a choice is made. Activity dropdowns require pressing another button.
No clear solution with the current frontend design for this class of problems - ZBXNEXT-1496 tracks the progress.
And this is our "regression".
In many locations in the frontend, dropown is used as an activity selector - for example, mass updating hosts or deleting items. This instance is actually a sad example of a regression - current dropdown-based control was introduced in 1.8. Zabbix 1.6 and before actually used buttons. Comparing bottom area of
Configuration -> Hosts in 1.6 and 2.2:
Why are they bad?
Activity (and navigation, see above) dropdowns are worse than buttons.
- A dropdown does not immediately tell how many activities are available
- Dropdown takes more clicks than a button.
- Button: one click.
- Dropdown: one - open it; two - choose activity; three - confirm activity.
- Dropdown is harder to use.
- With buttons, it is possible to intuitively memorise approximate location of some activity ("mass update is the last")
- With buttons, it is possible to scan them while moving the mouse cursor towards them and then quickly adjust for the correct button
- With dropdown, one has to locate dropdown first, then open it. Then, correct entry in the dropdown must be located - this operation would already had been done if buttons were used
- Vertical cursor positioning for most users is harder than horizontal - especially somewhat precise positioning, as required by dropdown. Note that dropdown entries also are less high than buttons (see the image to the right).
- Buttons could also optionally have icons, allowing to recognise them even faster.
- They are not consistent with navigation dropdowns. Navigation dropdowns act immediately after a choice is made. Activity dropdowns require pressing another button.
- In several places, only one activity is available. This makes dropdowns look even worse. Some examples:
Other places with a single entry in the dropdown:
Configuration -> Slide shows
Administration -> Scripts
Benefits of activity dropdowns
So far the only benefit of using dropdowns instead of buttons has been an argument that it might work better on narrow screens if there would be a large amount of activities, and that the amount of activities could grow significantly.
This will be counterargumented below.
This section shows how activity buttons could look like, and how various potential problems with them are not existing or can be solved.
If there is single entry only, button makes way more sense:
|Current situation - dropdown||Mockup - a button|
Showing the amount of selected entries
The dropdown design uses number on the
Go button. Such a count was not available in Zabbix 1.6 (last version to use activity buttons). For buttons to come back, count has to be displayed somehow. It should mostly be a graphical design question. An example how it could look like this:
Main ideas for the design:
- count should be positioned to the left of all the buttons so the amount of buttons does not change its location
- enough space should be reserved to the left so that 4-digit count could be displayed without shifting the buttons
- some background should be provided that makes it stand out enough, but not that similar to buttons (as the mockup above is)
- background should stretch to the left to accommodate longer numbers
Item configuration page seems to have the biggest amount of actions - 6. Here's a mockup on how it could look like with buttons:
To see how longer labels could look like, Russian is considered - a mockup of the same page follows ("selected" is not translated here):
Note that both bars are 800px wide - minimum width that Zabbix frontend should not wrap at. Additionally,
Copy to... is still used here - plain
Copy... would be used instead.
The suggested approach is to do show the counter on the same background as the bar - note that it might have to be inverted in the dark themes.
Large amount of activities
Considering the main argument against buttons, large amount of activities that might not fit in the screen horizontally, let's consider the place with the biggest amount of activities. That seems to be item configuration list with 6 activities. With a dropdown it looks like this (Zabbix 2.2):
Let's compare this with buttons from 1.6:
Zabbix guidelines call for 800 pixels without wrapping. This bar is 642px wide. Even if adding the selected amount indicator would take 100px, it would be below the 800px limit.
What about larger amount of activities? In the case of the most populated activity list, it has not grown in 5 years. As that is not a guarantee that this list won't grow in the future, what would happen if it would exceed 800px?
Buttons could be easily wrapped one way or another (if really required), and in general button text should be reviewed for potentially shorter versions - see the two following sections.
There's nothing wrong with wrapping the buttons, though. In case of a narrow screen or large amount of activities, buttons could be wrapped. They could be autowrapped, or two rows could be always used, based on a hardcoded 800px limit.
Shortening the text
But let's take a look at the text on those buttons. There seems to be quite some redundancy (as these activities always act on selected entries). With some reasonable renaming, the button bar could look like this:
Mass updatehas gained ellipsis to indicate that it leads to another dialog.
As can be seen, this easily allows adding two or 3 more buttons to this bar while staying 642px wide. Spacing between the buttons could be even reduced, which would look slightly better and would allow to fit more buttons. In the screenshots and mockups default 1.6 spacing of 10px is used.
With the shorter labels we have a bit more horizontal space. Adding icons would make it very easy to spot the desired button. A mockup showing two buttons with icons:
Preferably, there would be an option in user profile "Show icons on buttons". Long term maybe even an option to show icons only, skipping text (for those narrow screens). Mouseover on buttons would show text/tooltip, explaining what the button does.