After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 665588 - typing panel is hard to read, doesn't look good
typing panel is hard to read, doesn't look good
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Universal Access
3.3.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-05 11:46 UTC by Allan Day
Modified: 2012-05-17 17:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mockup - typing panel layout ideas (139.49 KB, image/png)
2011-12-05 11:46 UTC, Allan Day
  Details
A small proposal (50.88 KB, image/png)
2012-02-20 15:21 UTC, Felipe Erias Morandeira
  Details
Switch pattern proposal (51.61 KB, image/png)
2012-02-20 17:48 UTC, Christian Giordano
  Details
mockups - disclosure options (75.52 KB, image/png)
2012-02-21 09:41 UTC, Allan Day
  Details
Redesign a11y for consistency and smallness (287.13 KB, patch)
2012-05-09 00:15 UTC, William Jon McCann
none Details | Review
Redesign a11y for consistency and smallness (299.45 KB, patch)
2012-05-16 23:35 UTC, William Jon McCann
committed Details | Review

Description Allan Day 2011-12-05 11:46:16 UTC
Created attachment 202824 [details]
mockup - typing panel layout ideas

This was recently brought up on GNOME CC list. It's something that's been on my mind for a while.

The main problems are:

 * The relationship between headers and switches is unclear. The indentation of the switchers makes them appear disconnected from the headers. Labels are usually vertically centred with a control; we are left wondering whether it is the header or the explanation that is the label.

 * The explanation text is too far from the header and the switch (the distance is actually greater than that separating each group of controls).

 * The level of visual complexity is high due to a large number of alignment points.

I've attached a couple of alternative layout ideas which address these issues. I prefer the first one due to the greater proximity of the labels to the switches.
Comment 1 Allan Day 2011-12-05 12:21:31 UTC
CC'ing interested design parties.
Comment 2 Felipe Erias Morandeira 2012-02-20 15:21:09 UTC
Created attachment 208043 [details]
A small proposal

A few small changes to the original proposal: all items have title and (dummy) explanation, options for disabled items are not shown and options are aligned with the title.
Comment 3 Allan Day 2012-02-20 17:00:57 UTC
(In reply to comment #2)
> Created an attachment (id=208043) [details]
> A small proposal
> 
> A few small changes to the original proposal: all items have title and (dummy)
> explanation, options for disabled items are not shown and options are aligned
> with the title.

What if all options are enabled? Won't we end up back in the original situation?
Comment 4 Christian Giordano 2012-02-20 17:48:01 UTC
Created attachment 208051 [details]
Switch pattern proposal

Here the option I designed a while ago. I took into consideration all the instances of the switch widget and thought about how it could be consistently placed. So the switch is on the right not only to be sequential to its label but also to be consistent to the other instances.

I also don't understand why there should always be a description. If the label is clear enough, better to have less text.
Comment 5 Felipe Erias Morandeira 2012-02-20 23:26:41 UTC
(In reply to comment #3)
>
> What if all options are enabled? Won't we end up back in the original
> situation?

Yes, but only if all those options are enabled at the same time (I don't really know if that could be considered a corner case). In all other instances, the interface would be less crowded because only active elements would be shown.

My solution might not scale properly, so we might want to try e.g. using tabs on the side if we foresee that the amount of options would grow (in this or in other panels).
Comment 6 Allan Day 2012-02-21 09:41:25 UTC
Created attachment 208098 [details]
mockups - disclosure options

(In reply to comment #5)
> (In reply to comment #3)
...
> My solution might not scale properly, so we might want to try e.g. using tabs
> on the side if we foresee that the amount of options would grow (in this or in
> other panels).

My feeling is that some kind of disclosure is necessary for this top - there is too much content to display all at once.

Two ideas immediately come to mind (see the attachment) - 1. use a list to filter which options are displayed or 2. use expanders (which would work like an accordion).
Comment 7 Christian Giordano 2012-02-21 09:51:40 UTC
I think that hiding the disabled options is a natural solution.  It's true that if they are all enabled we are going to end up in the same situation, but it's also true that it is a very remote case.
I wouldn't be surprised if in the future more types of users will browse this panel (I already heard discussions where this could be linked from other panels) and the purpose of this exercise is also to preserve a delightful experience for the lucky ones who might not need all these support from the system.
Comment 8 Allan Day 2012-02-21 10:37:58 UTC
(In reply to comment #7)
> I think that hiding the disabled options is a natural solution.  It's true that
> if they are all enabled we are going to end up in the same situation, but it's
> also true that it is a very remote case.
> I wouldn't be surprised if in the future more types of users will browse this
> panel (I already heard discussions where this could be linked from other
> panels) and the purpose of this exercise is also to preserve a delightful
> experience for the lucky ones who might not need all these support from the
> system.

I think the question is whether all the options can be displayed without actually breaking the UI, by which I mean it (a) becomes too tall for some screens without scrolling or (b) displays an uncomfortably dense amount of information.
Comment 9 Christian Giordano 2012-02-21 10:50:05 UTC
The only options to achieve that are:

1) accordion where only 1 section is expanded at the time
2) split the panel in more tabs

But I think these are too tight requirements. The important is that edge cases don't break the UI. Having to scroll is not the end of the world, if scrolling is easy, and an "un uncomfortably dense amount of information" can be avoided, for instance, if the window expands when needed and more real estate is available. If we can design something delightful for 99.9% of the users and still usable for the 0.01%, I think we did a very good job.
Comment 10 Felipe Erias Morandeira 2012-02-21 11:42:03 UTC
> (In reply to comment #5)
> 
> Two ideas immediately come to mind (see the attachment) - 1. use a list to
> filter which options are displayed or 2. use expanders (which would work like
> an accordion).

Yep, I was thinking about that first option as well. The problem if we follow that route is that the user can not tell the state of the four main options right away. Maybe we could add a small ON/OFF label to the elements on the left list, or even move the checkbox there.
Comment 11 William Jon McCann 2012-05-09 00:15:42 UTC
Created attachment 213711 [details] [review]
Redesign a11y for consistency and smallness
Comment 12 William Jon McCann 2012-05-16 23:35:47 UTC
Created attachment 214221 [details] [review]
Redesign a11y for consistency and smallness
Comment 13 Bastien Nocera 2012-05-17 16:36:35 UTC
We're removing the text size options, and the shortcuts for increase/decrease size and switching the contrast. I'm not sure why we need to remove the text size options, but the shortcuts were supposed to be set to something by default[1], and this dialogue be the way to discover them.

Or maybe a fix for https://bugzilla.gnome.org/show_bug.cgi?id=632363 would be enough.

If you're still happy with that, feel free to commit after prepending "universal-access: " to the commit subject line.

[1]: I can't seem to find the bug, but it would be useful to point to the keyboard settings at least.
Comment 14 Bastien Nocera 2012-05-17 16:37:01 UTC
Ha, https://bugzilla.gnome.org/show_bug.cgi?id=531596#c7
Comment 15 William Jon McCann 2012-05-17 17:14:23 UTC
I don't think having a keybinding for bringing up a complex UI like this is a good idea. For one, it doesn't make sense in the login/lock screen.

These are all in the a11y menu already and are available everywhere and is relatively easily discovered.

I'm not opposed to adding a keybinding for large print or just keeping an existing one. But the scaling stuff is really hard to get right and have the shell and apps not look broken. And it isn't consistent with the presentation of the shell menu.