User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
We have an on screen keyboard on our website and are debating ISO vs ANSI because we are targeting European and Nordic customers. Unfortunately the keyboard layout can not really be detected with JavaScript.
I have never been overseas but in North America I have rarely seen anything but a United States keyboard layout(ANSI).
Is the ISO keyboard layout common enough overseas merit showing ISO ANSI?
Kudos for considering the user and their preferences on something as integral to the UX as the keyboard they use, and prefer. Since you are willing to consider the choice between ISO and ANSI, presumably with the ability to actually choose any keyboard layout, I'm going to suggest that you tackle the entire issue, and give the users the control of their choice. There are, as I see it, four levels to work through.
I would recommend that you develop the ability to accommodate more that just ISO and ANSI layouts. Research should show you what are the commonly used layouts in your target audience, and I suspect that it will be a number greater than two. What ever the research shows as having a non-negligible market share for layout choices in your audience should have the ability for your website to display and use. With the listed target audience you could be looking at a dozen, or more. While it might be a bit of a bother to develop them originally, the most important aspect will be knowing that you will develop multiple layouts, and plan for the code-base to accommodate any layout supplied to it.
As you are doing this for a website, I'm going to presume that you have access to back-end technology and are not limited to what JavaScript can discover about the user. The HTTP request-headers include an Accept-Language field. While it's not required that the browser send that field, it is worth checking it. Since it is a "range" field, there might be more than one language listed, and it's possible that the aggregate could reveal a likely layout better than the first-listed language. In any case, I'd recommend using that field, when available, as the selector for the layout to use. If the field is missing, the IP address might help. Of course, with TOR and VPN options available, it is much less reliable, and should be a consideration rather than determination. That is especially true if the IP seems at odds with other indicators. As a final layer of selection, your website is likely to have different URLs for different languages (I would hope), and you can select a layout conducive to the page's language. If all else fails, since your target audience is "European and Nordic customers," use the ISO as the fallback choice.
If the website is intended for use on a Kiosk, make the initial layout select-able by a config file loaded into each specific kiosk, and set that to the most common layout locally. If the website is both kiosk-enabled and general web access, develop some flag for the kiosk to send to the site to select its layout. Again, based on an individualised config file in the machine.
No matter which layout is served when the user connects, give an option to switch to something else. Many mobile keyboards have their controls under a gear icon as one of the keys on the keyboard, near where ALT and CTRL are on a desktop keyboard. The iPod Touch, running under iOS 6, has the globe with long/lat lines rather than a gear, with the same placement. If you can make that option available, the results can be added to any other preferences that you save in a cookie, or user profile if you have that functionality onsite. Perhaps, as an enhancement to the users, you could detect the platform they are on and use the icon common for that platform: globe for Mac/iOS devices, gear for Linux/Android, and double-gear for Windows.
If a kiosk is the source of the user input, still offer the ability to switch layouts. In addition, develop a way to reset the display when the user is finished, or it's determined that the user has abandoned the kiosk. At the same time that the display is reset, the layout should be reset to the initial layout as determined above.
It is worth acknowledging that some users might already have an on-screen virtual keyboard, or be on a mobile device that has an on-screen keyboard in-built, and the option to install third-party versions as well. In either case, if you can defer to that choice you will be accommodating the user's choice of layouts, and eliminate any learning curve associated with using your developed layouts completely.
Some virtual, or on-screen, keyboards attempt to duplicate the physical keyboard. Don't do that! No matter what layout is used, it's very unlikely that the users will be doing touch typing with the on-screen keyboard, and mimicking the physical keyboard will add more than is needed for website usability. It will also require more screen area, or smaller "keys" as targets for the user. Rather, use a simplified layout with strictly alphabetic characters, and use toggles to reach other characters. An example of which is the layout from an iPod Touch.
If your keyboard routines can be coded to detect a long mouse click, or a long press on touch, then I'd recommend using the trick that is on Android phones. The layout is essentially the same as the iOS version, with the addition of a second, smaller, character on the keys. If the user does a long press on one of those keys a tooltip opens with the second, and maybe several other, characters available. Sliding into the tooltip and selecting one of the alternatives will enter that rather than the original character. This can be seen in operation on the en-us layout, and the Norsk layout.
Having used that system I really dislike returning to the iOS variation on the iPod and iPad.
