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 643086 - Universal access: add dialog for zoom options
Universal access: add dialog for zoom options
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Universal Access
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 622414 653170 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-23 16:22 UTC by Joseph Scheuhammer
Modified: 2012-01-21 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
User interface file for zoom options dialog (28.99 KB, application/octet-stream)
2011-02-23 16:26 UTC, Joseph Scheuhammer
  Details
User interface for zoom options using tab panel (25.63 KB, application/octet-stream)
2011-02-23 17:52 UTC, Joseph Scheuhammer
  Details
Patch to universal access panel for launching zoom options dialog (42.10 KB, patch)
2011-03-11 16:01 UTC, Joseph Scheuhammer
none Details | Review
Patch to universal access panel for launching zoom options dialog (v2) (45.99 KB, patch)
2011-05-19 14:01 UTC, Joseph Scheuhammer
reviewed Details | Review
a screenshot (49.15 KB, image/png)
2011-07-12 14:08 UTC, Matthias Clasen
  Details
another screenshot (37.42 KB, image/png)
2011-07-12 14:08 UTC, Matthias Clasen
  Details
the other tab (35.31 KB, image/png)
2011-07-12 14:09 UTC, Matthias Clasen
  Details
Screenshot: mag factor slider with mag factor at 7.81x (119.06 KB, image/png)
2011-07-22 20:10 UTC, Joseph Scheuhammer
  Details
Crosshairs: intersecting and not intersecting mouse (27.75 KB, image/png)
2011-07-22 20:10 UTC, Joseph Scheuhammer
  Details
Patch to universal access panel for launching zoom options dialog (v3) (66.29 KB, patch)
2011-08-03 19:51 UTC, Joseph Scheuhammer
committed Details | Review
Implementation of hbons' mockup. (83.83 KB, patch)
2011-11-23 15:20 UTC, Joseph Scheuhammer
none Details | Review
Implementation of hbons' mockup using radio buttons for mouse tracking (85.70 KB, patch)
2011-11-23 15:21 UTC, Joseph Scheuhammer
none Details | Review
Implementation of hbons' mockup using radio buttons for mouse tracking (83.53 KB, patch)
2011-12-06 20:33 UTC, Joseph Scheuhammer
none Details | Review
Implementation of hbons' mockup using checkboxes for mouse tracking (83.72 KB, patch)
2011-12-06 20:35 UTC, Joseph Scheuhammer
none Details | Review
modified screenshot (68.79 KB, image/png)
2011-12-08 10:12 UTC, Allan Day
  Details
Implementation of hbons' mockup with allan's layout suggestions (84.34 KB, patch)
2011-12-18 06:08 UTC, Joseph Scheuhammer
committed Details | Review

Description Joseph Scheuhammer 2011-02-23 16:22:15 UTC
The Zoom section of the "Seeing" tab in the universal access settings has a hidden "Options" button that invokes a dialog for additional magnifier preferences.  That dialog needs to be implemented.
Comment 1 Joseph Scheuhammer 2011-02-23 16:26:37 UTC
Created attachment 181720 [details]
User interface file for zoom options dialog

Here is the .ui file for the zoom options.
Comment 2 Bastien Nocera 2011-02-23 17:24:03 UTC
This seems to be an attempt at fitting every single magnifier setting into the smallest space imaginable. This isn't going to work.
Comment 3 Joseph Scheuhammer 2011-02-23 17:52:02 UTC
Created attachment 181729 [details]
User interface for zoom options using tab panel

> This seems to be an attempt at fitting every single magnifier setting into the
> smallest space imaginable. This isn't going to work.

Okay, how about using a tabpanel to parcel up the real estate?
Comment 4 Joseph Scheuhammer 2011-03-11 16:01:12 UTC
Created attachment 183160 [details] [review]
Patch to universal access panel for launching zoom options dialog

A start at a user friendly magnifier options dialog.  I wasn't sure about making it a CcPanel so I opted for a GtkDialog.
Comment 5 Matthias Clasen 2011-04-15 23:01:32 UTC
Some initial impressions:

- The dialog lacks padding

- The '(x)' in the Magnification label looks out of place, I'd just drop it

- Also, I think it would look nicer to make the slider closer to the style of sliders in e.g. the mouse panel:

  Magnification:  None |---------------<>-----------------| Maximum

- The 'content scrolling' radio group is very hard to understand; I don't have an immediate proposal, but this should be reworded in some easier to understand way

