Note that the selector in wikipedia portal does not use the MW core widget.

I added a column for mobile front-end, because the usage of this UI pattern is very prominent on mobile. To be honest, when creating the portal typeahead, we based the style on mobilefrontend because that was the primary usage of this pattern (that we could find). I knew visualEditor was capable of this pattern, but wasn't sure where it was being used.

Also, as @santhosh mentioned, I believe mobile front-end also doesn't use the MW core widget.

The "link selector" is mw.widgets.TitleSearchWidget in MediaWiki, designed to be used everywhere, but yes, neither the mobile web code nor the dashboards use it.

I added another difference which was not manifested in the selected screenshots. Descriptions are wrapped in one version while they are cropped in the other:

Aspect	Portals	Visual Editor	MobileFrontend
Description wrapping strategy	Long descriptions wrap to a new line	Long descriptions are cropped	Long descriptions wrap to a new line

Wondering if Related articles should be included in our conversation?

@Volker_E good point. Given how the related articles stack on mobile, I think they can be certainly be considered the same UI pattern (although they serve a different function )

A recent patch by @JGirault https://gerrit.wikimedia.org/r/#/c/342296/ changes the highlight color on the portal typeahead to light blue instead of grey. The patch would change the portal typeahead from this to this:

For what it's worth, I think this is an improvement because the link turns blue on highlight, making it more clear that it's a link, and I just think the blue link looks nicer on a light blue background than the grey background.

At first I thought this change would be more aligned with existing highlights, but after taking a look at visualEditor here, I notice the highlight color is also inconsistent.

@Volker_E I'm sure there's a discussion around this highlight color somewhere, so:
1.) I'd like to know if this portal change aligns with other other discussions around highlight colors.
2.) M101 suggests a grey background on :hover, and light-blue on :active, but I'm not sure if keyboard navigation (which is a high use-case here) should follow those states as well.

Highlight colours for lists of articles (e.g. search on the portal) need not be the same as highlight colours for other kinds of lists (e.g. text formatting options in VisualEditor). VisualEditor's lack of internal standardisation is an issue worth investigating, but I think it's distinct from this task.

Julien's patch moves things in the right direction from the portal side, so looks good to me from a product perspective.

Would this new treatment (blue link over lighter blue highlighting) work the same for the portal on mobile and desktop?

In T153417#3105793, @debt wrote:

Would this new treatment (blue link over lighter blue highlighting) work the same for the portal on mobile and desktop?

Mobile will display the list same as before: the highlighting background doesn't apply to mobile because mouse and keyboard navigation don't apply.

Thanks, just wanted to confirm. :)

@Jdrewniak @JGirault Here the group-internal patch review was faster than I could take breath from T161177, which I cared about for most of last week.
We've got several levels opposing forces here for list-like :hover states. Related discussion is going on at T92452#3134888.
Yes, keyboard navigation currently follows :hover grey on highlighting, so the merged patch is further drifting away from standards.

But I'm open for discussion, I have never been too much of a fan of grey as highlight color in menu context.

Another question from a style guide perspective, should the thumbnails feature rounded borders?

In T153417#3137564, @Volker_E wrote:

Another question from a style guide perspective, should the thumbnails feature rounded borders?

I'm not sure they need rounded borders, however I would like to see mockups with more padding around the thumbnails. VE has the thickest white space, I think it's the way to go, I would add even more white space (4px around the thumbnail, giving 8px vertical white space between each thumbnail).

Following (and forking) @Pginer-WMF's lead on T92452, I've created a sample on codepen. This has more whitespace between thumbnails, and doesn't use gray for :hover.

In T153417#3141804, @Prtksxna wrote:

Following (and forking) @Pginer-WMF's lead on T92452, I've created a sample on codepen. This has more whitespace between thumbnails, and doesn't use gray for :hover.

This is useful. I had some small considerations:

• The separation between elements may work better with padding than margin, otherwise it feels like gaps between the elements.
• Changing the background color of the page would help to visualise the list.
• It may be interesting to try using even more paddign and the 2px radius on corners for the images.

I made an example based on yours to illustrate the ideas.

In T153417#3137564, @Volker_E wrote:

Another question from a style guide perspective, should the thumbnails feature rounded borders?

I think rounded corners like the ones in @Pginer-WMF's example definitely make sense. Compare it with one without border-radius. I think the former is softer on the eyes.

