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 > _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