- Also, how does the 'content scrolling' group interact with the 'scroll at screen edges' option ?

- I was surprised by how the 'view position' interacted with the 'loupe' feature. For the loupe, I had really expected a smaller region around the pointer to be magnified. That choice should be added, I think

On the crosshair tab

- You should do away with the excessive opacity slider, and just use the GtkColorButton support for opacity

- the length slider also looks quite excessive; could just use a short/long/fullscreen combo

- similar for the thickness: could just do a hairline/thin/thick combo

- I have no idea what the 'clip' option does
Comment 6 Matthias Clasen 2011-04-15 23:05:18 UTC
Oh, one more problem: the options button needs to be sensitive even when zoom is turned off, else it is impossible to explore the options
Comment 7 Matthias Clasen 2011-04-15 23:08:35 UTC
Here is some more feedback from others:

- Most of the options are entirely non-understandable

- Make some choices for meaningful options, and fit them on one page

- Of all the crosshair options, just the 'Show crosshair' checkbox seems worth keeping, just put that on the main page
Comment 8 Joseph Scheuhammer 2011-04-26 20:57:26 UTC
Thanks for your comments, Matthias.

I will reply to your earlier comments as well, but I wanted to first address the feedback from "others" about dropping the crosshairs. While I completely agree with the need, in general, to simplify user interfaces, the extra customizability is justified due to the diversity of abilities among low vision users. The Magnifier (like most magnifier products) is really a "Screen Enhancer" since its crosshairs and other features make GNOME Shell more usable by people who may not even need magnification per se.

To provide some concrete detail, I conferred with our resident Occupational Therapist to describe some of the visual conditions that would be addressed by the crosshairs feature:

<START QUOTE>

Diabetic Retinopathy (DR)
-------------------------
See picture from this link: http://www.nei.nih.gov/health/diabetic/retinopathy.asp for how a client with DR sees. For clients with DR, having a pointer without any enhancements, can result in the pointer being lost in one of their blind spots. A short cross hair pointer can also fall within areas of their visual field they cannot see. Allowing adjustments in the length and thickness of the cross hairs will allow them to have parts of the cross hairs/pointer that fall within visible parts of the visual field making it easier to see/find/follow the pointer.

Nystagmus
---------
See info about this eye condition here: http://www.nlm.nih.gov/medlineplus/ency/article/003037.htm. Many clients with nystagmus have difficulty focusing on the pointer due to the jerky movements of the eyes. The jerky involuntary movements are usually greater when focusing on a smaller target, e.g., a small pointer. Other clients have difficulties when having to make large saccades (i.e.,
movements) in their visual field (i.e., when moving their eyes from the left side of the screen to the right side). Thus, having the cross hairs that take up the full screen can make it difficult as well. Pending on how the nystagmus presents, it is important to have the adjustability with the cross hairs - need cross hairs available in various thicknesses & length.

Cataracts
---------
See picture from this link: http://www.nei.nih.gov/health/cataract/cataract_facts.asp on how a client sees when they have Cataracts. Being able to change the opacity of the cross hairs (i.e., making it more solid) allows a client who sees everything blurry to locate and follow the pointer with greater ease.

As you see from the examples I provided above, there should be the ability to adjust how the cross hairs are presented. There are MANY other eye conditions that I have not mentioned that are presented differently. I would recommend keeping / allowing for adjustments in the colour, length, thickness and opacity of the crosshairs in order to allow customization for the user based on their needs.

<END QUOTE>

And that's just crosshairs.  All the functionality in the magnifier was implemented in order to allow screen enhancement for a variety of users with different needs and abilities; and the options dialog that I proposed was meant to cover them.

