Problem/Motivation

On mobile/touch devices, some participants of the usability study found the 'add content' link in the sidebar hard to press.

Proposed resolution

Make it bigger, the recommendation is 44px x 44px
Consider a rule that makes non-content links bigger?

Remaining tasks

None.

User interface changes

Bigger touch targets on mobile

API changes

None.

Data model changes

None.

Files: 
CommentFileSizeAuthor
#70 mobile.png26.27 KBsudhanshug
#70 desktop.png47.62 KBsudhanshug
#70 interdiff-make_the_add_content_2524272-70.txt3.11 KBsudhanshug
#70 make_the_add_content_2524272-70.patch3.39 KBsudhanshug
#57 make_the_add_content_2524272-57.patch701 bytesbrahmjeet789
#57 interdiff-52-57.txt227 bytesbrahmjeet789
#52 make_the_add_content-2524272-52.patch698 bytestassilogroeper
#52 interdiff-2524272-47-52.txt1.01 KBtassilogroeper
#52 2524272-52-states.png8.01 KBtassilogroeper
#52 2524272-52-default.png8.13 KBtassilogroeper
#47 make_the_add_content-2524272-47.patch679 bytesanna@femath.com
Home___Site-Install.png289.17 KBLewisNyman
#1 bigger_tools_menu_links-2524272-1.patch933 bytesmErilainen
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 102,539 pass(es). View
#1 tools-menu.png39.77 KBmErilainen
#4 Screen Shot 2015-09-01 at 15.32.23.png18.76 KBemma.maria
#11 make_the_add_content-2524272-11.patch490 bytesChandeepKhosa
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,485 pass(es). View
#12 Screen Shot 2015-09-06 at 17.14.02.png25.73 KBlegolasbo
#16 make_the_add_content-2524272-14.patch888 bytesLewisNyman
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,542 pass(es). View
#16 Screenshot 2015-09-07 17.18.59.jpg30.9 KBLewisNyman
#34 normal.png3.86 KBpguillard
#34 touch.png4.42 KBpguillard
#42 interdiff-make_the_add_content-2524272-16-42-do-not-test.diff680 bytesszeidler
#42 Bildschirmfoto 2016-05-05 um 20.15.53.png21.85 KBszeidler
#42 make_the_add_content-2524272-42.patch624 bytesszeidler

Comments

mErilainen’s picture

Status: Active » Needs review
FileSize
933 bytes
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 102,539 pass(es). View
39.77 KB

Not sure if this is the correct approach, but since there is no general menu component css file in Bartik, I made a tools-menu.css and made the font-size bigger. The breakpoint is the same as for the main menu. Probably needs work.

LewisNyman’s picture

Thanks for the screenshots. From a design perspective I think that increasing the font size kind of breaks the heirachy of the element, because the title “Tools” is now smaller than the content.

Another way we've done this in the past is to increase the padding on the link, so the target increases without the font size changing. See the conversation in #1137800: Increase minimum size of targets for touch screens for more discussion.

I think there is also work to do from the code size, using @file comments and not using ID's. We can do the design changes first though and then pull in Emma to review the code.

LewisNyman’s picture

Status: Needs review » Needs work
emma.maria’s picture

I think this should be added to any menu placed in the sidebar. Modules seem to add items to the Tools menu, plus we should keep styles consistent.

In the screenshot I added padding top and bottom to any menu-item in the sidebar so they became a height of 44px.

See screenshots.
 

 

Also note the space on the left of menu items is a bug and being dealt with in another issue.

emma.maria’s picture

Issue tags: +Novice

As no one has answered I would like to move forward and implement a new patch with the direction in #4.
Any sidebar menu at a touch device screen widths gets the styles outlined in #4.

ChandeepKhosa’s picture

Assigned: Unassigned » ChandeepKhosa

Assigning to myself

ChandeepKhosa’s picture

Assigned: ChandeepKhosa » Unassigned
Status: Needs work » Needs review
FileSize
398 bytes
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,387 pass(es). View
462.91 KB

I created a patch that does this successfully, with changes to bartik/css/components/sidebar.css

I targeted the 'a' link tag which works well, the only issue with this is that the underline appears lower. Any ideas on how I can improve my patch?

Screenshot of this is attached.

legolasbo’s picture

Status: Needs review » Needs work

