Re: Low-Vision user observation

[Bryen M Yunashko <a11yrocks bryen com>]

On Mon, 2012-10-01 at 14:09 +0200, Piñeiro wrote:
> On 10/01/2012 04:52 AM, Bryen M Yunashko wrote:
> > Ok, so as promised, here's my observation of my experience starting with
> > 3.6.  Note that this was done in a VirtualBox instance and a physical
> > installation will probably happen later this week.  Here goes....
> >
> > WARNING:  Long, but hopefully insightful review.  If this review should
> > be placed somewhere else, please let me know.
> 
> Long are good, as mean more details.
> 
> Some comments and questions below.
> 
> >
> >
> > Magnifier Configuration:
> >
> > Indeed, finding my way to the Accessibility icon was easy enough because
> > I still have enough vision to get by on that.  (Note: A shipped
> > wallpaper by any distro could negatively affect one's ability to get to
> > the Accessibiliy icon if it is too bright of a wallpaper, overpowering
> > the ability to see activity bar) I had not noticed the options button
> > until it was pointed out to me.  Once I knew what to look for, then it
> > was "findable."
> 
> So any advice to have this more "findable"?
> 

Not really.  The way my vision works, it takes me time to calculate and
figure out what it is I'm seeing in everyday life.  The more familiar
the environment, the more quickly I can recognize things in my
surroundings.  The solution is as what has happened, I need to be "told"
what to look for so I can actually find it.

As an example of what that is like.  Sometimes I will see an object and
think "I'm looking at a tree."  Only later I will realize I'm actually
looking at a bike.  My brain takes longer to figure out the signals and
translate to proper vision, simply because my vision cells are not as
optimal as we'd like it to be.  :-)

> > 1.  The activity bar on top and the notification alerts on the bottom
> > are by default black.  With inverse turned on, they became white under
> > magnification.  This made them unreadable.  I could barely even see the
> > notification alert and certainly can't tell what time it is.  As I do
> > add the GNOME shell extension allowing for notification applets in the
> > activity bar, I won't be able to observe applet notifications under
> > magnification.
> >
> > Similarly, the Alt+F2 run function is also now in white and I cannot see
> > what I am typing.  Likewise, I just noticed that the login after screen
> > lokout during idle usage is also unreadable.
> 
> Yes, with inverse turned on, both became white, but in the same way, the
> text became black. So I assume that this is not enough.
> 

No it isn't because frankly, I am extremely sensitive to white (or
bright) colors, particularly when used with a backlight such as a
monitor.  They become very overpowering and a situation like this where
the area is white and the text is black, white background will overpower
the black text.  Only after staring at this for a long time will I
finally be able to see something.

Let's take a real-life example.  Imagine when you step inside after a
bright sunny day.  For a brief moment, your eyes will not be able to see
because your rods and cones need to quickly adjust to the new lighting
environment.   For those of us with retinitis pigmentosa (or Usher
Syndrome specifically in my case) it takes longer to adjust.  When I
enter a store from  outside, I usually have to wait a few minutes at the
entrance before I can proceed into the store because my rods and cones
are taking longer to do their magic.  

When there are too many elements of brightness on the monitor, I am
deeply affected in a similar way where I have to take moments to adjust
my eyes frequently as my eyes roam across the monitor.
 
> Do you have any proposal to solve this issue? Inversion is working fine,
> as far as I see, so don't know if the problem is related with the base
> color, so the lack of configurable themes on GNOME Shell itself.

I have yet to find a way to reconfigure color scheme for the activity
bar and related gnome-shell elements.  (Does it even exist?)   Indeed,
if we were to use magnification inversion, the ability to reconfigure
these elements would probably be a good solution.

> >
> > 2. The crosshairs option is nice, but I found it distracting for the
> > most part.  I suppose in all fairness if I stuck to it, after a while
> > I'd get used to it.  It was a lot easier to locate my mouse pointer than
> > a large cursor mouse pointer would be.  Nevertheless, the crosshairs do
> > interfere to some extent.  See this screenshot where configuring in
> > gnome-teak-tool, the crosshairs prevented me from seeing values as I
> > toggled up or down.  http://paste.opensuse.org/83634348 
> 
> Well, crosshairs has still room for improvement. For example, some
> people already asked that if you are not moving the cursor, or if you
> are writing, the crosshair should automatically disappear.
> 
I think that disappearing concept would be a wonderful solution.  That
would probably resolve my "Where the hell did the mouse go?!?" problems
infinitely!  However, I would love for this to be a standalone function
that does not have to be part of magnification.

As a side note, I'd like to explain how I typically work with my mouse.
I often lose sight of my mouse pointer.  So, to resolve this, I focus on
upper left corner of my monitor and then keep dragging my mouse until it
comes into my view.  Easy to drag the mouse physically in an
upward/leftward direction.    With GNOME Shell introduction of hot
corners, this proved quite problematic for me.  I resolved this by
installing GNOME Shell extension that disables this "feature."
Crosshairs would eliminate this years-long habit of mine in a good way,
though I still generally dislike the use of hot-corners in practice.

