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.

Only local images are allowed.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.

Luke Wroblewski

Files: 
CommentFileSizeAuthor
#9 Increased the size of admin list links-1137800-4438560.patch3.32 KBLewisNyman
FAILED: [[SimpleTest]]: [MySQL] Fetch test patch: failed to retrieve [Increased the size of admin list links-1137800-4438560.patch] from [drupal.org].
[ View ]
#8 admin-panels-1.jpg35.9 KBLewisNyman
#8 admin-panels-2.jpg32.44 KBLewisNyman

Comments

OK 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.

In 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.

OK, for the audit it might make sense to dump that into a spreadsheet (google doc) and either link to it or attach.

I'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

What 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?

I 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.

Issue tags:+mobile

Ok, 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.

StatusFileSize
new32.44 KB
new35.9 KB

Just 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

StatusFileSize
new3.32 KB
FAILED: [[SimpleTest]]: [MySQL] Fetch test patch: failed to retrieve [Increased the size of admin list links-1137800-4438560.patch] from [drupal.org].
[ View ]

Ok, 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.

#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.

Got 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 ;)

I 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.

Status:Active» Needs review

@lewisnyman any word on the group or the new issue?

Status:Needs review» Needs work

The last submitted patch, Increased the size of admin list links-1137800-4438560.patch, failed testing.

I think this has become more of a meta issue. I'll see if I can update the issue summary later.

Status:Needs work» Closed (fixed)

See 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.

Status:Closed (fixed)» Closed (works as designed)

Moving off "fixed" list.

Issue summary:View changes

Removing "meta" issue.