User input has to be made easy for users and font sizes have to be big enough for majority of the users.
One of the first things is to ensure that the pop up keyboard is relevant to the kind of input expected. For e.g. on a sign up form, when the user is required to input his mobile number, showing him a text keyboard by default is poor UX.
Html5 has a new form input type to make this easier to code. For e.g. changing the input type from ‘text’ to ‘tel’ does the trick for the above case as shown below.
Html5 has in fact added a lot of new input types. Input type email for e.g features the ‘@’ on the keyboard.
- allows client side validation, e.g for email ids.
- Has a pattern attribute to validate the input parameter, e.g only allowing India specific landline numbers).
- Has a ‘required’ attribute – i.e it tells the user that a particular input is mandatorily required before he can move on
- Has a ‘placeholder’ attribute – this allows for some hints to be given to the user that go away when the user starts typing.
However not all browsers may support html5 – in which case, unrecognised input type should fall back to ‘text’ (graceful degradation).
Another point to keep in mind is to always wrap ‘label’ elements around the ‘input’ elements. This increases the touchable area of the control i.e that the user can touch on the entire label and not just the input box to provide his input. In the example below, user will can only click on the checkbox in the first row but can click anywhere on the checkbox or the text itself in the second row.
Do remember that even though we do client side validation, it is a good practice to still do server side validation – this is because
- older browsers may not support such input types and
- because it is generally easy to circumvent client side validation.
One very useful feature on mobile is the click-to-call feature using the ‘tel: url’ attribute. This allows the users to directly call a number by clicking on a link – useful for businesses with a dial in number => customers can directly call the number when they are browsing on their mobile.
In the above example, clicking on the ‘call the lemur hotline’ directly leads to the screen below..
This should be however, disabled on desktops using a media query.
Simple rules for touch UI
- Don’t rely on :hover because a) Touchscreens usually don’t support hover and b) your finger would typically obscure whatever you would hover over.
- Use large hit targets – Unlike the mouse, which is a very accurate pointer, the finger is not and you need to make sure links / buttons are at least ~10mm in size.
- Don’t disable mouse support
- Do not assume that touch is useful only on mobile. Chrome and windows has allowed touch to surface even on desktop.
- Also, the user may use both touch and the mouse and even at the same time.
- Finally, you may not need to support touch by doing anything special. Touch events emulate mouse clicks and the browser builds in gestures like scrolling and zooming. So, you may need to do something only if the built in built in gesture support or mouse emulation does not give an optimum user experience.
- You do need to optimize for ‘click delay’. Mobile browsers interpret the double click as zoom-to-this-element and introduce a slight delay (about 1.3rd of a second) before it fires the click till it determines whether the user is double tapping. There are a few ways to fix the click delay as in below
- Disable double click – however, you have to ensure that in this case the user is not ever required to zoom in.
- Use a fast click library.
- Implement touch support directly.
The chrome developer tools lets you use mouse as a way to emulate touch events on a non-touch desktop in cases you do not have a touch supported mobile device to test.
However, ultimately there is no replacement possible to testing on actual touch devices.
Do read the other related posts which cover the notes for the other chapters of this course.
ps: to find all posts related to this post, searching for ‘mobile web development’ should help.