I think we need to do a full audit on the sizes of all our 'clickable' elements in Seven and then define a minimum height and width.
In the iPhone Human Interface Guidelines, Apple recommends a minimum target size of 44 pixels wide 44 pixels tall. Since physical pixel size can vary by screen density, Apple's pixel specifications apply best to the iPhone's 320 by 480 pixel, 3.5 inch display (164ppi). Since the release of the iPhone 4's Retina Display (326ppi) Apple has updated these specs to points instead of pixels.
In the Windows Phone UI Design and Interaction Guide (PDF), Microsoft goes further and suggests: a recommended touch target size of 9mm/34px; a minimum touch target size of 7mm/26px; a minimum spacing between elements of 2mm/8px; and the visual size of a UI control to be 60-100% of the touch target size.
They also suggest touch targets can be larger than 9mm if: the UI element is frequently touched; the result of a touch error is severe or really frustrating; the UI element is located toward edge of the screen or difficult to hit; or when the UI element is part of a sequential task –like using the dial pad.
Nokia's developer resources suggest that touchable interface elements should not be smaller than the smallest average finger pad, that is, no smaller than 1 cm (0.4") in diameter or a 1 cm × 1 cm square. Minimum target sizes for a finger usable UI element are:
- 7 x 7 mm with 1 mm gaps for index finger usage
- 8 x 8 mm with 2 mm gaps for thumb usage
- List type of components should have minimum of 5 mm line spacing
- The width of a finger limits the density of items on screen. If the items are too close, the user will not be able to choose a single one.
Comment | File | Size | Author |
---|---|---|---|
#29 | google-page-speed-ux.png | 154.2 KB | chriskinch |
#29 | admin-links-screenshot.png | 46.8 KB | chriskinch |
#9 | Increased the size of admin list links-1137800-4438560.patch | 3.32 KB | LewisNyman |
#8 | admin-panels-1.jpg | 35.9 KB | LewisNyman |
#8 | admin-panels-2.jpg | 32.44 KB | LewisNyman |
Comments
Comment #1
Jeff Burnz CreditAttribution: Jeff Burnz commentedOK just dumping out some thoughts on this:
- doesn't this apply equally as well to Toolbar and Shortcuts? What about contextual links?
- do we have any data at all - a full audit is a pretty big task so I'm wondering if there's a cheaper way to quickly identify problem areas?
- is there a maximum size? Can things be too big?
Sounds like we do need to investigate this more - perhaps we can take a first stab at collecting some data (partial audit) and see what problems start to crop up.
Comment #2
LewisNymanIn theory it will apply to any clickable element. I can't imagine we can do much about inline links thought.
I have made separate issue to deal with the toolbar and contextual links.
#1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop
#1138844: Add touch support to contextual links
We could try and be smart when going about an audit and trawl through the related CSS files for common elements instead of combing over each page. I'll get on that soon.
Comment #3
Jeff Burnz CreditAttribution: Jeff Burnz commentedOK, for the audit it might make sense to dump that into a spreadsheet (google doc) and either link to it or attach.
Comment #4
LewisNymanI've done a fairly shallow audit of the main pages, prioritizing pages most likely to be accessed from a mobile phone. I think with a bit of luck this will give us a fairly general feel of most touch targets.
Seven Theme Touch Target Audit
I've highlighted all the targets that fall below Apple's recommended height and width, 44px.
The modern suggestion seems to be to implement these sizes using points, so they stay a consistent size on retina displays
Comment #5
Jeff Burnz CreditAttribution: Jeff Burnz commentedWhat do you make of these results Lewis, clearly a large number of fails there, does this indicate we perhaps need to have some serious re-thinking on Seven mobile interface and a fix & repair job is not really going to cut it?
Forgive me if I am asking a dumbass question but how does zoom affect this, I use Android phone and mostly have very few issues navigating most sites since I can just zoom in a click something - is this the wrong way to be looking at this and do we need more of an app style UI and feel?
Comment #6
LewisNymanI see the zoom function as a fix put in place to allow users to navigate pages that have not been designed with handheld devices in mind. This is acceptable on news sites and blogs, although the rising use of applications like Readability and Reeder might be a good insight into how inefficient the regular browser is as fixing this. Users are ripping out the content themselves and placing it in a 'mobile friendly' wrapper.
I see the Drupal administration interface as something completely different to this, it is a web application for managing your Drupal site. I see it very close to a web app like Basecamp, which itself has recently gotten the mobile treatment.
I see this going two ways:
We escalate this whole MUX initiative to become a major UX concern. Every Drupal UX decision needs an equivalent mobile decision to go with it going forward. It would also require an analysis of all decisions made during D7UX.
We carry on picking up bits and pieces through limited testing and tweak the current components to achieve an acceptable experience on handheld devices.
I think we all know which would be best for Drupal in the long term but given the amount of interest in the initiative so far option 2 is far more achievable.
Comment #7
Jeff Burnz CreditAttribution: Jeff Burnz commentedOk, looks like we need to have more discussion on this and a broader assessment of the issues. Drupal 8 is in pretty early days and I think quite a few are still having a rest after 3 years on D7 + feeling out where they want to make an impact - the mobile issue is a big one and we probably need to spend more time in data collection and overall assessment of the issues such as what comes out of #1107906: Improve device responsiveness. so I'm personally not in too much of a hurry to jump into solutions and for myself at least need more of a handle on the problems.
Comment #8
LewisNymanJust posting an obvious improvement here:
Current target area of Admin Panels
Proposed target area
To use the account settings leaf as an example, we've gone from 20px X 135px to 64px X 547px
Comment #9
LewisNymanOk, I've made some progress with git and I've constructed a patch that increases the size of the admin panel links. I've also added appropriate styling for events.
Comment #10
Jeff Burnz CreditAttribution: Jeff Burnz commented#9 needs a separate issue and I'd like to see some UX input on this first before we work on a solution. When you post a patch for review you need to explain exactly what the patch does, how it solves the issue and why this approach is good/better etc.
What we really need to do is nail down a list of things that need changing, then go into a UX/design review and come with visual design for these changes then start working on patches/code solutions.
Comment #11
LewisNymanGot it, I'm setting up a group so we can take some decent discussion over these issues.
I worry about producing static images as 'designs' in this context. Considering the varying context and relevant tangible elements such as finger sizes to worry about I think rapid prototyping is a far better solution. We already have the content in place ;)
Comment #12
Jeff Burnz CreditAttribution: Jeff Burnz commentedI know that sound like a good idea (rapid prototyping) but I've been through enough issues the same or similar to know that rapid prototyping often turns into everything but rapid. A design phase can throw up interesting problems and creative solutions and give us thinking room for better implementations (and space to discuss various approaches before even writing any code at all) - we don't have to be in a hurry on this, we have plenty of time to get this right rather than just getting it done.
Comment #14
mgifford@lewisnyman any word on the group or the new issue?
Comment #16
LewisNymanI think this has become more of a meta issue. I'll see if I can update the issue summary later.
Comment #17
JohnAlbinSee also #1138844: Add touch support to contextual links
I'm not sure we need a meta-issue for this actually. There's no need to track all of these issues in one global issue. And there's no debate on whether this is needed. (It definitely is needed.) Closing since we have too many meta-issues already.
Comment #18
JohnAlbinMoving off "fixed" list.
Comment #18.0
JohnAlbinRemoving "meta" issue.
Comment #19
Bojhan CreditAttribution: Bojhan commentedI am going to reopen this. Lets actually first establish a guideline, in this issue and then make sure we apply it everywhere. We need a standard first.
Comment #20
LewisNymanTags
Comment #21
mgiffordSmall touch surfaces can have accessibility issues too.
So, some standard like "Apple’s iPhone Human Interface Guidelines recommends a minimum target size of 44 pixels wide 44 pixels tall."
http://www.smashingmagazine.com/2012/02/21/finger-friendly-design-ideal-...
"usually suggested in style guides to use a general target sizes of 9mm"
http://ux.stackexchange.com/questions/39023/what-is-the-optimum-button-s...
These were also interesting..
http://www.uxmatters.com/mt/archives/2013/03/common-misconceptions-about...
http://mobiforge.com/design-development/designing-touch-thumb-and-finger...
Comment #22
mgiffordWe need UX approval on this, even though it won't cause any visual changes to the page.
Moving this to 8.1 for now.
Comment #23
mgiffordComment #25
kopeboy CreditAttribution: kopeboy commentedCan we have an update? It's a simple fix and affects D7 as well.
Google PageSpeed Insights won't give any website a 100/100 in User experience cause of this.. :/
The tap target
<a href="#main" class="element-invisi…ment-focusable">Skip to main content</a>
is close to 1 other tap targetsComment #26
mgifford@kopeboy Agreed that it wouldn't take too long to re-roll https://www.drupal.org/files/issues/Increased%20the%20size%20of%20admin%... but Jeff thinks it should be a new issue instead.
Can you have your Skip to main link show up in another location that doesn't interfere with the other links?
Comment #27
Jeff Burnz CreditAttribution: Jeff Burnz commented@mgifford just do what we need to I think, issue is way old and needs to be addressed :)
Comment #29
chriskinch CreditAttribution: chriskinch as a volunteer and at Dennis commentedI was going to take a look at this as part of my first Drupal Con Dublin code sprint but it looks like it may have been resolved elsewhere?
I've added a screenshot for how the admin links look in 8.3.x.
Also, from what I can tell Google Page Speed is no longer complaining about UX (100/100) from #25
Not sure if any of this helps move the issue on?
Comment #30
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedThanks @chriskinch - let's close this old issue then.