Make Bartik sidebar menu blocks finger-friendly

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.

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.

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.

Assigning to myself

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.

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.

@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

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

Thanks again. Here is the fresh re-roll

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

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.

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

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.

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?

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

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.

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

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

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

Added to any menu in sidebar +1

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

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

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

Tested the patch in #16 but see nothing happening.

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

So I guess this is what we want!

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

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

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:

Core's toolbar uses the same pattern:

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?

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.

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

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.

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.

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

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

I am at the mentored sprint at Drupal Con 2016

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

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.

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

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.

@emma.maria, what do you think?

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

The #57 patch works for me

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

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. :)

Also, this is actually an important hyphen.

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.

Perhaps a more accurate title.

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?

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!

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

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

I like the general direction of #70 but I think they should look less button-y and more like how the tabs/main menu look in Bartik (screenshot below). I think buttons should be used for performing actions, not navigating.

Agree with Cottser here, and most of that is in the roundness applied. Also on "submission forms" like create content this will be confusing otherwise.

@cottser i had re-implemented the theming for add content link as per you comment. Now user can click on link on mobile device i had increased its height with padding so the link can be clickable on mobile. The recommendation was 44px x 44px now the height is 40px

Please look into this once.

Any update on this task.

This appears to be bartik specific and since bartik has been removed from core in D10 moving to the contrib project.

Sorry Bartik, we tried but after 7 years we still couldn't come to an agreement on how to add a little bit of space between items in the sidebar menu. :-)

Successfully Applied patch #16 for Drupal 10.1.x version. It is working as expected. Adding screenshots to refer after and before patch.

Hi @joginderpc

Confirmed it resolves when I applied patch #73 to the Bartik contrib theme against 1.0.2 version and with the Drupal core version 9.5.6.

Moving now to RTBC and
Please see the attached screenshots for your reference.

Please put the patch into an issue fork and merge request.

MR created, there were some non-related core changes in the patch in #73, now the patch is css only and for Bartik only. Hence "Needs review" again.
And patch provided too.

Hi @merilainen,

Confirmed it resolves when I applied MR!16 to the Bartik contrib theme against 1.0.x-dev.

Please see the attached screenshots for your reference.

I'm moving this now to "RTBC".

Thank you!

Does your RTBC apply to 1.1.x?