Page MenuHomePhabricator

Increase touch target for superscript links
Closed, ResolvedPublic

Assigned To
Authored By
bearND
Apr 28 2020, 11:19 PM
Referenced Files
F34462850: LTR-one-sup-afrer-link.png
May 21 2021, 2:46 PM
F34462838: LTR-two-sups-left.png
May 21 2021, 2:46 PM
F34462828: RTL_issue-one-sup-links-around.png
May 21 2021, 2:46 PM
F34462840: LTR-two-sups-right.png
May 21 2021, 2:46 PM
F34462872: LTR-issue-three-sups-link-near-by.png
May 21 2021, 2:46 PM
F34462826: RTL_issue-one-sup-after-link.png
May 21 2021, 2:46 PM
F34462852: LTR-one-sup-afrer-link-and-small-text.png
May 21 2021, 2:46 PM
F34462844: LTR-three-sups-left.png
May 21 2021, 2:46 PM
Tokens
"Orange Medal" token, awarded by scblr.

Description

Parent ticket: T226401#5780144

(15) The superscript link on articles is 13dp x 14dp. Please increase to 48dp.

This comment might be helpful: https://phabricator.wikimedia.org/T226401#5348504

Event Timeline

Hi, @Volker_E , @MSantos ! Could you please review next approaches:

Possible solution to the issue:

Case 1:

A <sup> is NOT "surrounded" with <a> from both sides AND it is NOT multiple.

Solution to case 1:

Making touch target wider ang higher (but not as high as in the description as there could be an <a> element above the <sup>
(touch target can be increased from the bottom\left\right as in the description to this task)).

Case 2:

There is an <a> element from the left/right/both sides of the <sup>.

Solution to case 2:

Making touch target wider depending on from which side there is an <a>, increase touch target to the bottom direction (as in the description)
AND higher (but not as high as in the description as there could be an <a> element above the <sup>) .

Case 3:

There are multiple <sup> elements - (3 of them for example).

Solution to case 3(1):

Increasing touch target from left\right\bottom\top (with the restrictions, mentioned in previous cases), so,
for instance the touch target for the second <sup> of three of them will be increased only Up and down (But we can think of making space between multiple<sup> elemnts).

Solution to case 3(2):

We could combine multiple <sup> elements to look something close to [1,2,3], make them clickable with further small Popup display where a user could click each of them.
(In this case(if we make a popup) the touch target could be of the needed size, described in the description)


P.S. the clickable area can be increased with the help of -> Encreasing Paddings and Decreasing Margings (to the same values) around <sup>.

Thanks, everyone!

@Art.tsymbar I guess Solution 3(2) is something we don't want to do. The others, I would like to see in practice in a POC, please paste images here with your proposals for cases 1, 2, and 3.

Thanks, @MSantos !

Here they are:
("Michael_Lewis_(wide_receiver)" taken as an example)

Case 1: (A <sup> is NOT "surrounded" with <a> from both sides AND it is NOT multiple.)

case_1.png (221×534 px, 19 KB)

Case 2: (There is an <a> element from the left/right/both sides of the <sup> AND it is NOT multiple.)

case_2.png (168×433 px, 11 KB)

case_2_1.png (211×316 px, 8 KB)

Case 3: (There are multiple <sup> elements - (2 of them in this example))

case_3_1.png (213×310 px, 11 KB)

case_3_2.png (201×355 px, 11 KB)

To case 3 also:

  • if there are 3 of <sup>, the touch target for the second one will be increased from the top and bottom only
  • if there is an <a> element from the left/right/both sides of the <sup> - the restrictions from the Case 2 will be applied as well

The clickable area is increased for all this cases with the CSS like this:

margin: -4px -16px -16px -16px;
padding: 4px 16px 16px 16px;

@Art.tsymbar nice job! I'll give @cmadeo and @schoenbaechler a chance to comment on it in case I'm missing something.

The only thing that I would like to ask is: the behavior for N of <sup> that you describe is going to be applied if N >= 3 or just equals to 3?