Matching part of the title

An underline makes the most sense to me. Changing the weight of a few alphabets in a word will make them shift horizontally as the user types (in some fonts).

Description wrapping strategy

We could allow for both (ellipses and wrapping) and let the context decide how much information is needed.

Image size (compared to text)

This too, I feel, should be based on the context. The standard could define margins etc, but the size can be left to the user. For example, in the case of Commons' categories or File pages, a larger thumbnail, like in Related Pages, might be helpful.

Updating @Pginer-WMF example to add underlines and a longer description.

Initially I preferred the 'full-bleed' thumbnails, but now I see how the rounded corners (and necessary margin/padding) add finesse to the design.

One thing notably absent from @Pginer-WMF's example is the hairlines separating the list items. If this was intentional then let me defend those hairlines for the following reasons:

• They create clearer separation between list items.
• They guarantee better readability in case of a white background

I think those hairlines are important because not only do they help distinguish each item, but they make clear how many items are in the list. With that, I forked the proposal here with hairlines (a.k.a borders between list items) .

• In all your examples, applying line-height: 1.6; and making a few adjustments to center the text vertically would make the proposals look even nicer .

• Should the thumbnail size be 48x48 instead of 50x50 ?

I definitely like the way to see these iterations

Do we have consensus on this - http://codepen.io/anon/pen/aJQjao?

I do feel that it might not be the right way to go for Related Pages (mobile - Beta), as that feels more like a stack of cards, than a list of items.

In T153417#3168023, @Prtksxna wrote:

Do we have consensus on this - http://codepen.io/anon/pen/aJQjao?

It works for me.

Note that in VE's context we'll still need to style the results as links when they're going to be links (so link editor, redirect setting, etc.) but not in other search results (categories, templates, …).

I have added some thoughts to the topic:

• (A) - Latest consensus: http://codepen.io/anon/pen/aJQjao
  • (B) - With line-height: 1.6, text aligned vertically: http://codepen.io/jgirault/pen/EmYYjR
    • (C) - With more horizontal padding: http://codepen.io/jgirault/pen/mmbbeb
• Exploring another solution:
  • (D) - With illustration on the right side, to reduce the attention it captures http://codepen.io/jgirault/pen/MpNNJe
    • (E) - With accented titles http://codepen.io/jgirault/pen/LWwwWQ

Proposals D and E:
By working on it, I came to question whether we should keep the illustration on the left.
We promote encyclopedic content, therefore we need to give prominence to the substance rather than the form. The illustrations capture a lot of the attention, and I worry they may distract the users from their initial query. I started to think the illustration should be put secondary in the presentation.

In T153417#3170150, @JGirault wrote:

The illustrations capture a lot of the attention, and I worry they may distract the users from their initial query. I started to think the illustration should be put secondary in the presentation.

Interesting point. I was reading somewhere that it is quicker to recognize faces and people than text (in some case, of course).

It is in general, not only faces, evolutionary processing images by the factor 60 faster (a resource on advantage of data visualization). The point of @JGirault seems to me more, is the attached image relevant and sufficient? As they are curated, they are already used in several contexts (lead images mobile web/apps, related pages, Page previews) I'd say yes. I don't think that the image on the end provides us with special advantage…

I don't agree with line-height: 1.6 on multiline text, it's not harmonious and hard to read. Although I do understand where it originates from, maybe we could use some CSS magic to have one-liners differently positioned to the accompanying image than multiline descriptions.

In T153417#3170150, @JGirault wrote:

The illustrations capture a lot of the attention, and I worry they may distract the users from their initial query. I started to think the illustration should be put secondary in the presentation.

In this context images are helpful for quick disambiguation. In the example, we are using a one character search, but a more realistic example would be to search for a word where the results are more similar in text and their images help to identify the one you are looking for. For example, searching for "einstein" leads to a set of results where having images first works as a useful visual index.

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons:

• Simplicity. Avoids adding additional visual elements.
• It's a common practice in similar contexts such auto-completion lists in search engines.
• Underline may be associated with links so it may generate some confusion about why part of the result is a link (and another part is not). Although this is a minor concern since, I don't think it would prevent the list from being usable in any case.

Here are some experiments:

