See Google Material Design (http://www.google.com/design/spec/patterns/selection.html) where it is mentioned that "Using checkboxes (or custom analogs) to initiate selection is an explicit anti-pattern for mobile".
-
Wow. That's not a great example of good proofreading. The recommendations are quite unclear. Judging from the context, they're talking about selecting items for manipulation. Long-press isn't the global gesture to select data in other contexts. After all, checkboxes are still present in List controls.– dnbrvFeb 11, 2015 at 6:53
-
And I've never used (and would never think about using) a two-finger tap to select an item...– virtualnobiFeb 11, 2015 at 7:08
2 Answers
Material design doesn't discourage the use of checkboxes for mobile.
The link posted in the question refers to a specific use of checkboxes as a way of selecting items (eg an entire row, or a group of controls, or some text). Checkboxes are not good for that kind of interaction because it confuses the function of the checkbox. There are several reasons why:
You would be "clicking on one place to select at another place" which masks ux intent.
In mobile/responsive design you cannot depend on the area being selected being rendered continuously (eg a row may get wrapped) so checkboxes for selection leads to confusion.
It conflates the function of the checkbox with other normative uses for the same control (Ie tradition check-the-box control)
All other "conventional" uses of checkboxes are perfectly fine for mobile, and in fact checkboxes can be a great control for some mobile interfaces because of how compact and broadly recognized they are.
As a practical matter, checkboxes are among the worst rendered native html control in most browsers so if you do use checkboxes a styled control may be more usable for many situations.
I can only guess, but I think the intention behind this guidance is that Google wants to eliminate the ubiqitious appearance of checkboxes as first column in every table, for (single or multiple) selection. I would agree with the statement that this is an explicit anti-pattern for mobile (while it appears often on desktop designs).
As stated, first think about whether multiple selection is required. If it is not, don't use checkboxes at all, but directly select and/or act on the item. If multiple selection is required, show checkboxes only after the user indicated he wants selection (like long press, dragging, etc.). I've even seen tables with an explicit "Show checkboxes" button in the header bar.
Note that the guidance explicitly allows checkboxes in other contexts than selection (i.e., "The use of checkboxes in contexts such as [...] is entirely appropriate." So the formulation of the question in this generality here is not supported by the Google guidance at all.
EDIT: I think the reason for not showing checkboxes initially is that they take up space and add visual clutter to the design. So if multiselection (what checkboxes are needed for) is a rare use case, the designer can keep the design leaner for the more frequent use cases. For example, I've seen apps that have a trashbin in the top right corner initially. Only if you press that, checkboxes appear on all table rows (requiring labels to shrink).
-
Can you please elaborate on "If multiple selection is required, show checkboxes only after the user indicated he wants selection (like long press, dragging, etc.)"? Why are you recommending to not show checkboxes all the time and make the user do something to see checkboxes. Feb 11, 2015 at 9:15
-
In gmail app, the big circle acts as a checkbox. I can tap on multiple circles and the option in the header change accordingly. Honestly, for months I'd no clue that it was a checkbox. I always tapped on the mail subject and it opened. I may be one of those many dumb users ;) but I still feel that showing checkboxes upfront is better from user's perspective. Feb 11, 2015 at 9:18
-
@PratapGadgil I've added a hopefully clearer explanation. And I wouldn't call any software user dumb. You may be inexperienced, but the designer's task is exactly to make the software usable for inexperienced users as well. The hard part (for the designer) is then to make expertise valuable as well... Feb 27, 2015 at 12:07
-
I agree that it's upon the designers to make the design work smoothly for novice users, preferably without any training / hand-holding. I also observe a difference of interaction regarding desktop and mobile sites and both make perfect sense respectively. I am running some quick tests to see whether there's a common approach to this interaction. Mar 2, 2015 at 3:34