> Anyway, in relation with the mouse pointer, some other people have
> already asked that. For example, one month ago I was at a presentation
> made by ONCE about their experiences with GNOME, and how to configure it
> for some schools using GNOME. They mentioned that had some problems with
> the mouse pointer. Also about how to increase the size of the text cursor.
> 
> We should take a look to this for the next release.
> 

Unfortunately, there are some things that are just not intuitive or
logical.   For example, if you go to gnome-control-center, you'll see
"Mouse and Touchpad" under the Hardware category.  Yet, if you go in
there... umm... there's no way to actually configure the look and feel
of your mouse.  To do that, you have to go into gnome-tweak-tool.  Does
the average user know about g-t-t?  Would the user look at g-c-c, see
limitations in the hardware settings and assume "oh... that's all we can
do" and give up and walk away?

That's not exactly an accessibility criticism, more of a design
criticism.  So probably doesn't directly belong in this discussion.
However, there are often gradients between accessibility usage and
"normal" (for lack of a better word) usage, thus the confusion in g-c-c
can have a more profound effect on an accessibility user.

> >
> > 3.  Performance is a concern.  I'll be fair and not completely judge the
> > performance because I was running in virtual machine mode.  It was jerky
> > moving around, my personal performance was a lot slower because of this.
> > I couldn't just zip around.  I found myself frustrated with having to
> > very slowly push my mouse to get to where I wanted to go.
> 
> Well, as you mentioned that you are running it in a virtual machine.
> Just to mention that a virtual machine usually lower the performance a
> bit. In my computer I don't have any problem with GNOME Shell, but when
> tried a virtual machine performance became sloppy.
> 

Fair enough.  As I originally stated, I won't completely judge the
performance based on my VM experience.  :-)  Not fair to it.  
> >
> > I'm also not the kind of person who turns his machine off frequently.  I
> > work off of my computer literally 24/7 and eventually leaving the vm
> > running with magnification enabled soon chewed up even the RAM on my
> > physical machine which overall runs on 4GB RAM.  I had to do a hard
> > shutdown.
> 
> Hmmm, this sounds like something new to me. So it seems that having the
> magnification activated a long time consumes RAM. We need to check if
> that also happens without a virtual machine, and if so, that would mean
> a bug. Thanks for pointing it.
> 

Curious about what your personal experience has been when leaving mag on
for long periods of time.  What type of hardware are you using?  In any
case, the use of magnification, even minutely, would consume some level
of system resources.  Depending on the user's needs, that could be a bad
thing if they were doing many complex things.  Example, working
extensively with artwork designs.  Use of a high contrast theme instead
of an application, imho, does not consume additional system resources.

> >
> > General Usage:
> >
> > My main challenge when using a computer these days is getting good high
> > contrast inversion along with larger fonts and windows.  Generally, I
> > set my fonts on the system to about 16.  
> 
> You can still set this value using the tweak tools.
> 

Yes, and I currently do that.

> >
> > That first step of getting to HighContrastInverse is probably the most
> > challenging because I have to first encounter a white window in
> > gnome-tweak-tool before I can finally find my way to the specific
> > setting under the right tab.  Once that is accomplished, (through much
> > eye-squinting) the rest is "accessibly-easy" to do.
> >
> > However, now... with the introduction of GNOME 3.6, that theme is no
> > longer provided.
> As you mentioned this also on your original mail. In short: Yes, we know
> that the HightContrastInverse was dropped.
> 
> Long explanation: we found that maintaining HightContrast and
> HightContrastInverse themes was a time-consuming task, and in several
> cases both were below the required maintenance status. More or less at
> the same time, Joseph was working on the inverse and color effects of
> the magnification tool, and we found that were really good. So we
> concluded that instead of having two half-made themes, it would be
> better to have a well done HighContrast theme, and that we could get the
> HightContrastInverse theme by just using HightContrast theme plus the
> inverse effect of the magnifier.
> 
> Were we wrong with that conclusion/decision?
> 

I'm not going to dive off the plank and say "you were wrong!"  :-)
Resources are what resources are.  And we can scream bloody murder for
the loss of a feature all we want, but simply put, if the resource isn't
there to maintain it, we're up against a wall all around.

But, from where I'm standing (or sitting!), the loss of
HighContrastInverse is quite painful.  And I know this would affect just
about every person afflicted with Usher Syndrome.  I've pointed out in
this thread what were my personal gains and losses were with 3.6, and
frankly, the baby was thrown out with the bathwater.   I do not think we
should have gone with a "one or the other solution."

The VM scenario is a perfect example where this wasn't a positive move
forward.  At least you and I, and I'm sure many others, use VMs.
Inversed magnification instead of the traditional standbys, plus
performance problems, basically rendered ability to use VMs comfortably
useless.  Let's face it, Linux users, regardless of whether you are
fully-sighted or fully-blind, are geeky users.  The loss of VM usage is
too great here, especially for those of us who may have job-related
necessity to use VMs.


