> >
> > 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."
I would definitely encourage you to file a bug against Gnome-Themes-Standard explaining what solution would work best for your use case. The Design Team specifically mentioned that they would like feedback on this decision so users' needs can be met.
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.
>
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?
(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
