Page MenuHomePhabricator

[Design] Link inspector layout issues
Closed, ResolvedPublic

Description

There are a few issues with the layout of elements in the link inspector on both desktop and mobile.

IssueActualExpectedImplemented
1. Image thumbnail size is too large
image.png (594×782 px, 67 KB)
Expected
image.png (1×1 px, 546 KB)
Screen Shot 2021-05-19 at 12.58.46 PM.png (346×574 px, 51 KB)
2. Image thumbnail should have 2px radiussee aboveper aboveborder-radius: 2px; for .mw-ge-recommendedLinkContextItem-linkPreview .oo-ui-iconWidget, .mw-ge-recommendedLinkContextItem-linkPreview .ve-ui-mwInternalLinkContextItem-hasImage
3. Image icon should be used when there is no image for the articlesee above
image.png (714×1 px, 426 KB)
Screen Shot 2021-05-19 at 1.02.47 PM.png (336×542 px, 49 KB)
4. Extraneous space between article and Yes/No/Prev/Next buttons
image.png (646×860 px, 39 KB)
image.png (546×1 px, 85 KB)
padding-top: 16px; still seems to be a bit too much
Screen Shot 2021-05-19 at 1.04.14 PM.png (371×543 px, 56 KB)
5. Yes button should be left-aligned with the suggested article titlesee aboveper above
Screen Shot 2021-05-19 at 1.07.04 PM.png (385×599 px, 74 KB)
6. Space between No button and Next button is more than expected when the buttons wrapsee above
image.png (272×914 px, 27 KB)
(mobile)
IMG_9741.PNG (1×640 px, 167 KB)
7. More padding between Prev and next chevron buttons than expected (this may be partly as the expected button use is a quiet button which would have less padding than the one in the actual one shown
image.png (434×800 px, 43 KB)
image.png (424×1 px, 42 KB)
Screen Shot 2021-05-19 at 1.40.37 PM.png (378×627 px, 80 KB)

Event Timeline

Hi @RHo, a few questions:

For 5, currently the Yes and No buttons are center aligned to maximize the chances that they would both fit on one line (since the previous button doesn't have a label, the available space is not symmetrical on both sides). If the button is always going to be aligned with the title, how would the UI look when only Yes fits on one line or when the recommendation has been rejected and three buttons are shown?

For desktop, should the buttons wrap onto the next line like in mobile? I couldn't find the mock for this state in desktop.

For 4, confirming the distance between the text and the buttons — it looks like the actual screenshot is from mobile but the expected mock is desktop's. Should it be 24px for mobile and 16px for desktop?

Mobile

Screen Shot 2021-04-16 at 9.49.20 AM.png (668×1 px, 123 KB)

Desktop

Screen Shot 2021-04-16 at 10.31.20 AM.png (740×1 px, 208 KB)

mewoph moved this task from Incoming to In Progress on the Growth-Team (Current Sprint) board.
mewoph moved this task from Backlog to April 19 - April 23 on the Add-Link board.
RHo updated the task description. (Show Details)

Hi @RHo, a few questions:

For 5, currently the Yes and No buttons are center aligned to maximize the chances that they would both fit on one line (since the previous button doesn't have a label, the available space is not symmetrical on both sides). If the button is always going to be aligned with the title, how would the UI look when only Yes fits on one line or when the recommendation has been rejected and three buttons are shown?

Ah yes, I was intentionally aligning the Yes with the title because the lack of label on the previous buttons meant that center-aligning would not be symmetrical. But your question made me realise and add point 7 in the task description about the Prev/Next buttons having less spacing internally and from the edges of the screen which might help provide more space for the Yes and No buttons with this alignment to the title.

I do see your point about how having a long 'Yes' and or 'No' could also cause further wrapping, so would we be able to provide one further flex in that case so that the buttons then left align and fit across the whole width, but any further we would clip so that the Yes No (and "..." if shown ) buttons always stay on one 1-line.

image.png (828×1 px, 188 KB)

For desktop, should the buttons wrap onto the next line like in mobile? I couldn't find the mock for this state in desktop.

I didn't include this for desktop as I assumed the inspector width would fit-content per the 'ideal' case, but you've made me realise this could lead to overly wide inspectors, so I have since added the additional states for desktop when text is long following the same rules as mobile above.

image.png (922×1 px, 312 KB)

For 4, confirming the distance between the text and the buttons — it looks like the actual screenshot is from mobile but the expected mock is desktop's. Should it be 24px for mobile and 16px for desktop?

Mobile

Screen Shot 2021-04-16 at 9.49.20 AM.png (668×1 px, 123 KB)

Desktop

Screen Shot 2021-04-16 at 10.31.20 AM.png (740×1 px, 208 KB)

Ahh it is actually the same for Mobile and Desktop, but I am measuring it as 16px from the bottom of the article result including the 8px bottom padding that should exist between the image thumbnail/article extract text and the bottom of that article result div.

Desktop
image.png (446×1 px, 160 KB)
Mobile
image.png (618×916 px, 135 KB)

I do see your point about how having a long 'Yes' and or 'No' could also cause further wrapping, so would we be able to provide one further flex in that case so that the buttons then left align and fit across the whole width, but any further we would clip so that the Yes No (and "..." if shown ) buttons always stay on one 1-line.

Here's how I would break down the work involved for this ask:

  1. Yes/No/Ellipsis breaks off when it can't fit on the same line as Previous/Next while aligned to the title.
  2. When it breaks off, Yes/No/Ellipsis are on the same line.
  3. When Yes/No/Ellipsis are on the same line, "proper" truncation is applied.

1 & 2 are fairly straightforward. I think 3 would be challenging to do right and there would be many edge cases to consider and to test out. Truncation requires that an element's width (or max width) be specified. A somewhat simple solution would be to pick a single value. This could lead into a situation where a button is truncated when it doesn't need to be (for example, if the translation for "Yes" is significantly longer than "No"), which would look pretty weird. To avoid this issue, we'd need to come up with a way for the width to be distributed evenly between all the buttons relative to their natural widths.

Here's an example when the max widths are distributed equally, but ideally the Yes button could take some of the allocated width from the No button.

Screen Shot 2021-04-19 at 9.02.42 AM.png (622×726 px, 56 KB)

@kostajh @MMiller_WMF @RHo — do you think this truncation (2 & 3) is needed for the initial launch? It will take me some time to get it right. The alternative is that we implement 1 and wrap the buttons when they don't all fit on a single line.

@mewoph -- no, I do not think that smart truncation is needed for the initial launch. I am okay with breaking to the next line as you described. I also want to propose one other alternative, in case @RHo likes this better than going to the new line: in the case when all the buttons don't fit on the same line, how about we use just the ✔ and ❌ on the buttons, with no words?

@mewoph -- no, I do not think that smart truncation is needed for the initial launch. I am okay with breaking to the next line as you described. I also want to propose one other alternative, in case @RHo likes this better than going to the new line: in the case when all the buttons don't fit on the same line, how about we use just the ✔ and ❌ on the buttons, with no words?

Thanks @mewoph - I agree with @MMiller_WMF that truncation is not needed for initial launch. However, I am wary of providing icon-only buttons as it is generally not advised UX practice [1] given there are very few universally-recognised icons suitable for this usage, though admittedly the checkmark/cross seems seems to be a strong contender. Perhaps another thing to consider is to include a note in the QQQ about keeping to as succinct text strings as possible in the translation, and we can revisit icon-only if we see a lot of wikis with truncating/overflowing action buttons?

[1] https://www.nngroup.com/articles/icon-usability/

Change 681198 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: Update link inspector styles and overflow state

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

I've added Please keep to as succinct text strings as possible in the translation. to the QQQs for growthexperiments-addlink-context-button-accept and growthexperiments-addlink-context-button-reject

Desktop

Screen Shot 2021-04-19 at 2.49.16 PM.png (650×850 px, 115 KB)

Mobile

Screen Shot 2021-04-19 at 2.33.59 PM.png (618×914 px, 67 KB)

Change 681198 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: Update link inspector styles and overflow state

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

Etonkovidova moved this task from QA to Design Review on the Growth-Team (Current Sprint) board.
Etonkovidova added a subscriber: Etonkovidova.

For @RHo review - I've updated the task description table with Implemented column.

Thanks @Etonkovidova and @mewop, this is almost done except for the following 2 minor items:

  • Item [3] is implemented but the image icon is still larger than the expected 20x20dp.
Expected
image.png (714×1 px, 426 KB)
Actual
Screen Shot 2021-05-19 at 12.58.46 PM.png (346×574 px, 51 KB)
  • Item [7] still seems to not be using a quiet icon button styling for the previous button, so it visually about 8px more padding on the left than the next button chevron is to the right. In other words, the "Next >" button is now looking good, but the previous "<" button needs to have reduced left padding:
Expected
image.png (424×1 px, 42 KB)
Actual
image.png (346×946 px, 33 KB)

Hi @RHo I'm not sure what you mean by "quiet" styling — I was looking at https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop and we are using the same ButtonWidget as the ones marked as quiet without any style overrides. Are you suggesting that we need to deviate from the default?

	this.prevButton = new OO.ui.ButtonWidget( {
		icon: 'previous',
		framed: false,
		classes: [ 'mw-ge-recommendedLinkContextItem-buttons-prev' ]
	} );

Hi @RHo I'm not sure what you mean by "quiet" styling — I was looking at https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop and we are using the same ButtonWidget as the ones marked as quiet without any style overrides. Are you suggesting that we need to deviate from the default?

	this.prevButton = new OO.ui.ButtonWidget( {
		icon: 'previous',
		framed: false,
		classes: [ 'mw-ge-recommendedLinkContextItem-buttons-prev' ]
	} );

Hi @mewoph - I mean the standard frameless button style in OOUI typically has the icon LHS aligned to the text more so than what it currently looks like in the mock. It's this button in the demo screen:

image.png (872×2 px, 131 KB)

Change 694671 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: link inspector style fixes

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

Change 694671 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: link inspector style fixes

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

Checked in wmf.14

  1. Image icon should be used when there is no image for the article

The placeholde 'no-image' img is 20x20 (I checked with Page Ruler redux).

Screen Shot 2021-07-16 at 4.00.10 PM.png (862×1 px, 133 KB)

@RHo - not sure if Previous button looks balanced enough. If it is, you may mark the ticket as Resolved

  1. More padding between Prev and next chevron buttons than expected (this may be partly as the expected button use is a quiet button which would have less padding than the one in the actual one shown
Screen Shot 2021-07-16 at 4.14.28 PM.png (492×780 px, 72 KB)
Screen Shot 2021-07-16 at 4.18.39 PM.png (377×723 px, 42 KB)

Wonderful, thanks all!

Checked in wmf.14

  1. Image icon should be used when there is no image for the article

The placeholde 'no-image' img is 20x20 (I checked with Page Ruler redux).

Screen Shot 2021-07-16 at 4.00.10 PM.png (862×1 px, 133 KB)

@RHo - not sure if Previous button looks balanced enough. If it is, you may mark the ticket as Resolved

  1. More padding between Prev and next chevron buttons than expected (this may be partly as the expected button use is a quiet button which would have less padding than the one in the actual one shown
Screen Shot 2021-07-16 at 4.14.28 PM.png (492×780 px, 72 KB)
Screen Shot 2021-07-16 at 4.18.39 PM.png (377×723 px, 42 KB)