Good start, thanks for your efforts. You'll find my review below.

  1. +++ b/core/themes/bartik/css/components/sidebar.css
    @@ -65,3 +65,7 @@
    +  padding: 44px 0;
    

    This adds 44px of padding to the top AND bottom making the element at least 44px high. Also, since there is no media query. it also gets applied on regular screen sizes, not just mobile devices.

  2. +++ b/core/themes/bartik/css/components/sidebar.css
    @@ -65,3 +65,7 @@
    \ No newline at end of file
    

    As per the coding standards, there should be a newline at the end of a file.

ChandeepKhosa’s picture

Status: Needs work » Needs review
FileSize
487 bytes
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,468 pass(es). View

@legolasbo, thanks for the feedback. That's what you get when writing a patch in a hurry before lunch :)
1) Have changed this so it adds 22px to the top, and 22px to the bottom. I have targeted this to viewports less than 768px wide.
2) Done

legolasbo’s picture

Status: Needs review » Needs work
+++ b/core/themes/bartik/css/components/sidebar.css
@@ -1,5 +1,10 @@
+@media screen and (max-width: 768px) {

I assume you didn't test this, because your media query is missing a {

Also, why did you choose the 768px breakpoint? The sidebar has a breakpoint at 851px (min-width) and the menu uses 900px. The general consensus seems to be to use 851px, which means you would have to break at max-width 850.

ChandeepKhosa’s picture

Status: Needs work » Needs review
FileSize
490 bytes
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,485 pass(es). View

Thanks again. Here is the fresh re-roll

legolasbo’s picture

Status: Needs review » Needs work
FileSize
25.73 KB

I reviewed the results of the patch, it doesn't produce the desired result. Please see attached screenshot taken at about 800px screen width.

LewisNyman’s picture

Assigned: Unassigned » LewisNyman

Emma asked me to come up with a better design for this

szeidler’s picture

What is lacking in patch #11 is a display: inline-block. Otherwise the padding-top and padding-bottom will be ignored completely.
The downside of using inline-block or other displays, is that the border-bottom will be pushed down and away from the actual text, which looks weird.
See attached patch and screenshot.

The only solutions, that come to my mind, would be a usage of :before or:after for in some way. But feels too much for such a task.

szeidler’s picture

LewisNyman’s picture

Assigned: LewisNyman » Unassigned
Issue summary: View changes
Status: Needs work » Needs review
FileSize
888 bytes
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 110,542 pass(es). View
30.9 KB

Here's the patch. I changed a lot of the original patch so an interdiff didn't seem worthwhile.

emma.maria’s picture

Issue tags: -Novice
legolasbo’s picture

Status: Needs review » Needs work

@LewisNyman,

Even though i like the chevrons, they are out of scope for this issue. The patch should only fix the issue at hand. Adding chevrons should be done in a separate issue. Besides that your changes look good from a code perspective.

LewisNyman’s picture

@legolasbo I agree the scope has expanded a little, it's tricky to just fix the problem at hand if it looks bad. It requires a little bit of design on top of the technical solution. I'll ask Emma to comment on the scope.

emma.maria’s picture

Status: Needs work » Needs review
Issue tags: +Needs usability review

I agree that a solution for touch here will probably need a change in design. I will however admit that the blue arrows initially surprised me as nothing like this exists in Bartik right now.

I'm adding the mighty "Needs usability review" tag to get more eyes on this.

yoroy’s picture

The underline moving down is because it's a border style, not an actual link underline, right?
So, why is it a border in the first place?

emma.maria’s picture

The default link style has a dotted underline, which can only work with a bottom border :-(

LewisNyman’s picture

This decision was made in #890362: Links should not be indicated by color only and it has come back to bite us ever since

yoroy’s picture

Right. I wouldn't want to revert to underline instead of border-bottom just for this issue alone, but if that decision is hurting us in more places we should probably reconsider.

Bojhan’s picture

Issue tags: -Needs usability review

I think the design approach by Lewis here makes a lot of sense, you shouldn't have more than a couple links in here anyway

yoroy’s picture

So the chevrons would only be applied to the 'Tools' menu, right?

emma.maria’s picture

I thought for consistency it should be any menu added to the sidebar as they will all print like the Tools menu. Bad idea?

legolasbo’s picture

Added to any menu in sidebar +1

Hubbs’s picture

I do like the updated menu as Lewis has it in comment #16, but I question the chevrons. It's common to have an chevron/arrow as part of a single link or button design (i.e. Read More buttons). However, chevrons/arrows in a menu often mean there is some sort of slideout or dropdown that will activate. If we don't include the chevron/arrow we leave open the possibility for adding one in later, if multiple menu levels are required. Just a thought :)

emma.maria’s picture

Issue tags: +Needs usability review

@yoroy would you be able to take a look at this issue again with fresh eyes and provide any input?

yoroy’s picture

Ok! I retract my #26 :)

for consistency it should be any menu added to the sidebar as they will all print like the Tools menu.

Lets see a patch that does this. We need to see it in action to make a call on this. Lets explore this direction where any menu in the sidebar would get the same treatment with the chevrons ">".

yoroy’s picture

Version: 8.0.x-dev » 8.2.x-dev
Status: Needs review » Needs work

Tested the patch in #16 but see nothing happening.

yoroy’s picture

pguillard’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
3.86 KB
4.42 KB

I just compared adding a touch class to the container, and this is what I got :

Normal

Touch

pguillard’s picture

So I guess this is what we want!

yoroy’s picture

Looks like it yes! :) Is the patch in #16 still ok then?

pguillard’s picture

Status: Needs review » Reviewed & tested by the community

It is still OK. I would say RTBC for that one !

yoroy’s picture

Issue tags: +sprint
webchick’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
FileSize
28.02 KB
125.63 KB

Hubbs raised a good point in #29 that I don't think was addressed, and was my first thought when seeing this, too. Basically, it seems like > in a mobile pattern normally means an "expando-thingy" to take you down a sub-nav. Here are some examples I found while searching for mobile navigation patterns:

On navigation, only 'Shop' has a chevron, leading to sub-items

Core's toolbar uses the same pattern:

Core's toolbar has arrows as buttons that also expand down

So I'm a little worried that mixing the two might be confusing, because on Tools and other associated menus, clicking the link just takes you straight to a page. Any data we out there that illustrates when chevrons are appropriate?

markconroy’s picture

There's an interesting study here about using icons in menus: https://www.viget.com/articles/testing-accordion-menu-designs-iconography

An interesting takeaway:
"Finally, participants were asked via multiple choice question what they thought would happen after they clicked. The majority of participants believed the menu would change (Figure 4), while a small number believed they would be taken to a new page..."

What we are doing with this patch is "taking people to a new page" - the expected behavior of only a "small number".

Also in the study (albeit there was only a small sample of people used), having the chevron on the right resulted in slower response times.

The results of this would suggest not using the arrow unless it is to expose more menu options. Presently as a stylistic device it may look nice, but as a UX tool it should serve a different function.

yoroy’s picture

Status: Needs review » Needs work

Thanks for that. So we want something without the chevron.

szeidler’s picture

Thanks @markconroy for the linked study. It approves the feeling, that the chevron could be ambiguous ux-wise. Then we should focus on solving the main purpose of the issue, making the links finger friendly, without introducing new and potentially confusing patterns.

I removed the chevrons from Lewis' approach, but keeping the borders, which makes the link area identifiable and follows the button separation pattern from core's toolbar.

markconroy’s picture

Why are we changing this for touch screens only? I don't think we lose any benefit by having it for all screen types.

Actually, I think click screens would also benefit, especially for people who are not too steady with a mouse.

mikeohara’s picture

Issue summary: View changes

I am going to take a screenshot of the result of #42 as part of this issue at Drupal Con 2016

mikeohara’s picture

I attempted to test #42 on both Simpletest.me and on my local environment and did not see the expected result.

Only local images are allowed.

I am at the mentored sprint at Drupal Con 2016

mikeohara’s picture

Status: Needs review » Needs work

I am changing this ticket to "Needs Work" because of the results obtained from my test of the most recent patch.

anna@femath.com’s picture

Status: Needs work » Needs review
FileSize
679 bytes

This is a new approach than the last patch that was submitted so I have not included an interdiff.

  • I removed the .touch class and used a media query instead.
  • I also adjusted the spacing of the menu below the heading so the spacing is visually equal.
  • For a hover/active rule, I added a background color instead of a text decoration. (The color contrast is not acceptable for accessibility, but none of the links have sufficient contrast on hover/active. I will be creating a separate issue for that.
mikeohara’s picture

Status: Needs review » Reviewed & tested by the community

I tested the patch above and do see that it does perform as intended. I do think it is an improvement.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 47: make_the_add_content-2524272-47.patch, failed testing.

yoroy’s picture

Status: Needs work » Needs review
Issue tags: +DevDaysMilan
tassilogroeper’s picture

Assigned: Unassigned » tassilogroeper
tassilogroeper’s picture

Hi,

nice work so far. Since this issue had not moved on, I took the liberty to review it and update the styles.
- As pointed out by @markconroy #43 there is no need to actually media query the links only to mobile. Thus, I removed it.
- Plus, I also added the active state with a solid white background. see screens attached.

Side note:
Bare in mind, touch targets are not only limited to mobile device widths. Even large displays may have the ability to engage via touch.

One Important thing can come up, too: you may have to add additional margin between the elements to make them touch friendly. In my experience, Google Page Insight sometimes complains about links being too close to each other.

FYI: working on it at the Milan DevDays.

tassilogroeper’s picture

Assigned: tassilogroeper » Unassigned

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.

yoroy’s picture

Assigned: Unassigned » emma.maria
Issue tags: -sprint

@emma.maria, what do you think?

tkoleary’s picture

Issue tags: -DevDaysMilan +sprint
brahmjeet789’s picture

@tassilogroeper i have reviewed your patch and it is working fine for me but the menu hover color is different that's why i used the same background color on hover that is used in search icon's hover ,please review it.

Status: Needs review » Needs work

The last submitted patch, 57: make_the_add_content_2524272-57.patch, failed testing.

Bojhan’s picture

Assigned: emma.maria » Unassigned

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tikaszvince’s picture

Status: Needs work » Reviewed & tested by the community

The #57 patch works for me

tikaszvince’s picture

Issue tags: +SprintWeekend2017
Gábor Hojtsy’s picture

Just expanding on @tikaszvince's comment, I've seen him testing on an Android phone and on desktop for touch friendliness in person at the sprint weekend :)

xjm’s picture

The screenshot images in the summary seem to be broken; can someone embed the latest screenshots up there for clarity?

Also it looks like a theme maintainer hasn't had a chance to review this in the past year, so tagging for subsystem maintainer review. Leaving RTBC though because that review could also be our frontent framework manager's on commit. :)

