Custom pointers in @dhis2/ui

[ghost]

In this PR we were talking about whether or not a checkbox should have cursor: pointer set. My thought was to just stick to the browser defaults (only use a pointer for links), but @KaiVandivier mentioned that the pointer cursor is often used to indicate that clicking something will trigger an action, which makes sense as well.

I took a quick look, and found a couple of articles arguing for and against setting a custom pointer:

• https://uxdesign.cc/missing-the-pointer-1dfc5cd60c8c
• https://medium.com/simple-human/buttons-shouldnt-have-a-hand-cursor-b11e99ca374b
• https://ux.stackexchange.com/questions/95176/using-pointer-mouse-cursor-shape-on-controls

I haven't really taken a proper look at this yet (plus there are a lot more articles than just the three above of course), but if we have the time, it would probably be good to decide on which convention we want to follow, so that it's consistent throughout our platform.

[KaiVandivier]

I'll add these:

1. It seems to be the common convention for modern web pages to use cursor: pointer on anything that triggers an action; I'm guessing it's what users expect
2. There is precedent in the UI library for pointers on tabs, chips, buttons, and select options (and switches, but those are pretty similar to checkboxes)... I guess that's what this discussion's about now!

[varl]

We should be careful to not create a user expectation that everything that is interactive has the pointer cursor.

As a design pattern it is not possible to be entirely consistent with that expectation, and if we inadvertently train our users to expect that "everything that is interactive has the pointer cursor" then our user experience is going to "feel weird" because of the exceptions that we have to those situations.

It is common to wrap the checkbox in a label to get the entire label to act as a clickable area for the checking the checkbox. Which is nice since it's a lot easier to hit the label than the square box.

If we want to use the pointer cursor to indicate that the checkbox is an interactive element we should apply it to the label as well, right?

Otherwise the checkbox has the pointer cursor, but the label would have the default arrow. But the label is still interactive and toggles the checkbox, just like clicking the checkbox itself. So we apply the pointer cursor to the label as well. Now the entire unit (checkbox+label) look and feel the same.

If we add a link inside the label text however, that obviously needs to have the pointer cursor as well. But now the interaction feels off between the three elements. Naturally, since our elements are visually distinct and immediately obvious to what is interactive, it still works as the user expects, but it feels slightly off.

The additional hinting that the cursor gives when hovering a link would move the experience from "i guess that this is going to open the link" to "i know that this is going to open the link".

Interactive components should be easy to visually identify.

It is less efficient to attempt to mouse over all the elements on a page to figure out if they are interactive, than to visually scan the page and see if they are interactive.

The pointer is an additional hint to the user, but it should not be a necessary hint.

Not all devices are capable of "hovering" over elements; touch screens for example, but also simpler eye-tracking solutions for people that cannot use a mouse to interact.

Applications should respect the host platform.

Deferring to what the browser does when we build web apps is principally the same as deferring to what the operating system does when building native apps.

It is best practice to align with the platform standards in both cases.

Changing the cursors and other such properties should be reserved to restore alignment with native controls when we break them by re-implementing our own version, not introduce friction and conflict between the app and the platform.

[cooper-joe]

I believe there are three realistic approaches to choose from:

1. Apply platform standards: use pointer for links only
2. Use pointer for all interactive elements
3. Custom mix of 1 and 2:
   • Use pointer for some interactive elements based on some guideline. An example guideline might be "anything with more consequence than a state change should use pointer" Examples for that guideline might be:
     • Checkbox: do not use pointer because this is a state change
     • Expanding a collapsed parent item: do not use pointer because this is a state change
     • Button to execute an action: use pointer as an executed action is more than a state change (...is it?)
     • Menu item to save an object: use pointer as "Save" is an executed action

Evaluating each approach

1. Apply strict platform standards

Pros

• simple to understand, simple to implement
• informed by accepted platform standards
• consistent
• prevents overreliance on pointer as interactive affordance
• inherits benefits of a native control. for example, if a platform or browser chooses to change the default cursor implementation/spec, our implementation would inhereit whatever the platform spec implements

Cons

• does not follow unwritten, but pervasive, standards set by (some) modern web applications. May not match user expectations depending on other applications they frequently use
• removes use of pointer on many existing DHIS2 elements, so may require user relearning/unlearning
• removes a useful "this is clickable" affordance for some elements

2. Use pointer for any interactive element

Pros

• relatively simple to understand and implement, once a definition of interactive has been agreed upon
• consistent
• aligned with (some) modern web standards

Cons

• pointer alone may be relied upon as a weak indicator of interactivity
• does not follow platform standards, may need revisiting if platform standards change

3. Custom mix of 1 and 2 using an agreed-upon standard defined by ui

Pros

• allows alignment for (some) modern web standards
• custom designed for DHIS2 user needs
• closest to current approach, reducing friction and work needed

Cons

• Potentially confusing, any rule or standard will have loopholes or edge cases that have to be hashed out. What if a button toggles a state change? etc.
• Requires consideration for each use case. New uses case will always have the potential to break the system.
• Multi-use components, those that could trigger and action or a simple state change, would need to allow cursor customisation through props and then rely on developers following consistent guidelines.

Conclusion

My conclusion, after considering the above, is that option 1, apply platform standards, is the best approach.

Addressing the cons listed for that approach:

Does not follow unwritten, but pervasive, standards set by (some)modern web applications, and therefore may not match user expectations
Though the pattern is common, it is not universal. I would strongly hesistate to use this as a reason to choose another option, what if those modern applications updated to change, would DHIS2 follow those changes too? If we are to follow a standard, it should be the one we get "for free" from an internation standards organization (W3C).

Removes use of pointer on many existing DHIS2 elements, so may require user relearning/unlearning
Valid, but not meaningful enough to warrant taking a substandard approach. Interaction would not be broken while this work is carried out, so it isn't a critical consideration.

Removes a useful "this is clickable" affordance for some elements
This can be flipped to a positive if we consider, as @varl notes above, that the pointer alone should never be used to indicate interactivity. If an element is not obviously interactive when pointer is removed, then there is a problem with the design. Taking this approach will highlight these problems and enforce better usability in the long term.

Bonus: What about buttons that link to somewhere or navigate?
To keep to the W3C standard, link should be preferred for navigation, rather than buttons. If we agree that we want to allow navigation via a button-like element, we should provide a link that can be optionally styled like a button.

---

While investigating this topic I researched the cursor patterns used in popular web applications, platforms and frameworks. I used the behaviour of the checkbox element as a reference. While the use of pointer is widespread, it is not an adopted standard as the following sample from the research shows:

Platform	Cursor on <checkbox> hover
Microsoft 365	pointer
Material Design	pointer
Jira	auto
USWDS	pointer
GOVUK	pointer
Github	auto
Bootstrap	auto

[ghost]

That's some proper research, nice. I was already biased towards option 1, so maybe take my viewpoint with a grain of salt, but to me your reasoning makes a good case for going with 1. I'd be ok going with that 👍