Thanks, @MSantos !
I've taken 3 of <sup> as an example to show that a touch target of a <sup>, that is surrounded with other <sup>s, will be increased from the top and bottom only, So the behaviour, described in the example will be applied to any number of <sup> elements -> ( <sup> >=3).

Thanks @MSantos for the ping and @Art.tsymbar for working on this.

Per T251354#6984215 — do I understand correctly that the tap target size is going to be 36px high and ~ 18-45px wide? Google recommends 48x48dp, Apple 44x44pt as a tap target size. Is there a way to achieve this?

Thanks again!

CC: @cmadeo

Thanks, @schoenbaechler for the reply!

I can increase the touch target for a <sup> from the left and right sides to, for instance, 48px in case the <sup> is not surrounded with <a> elements as here:

case_1.png (221×534 px, 19 KB)

And if there is an <a> element from the left or right or both sides -> I can not as the part of an <a> will not be clickable.
Also, I could slightly increase a touch target from the bottom, but not to much as there can be an <a> element under a <sup> (on the next line).
And also there is a chance that there will be an <a> element above a <sup>: ,
case_2.png (168×433 px, 11 KB)

so it's also risky to increase a touch target in top direction. (And I do not think I could calculate if there is an <a> element above or under a <sup> element)
Thanks!

Thanks for the detailed answer @Art.tsymbar — from my end it’s fine to move ahead with your suggestions, it seems like you’ve managed to achieve the optimum here! 🚀

Change 692972 had a related patch set uploaded (by Vadim Kovalenko; author: Vadim Kovalenko):

[mediawiki/services/mobileapps@master] Increase touch target for superscript links

https://gerrit.wikimedia.org/r/692972

Hi @schoenbaechler , @MSantos , @Art.tsymbar

I've uploaded a patch set that solves this problem in the most cases. Also, I implemented solution for both RTL and LTR wikis.
Since this solution related to UX as well, I provide some screenshots with examples:

For LTR
Correct behavior (check localhost/en.wikipedia.org/v1/page/mobile-html/Cat):

  1. Single <sup> element

LTR-one-sup.png (75×217 px, 9 KB)

  1. Two <sup> elements

LTR-two-sups-left.png (95×695 px, 25 KB)

LTR-two-sups-right.png (87×714 px, 25 KB)

  1. Three and more <sup> elements

LTR-three-sups-left.png (86×398 px, 17 KB)

LTR-three-sups-middle.png (88×398 px, 17 KB)

LTR-three-sups-right.png (85×461 px, 18 KB)

  1. Single <sup> with link near by

LTR-one-sup-afrer-link.png (68×359 px, 16 KB)

LTR-one-sup-afrer-link-and-small-text.png (71×526 px, 16 KB)

  1. Two sup elements with the small text on the left bounded by the link

two-sup-after-small-text.png (81×389 px, 17 KB)

Incorrect behavior

  1. Two <sup> elements with link in the right

LTR-issue-two-sups-next-link.png (69×453 px, 14 KB)

  1. Three or more <sup> elements with link in the right

LTR-issue-three-sups-link-near-by.png (98×420 px, 24 KB)

For RTL
Solving RTL languages required creation the similar method as for LTR, but with reverted logic. Almost everything is correct, except few cases ( and probably reverted issues from LTR ).
For example:

  1. RTL_issue-one-sup-after-link.png (93×345 px, 14 KB)
  2. RTL_issue-one-sup-links-around.png (75×359 px, 11 KB)

These issues appeared because I use previousSibling and nextSibling instead of previousElementSibling and nextElementSibling methods.
If I try to use both these methods inside if statement, it will significantly increase the difficulty of already implemented logic since I'll need to add more than 3 levels of nested 'if'-s. Usage only previousElementSibling and nextElementSibling also is not an option because it will lead to worse bugs. In conclusion, all problems appear when I try to handle link near <sup> element.
Please, take a look at the code and share your thoughts here.

Change 692972 merged by jenkins-bot:

[mediawiki/services/mobileapps@master] Increase touch target for superscript links

https://gerrit.wikimedia.org/r/692972