The Web is available in all kinds of flavours. You can access it from a pair of glasses to a big TV screen, not to mention the ubiquitous mobile and tablet devices. Designing a solution that works across all these different devices is a challenging task.
Each platform has its unique set of both capabilities and limitations. One way to support all those platforms could be to stick to the features that all of them have in common. However, with more and more different platforms, that common space becomes smaller and smaller. So what to do?
When designing a solution for multiple platforms we should not automatically discard a feature just because it is lacking on some platforms. Especially if this unique feature improves the user experience for users of that platform and it is not preventing the users of other platforms to achieve their goals. That is, the feature is either not essential to complete the user actions, or an alternative path is provided to compensate for the lack of the feature on other platforms.
Some examples below:
- Don’t use hover, it does not work on mobile!
While it is true that hover is not working on touch devices. More appropriate questions would be:
- Is this preventing some users to achieve their goals? The use of hover to provide a cue of interactivity or some clarifications may be a little aid that the users can live without it. However, if you find that it is useful for users, does it make sense to deliver a worse experience to those you can provide the feature just because there is a subset of users for which you cannot?
- Is there an alternative for users lacking this feature? If the feature is part of an important path toward the user goal, it is important to provide an additional safer path so that a users can reach their goals. For example, if some important controls are revealed on hover, you need to figure out how to make those controls reachable to touch users (make them appear on tap too, provide them on the separate detail view…).
Similar concerns have been raised about the use of gestures, keyboard shortcuts, or adding custom actions to contextual menus. In those cases, in addition to platform limitations, the limitations to discover them prevents some users from using the feature even if it is available to them just because they don’t know it exist.
For those cases, consistency (e.g., making gestures work similarly on similar context), subtle cues (e.g., transitions), and providing a general sense of safe exploration (where bad things do not suddenly happen) could help to mitigate the discovery issues.
In any case the reasoning is the same as above. If it gives a positive user experience, and is not preventing other users to achieve their goals, there is no reason to discard those features.
When conflict occurs
Something worse than a feature lacking is a bad attempt to support it. For example, bold text is not supported by some languages such as Hindi (the concept just does not exist in that language). According to the above reasoning, we could get to the conclusion that it is perfectly fine to use bold in our UI text as long as it either:
- The message still works when text is not bold.
- Other properties such as font size or colour are used to ensure the text is at the appropriate prominence level even on those languages lacking the “bold” feature.
Unfortunately, when bold is lacking, browsers attempt to artificially generate bold, seriously affecting readability on some languages. So we need to be aware of side-effects of lacking features, and take the extra actions needed to make sure that making better the user experience for a given group is not making it worse for a different one.