4 ms·

> There are thousands of unhealthy people who are being deliberately excluded from Google's cheap computing revolution. Remove the word deliberately and you've

> There are thousands of unhealthy people who are being deliberately excluded from Google's cheap computing revolution. Remove the word deliberately and you've got the truth. It's not like they sat around the boardroom and said: "You know what, let's make our computers only usable by healthy folk". It just happened, Google has a ton of people who didn't think about this aspect. It wasn't something they planned or even thought about.

moftz 8y ago
You can read all of the comments by the devs who aren't even considering the accessibility option. Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work.
- pgeorgi 8y ago
  > Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work. That's because key mapping and button mapping is more or less the same problem, as far as computers are concerned. From the blog: "Evoluent - the manufacturer of my mouse - also provide a handy tool for Windows and Mac so that I can set the mouse buttons up just the way I like them". There's a technical reason for that (actually, two): USB HID allows devices to expose how many buttons they have, plus some characteristics, but it's utterly useless to expose the information that "button 17 is the one in the top right corner when seen from above". The other reason is that USB device vendors (no matter which device type) don't feel the need to implement standards faithfully, so devices need special handling in drivers all the time. So Evoluent provides its own Windows and Mac tool. In the bug linked in the post, the devs are discussing adding such special cases, or - instead, and preferred - providing an API through which third parties (no matter if Evoluent or that chap who can write xinput configs) could develop frontends that could do such configuration. Now, these APIs shouldn't enable third parties to essentially log everything entered by the user. And that's where the discussion is at. I'm not sure if the Evoluent tool reconfigures the device (through some proprietary vendor commands to the mouse) or reconfigures Windows to remap these buttons. Interestingly the former case might already be supportable on Chrome OS, since it supports the WebUSB APIs. Since these USB commands would be non-standard and most likely undocumented by the hardware vendor, it would be up to Evoluent to provide such a frontend to configure the device. The latter case (configuring a remapping) would be similar to that API that is under discussion. It doesn't go as fast as the blog post's author wants, okay. But screaming into the void (or even here) doesn't help with advancing that process.
hopler 8y ago
They did though. They admitted on the bug that ChromeOS is not for power users, meaning anyone who needs a different configuration from the default. They didn't accidentally forget,they made a conscious choice, repeatedly.
- johnnyfaehell 8y ago
  > They admitted on the bug that ChromeOS is not for power users Yes, they admitted it wasn't for power users. Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature. That's why everyone is complaining about it. They made a conscious choice not to add power user features. They did not make a conscious choice not to add accessibility feature, it was just a knock on effect. Hence it not being deliberate.
  - namdnay 8y ago
    >Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature I agree. The "power user" requirement here would be: needing to override/remap this behaviour in the OS, as opposed to having a specialist device with different buttons
- ethbro 8y ago
  I think that's op's point. Calling someone with a disability a power user... grates. There's a big difference between my productivity-enhancing .vimrc and not being able to use something. Half the devs seem to understand this. Either way, it's a valid decision if Google decides not to implement the requested feature. But there's a difference between "We're not implementing a feature for power users" and "We're not implementing an accessibility feature for disabled users." The whole point of ADA is that we should strive, where possible, to allow people with disabilities to live the same lives everyone else enjoys.
