Messing With Support through poorly designed APIs

Ever thought about how “remote assistance” sessions work on a Windows machine? You know, the support d?r?o?i?d? person takes control of your keyboard and mouse inputs (or shares them) to sort out a tech problem.

When they use their mouse buttons, a well-designed API would send events like “primary mouse button down”, “primary mouse button up”, “secondary mouse button down” and so on. But a na?vely & poorly designed one would send events like “left mouse button down”, “right mouse button up”. Subtle difference - merely a layer of abstraction, but you can see where this is going.

Purely in the interests of science[1] I tested this by using my mouse left-handed (with swapped buttons)[2] when support did a remote assistance session on my device. Turns out that the API is indeed na?vely designed. Obviously I took no delight at all[3] when the support person couldn't get anything to work and instead had to tell me what needed doing and watch me doing it.

To me this na?vety of design would be on a par with sending which keyboard key was pressed rather than which character was being generated. Sadly neither I nor the support person had a device with a French AZERTY, German QWERTZ, or Dvorak PYFGC keyboard handy to check[4].

Poor design like this should have been shown up through testing early enough to rectify it. If you are involved in product development or definition, is your testing method good enough to flush out edge cases like this?

Footnotes

[1] Oh, ok, actually because the IT Support function at this particular organisation had failed for weeks on end to actually do something really simple but which required administrative rights to achieve. But one can do science and have fun, surely.

[2] !??lqmi? | Simples! (When you're ambidextrous, anyway)

[3] Sorry, this is a lie.

[4] I've always been a fan of Das Keyboard myself. A keyboard so utterly black that it would suit Hotblack Desiato down to the ground, and light just slides off it.