• Bolding the matching part (or try the approach live at quora)
• Bolding the unmatched part (or try the approach live at google or bing)

In T153417#3170622, @Pginer-WMF wrote:

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons…

In T153417#3143306, @Prtksxna wrote:

Matching part of the title

An underline makes the most sense to me. Changing the weight of a few alphabets in a word will make them shift horizontally as the user types (in some fonts).

With our font stack, I am not sure if we can ensure fixed width. Will need to do some testing.

In T153417#3170624, @Prtksxna wrote:

In T153417#3170622, @Pginer-WMF wrote:

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons…

In T153417#3143306, @Prtksxna wrote:

Matching part of the title

An underline makes the most sense to me. Changing the weight of a few alphabets in a word will make them shift horizontally as the user types (in some fonts).

With our font stack, I am not sure if we can ensure fixed width. Will need to do some testing.

I don't think that the width change produced by the font weight change would cause much disruption here (compared to changing it on hover, where it can become annoying, for example). In this context, as the user types, some results in the list would disappear completely, others will appear, and others will change their position in the list (as a result of the former).

In T153417#3170625, @Pginer-WMF wrote:

I don't think that the width change produced by the font weight change would cause much disruption here (compared to changing it on hover, where it can become annoying, for example). In this context, as the user types, some results in the list would disappear completely, others will appear, and others will change their position in the list (as a result of the former).

Yep, I agree with you. With so much change happening in the list, that the minor horizontal shift, if any, would be undecipherable.

Multiline text

I don't agree with line-height: 1.6 on multiline text,

@Volker_E touched on a point that the current proposals do not address, and one that deserves further investigation: multiline content. Broadly, there are 2 ways of handling multi-line content:

1. Truncate the content

A.	B.

content limited to a few lines, truncated with either ellipses (A.) or a white gradient (B.)

2. Expand the height of the item

C.

Item expanded to fit content, with thumbnail expanding to fill height

If we expand item height, then how should we treat the thumbnails? in pic C the thumbnails are expanded to fit the height, but that only works for 'full-height' thumbnails. In pic A there are 2 list sizes (with small and larger thumbs), but mixing these two sizes in the same list would look weird. I think that leaves two options: truncate the content to a set number of lines, or, let the item height expand, but keep the size of the thumb static (maybe pinning it to the top of the item).

In T153417#3170622, @Pginer-WMF wrote:

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons:

Strongly agreed! :)

In T153417#3170622, @Pginer-WMF wrote:

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons:

• Simplicity. Avoids adding additional visual elements.
• It's a common practice in similar contexts such auto-completion lists in search engines.
• Underline may be associated with links so it may generate some confusion about why part of the result is a link (and another part is not). Although this is a minor concern since, I don't think it would prevent the list from being usable in any case.

Here are some experiments:

• Bolding the matching part (or try the approach live at quora)
• Bolding the unmatched part (or try the approach live at google or bing)

Screenshots from biggest search engine:

Yandex	bolding the matching part
Duckduckgo	bolding the matching part
Google	bolding the unmatched part
Bing	bolding the unmatched part

My intuition is that bolding the unmatched part is the most interesting, as it boldens the information we want the user to read as instantly as possible. I also think Google and Bing have done research to come to that conclusion. We can assume that, or we can run our own research on the portal with an A/B test.

It's important to notice that Duckduckgo and Bing also use a lighter font color for the unmatched part, giving the highlighted part even more prominence.

In T153417#3179913, @JGirault wrote:

My intuition is that bolding the unmatched part is the most interesting, as it boldens the information we want the user to read as instantly as possible. I also think Google and Bing have done research to come to that conclusion. We can assume that, or we can run our own research on the portal with an A/B test.

It's important to notice that Duckduckgo and Bing also use a lighter font color for the unmatched part, giving the highlighted part even more prominence.

I agree with this (the assumption about research), but having default suggestions that are seen by a lot of users bold matched text and these styles bold unmatched text would bring somewhat more confusion in the interface. If you are deciding on this, then it should also affect another important existing style.

Detailed rant: I've never come to accept that we glue the images in the results so closely together. I personally find this more confusing and badly designed then helpful. One of the imaginative side-effects is navigating separated results.

Is wvui TypeaheadSearch the answer here? Interested in this as I'm thinking about getting the team to port RelatedArticles to the new wvui component...