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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jeff Burnz’s picture

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.

LewisNyman’s picture

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.

Jeff Burnz’s picture

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

LewisNyman’s picture

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

Jeff Burnz’s picture

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?

LewisNyman’s picture

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.

Jeff Burnz’s picture

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.

LewisNyman’s picture

FileSize
32.44 KB
35.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

LewisNyman’s picture

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.

Jeff Burnz’s picture

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

LewisNyman’s picture

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

Jeff Burnz’s picture

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.

mgifford’s picture

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.

LewisNyman’s picture

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

JohnAlbin’s picture

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.

JohnAlbin’s picture

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

Moving off "fixed" list.

JohnAlbin’s picture

Issue summary: View changes

Removing "meta" issue.

Bojhan’s picture

Issue summary: View changes
Status: Closed (works as designed) » Needs work

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

LewisNyman’s picture

Issue tags: -#d8ux +Usability, +frontend, +CSS

Tags

mgifford’s picture

Issue tags: +Accessibility

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

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Needs work » Postponed

We need UX approval on this, even though it won't cause any visual changes to the page.

Moving this to 8.1 for now.

mgifford’s picture

Status: Postponed » Active

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kopeboy’s picture

Can 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 targets

mgifford’s picture

Issue tags: +Needs reroll

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

Jeff Burnz’s picture

@mgifford just do what we need to I think, issue is way old and needs to be addressed :)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

chriskinch’s picture

Issue tags: +Dublin2016
FileSize
46.8 KB
154.2 KB

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

Manuel Garcia’s picture

Status: Active » Closed (outdated)
Issue tags: -Needs reroll

Thanks @chriskinch - let's close this old issue then.