Increase target size of contextual links on touch devices

Tagging for Spark, mobile and touch.

Right now, we don't have any "edit in place" part of contextual links so I see no reason to switch to a pen.

Also is there a larger design here? Because switching to horizontal contextual links is quite a change, I am not sure I follow.

So I guess the main question, what is the scope? If its only to provide a better target area, why don't we just make the target area larger?

With the patch applied, all contextual menu items appear right away when hovering over a related item (not hidden under the gear dropdown). Note that the gear and the down arrow are still visible. The click/touch areas of the links are much bigger (not as big as on the design).

Also attaching a better setup patch, since both #1304470: Add tests for module-provided contextual links on blocks and #1868348: Missing contextual links on system menu blocks are needed to fix underlying contextual menu bugs. If this is not applied, all blocks only exhibit a configure link...

Crosspost.

Nice, I was going to open an issue very similar to this.

My idea was to use an invisible select box to invoke the native UI. Not only does this provide more focused and arguably better UI elements than we are capable of doing with CSS, it's also adaptable to the form factor of the device and the conventions of the OS in use. See the UI differences on a phone and a tablet I've attached below.

For more information on implementation See this page

@Bojhan: responding to your questions: the prime goal is to make contextual links touch friendly. Overall if it is a dropdown that appears on hover then it is not accessible on touch devices because there is no hover to make the dropdowns appear. @tkoleary's proposal is to achieve the touch compatibility by coupling this styling of the contextual links with the edit module. So the styling would not necessarily apply to Drupal without edit module being present. The patch changes Drupal as-is to make it easier to discuss (and figure out if we want to make it apply to Drupal in general as well without edit's global toggle).

Also, if the menu cannot be displayed above the block (for blocks at the top of the page), it would display vertically:

(That is not yet in the patch either).

@lewis That's a very interesting idea, @Gabor what do you think?

I dont think we should have any magical horizontal vs. vertical toolbars. The vertical contextual links will work just fine, across devices and scale much better than a horizontal one - which if it goes beyond the horizontal width (on sidebars easily achievable) looks off key. I really like the initial idea of #8, I dont know what those arrows do though

I'm neither a designer nor a mobile expert, but my personal opinion on using select lists is that it puts in an intermediate "alien" interaction to the navigation. Eg. showing a select list on all blocks and wanting to go edit a block or a menu displayed would need to go into a select list interaction would not make it easier to edit blocks in quick succession. I'll ask @tkoleary to follow up as well. He designed these proposals.

@jessebeach Cool, I really like the idea of making the contextual links better hit targets. I am not so sure about the horizontal vs. vertical decision, but definitely open for more discussion about. Some background on this at http://bojhan.nl/contextual-links, where we actually tested both options. Also the contextual links issue has some discussion around this.

Bojhan, fyi the designs above came from this prototype: http://invis.io/DTAMV1JF which I just finished a video on that Dries is about to include in a blog post.

Sorry guys, I'm able to give a better example now. It's a link that looks like any styled element (not a select box) that invokes the same UI that a select box triggers. I actually used this technique for the filter dropdown in my first prototype and you can check it out by visiting nav.d8mux.org and drilling down to the content listing page and tapping on the filter icon (cheesy I know)

Seems like we might have some scope creep here... If we are going to broadly redesign contextual links anyway then we might as well close this issue.

@lewisnyman This looks like a really interesting approach. Have you explored how it would work across multiple devices?

@tkoleary Sure, most modern mobile OS' use their own native widgets to make some form widgets more usable. All these styles are documented in each OS hig.

• iOS
• Android
• Windows

If we are targeting just touch devices in this patch we would be relying on detection of the Javascript touch event. That means that less modern non-touch devices will simply fall back to the current behavior.

@all,

I'm not sure if I still understand the intent of this issue, for the sake of discussion I've created an MVP patch that solves this issue with one additional CSS selector.

@lewisnyman This does seem to simplify implementation. I will test it out and think about how it integrates with the other interactions, especially the ones that involve moving blocks around. Also, what about the variety of flavors of Android? Will that be a problem?

@lewisnyman Urgh. Applied the patch to my local but cant seem to get it to work in xcode ios emulator. Any ideas?

Hey Kevin,

Sorry, I should of explained the above patch, all this one does is increase the text size of the contextual links on a touch device, which makes the links bigger targets, purely a minimal solution.

If you want me to knock up a prototype of my proposed concept for testing purposes... I'll have a look, splitting the contextual links theme function looked a bit over my head, I might be able to do it using javascript to modify the html.

@ lewisnyman that would be *awesome*. Meantime i'm installing squid so I can get my ipad to see all my Dev Desktop local installs. My first experience installing software directly from the command line.

A patch!

I gave it a pretty thorough test on iOS. Haven't got time to break out the phones but feel free to try it out. I'm trying to get it up on a publicly accessible server and failing...

Some discussion around the display of the contextual links when coupled with edit mode is also at #1882482: [meta] Unify editing approaches in Drupal.

I got this patch working now. It uses Tinynav.js

Hey Jesse, yeah that would be my preferred implementation. It makes no sense to put front end strain on mobile devices. I haven't seen any third party libs that handle this, maybe it's worth forking and reversing an existing lib like tinynav.js? Maybe not.

We all lost track of this for some reason a long time ago. I particularly like the extremely minimal MVP patch of LewisNyman in #18. It works rather well. It's an incremental improvement.

Perhaps this can get a screenshot?

Before

After

Nice! Ok, lets do this

Better title.

That looks a bit too B I G to me, but apparently people with better design sense than I have think this is a good idea, so cool. :) Plus I'm not sure how to make it smaller without moving to em/px instead of nice semantical stuff, so...

Committed and pushed to 8.x. Thanks!