Design Decisions*
I was doing some bug fixing for the control center today and came across bug 442168. It is asking for a preference to be added to the control center that would allow users to change the size of icons in menus, buttons and toolbars across the desktop. I can see at least two possible valid use cases for this:
- Users with low screen resolution want to reduce the size of their icons to maximise efficiency in screen estate
- Users want to increase the size of the icons for accessibility reasons
These are obviously two conflicting use cases, where an option would be necessary to satisfy them both. However, there is some disagreement over whether this is a useful enough option to add to the UI. I can see that to some people this would be a greatly beneficial, and that if the option were to be added, even more people may end up using it. On the other hand, not including this option doesn’t have any serious drawbacks and in fact, helps us maintain a more clean and simple user interface.
A Quantitative Approach?
The problem here is that the advantages and disadvantages do not clearly out way one another. Could we therefore find a more quantitative approach to making this decision? Firstly, we might want to look at the percentage of users who would find the option useful and then compare with the following thresholds:
- 0% to x%: Not many users will choose this option, therefore not useful enough to consider adding to the UI
- x% to y%: Some users will want to change this option, therefore useful to have
- y% to 100%: Lots of users will use this option, we must have made a bad design decision somewhere
In addition to the number of users who would consider using an option, we must also look at the importance of the option per user. For example, I would suspect that some accessibility options are used by only very few people, but these options are of critical importance to those using them. The resulting decision would have to be made on an interpolation of the two sets of figures.
So the bigger question is, how do we (as the free software community) go about finding these statistics in the first place, and what is the best thing to do if we can’t agree on a decision?
* If you haven’t already done so, read Havoc’s paper on UI design choices as background
I think ranking prefs by importance might be easier than assigning an absolute score.
A useful way to approach the control center would be to force discipline as a design requirement. Say that the overall thing can’t be more than say 10 menu items, with ideally no tabs in each dialog, but at most say 3 tabs per dialog (which is pretty bad already).
Beyond that, it becomes too hard to find things, and the overall UI for desktop prefs starts to suck. Even if a case can be made for each individual setting, if there are 30 dialogs, nested in submenus and 5 tabs, then the control center ends up being crap.
Setting some fixed amount of space forces tradeoffs. Rank by importance, and include only the top N things that fit. Once there are N things, the control center is full. To add something, you have to propose what to take out.
If a setting doesn’t fit in the control center, that doesn’t mean it can’t exist. People seem to think being in the control center is somehow good or makes their app “GNOME integrated,” but that’s just wrong.
The first place to put any setting should be in a relevant context. For example, network settings might be reached from the NetworkManager tray icon menu, power management settings from the power manager tray icon, sound settings from the volume control icon, app settings should of course be in the app, and so forth.
The control center should be reserved for settings that don’t have an obvious context – I would say an example is the theme, or the desktop font.
If something doesn’t fit in a relevant context, but isn’t important enough for the control center, I can think of two more fallbacks: 1) a “unix power user” tool or “TweakUI” which would be a sort of huge dialog with multiple panes or tabs; and 2) hidden settings accessible only from gconf-editor.
So, there are at least 4 total places to put settings, and having a control center as sprawling as the current one is hardly inevitable.
One thing to think about is, is this option the only way to satisfy the use cases it’s trying to satisfy.
I mean if low screen resolution is the problem, then maybe the toolkit should automatically use smaller icons if the screen resolution is small.
If accessibility is the problem, then maybe a low-vision icon theme should just use bigger icons by default.
Those are just two other possible solutions to the problem. It just seems like those two use cases are pretty independent of each other, so it doesn’t seem like there needs to be a common solution between the two.
While there may be many cases where having such an approach would be valuable, I think it’s important to also consider for each preference that maybe the best solution is not “Yes” or “No”, but to find a more intelligent solution.
For example, in this case: Imagine a resolution-independent, display-size-aware desktop, where software could see, “I’m running resolution X*Y on a 21″ monitor.” In this case, we can determine how large each icon will appear, and how much screen real-estate will be left over. This will let us eliminate a large chunk of the users needing this preference.
Then let users customize the size of all the elements/widgets on their desktop (which is quite reasonable on a resolution-independent desktop). Consider giving themes control of this, or otherwise having “poor eyesight” preferences in general. This will eliminate almost all the remaining users of this preference.
This of course would require revolutionary changes and a huge amount of work, so it’s silly to compare it to adding a checkbox. But at the same time, it illustrates that the “best” solution is neither to add the checkbox or not add it, but to find a deeper solution to the problem. I think there are often cases like that, and thus it’s best not to become too trapped in the box of “preference or no preference?”