17

The scenario: A 20+-year-old legacy desktop system is being uplifted to a SaaS/web platform. Each screen contains a large amount of input fields. Traditionally, users have built "muscle memory" moving between fields using arrow keys, or the Enter key.

The question: Users have indicated that they can live with using the Tab key to move to the next field, but they are frequently moving in multiple directions in the current state (up, down, left, right) and having to constantly shift between mouse and keyboard is a major pain point identified in the research. Some users are doing almost everything with a numeric keypad. Would there be any issues with allowing users to traverse screens using arrow keys (apart from selector menus needing them)? Or should we design the new system in a way that minimizes multidirectional movement and train the users to use tab/ shift-tab to go backward/forward?

Improve this question
5
  • 3
    One thing to note when working on the web: A page can flow differently on different devices, and does so in much larger degree than desktop apps. So what you coded as up and down might not match what a user sees on their screen.
    – Matsemann
    Oct 7, 2021 at 11:42
  • 3
    How many different groups are you expected to serve with this? If you have a large pool of users that are well used to the old system, rely on it, and there will be little influx of new users that want to do things a different way, code the system to macth the requirements of the user rather than forcing N hundred(?) users to learn a new behavior.. Otherwise you'll just end up as the disliked the new dev that imposed the crap new system on a bunch of people that liked working with the old one. To answer this effectively you need to do more research about the end user
    – Caius Jard
    Oct 8, 2021 at 9:16
  • That's why I think the mode setting is the right solution. There are users who have relied on arrow keys for 30 years, but there will also be new users who will expect the platform to work like other SAAS platforms vs. traditional software.
    – Izquierdo
    Oct 8, 2021 at 13:15
  • Just want to add... it's typical for spreadsheet UIs to use TAB for navigating to the next field (left to right, and down to the next row when at the end), CTRL + TAB for the reverse, and ENTER to move down. Since TAB already works this way, you'd only need to implement the ENTER functionality. For users not interested in the legacy ARROW key support, I recommend implementing ENTER support. If modifying many values within a single column, ENTER support is super important.
    – Aaron Cicali
    Oct 8, 2021 at 16:51
  • If you give users this functionality, you need to be careful on how you implement it, because a web app usually means "responsive" which on itself means "different field layouts on different screens/windows sizes"
    – Josh Part
    Oct 8, 2021 at 18:00

1 Answer 1

Reset to default
36

Technically this would fall under "unexpected behaviour" for new users or people using a screen reader (where your controls may impact their usage when in "forms mode" as arrow keys are used heavily by screen reader users).

A simple solve would be a well described option checkbox / toggle button at the top of the form that saves a user preference.

So something like "enable arrow key navigation" yes/ no.

That way if you arrow key logic interferes with a screen reader they can just switch it off but everyone else can use the key controls they are used to.

I would perhaps default it to "off" and let people toggle it on, it may also need a help section to explain it in more detail but without seeing the design and knowing your user base, it is hard to say.

Improve this answer
5
  • 2
    I hadn't thought of a setting - that would be useful for different groups. Thanks.
    – Izquierdo
    Oct 6, 2021 at 19:28
  • 29
    To expand on the setting idea, it may be a good idea to enable it for all existing users, then default to off for new ones. Might be as easy as pulling your userlist, and enabling it for each of them wherever you store settings, then setting the default to off.
    – James
    Oct 7, 2021 at 2:22
  • 4
    @James yeah that is actually a better idea then defaulting it to off for everyone 👍 as it is a legacy userbase, storing that idea for future projects!
    – GrahamTheDev
    Oct 7, 2021 at 6:32
  • 3
    "A simple solve" — bear in mind you're committing to testing and supporting two different ways for the interface to work; both for the system as it is now, and for any new features that get added.
    – Paul D. Waite
    Oct 8, 2021 at 10:32
  • 2
    @PaulD.Waite The "simple solve" was directed towards the ability to switch the feature on and off, obviously I should have made it more clear that the feature itself is not simple. A good point and an important warning for others who may be thinking of implementing this!
    – GrahamTheDev
    Oct 8, 2021 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.