alias_neo 8y ago
"Ignorance". That's the word we're all looking for here. As a lefty, I've often felt frustrated, or even furious as the ignorance of UX for those of us that don't fit the norm. The comments from the developers that responded to this clearly showed such ignorance, that it's a "power-user" feature etc. If I use my mouse left handed, as a left-handed person, is it a "power-user" feature to want the buttons the opposite way around? You'll probably find that the less stubborn lefties of the world, such as myself, have actually developed into a form of ambidexterity. Not entirely ambidextrous (I can't write well with my right hand, for example), but something of the sort. I'm a lefty, there is no doubt, but I use a computer like any other right-handed person (apart from using tenkey-less keyboards, because a numpad is useless to me). This is the option we have when the world around us is created for everyone _else_. I once worked for a company that was commissioned by a local government body to add accessibility features to the company's own (local travel) app because it was unusable by the members of the community that required those accessibility features. This is great, but, the task was given to me. What experience do I have with resolving accessibility problems? I'm just a developer. Was I given the resources to go out and survey those that required the accessibility features? Was I given contact with the local government that commissioned the improvements? Was I given a book on "Designing & Developing with Accessibility in Mind"? No. I completely understand where OP is coming from with this, and when the problem is with a company as large, ethereal and ignorant as Google is, it goes beyond frustration.
- pgeorgi 8y ago
  > is it a "power-user" feature to want the buttons the opposite way around? That's supported. What isn't supported is mapping arbitrary buttons to arbitrary functions because that's a hard problem to solve generically: see Evoluent having to ship their own customization software for Windows and Mac instead of just using OS configuration screens.
  - alias_neo 8y ago
    My example isn't the greatest, I agree, because it is, generally supported everywhere. A more appropriate example might have been scroll-bars, very few devices support moving them to the left. particularly when it's a touch device and I want to actually use my left-index finger, or a stylus (a la Nintendo DS, et al). This is not a hard problem to solve generically, but it is rarely solved in my experience. I agree with what you're saying, the problem I see is that OP has pointed out _why_ this feature is required (accessibility) but 5 years later it's still not solved. This is frustrating as the person that _needs_ that feature. If any one of those developers had _needed_ the feature, I bet it'd have been implemented in no time at all. The people responsible aren't affected, and thus don't care. When your user-base is as large as Google's, a small feature like this might affect more people in that tiny minority that the entire customer base of some small companies, but at this scale they're so far removed, nobody cares. Talking of features we want Google to add; when are they going to finally allow us to set the hostname on Android phones? I'm sure that one was opened half a decade or so ago (This one issue is now 9 years old: https://issuetracker.google.com/issues/36912590 https://issuetracker.google.com/issues/36912590)
skywhopper 8y ago
It amounts to the same thing. Google decision-makers are aware they are excluding a significant chunk of "edge cases" in order to hit their profit goals. They don't think of it in terms of "let's screw over people who need to remap mouse buttons because of physical disabilities!" but that's only because they are actively choosing _not_ to think about the impact of their hyper-"logical" efficiency decisions. Given the big Chromebook push into the education space, accessibility issues like this which impact the 5% of "edge cases" out there are actually really critical. There's no good excuse for skimping on accessibility. The fully-abled developers on the project--who likely don't work with anyone with disabilities, much less have they ever considered what it would be like to use their products with disabilities--have fully embraced the data-driven, A-B tested, "simplicity" (for most) at all costs approach that doubles down on human biases against disabled individuals, but just because they aren't actively choosing the predictable consequences doesn't mean they aren't responsible for the predictable consequences.
SilasX 8y ago
It's probably more like, "let's lock ourselves into an early design decision that makes it hard to expose input remapping without realizing that's what we're doing because the architecture looked so much cleverer that way". The OP isn't asking for some beautifully engineered UX with GUI that walks you through every possible disability modification. He's more than happy to go through a long procedure [1], as on Linux, to get that memory block to point to a different address. He just wants it to be exposed at all. Others have claimed that this is some kind of full-featured thing. Well, as best I can tell, his Linux workaround just involves xinput and lsusb, both of which are available on Alpine Linux, the ultra-minimal distro. [1] https://shkspr.mobi/blog/2018/05/using-the-evoluent-vmcr-c-series-vertical-mouse-with-linux/ https://shkspr.mobi/blog/2018/05/using-the-evoluent-vmcr-c-s...

moftz 8y ago

You can read all of the comments by the devs who aren't even considering the accessibility option. Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work.

pgeorgi 8y ago
> Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work. That's because key mapping and button mapping is more or less the same problem, as far as computers are concerned. From the blog: "Evoluent - the manufacturer of my mouse - also provide a handy tool for Windows and Mac so that I can set the mouse buttons up just the way I like them". There's a technical reason for that (actually, two): USB HID allows devices to expose how many buttons they have, plus some characteristics, but it's utterly useless to expose the information that "button 17 is the one in the top right corner when seen from above". The other reason is that USB device vendors (no matter which device type) don't feel the need to implement standards faithfully, so devices need special handling in drivers all the time. So Evoluent provides its own Windows and Mac tool. In the bug linked in the post, the devs are discussing adding such special cases, or - instead, and preferred - providing an API through which third parties (no matter if Evoluent or that chap who can write xinput configs) could develop frontends that could do such configuration. Now, these APIs shouldn't enable third parties to essentially log everything entered by the user. And that's where the discussion is at. I'm not sure if the Evoluent tool reconfigures the device (through some proprietary vendor commands to the mouse) or reconfigures Windows to remap these buttons. Interestingly the former case might already be supportable on Chrome OS, since it supports the WebUSB APIs. Since these USB commands would be non-standard and most likely undocumented by the hardware vendor, it would be up to Evoluent to provide such a frontend to configure the device. The latter case (configuring a remapping) would be similar to that API that is under discussion. It doesn't go as fast as the blog post's author wants, okay. But screaming into the void (or even here) doesn't help with advancing that process.

hopler 8y ago

They did though. They admitted on the bug that ChromeOS is not for power users, meaning anyone who needs a different configuration from the default. They didn't accidentally forget,they made a conscious choice, repeatedly.

johnnyfaehell 8y ago
> They admitted on the bug that ChromeOS is not for power users Yes, they admitted it wasn't for power users. Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature. That's why everyone is complaining about it. They made a conscious choice not to add power user features. They did not make a conscious choice not to add accessibility feature, it was just a knock on effect. Hence it not being deliberate.
- namdnay 8y ago
  >Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature I agree. The "power user" requirement here would be: needing to override/remap this behaviour in the OS, as opposed to having a specialist device with different buttons
ethbro 8y ago
I think that's op's point. Calling someone with a disability a power user... grates. There's a big difference between my productivity-enhancing .vimrc and not being able to use something. Half the devs seem to understand this. Either way, it's a valid decision if Google decides not to implement the requested feature. But there's a difference between "We're not implementing a feature for power users" and "We're not implementing an accessibility feature for disabled users." The whole point of ADA is that we should strive, where possible, to allow people with disabilities to live the same lives everyone else enjoys.

alias_neo 8y ago

"Ignorance". That's the word we're all looking for here. As a lefty, I've often felt frustrated, or even furious as the ignorance of UX for those of us that don't fit the norm. The comments from the developers that responded to this clearly showed such ignorance, that it's a "power-user" feature etc. If I use my mouse left handed, as a left-handed person, is it a "power-user" feature to want the buttons the opposite way around? You'll probably find that the less stubborn lefties of the world, such as myself, have actually developed into a form of ambidexterity. Not entirely ambidextrous (I can't write well with my right hand, for example), but something of the sort. I'm a lefty, there is no doubt, but I use a computer like any other right-handed person (apart from using tenkey-less keyboards, because a numpad is useless to me). This is the option we have when the world around us is created for everyone _else_. I once worked for a company that was commissioned by a local government body to add accessibility features to the company's own (local travel) app because it was unusable by the members of the community that required those accessibility features. This is great, but, the task was given to me. What experience do I have with resolving accessibility problems? I'm just a developer. Was I given the resources to go out and survey those that required the accessibility features? Was I given contact with the local government that commissioned the improvements? Was I given a book on "Designing & Developing with Accessibility in Mind"? No. I completely understand where OP is coming from with this, and when the problem is with a company as large, ethereal and ignorant as Google is, it goes beyond frustration.

pgeorgi 8y ago
> is it a "power-user" feature to want the buttons the opposite way around? That's supported. What isn't supported is mapping arbitrary buttons to arbitrary functions because that's a hard problem to solve generically: see Evoluent having to ship their own customization software for Windows and Mac instead of just using OS configuration screens.
- alias_neo 8y ago
  My example isn't the greatest, I agree, because it is, generally supported everywhere. A more appropriate example might have been scroll-bars, very few devices support moving them to the left. particularly when it's a touch device and I want to actually use my left-index finger, or a stylus (a la Nintendo DS, et al). This is not a hard problem to solve generically, but it is rarely solved in my experience. I agree with what you're saying, the problem I see is that OP has pointed out _why_ this feature is required (accessibility) but 5 years later it's still not solved. This is frustrating as the person that _needs_ that feature. If any one of those developers had _needed_ the feature, I bet it'd have been implemented in no time at all. The people responsible aren't affected, and thus don't care. When your user-base is as large as Google's, a small feature like this might affect more people in that tiny minority that the entire customer base of some small companies, but at this scale they're so far removed, nobody cares. Talking of features we want Google to add; when are they going to finally allow us to set the hostname on Android phones? I'm sure that one was opened half a decade or so ago (This one issue is now 9 years old: https://issuetracker.google.com/issues/36912590 https://issuetracker.google.com/issues/36912590)

skywhopper 8y ago

It amounts to the same thing. Google decision-makers are aware they are excluding a significant chunk of "edge cases" in order to hit their profit goals. They don't think of it in terms of "let's screw over people who need to remap mouse buttons because of physical disabilities!" but that's only because they are actively choosing _not_ to think about the impact of their hyper-"logical" efficiency decisions. Given the big Chromebook push into the education space, accessibility issues like this which impact the 5% of "edge cases" out there are actually really critical. There's no good excuse for skimping on accessibility. The fully-abled developers on the project--who likely don't work with anyone with disabilities, much less have they ever considered what it would be like to use their products with disabilities--have fully embraced the data-driven, A-B tested, "simplicity" (for most) at all costs approach that doubles down on human biases against disabled individuals, but just because they aren't actively choosing the predictable consequences doesn't mean they aren't responsible for the predictable consequences.

SilasX 8y ago

It's probably more like, "let's lock ourselves into an early design decision that makes it hard to expose input remapping without realizing that's what we're doing because the architecture looked so much cleverer that way". The OP isn't asking for some beautifully engineered UX with GUI that walks you through every possible disability modification. He's more than happy to go through a long procedure [1], as on Linux, to get that memory block to point to a different address. He just wants it to be exposed at all. Others have claimed that this is some kind of full-featured thing. Well, as best I can tell, his Linux workaround just involves xinput and lsusb, both of which are available on Alpine Linux, the ultra-minimal distro. [1] https://shkspr.mobi/blog/2018/05/using-the-evoluent-vmcr-c-series-vertical-mouse-with-linux/ https://shkspr.mobi/blog/2018/05/using-the-evoluent-vmcr-c-s...