xjm’s picture

Title: Make the 'Add content' link in the 'Tools' block finger friendly » Make the 'Add content' link in the 'Tools' block finger-friendly

Also, this is actually an important hyphen.

Cottser’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs subsystem maintainer review

Thanks everyone, and sorry that this got stuck in the queue.

Reviewed this with some of the other committers and we found some design and usability issues with it. The hover looks a bit weird (especially on desktop) and the contrast ratio there is questionable.

@xjm will upload a screenshot or two later on.

Cottser’s picture

Title: Make the 'Add content' link in the 'Tools' block finger-friendly » Make Bartik sidebar menu blocks finger-friendly

Perhaps a more accurate title.

xjm’s picture

Issue summary: View changes
FileSize
49.18 KB
56.9 KB

So yeah, the design on the hover needs review I think:

We also should confirm (for any such fix) that the colors meet contrast guidelines per the accessibility gate.

While the hover makes it clear what the clickable area is on desktop, so that the user would not be surprised by the link opening when they click there, that's not really helpful on mobile because there is no hover. There is no visual indication for mobile that the entire area is clickable, so it introduces the inverse of the original usability problem: a mobile user has no indication that the empty gray area is a link, and so if they click on it unintentionally, they will unexpectedly be taken away from their current page to somewhere strange they did not intend. Screenshot on mobile with the current patch:

Is there any reason the sidebar menu shouldn't just be responsive?

abbym’s picture

To be clear - per comment #68 above (xjm), is the suggestion that we retain the latest's patch's vertical padding, but make it no wider than the word itself? Also, what specifically is meant by "Is there any reason the sidebar menu shouldn't just be responsive?" Thanks!

sudhanshug’s picture

I suggest to make the anchors in the side-menu look like buttons but behave like anchors anyways. I propose the following solution:

Desktop(notice that the colors are changed for perfect contrast ratio as suggested in #68):

Desktop

Mobile(notice that the anchors look like CTAs and hence are intuitive to user's click behavior):

Mobile