5 ms·

One of my first jobs involved writing a modern (for the time) GUI app to replace some ancient services that involved logging in a mainframe to use. They needed

One of my first jobs involved writing a modern (for the time) GUI app to replace some ancient services that involved logging in a mainframe to use. They needed to updated for a host of technical reasons, but there was also hope that more user-friendly versions would decrease the onboarding time for new employees. The first version was a fairly literal replacement of the workflows. The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to. It was interesting to see the reluctance to any change at all.

wizzwizz4 5y ago
> The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to. If you removed my keyboard workflow, I'd be pissed too. Muscle memory means you don't have to think about it; with the mouse, you always have to think about what you're doing, and can't think of other things (e.g. why you're doing it) while you're doing the rote bits. Is there a particular reason you couldn't've supported the Y/N workflow? (i.e. “Y” is like “set, tab” and “N” is like “clear, tab”)
- ddingus 5y ago
  Yes. People who interact with those things just blow through them at high speed without even thinking! That frees them to think about other things. Arguably, more important things.
  - jimmaswell 5y ago
    It calls into question if the original version had to be replaced at all. It probably didn't.
    - ddingus 5y ago
      Indeed. My other comment has to do with meta info. Docs, procedures, training material. Cost of change is high, rewards or returns? Low.
- banana_giraffe 5y ago
  To be clear, we did support keyboard workflows, like Y/N They were pissed we replaced the Y/N text items with a checkbox. Any deviation, including things like lower case text, were pushed back.
  - ddingus 5y ago
    Maybe that has to do with things like documents workflows, other meta information related to the applications.
  - wizzwizz4 5y ago
    > They were pissed we replaced the Y/N text items with a checkbox. At this point, I'd probably factor out the UI, hand them the client-side source code and tell them to get on with it. If they want to customise the UI, then so long as you're not supporting it… … but yeah; that's a less reasonable objection than I thought it was. (Still a change to their workflow, and still understandable, but there were legitimate business reasons that the workflow needed to be changed.)

wizzwizz4 5y ago

> The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to. If you removed my keyboard workflow, I'd be pissed too. Muscle memory means you don't have to think about it; with the mouse, you always have to think about what you're doing, and can't think of other things (e.g. why you're doing it) while you're doing the rote bits. Is there a particular reason you couldn't've supported the Y/N workflow? (i.e. “Y” is like “set, tab” and “N” is like “clear, tab”)

ddingus 5y ago
Yes. People who interact with those things just blow through them at high speed without even thinking! That frees them to think about other things. Arguably, more important things.
- jimmaswell 5y ago
  It calls into question if the original version had to be replaced at all. It probably didn't.
  - ddingus 5y ago
    Indeed. My other comment has to do with meta info. Docs, procedures, training material. Cost of change is high, rewards or returns? Low.
banana_giraffe 5y ago
To be clear, we did support keyboard workflows, like Y/N They were pissed we replaced the Y/N text items with a checkbox. Any deviation, including things like lower case text, were pushed back.
- ddingus 5y ago
  Maybe that has to do with things like documents workflows, other meta information related to the applications.
- wizzwizz4 5y ago
  > They were pissed we replaced the Y/N text items with a checkbox. At this point, I'd probably factor out the UI, hand them the client-side source code and tell them to get on with it. If they want to customise the UI, then so long as you're not supporting it… … but yeah; that's a less reasonable objection than I thought it was. (Still a change to their workflow, and still understandable, but there were legitimate business reasons that the workflow needed to be changed.)