Anyhow, as I said above, I will address your earlier comments individually in the coming days.
Comment 9 Joseph Scheuhammer 2011-04-26 21:05:23 UTC
(In reply to comment #6)
> Oh, one more problem: the options button needs to be sensitive even when zoom
> is turned off, else it is impossible to explore the options

I agree completely.
Comment 10 Joseph Scheuhammer 2011-04-29 13:27:07 UTC
(In reply to comment #5)
> Some initial impressions:
> 
> - The dialog lacks padding

Okay, I'll add more.

> - The '(x)' in the Magnification label looks out of place, I'd just drop it

It's pretty typical in other magnifier preference dialogs that I looked at. although some use "%" (e.g., 200% for twice the size).  However, I'm not going to insist; I'll take the '(x)' out.

> - Also, I think it would look nicer to make the slider closer to the style of sliders in e.g. the mouse panel:
> 
>   Magnification:  None |---------------<>-----------------| Maximum

Dilemma:  consistency with other control panels vs. what users want, as in:  "I want to set magnification to exactly 3.55 X".  I'll research to see if there is a preference here.  Otherwise, I have no objection to switching to the more qualitative presentation.

> - The 'content scrolling' radio group is very hard to understand; I don't have an immediate proposal, but this should be reworded in some easier to understand way

It was based on a similar radio group in Mac OS X's zoom options sheet.  Compare:

"When zoomed in, the screen image moves:
() Continuously with pointer
() Only when the pointer reaches an edge
() So the pointer is at or near the center of the image"

I'll work on it to make it more intelligible.

> - Also, how does the 'content scrolling' group interact with the 'scroll at screen edges' option ?

Until now, I didn't think there was an interaction :-).  The 'scroll at screen edges' is for low vision users that want/need to see the edge of the desktop to know when they've reached it.  Normally, content scrolling will stop when the mouse pointer nears an edge.  However, for these particular users, the contents will keep scrolling to alert them of the edge.  Is "edge of desktop" is a better way to describe it than "edge of screen"?

> - I was surprised by how the 'view position' interacted with the 'loupe' feature. For the loupe, I had really expected a smaller region around the pointer to be magnified. That choice should be added, I think

There is no 'loupe' feature, or, rather, the 'view position' + 'lens mode' was not intended for a 'loupe'.  A problem with magnification is losing one's place since, when the contents are magnified, one can no longer see the entire desktop.  A solution is to use a split screen where one half of the screen is "normal" magnification.  The view position menu allows users to decide how they want to split the screen.  Adding in the "lens mode" helps even more since the user can now move that half of the screen to get a better idea of where they are.

That was not intended to be a 'loupe' in the sense of a *small* region around the mouse.  Such could be added as you suggested.  And, that would require some mods to the magnifier itself (most of the functionality is there).

Aside: a result of user testing was a request to add the ability to change the size of the lens on the fly (expand and shrink).  That's a better approach.

> On the crosshair tab
> 
> - You should do away with the excessive opacity slider, and just use the GtkColorButton support for opacity

Okay.  Proposed new label: "Color and opacity:".

> - the length slider also looks quite excessive; could just use a short/long/fullscreen combo
> 
> - similar for the thickness: could just do a hairline/thin/thick combo
> 

See my previous comment based on our OT's input:  users who need crosshairs want a lot of control over their appearance.

> - I have no idea what the 'clip' option does

The check box label needs work -- here's an explanation.  Some users use crosshairs as a way of locating the mouse pointer.  Some of those users find that the crosshairs interfere with their perception of the mouse pointer where the two intersect.  The solution is to clip the crosshairs and leave a gap around the pointer such that the hairs don't intersect the pointer image.  The trick is saying all of that in a checkbox label.  How about "Crosshairs do not intersect the mouse pointer"?  Or, "Leave gap around pointer"?
Comment 11 Joseph Scheuhammer 2011-05-19 14:01:18 UTC
Created attachment 188127 [details] [review]
Patch to universal access panel for launching zoom options dialog (v2)

> > - Also, I think it would look nicer to make the slider closer to the style
> > of sliders in e.g. the mouse panel:
> > 
> >  Magnification:  None |---------------<>-----------------| Maximum

> Dilemma:  consistency with other control panels vs. what users want, as in:
> "I want to set magnification to exactly 3.55 X".  I'll research to see if
> there is a preference here.  Otherwise, I have no objection to switching to
> the more qualitative presentation.

Our OT was pretty clear on this: magnifier users want the numerical value of the magnification factor.  I've left it as is.  However, for the crosshairs length slider, she confirmed that users don't need/want to know the exact pixel length. That slider is now qualitative and similar to the style of the other sliders.

Joanie and I worked on the wording for the mouse tracking radio buttons.

> > - You should do away with the excessive opacity slider, and just use the
> > GtkColorButton support for opacity

Done.  However, doing so loses immediate feedback in that changes to opacity is not seen until the GtkColorSelectionDialog is dismissed.  In the previous itertion where the slider was outside the colour chooser, as the thumb was moved, the opacity of the crosshairs immediately changed.  I couldn't find a way to access the opacity property the colour chooser -- if it could be accessed, then immediate feedback is possible.  Is there a way to acquire the GtkColorSelectionDialog/GtkColorSelection invoked from the GtkColorButton?  The documentation seems to indicate that it isn't possible.

Overall, I've tried to make the labels and other text more meaningful.

There should be tooltips, and help, but I didn't want to do that until the UI had firmed up.
Comment 12 Florian Müllner 2011-06-09 15:50:30 UTC
*** Bug 622414 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2011-06-22 14:39:06 UTC
*** Bug 653170 has been marked as a duplicate of this bug. ***
Comment 14 Matthias Clasen 2011-07-12 14:07:14 UTC
> Done.  However, doing so loses immediate feedback in that changes to opacity is
> not seen until the GtkColorSelectionDialog is dismissed.  In the previous
> itertion where the slider was outside the colour chooser, as the thumb was
> moved, the opacity of the crosshairs immediately changed.  I couldn't find a
> way to access the opacity property the colour chooser -- if it could be
> accessed, then immediate feedback is possible.  Is there a way to acquire the
> GtkColorSelectionDialog/GtkColorSelection invoked from the GtkColorButton?  The
> documentation seems to indicate that it isn't possible.

If it helps, I'll happily expose the dialog as a property of the button, so you can get it.
 
> Overall, I've tried to make the labels and other text more meaningful.

Thanks, it is certainly better. I still feel that we are not quite there yet. I am going to attach screenshot and ask the designers for opinions.

Btw, when playing with this in a jhbuild, I couldn't get gnome-shell to pick up any of my changes in the dialog - may just be jhbuild shenanigans, is this supposed to work ?
Comment 15 Matthias Clasen 2011-07-12 14:08:27 UTC
Created attachment 191811 [details]
a screenshot
Comment 16 Matthias Clasen 2011-07-12 14:08:53 UTC
Created attachment 191812 [details]
another screenshot
Comment 17 Matthias Clasen 2011-07-12 14:09:13 UTC
Created attachment 191813 [details]
the other tab
Comment 18 Matthias Clasen 2011-07-12 15:14:09 UTC
One thing I would really like to see is to have the 'moveable lens' be available via some modifier press, like the 'Ctrl to locate pointer' feature.
Comment 19 Joseph Scheuhammer 2011-07-12 16:20:24 UTC
(In reply to comment #14)
> ...
> Btw, when playing with this in a jhbuild, I couldn't get gnome-shell to pick up
> any of my changes in the dialog - may just be jhbuild shenanigans, is this
> supposed to work ?


It worked for me when I submitted the patch (May 19).  However, about two weeks ago I upgraded to Fedora-15, and only yesterday successfully built gnome-shell and all of the other 42 (?) modules.  Thus far, though, I can't get it to launch without crashing immediately.  So, I can't begin to diagnose why the patch doesn't work for you.  Yet.
Comment 20 Bastien Nocera 2011-07-13 15:06:04 UTC
A little UI review. I'll pass on the padding and alignment problems.

General tab:
- "Magnification:" label, this isn't how we show headings. Use a GtkFrame with a bold header instead. The main universal access panel shows that.
- Don't show the value in the scale. If using an exact value is important, show it in a separate label underneath (I doubt it is). Add "marks" at useful values.
- "Zoomed image moves with the mouse pointer" header, same problem as above. I would also remove the "Zoomed" as it's redundant.
- "Image moves with the mouse pointer" should probably be a tickbox, followed by a drop down with 3 options ("To keep the computer visible", etc.)
- "Position of magnified view on screen" should be presented more "graphically". Present it in a square, with radio buttons.

Crosshairs tab:
- The whole section need to be indented under "Show crosshairs"
- What does "do not intersect mouse pointer" mean?
- Again, heading with colons when frames with bold headers are needed
- Length is completely without units. You should probably add some marks here as well, such as "half-screen", "full-screen", etc.
- Why does thickness use a spinner and not a scale instead?
Comment 21 Bastien Nocera 2011-07-13 15:07:04 UTC
Comment on attachment 188127 [details] [review]
Patch to universal access panel for launching zoom options dialog (v2)

The patch itself is missing additions into po/POTFILES.in.
Comment 22 Bastien Nocera 2011-07-14 14:00:43 UTC
UI review was done (and removed the a11y keyword, it's just utterly silly for "Universal Access" panel bugs, which are _all_ a11y bugs).
Comment 23 Joseph Scheuhammer 2011-07-22 20:10:12 UTC
Created attachment 192500 [details]
Screenshot: mag factor slider with mag factor at 7.81x
Comment 24 Joseph Scheuhammer 2011-07-22 20:10:53 UTC
Created attachment 192501 [details]
Crosshairs:  intersecting and not intersecting mouse
Comment 25 Joseph Scheuhammer 2011-07-22 20:21:30 UTC
(In reply to comment #20)
> A little UI review. I'll pass on the padding and alignment problems.
> 
> General tab:
> - "Magnification:" label, this isn't how we show headings. Use a GtkFrame with
> a bold header instead. The main universal access panel shows that.

Sure.  I'll use the main panel as a guide; but, for future reference, where is the style guide that details these rules?

> - Don't show the value in the scale. If using an exact value is important, show
> it in a separate label underneath (I doubt it is). Add "marks" at useful
> values.

I noted above that the value is important to low vision users.  The problem with putting the value as a label is that as the magnification factor increases, less and less of the slider is visible within the magnified view.  Btu, the thumb remains in view as users move it.  See the "Screenshot: mag factor slider with mag factor at 7.81x" attachment to get a sense of what I mean.  If the value display travels with the thumb, as it does now, then the user can see the current value even at higher magnification levels.

Regarding "useful values":  since the value a specific low vision user desires is idiosyncratic, it's not clear what the set of "useful values" is.  I suspect you mean evenly spaced such 1.25, 1.50, 1.75, etc.  I doubt that low vision problems are that linear.  However, I'm doing some research to see if there is a pattern that can be used here.

Note that these points argue for using a spinner instead, since the displayed value doesn't move as the user manipulates the spinner, and one doesn't need to display a set of ticks/useful values.  What do you think about changing the magnification factor slider to a spinner?

> - "Zoomed image moves with the mouse pointer" header, same problem as above. I
> would also remove the "Zoomed" as it's redundant.

Okay, and okay.

> - "Image moves with the mouse pointer" should probably be a tickbox, followed
> by a drop down with 3 options ("To keep the computer visible", etc.)

Do you mean a "checkbox"? And, replacing the mouse tracking radio button group with a drop down?  Okay, but see below.

> - "Position of magnified view on screen" should be presented more
> "graphically". Present it in a square, with radio buttons.

So: switch the mouse tracking radio button group into a drop down, and the screen position drop down into a radio button group?  Okay, but note that users are more likely to change mouse tracking than they are to change screen position.  Having to pop open a drop down every time they want to do that is a pain.  Having immediate access to a set of radio buttons is less so.

> 
> Crosshairs tab:
> - The whole section need to be indented under "Show crosshairs"

Okay.

> - What does "do not intersect mouse pointer" mean?

See the attached graphic, "Crosshairs:  intersecting and not intersecting mouse".  The left side shows the crosshairs intersecting the mouse pointer.  The right shows them not intersecting.  I've wrestled with this label.  Any suggestions of more intuitive text are welcome.

> - Again, heading with colons when frames with bold headers are needed

Okay

> - Length is completely without units. You should probably add some marks here
> as well, such as "half-screen", "full-screen", etc.

Good idea, but it will be a little tricky since what is half-screen depends on the current screen resolution.  Assuming users don't change their resolution often ... probably a safe assumption.

> - Why does thickness use a spinner and not a scale instead?

I'll make them both scales.
Comment 26 Bastien Nocera 2011-08-01 17:24:51 UTC
(In reply to comment #25)
> (In reply to comment #20)
> > A little UI review. I'll pass on the padding and alignment problems.
> > 
> > General tab:
> > - "Magnification:" label, this isn't how we show headings. Use a GtkFrame with
> > a bold header instead. The main universal access panel shows that.
> 
> Sure.  I'll use the main panel as a guide; but, for future reference, where is
> the style guide that details these rules?
> 
> > - Don't show the value in the scale. If using an exact value is important, show
> > it in a separate label underneath (I doubt it is). Add "marks" at useful
> > values.
> 
> I noted above that the value is important to low vision users.  The problem
> with putting the value as a label is that as the magnification factor
> increases, less and less of the slider is visible within the magnified view. 
> Btu, the thumb remains in view as users move it.  See the "Screenshot: mag
> factor slider with mag factor at 7.81x" attachment to get a sense of what I
> mean.  If the value display travels with the thumb, as it does now, then the
> user can see the current value even at higher magnification levels.

Makes sense.

> Regarding "useful values":  since the value a specific low vision user desires
> is idiosyncratic, it's not clear what the set of "useful values" is.  I suspect
> you mean evenly spaced such 1.25, 1.50, 1.75, etc.  I doubt that low vision
> problems are that linear.  However, I'm doing some research to see if there is
> a pattern that can be used here.

Right. I completely understand that the levels of zoom are completely

> Note that these points argue for using a spinner instead, since the displayed
> value doesn't move as the user manipulates the spinner, and one doesn't need to
> display a set of ticks/useful values.  What do you think about changing the
> magnification factor slider to a spinner?

I'm not attached to the slider, if the spinner is more useful, and the reason for its use documented.

> > - "Zoomed image moves with the mouse pointer" header, same problem as above. I
> > would also remove the "Zoomed" as it's redundant.
> 
> Okay, and okay.
> 
> > - "Image moves with the mouse pointer" should probably be a tickbox, followed
> > by a drop down with 3 options ("To keep the computer visible", etc.)
> 
> Do you mean a "checkbox"? And, replacing the mouse tracking radio button group
> with a drop down?  Okay, but see below.

I would have used a drop down, making it look as if one was completing the sentence, but a list of radio buttons might also work for 3 options.

> > - "Position of magnified view on screen" should be presented more
> > "graphically". Present it in a square, with radio buttons.
> 
> So: switch the mouse tracking radio button group into a drop down, and the
> screen position drop down into a radio button group?  Okay, but note that users
> are more likely to change mouse tracking than they are to change screen
> position.  Having to pop open a drop down every time they want to do that is a
> pain.  Having immediate access to a set of radio buttons is less so.

I don't think that one option being quicker to access than the other will make a lot of difference, we're already in a sub-dialogue.

> > Crosshairs tab:
> > - The whole section need to be indented under "Show crosshairs"
> 
> Okay.
> 
> > - What does "do not intersect mouse pointer" mean?
> 
> See the attached graphic, "Crosshairs:  intersecting and not intersecting
> mouse".  The left side shows the crosshairs intersecting the mouse pointer. 
> The right shows them not intersecting.  I've wrestled with this label.  Any
> suggestions of more intuitive text are welcome.

[X] Show crosshair intersection

> > - Again, heading with colons when frames with bold headers are needed
> 
> Okay
> 
> > - Length is completely without units. You should probably add some marks here
> > as well, such as "half-screen", "full-screen", etc.
> 
> Good idea, but it will be a little tricky since what is half-screen depends on
> the current screen resolution.  Assuming users don't change their resolution
> often ... probably a safe assumption.

Even if those are rough estimates, I would consider it better than nothing.

> > - Why does thickness use a spinner and not a scale instead?
> 
> I'll make them both scales.

Cool.
Comment 27 Joseph Scheuhammer 2011-08-03 19:51:41 UTC
Created attachment 193202 [details] [review]
Patch to universal access panel for launching zoom options dialog (v3)

Another attempt at a zoom options dialog incorporating what we discussed above.  

Highlights:
- Changed magnification factor from a slider to a spinner for the reasons above.  Where should I document the rationale?

- Kept mouse tracking as radio buttons, but removed the "none" option.

- Used your suggestion for the crosshairs intersection show/hide checkbox.

- Added some tick marks to the crosshairs slider.

- Tried to make a "graphical" set of radio buttons for screen position, but I'm not really satisfied with the result.  There's got to be a better way -- suggestions are welcome.
Comment 28 Bastien Nocera 2011-09-21 18:43:34 UTC
Made a few changes on top of your patch. It's not ready yet though, and will need quite a bit of work in glade to be up to standards. I think that all the items can fit on a single dialogue page.

commit c01531a27c67a9e7067d7e517b061e3b926c797b
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 19:19:53 2011 +0100

    universal-access: Remove colons from frame headings

commit 8e6378ef9f6159b2aaf37cbf83d4bb1314f1cecf
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 19:19:06 2011 +0100

    universal-access: Disable zoom options for now
    
    The UI really isn't quite finished.

commit ff394b08a1d800844bf291575e3193b1ae74beb2
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 19:09:14 2011 +0100

    universal-access: Simplify colour reading code
    
    Using GdkRGBA directly, and making our own #rrggbb colour.

commit 6bc75e2ec1fc6b6a043065a55e7e34fc555a85d5
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 19:04:08 2011 +0100

    universal-access: Fix 4-char tabs
    
    Either you use spaces, or 8-char tabs, never 4-char tabs.

commit 5b47678f460f84b14c1fd5540733c5a2d4b8578b
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 18:55:02 2011 +0100

    universal-access: Simplify WID() macro

commit 16690064d25468c43e64333be124805a618c5987
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 18:54:42 2011 +0100

    universal-access: Fix style of comments

commit 810f3a97d0da41ce6bcf965ff588a86a2c86243c
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Sep 21 18:54:08 2011 +0100

    universal-access: Fix compile-time warning
Comment 29 Bastien Nocera 2011-10-25 14:09:51 UTC
Another pass at a UI review:
- Use a single tab, not two
- Only 2 headings:
  - Magnification (under which the first tab's content would be)
  - Crosshairs (under which the 2nd tab's content would be)
- Use marks to set the "Short"/"Long" markers on the crosshair length (otherwise they're not vertically aligned with the slider)
- For the crosshairs part, align the items just as in the "Pointing and Clicking"/"Hover Click" part of the main dialogue (main switch to the left under the heading, other items in normal font, to the right of the dialogue, with the switch controlling the sensitivity of the section)


Please try to follow the HIG for the spacing requirements, there's a lot of items with at least 20 pixels of white space between them, and others on top of each other.
Comment 30 Bastien Nocera 2011-10-25 14:11:19 UTC
You can easily test your changes by running "git revert 8e6378ef9f6159b2aaf37cbf83d4bb1314f1cecf".

If in doubt about your changes, feel free to come around in #gnome-design and post your screenshots as you make changes.
Comment 31 Bastien Nocera 2011-11-02 12:20:12 UTC
Updated mockup from hbons:
https://github.com/gnome-design-team/gnome-mockups/blob/master/system-settings/zoom/zoom.png
Comment 32 Joseph Scheuhammer 2011-11-23 15:20:08 UTC
(In reply to comment #31)
> Updated mockup from hbons:
> https://github.com/gnome-design-team/gnome-mockups/blob/master/system-settings/zoom/zoom.png

I have implemented a version that is based on hbons wireframe.  The trickiest bits were the checkboxes in the middle that handle the various mouse tracking modes (e.g., "Keep magnifier cursor in center of magnifier", etc.).  The logic is gnarly, but I've got something that works (see attached patch below).

However, IMHO users won't find this part of the dialog intuitive:  if a user wants "push" mode, they first have to check the "keep centered" checkbox to enable the "push" checkbox, and then check the "push" checkbox.  And, if they then want the default ("proportional"), both check boxes must be unchecked.  The semantics are not right, either.  The indentation implies that "push" is a special case of "centered".  But, it isn't, since "push" mode is not "centered" mode (and both of them are different again from "proportional").

The mouse tracking modes form a mutually exclusive set.  I think they are better represented by a set of radio buttons.  With that in mind, I've implemented a second version, based on hbons' mockup, using radio buttons (see second patch below).

A reasonable compromise?
Comment 33 Joseph Scheuhammer 2011-11-23 15:20:33 UTC
Created attachment 202001 [details] [review]
Implementation of hbons' mockup.

Zoom options dialog that implements hbons wireframe.  This version uses indented checkboxes for the mouse tracking preferences, as shown in the mockup.

Here is a screen shot:
http://clown.idrc.ocad.ca/aegis/GS-Mag/ZoomOptionsChecks.png
Comment 34 Joseph Scheuhammer 2011-11-23 15:21:07 UTC
Created attachment 202003 [details] [review]
Implementation of hbons' mockup using radio buttons for mouse tracking

Zoom options dialog that implements hbons wireframe, but uses three radio buttons for the mouse tracking preferences.

Here is a scree shot:
http://clown.idrc.ocad.ca/aegis/GS-Mag/ZoomOptionsRadios.png
Comment 35 Matthias Clasen 2011-11-24 20:10:29 UTC
Looks fairly close, except for some spacing issues. I think we should try to follow hbons' mockup and put the zoom options and the crosshair switch inline with their headings.

As for your second variant, I think nested radio groups are a little awkward. But then, so are dependent checkboxes, as you pointed out above. Maybe it would look a little better if you follow hbons' mockup and move the 'extends' checkbox up above the mouse tracking options.
Comment 36 Joseph Scheuhammer 2011-12-06 20:33:54 UTC
Created attachment 202944 [details] [review]
Implementation of hbons' mockup using radio buttons for mouse tracking

(In reply to comment #35)
> I think we should try to follow hbons' mockup and put the zoom options and the
> crosshair switch inline with their headings.

Here's a version that more closely follows hbon's wireframe, placing the magnification and crosshairs switch inline, and, also, puts the "extends" checkbox first.

This version uses radio buttons for mouse tracking modes.  Screenshot:
http://clown.idrc.ocad.ca/aegis/GS-Mag/ZoomOptionsRadiosV2.png

The version that uses checkboxes follows.
Comment 37 Joseph Scheuhammer 2011-12-06 20:35:46 UTC
Created attachment 202945 [details] [review]
Implementation of hbons' mockup using checkboxes for mouse tracking

Version that puts magnification and crosshairs inline, and places "extends" checkbox first.  This uses nested checkboxes for mouse tracking.  Screenshot:
http://clown.idrc.ocad.ca/aegis/GS-Mag/ZoomOptionsChecksV2.png
Comment 38 Matthias Clasen 2011-12-07 04:18:50 UTC
Looks good to me, just need to fix up the spacing a bit. Maybe we can get a designer to shift around the pieces of your screenshot to show some nice spacing. 

I think the labeled marks on the length slider are a bit much, maybe. Can we go with just the end labels 'Short' and 'Long' ? That would also make the slider line up much more nicely with the one above.
Comment 39 Matthias Clasen 2011-12-07 04:21:07 UTC
I'm fine with going with the radio-button version that you prefer, btw.
No need to keep producing two variants, as far as I'm concerned.
Comment 40 Matthias Clasen 2011-12-07 04:22:48 UTC
I think making the sliders a bit smaller will help with the overall balance of the dialog
Comment 41 Allan Day 2011-12-08 10:12:51 UTC
Created attachment 203048 [details]
modified screenshot

(In reply to comment #37)
> Created an attachment (id=202945) [details] [review]
> Implementation of hbons' mockup using checkboxes for mouse tracking
> 
> Version that puts magnification and crosshairs inline, and places "extends"
> checkbox first.  This uses nested checkboxes for mouse tracking.  Screenshot:
> http://clown.idrc.ocad.ca/aegis/GS-Mag/ZoomOptionsChecksV2.png

Looks good, Joseph! I agree with Matthias about the spacing and the sliders.

I've attached a modified version of your screenshot with some guidance on the layout.

You need to emphasise the three groups of controls more using spacing. If possible, reduce the vertical spacing within each group and increase it between each group.

Also try and keep the vertical spacing even within each group, particularly the checkboxes in the magnifier position section.

It would also help if you increased the horizontal spacings you have there. In the image I attached I increased the horizontal spacing between the content and the window edge by 12px. I did the same for the horizontal indent for each section.

I've also moved the screen part combobox closer to its label and removed the colon from the magnifier position header.
Comment 42 Joseph Scheuhammer 2011-12-12 21:41:42 UTC
(In reply to comment #38)
> 
> I think the labeled marks on the length slider are a bit much, maybe. Can we go
> with just the end labels 'Short' and 'Long' ? That would also make the slider
> line up much more nicely with the one above.

We are in danger of going in circles.  Back in comment #30, Bastien wrote:

> You should probably add some marks here as well, such as "half-screen",
> "full-screen", etc.

I think they're useful, but I'm not married to them, and they are easy enough to remove.  But, I want general consensus here before I take them out.  I don't want to see a subsequent suggestion, "you should add some tic marks ...".
Comment 43 Joseph Scheuhammer 2011-12-12 21:45:16 UTC
(In reply to comment #41)
Thanks Allan!

Your layout suggestions are most welcome.

The million dollar question:  was your screenshot done using glade?  If so, can you attach the glade file?

If not, I'll poke away in glade until it approximates your version (for some reasonable value of 'approximate').

Thanks again.
Comment 44 Matthias Clasen 2011-12-13 13:58:52 UTC
> We are in danger of going in circles. 

Thanks for pointing that out. I don't think we'll make the presence or absence of tick marks a blocker... but I do think it looks much more balanced without.

> The million dollar question:  was your screenshot done using glade?

I think it was probably done using the gimp...
Comment 45 Joseph Scheuhammer 2011-12-18 06:08:19 UTC
Created attachment 203771 [details] [review]
Implementation of hbons' mockup with allan's layout suggestions

Bascially, the same as the last patch, but with spacing, padding, etc. as per Allan Day's suggestions (comment #41).
Comment 46 Bastien Nocera 2012-01-21 14:27:27 UTC
Pushed with a few changes on top.