Align the style for lists of pages
Open, HighPublic0 Story Points

Description

Showing the user a list of pages to select is a pattern that is useful in many different contexts.
While it makes sense for the pattern to be adjusted according to the context, it seems that current implementations have discrepancies on common aspects we may want to align.

I compared the search box of Wikimedia-Portals with the link selector of VisualEditor, and these are the differences I found:

AspectPortalsVisual EditorMobileFrontendRelated Pages (mobile - Beta)
Screenshot
Page title colorDark greyBlueDark greyBlack
Matching part of the titleUnderlinedBoldedUnderlinedN.A.
Description text colorDark greyLight greyDark greyDark grey
Title and description text sizeTitle bigger than descriptionSame size for title and descriptionTitle bigger than descriptionTitle bigger than description
Description wrapping strategyLong descriptions wrap to a new lineLong descriptions ends in '...'Long descriptions wrap to a new lineLong description cropped and ends in '...'
Image transparencyImages are always opaqueImages are translucent (unless item is hovered)Images are always opaqueImages are opaque
Image size (compared to text)More prominentLess prominentMore prominentEven more prominent
Background color on hoverLight greyLight blueNo changeNo change
Separation between itemsThin line in light greyThicker white spaceThin line in light greyThin line in light-grey
Restricted Application added a project: Discovery. · View Herald TranscriptDec 16 2016, 8:26 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

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

Jdrewniak updated the task description. (Show Details)Dec 16 2016, 4:03 PM
Jdrewniak added a subscriber: Jdrewniak.

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.

Pginer-WMF updated the task description. (Show Details)Dec 20 2016, 9:36 AM

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:

AspectPortalsVisual EditorMobileFrontend
Description wrapping strategyLong descriptions wrap to a new lineLong descriptions are croppedLong descriptions wrap to a new line

Wondering if Related articles should be included in our conversation?

Volker_E triaged this task as High priority.Jan 5 2017, 10:30 PM

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

Jdrewniak updated the task description. (Show Details)Jan 10 2017, 11:31 PM

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.

debt added a subscriber: debt.Mar 16 2017, 12:29 PM

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

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.

debt added a comment.Mar 16 2017, 9:24 PM

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?

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.

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.

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.

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:

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.

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

Volker_E added a comment.EditedApr 11 2017, 7:41 AM

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.

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:

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…

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.

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…

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

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

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! :)

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:

Yandexbolding the matching part
Duckduckgobolding the matching part
Googlebolding the unmatched part
Bingbolding 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.

cmadeo added a subscriber: cmadeo.Jun 6 2017, 11:29 PM
Jdforrester-WMF set the point value for this task to 0.Jun 28 2017, 12:01 PM