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

Desktop

In T280277#7009876, @mewoph wrote:

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.

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.

In T280277#7009987, @mewoph wrote:

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

Desktop

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

Mobile

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.

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

In T280277#7015675, @MMiller_WMF wrote:

@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

Mobile

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

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	Actual

• 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

Actual

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' ]
	} );

In T280277#7111854, @mewoph wrote:

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:

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

With latest changes:

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

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

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