> 
> > The mouse pointer is the next biggest challenge as it is often far too
> > small for me to see in shipped default.  With the introduction of GNOME
> > 3, I no longer had the ability to scale my mouse.  Instead, I would
> > search on the web to find large-sized pointers and manually add them to
> > my installation. 
> 
> Yes, on that ONCE presentation that I mentioned, they needed to do
> manual configuration like that for those students.
> 

And that's not good for the home user who doesn't have an IT staff
nearby to do the configurations and isn't familiar enough to know where
to go.

> 
> >
> > Naturally, I need to remember exactly where I'm supposed to put themes
> > or pointers in my filesystem and because this is a one-time thing to do
> > with each installation, I find myself scatching my head for a few
> > minutes to recollect the steps I was supposed to do with each new
> > release.  Clearly, this wouldn't be a good process for less-experienced
> > GNOME users.
> 
> Yes, in general, taking into account the summary of your experience, and
> the experience from other users, sometimes it is hard to know how to
> configure your desktop. We have a lack of documentation and user
> tutorials. The fact that some of the options are already considered as
> "common" on the universal settings and other as "custom" on the tweak
> tools, made the need of tutorials more important. In the same way, in
> several cases, that split is debatable, and some of the things available
> on the tweak tools should be available on the universal settings dialog
> (IMHO).
> 

Agreed.  In some cases, we need better documentation.  In other cases,
we need things to be more intuitive.  Thus why I was proposing a
walkthrough observation.

I think I basically did give my own personal walkthrough observation
here.  But I will never assume that my issues are the same across the
board with other low-vision users.  Low vision is like a snowflake, no
two are alike.  (Hmm... does it snow in Spain rather than rain mainly on
the plain?)


> >
> > I like that High Contrast is now an option listed under the
> > Accessibility Icon.  However, I'm disappointed HighContrastInverse isn't
> > also an option.  Having this option + a hotkey combination to
> > automatically enable this upon first setup would be awesome and remove
> > much of my initial machine setup challenges.  If this could be done
> > without affecting the GNOME activity bar and notification alerts, it
> > would be super-awesome.
> 
> Design team is working on the definition of the default KeyboardShortcuts:
> https://live.gnome.org/GnomeOS/Design/Whiteboards/KeyboardShortcuts
> 
> Probably it would be good to propose some kind of keyboard shortcut for
> this kind of theme activation.
> 
Would be a great proposal once such inversion (whether through theme or
some other solution) exists.  However, I think the user observation is
more important than going to the design team and telling them to create
a shortcut for a specific function.  Once we understand more what the
typical user experience is when setting up a new machine, we can propose
a saner list of desired shortcuts where in some cases the same shortcut
could be used for multiple functions (by toggling through several
options.)

Perhaps even an additional feature for toggling.  For example, let's say
there's four options you can toggle through with a keyboard shortcut.
For each option you arrive at, a sound occurs.  Thus you know you just
went to the next option.  No this doesn't work well for DeafBlind
people, but we can't have everything!  :-)

That sound alert would be useful for people who don't know if they've
arrived at next option or if their machine is being too slow.

> >
> > I would very much like to see us re-assess how low-vision users, who do
> > not rely on magnification as a whole, configure their machines and see
> > how we can make the steps shorter and more intuitive.
> 
> As far as I understand this paragraph, you are suggesting to allow the
> configuration of the color effects outside of the magnification tool,
> right? We already have a bug related with that, although we still don't
> have any conclusion yet:
> https://bugzilla.gnome.org/show_bug.cgi?id=676814
> 
> >
> > For me, the ultimate solution in an ideal world would be not to even
> > create a workable Inverse theme, but to literally toggle screen
> > inversion in the workarea space of GNOME.  But the theme option has been
> > a reasonable fall-back in lieu of this toggle option.
> >
> But you already mentioned that just using the inverse effect made you
> hard to see the top panel and the alt+f2 run dialog. Could you elaborate
> that?

By "workarea" I mean the area outside of the GNOME Shell elements
(activity bar, notification alerts, etc.)  If toggling inversion could
be done without touching these elements (or treating these elements with
separate configuration) were possible, that would be my ideal solution.

> 
> Finally, thanks for your detailed report. It included a lot of things to
> think about, and pointed some elements that still require some work.
> 

And thank you for the patience to read through the long evaluation
email.  :-)   I hope it is viewed as a positive criticism rather than a
harsh bashing, which would never be my intention.

I would love to get involved in these kinds of use-case discussions on a
more organized and pre-release basis.  However, I find it difficult to
become a tester on a pre-released version because by nature they can be
quite buggy and by the time they are stable enough, feature freeze is
already introduced.  By the time we are able to comment on successes and
failings, it is too late and any changes will have to wait until next
release 6 months later.  Furthermore, the problem is exacerbated by what
I mention here about ability to test and provide feedback.  So, by the
time we can comment on a certain implementation, we've already
encountered a new feature freeze and thus cannot expect a more perfect
implementation until the _NEXT_ release.  Thus, in theory, it could take
a year (or possibly longer) to finally arrive at solutions that are
universally acceptable.

How can we break this cycle to get us more directly involved during the
most critical moments?  I am sure we are missing the opportunity to get
more timely feedbacks because many are in the same boat as me.


> Best regards
>