Truncate Page and Topic Names and Msg Excerpts in Notifications Fly-Outs and Page
Closed, ResolvedPublic

Description

The new designs for notifications display Page Names and Topic Names in numerous situations and positions. Because these names can run to hundreds of characters, creating attractive and user-friendly designs will require us to truncate the names. The new designs also call for excerpts from page posts to be displayed, and the same requirement applies to these.

In establishing appropriate character limits, it may be desirable for the number of characters for a piece of data to vary in different positions: e.g., page names might need to be shorter in a secondary link versus a message body. However, while space is less constricted on the Notification Page than it is on the Notifications Panel, Engineering would prefer that limits for individual elements (e.g., message body, secondary link) remain consistent across both designs.

Below is a list of all the different positions and elements I can think of that will need truncation. Pau, I think the first part of this task falls to you -- to set appropriate limits based on your designs.

PAGE NAMES

  • in the first lines of notifications (Panel/Page).
  • in secondary links (Panel/Page)
  • in filtering menus (at left) on the Notification page

TOPIC NAMES

  • in the first lines of notifications (Panel/Page).
  • in secondary links (Panel/Page)
  • in bundled notifications (Panel/Page)
  • in filtering menus on the Notification page

CONTENT EXCERPTS

  • in the second lines of notifications (Panel/Page).

Proposed solution

For the notification text:

  • Truncate usernames at 20 characters.
  • Truncate page titles at 50 characters.

For the secondary actions:

  • Truncate both usernames and page titles at 15 characters (we could explore options for these to adapt to the available space, but 15 characters should provide enough information without causing the line to wrap).
  • Don't truncate when they are inside the more ("...") menu. This happens with bundled notifications, for example.

For excerpts:

  • Show one line of content and truncate when they overflow based on the available width (e.g., using text-overflow: ellipse).
    • If this makes hard to present the content inside quotes, we can skip the quotes and rely on the lighter grey text color to act as the delimiter for the excerpt.

Some additional considerations:

Additional considerations:

  • Make the notification panel a bit wider to have more room for content (e.g., 500px instead of the current 450px as recommended in T122646).
  • Check that truncation works well across scripts. This is always problematic since the concept of "character" is not trivial to map to some languages.
  • Apply character-based truncation with a safety range. For example only truncate to X characters if the text is longer than X+5 characters. That will avoid a 31 character-long username to get truncated just because of one character (making the truncated version with the ellipses longer than the original one).

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Checked in betalabs.

Several points:

  1. All truncation seems to be in place, although some minor adjustments may be needed - see T125909: [minor] Notification panel layout issues for multiline messages.
  2. 'Thanks' notifications do not truncate page and topic names according to specs - topic name is truncated to 199 from 229, and page titles is displayed with 105 char.

For the notification text:
Truncate usernames at 30 characters.
Truncate page titles at 50 characters.

For the secondary actions:
Truncate both usernames and page titles at 15 characters

For excerpts:
Ideally we should show one line of content [...]

For testing were used names with the following length:
username = 75 chars
page title = 105 chars
topic title = 215 chars

'Thanks' notifications:

Change 268605 had a related patch set uploaded (by Sbisson):
Truncate title and topic title in 'flow-thank' notification

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

  1. 'Thanks' notifications do not truncate page and topic names according to specs - topic name is truncated to 199 from 229, and page titles is displayed with 105 char.

I forgot flow-thanks, the fix is in https://gerrit.wikimedia.org/r/268605

Change 268605 merged by jenkins-bot:
Truncate title and topic title in 'flow-thank' notification

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

Etonkovidova added a comment.EditedFeb 6 2016, 12:45 AM

'Thanks' truncations are fixed.

Also, notice how there is no visible distinction from a user name, topic title, and Flow board title.

Including Notification page

@Pginer-WMF, do you want to look one more time at the screenshots here to confirm that these are the limits you like?

@Pginer-WMF, do you want to look one more time at the screenshots here to confirm that these are the limits you like?

From what I see in the screenshot below, it seems that the timestamp can still be pushed down for a combination of long user names and pages. Although that may be an edge case, we ay consider reducing the username limit to 20 characters.

There is also a separate ticket to make timestamps more compact: T125970: Use more compact timestamps for notifications

@Pginer-WMF wrote:

consider reducing the username limit to 20 characters.

Do you want to make that the new spec? (IMHO, 20 chars is probably sufficient).

@Pginer-WMF wrote:

consider reducing the username limit to 20 characters.

Do you want to make that the new spec? (IMHO, 20 chars is probably sufficient).

Yes.
To avoid confusion, and the need to read the whole comment history it would be good to update the ticket description (on top) with the latest updated proposal. I'll go ahead and I'll add it there.

Pginer-WMF updated the task description. (Show Details)Feb 9 2016, 6:25 PM

@Pginer-WMF wrote:

To avoid confusion, and the need to read the whole comment history it would be good to update the ticket description (on top) with the latest updated proposal. I'll go ahead and I'll add it there.

Brilliant! We should always do that.

Oh yes, good idea. I am now having a "good experience" of this ticket.

Change 269459 had a related patch set uploaded (by Sbisson):
Truncate usernames to 20 char in notifications

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

Change 269459 merged by jenkins-bot:
Truncate usernames to 20 char in notifications

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

Checked in betalabs.

User name 75 chars long shortened to 17 chars in message content and to 35 chars in secondary link.
Page name 142 chars long shortened to 30 chars.
Topic name 229 chars long shortened to 27 chars.

  • Text excerpts** 113 chars long shortened to 63 chars.

The screenshots show as a user with long username mention and thanked another users in a topic with a long name on a page with a long name.

The following needs some adjustments? Or the layout will be adjusted when fixing T126617: Too long line for secondary actions results in adding a horizontal scroll bar?

Etonkovidova added a comment.EditedFeb 11 2016, 11:36 PM

Adding the screenshot for secondary notifications -


Comparing Elena's counts to Pau's spec, some of these are right and some not:

  • User name 75 chars long shortened to 17 chars in message [CORRECT ]
  • User name 75 chars long shortened to...35 chars in secondary link. [INCORRECT, the limit in secondary links should be 15]
  • Page name in secondary link (not in Elena's count but I see in screenshots) [INCORRECT, the limit in secondary links should be 15]
  • Page name 142 chars long shortened to 30 chars [in header text]. [INCORRECT. limit in header text is 50 chars]
  • Topic name 229 chars long shortened to 27 chars [in header text]. [INCORRECT. limit in header text is 50 chars]
  • Text excerpts 113 chars long shortened to 63 chars. [CORRECT AS TO LENGTH but lacking quotation marks-- see below]

@Pginer-WMF, I'm sending this back to Product/Design Work so you can have another look at the spec. A couple of points:

  • Do the limits you made for page titles apply to topic titles? Just confirming.
  • What are the rules for truncating secondary links in the "..." menus that show in grouped x-wiki notifications? The same?
  • Also, are there design specs for those menus? Elena just showed me a screenshot she's adding to this that shows those going off the side of the menu, with scorllbars at the bottom. The fonts appear to be larger than in the rest of the notification.
  • Do you in fact want to widen the panels, as suggested above?
  • Elena thinks that perhaps the safety range idea you mention is in place. I agree that we shouldn't drop a ten-letter word because it is just over the line. A possibly simpler alternative might be to remove the requirement that truncation happen only between words. I personally don't mind seeing partial words, as we currently do with the excerpt. In fact, I find it adds clarity -- one more indication that truncation is happening.

Quotation marks

Pau writes:

If this makes hard to present the content inside quotes, we can skip the quotes and rely on the lighter grey text color to act as the delimiter for the excerpt.

I think this is a problem. Here's why: all parts of the notifications except the excerpts come, essentially, from the wiki. The wiki is either sending you a message (Congratulations!) or letting you know that such and such an action happened.

But the excerpt is not part of the wiki's message. To understand the excerpt, the reader needs to perceive a change in speaker. The excerpt is literally a quote from someone else's message. We've all read modernist novels where the author doesn't use quotation marks to signal changes from the authorial voice to the characters; they're hard to read! This is the same for me. When I look at the example above that has no quote marks I find it hard to follow.

Roan did some quick investigating just now and the method used to calculate that the excerpt will stay on one line may not work with quotation marks. If that's true, I'd rather fall back to using a character count -- as inexact as that may be -- so as to include the punctuation.

Re. my comments above

But the excerpt is not part of the wiki's message. To understand the excerpt, the reader needs to perceive a change in speaker. Etc...

I just looked at my own notification panel and I may have been too strong on this opinion. The context does a lot to clarify what's going on (context that is absent in the screenshots). So maybe some font or style change could help to set these off if quotation marks are too awkward to insert.

Re. my comments above

But the excerpt is not part of the wiki's message. To understand the excerpt, the reader needs to perceive a change in speaker. Etc...

I just looked at my own notification panel and I may have been too strong on this opinion. The context does a lot to clarify what's going on (context that is absent in the screenshots). So maybe some font or style change could help to set these off if quotation marks are too awkward to insert.

I think using a different tone of grey can help to make the distinction. Fixing these two issues would help in this area:

Ideally it would be great to have both, excerpts that show as much context as possible (one line long), and using quotes. If that is not possible, I still prefer the former to the later.

Do the limits you made for page titles apply to topic titles? Just confirming.

Yes. Topics titles tend to be a bit longer than pages but 50 chars seems enough for users to recognise which topic the notification is about.

What are the rules for truncating secondary links in the "..." menus that show in grouped x-wiki notifications? The same?

For the menu options I'd crop based on length. I'll elaborate:

My intention is the following:

  • Avoid horizontal scrollbars. It is not comfortable to move around a small interactive panel.
  • Avoid secondary actions to be cropped too early. If extensions provide actions such as "Mark this notification as read" and we truncate it to "Mark this notification as..." that is not very helpful.
  • Avoid the menu to become extremely wide. We don't want a menu that takes most of the user screen because it no longer will be perceived as a menu.

These are somewhat contradicting requirements, so I think a good middle ground could be:

  • Let the menu width grow based on the size of its contents up to a given limit (300px seems wide enough for a menu).
  • The titles of the actions (which can be page names, usernames, or actions provided by other extensions) will be cropped based on the length of the menu when they reach the above limit. We need to make sure that the title property includes the full content so that a tooltip is shown for the user in the cases where the cropping left out some relevant info (which should be rare).
  • Action descriptions will wrap when needed if the former length limit is reached. We encourage short descriptions, but show the information the extensions consider essential to explain the action.

The proposed approach illustrated (second action made extra long for the purpose of the example):

Compared to letting the text wrap:

Also, are there design specs for those menus? Elena just showed me a screenshot she's adding to this that shows those going off the side of the menu, with scrollbars at the bottom. The fonts appear to be larger than in the rest of the notification.

The menus were illustrated in T114357, but I can add more details in specific tickets (and the notification page prototype can be useful also as a reference). I created the following for the aspects that are not being met:

Do you in fact want to widen the panels, as suggested above?

The suggestion was to change the width from 450px to 500px. That was already done in T122646. So the current version already shows the slightly wider size.

Elena thinks that perhaps the safety range idea you mention is in place. I agree that we shouldn't drop a ten-letter word because it is just over the line. A possibly simpler alternative might be to remove the requirement that truncation happen only between words. I personally don't mind seeing partial words, as we currently do with the excerpt. In fact, I find it adds clarity -- one more indication that truncation is happening.

I'm ok in letting the truncation happen between words.

Change 270856 had a related patch set uploaded (by Sbisson):
Truncate section names to 50 char

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

Do we want to see the same truncation of secondary action labels on Special:Notifications?

I know the page is going away but in the meantime, should we truncate the links label like the flyout, differently, not at all?

For the secondary actions:

  • Truncate both usernames and page titles at 15 characters (we could explore options for these to adapt to the available space, but 15 characters should provide enough information without causing the line to wrap).

@Pginer-WMF Does it mean that we only truncate secondary link label if they are usernames or titles? For example: "Your translations" or "All links to this page" would not be truncated even if they are longer than 15 chars.

Change 270856 merged by jenkins-bot:
Truncate section names to 50 char

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

For the secondary actions:

  • Truncate both usernames and page titles at 15 characters (we could explore options for these to adapt to the available space, but 15 characters should provide enough information without causing the line to wrap).

@Pginer-WMF Does it mean that we only truncate secondary link label if they are usernames or titles? For example: "Your translations" or "All links to this page" would not be truncated even if they are longer than 15 chars.

Yes. Those actions are in control of the creators of the extension (unlike the page, user or topic related to the notification). We can recommend to have the actions as short as possible, but I'm not inclined to impose a strong limit (e.g., resulting in "Your translatio...") on those until we see it is really needed.

Change 271297 had a related patch set uploaded (by Sbisson):
Truncate secondary link labels

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

Change 271298 had a related patch set uploaded (by Sbisson):
Truncate secondary link labels

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

Change 271299 had a related patch set uploaded (by Sbisson):
Truncate secondary link labels

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

Truncation of secondary link labels for:

Change 271297 merged by jenkins-bot:
Truncate secondary link labels

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

Change 271299 merged by jenkins-bot:
Truncate secondary link labels

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

Change 271298 merged by jenkins-bot:
Truncate secondary link labels

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

Rechecked for

  • User name in secondary link- the limit in secondary links should be 15 - in the screenshot below it's 12
  • Page name in secondary link - the limit in secondary links should be 15 - in the screenshot below it's 12
  • Page name [in header text] - limit in header text is 50 chars - in the screenshot below it's 47 -Topic name [in header text] - limit in header text is 50 chars - in the screenshot below it's 42
  • Text excerpts - grayish font is in place - see the second screenshot.

Thanks for the counts Elena. Looking at them, I have a question about what's going on in the secondary links.

In the message header, page names and topic titles are cutting off at 47 (Elena, I think you forgot to include the namespace in your second count). The rules here are allowing partial words, so it appears ellipses are being counted as 3-- since that gets us to the correct limit of 50. Thus the rule here seems to be:

  • Partial words are OK, ellipses count.

In the secondary links, I can't actually tell what rules are being applied, since the 12 chars of the displayed phrase plus ellipses get us right to 15. @SBisson, are the rules the same as regards partial words and ellipses? And did we ever do anything with the idea of a "safety range"?

SBisson added a comment.EditedFeb 26 2016, 1:49 PM

Thanks for the counts Elena. Looking at them, I have a question about what's going on in the secondary links.

In the message header, page names and topic titles are cutting off at 47 (Elena, I think you forgot to include the namespace in your second count). The rules here are allowing partial words, so it appears ellipses are being counted as 3-- since that gets us to the correct limit of 50. Thus the rule here seems to be:

  • Partial words are OK, ellipses count.

    In the secondary links, I can't actually tell what rules are being applied, since the 12 chars of the displayed phrase plus ellipses get us right to 15. @SBisson, are the rules the same as regards partial words and ellipses? And did we ever do anything with the idea of a "safety range"?

The exact same rules are applied to the secondary links. 12+3=15

We're using MediaWiki's standard truncation everywhere.

It includes the ellipsis (which are not the same in all languages) in the count by default but I can disable it if you prefer.

It has no concept of safety range but I can add it if you want.

EDIT: I take it back, excluding the ellipsis in the count without a safety range could produce strings that are longer after truncation.

I propose the following options, in order of effort:

  1. Do nothing. Same behavior as everything else in MediaWiki.
  2. Keep the rules but increase the limits by 3 or 5 so we can view more content while keeping the width under control.
  3. Add a configurable safety range to Core truncation.

Thanks Stephane. Pau, my guess is that when you said 15 characters, you were thinking of actual content, not just the ellipses. I propose we keep the standard truncation rules but increase them by 3 chars, so we have 15 true characters.

@SBisson, please confirm that partial words are allowed in secondary links. I think partial words work fine and eliminate need for any complicated safety range.

@Pginer-WMF, what do you think?

@Pginer-WMF, what do you think?

I was thinking of 15 characters of actual content.

I think partial words work fine and eliminate need for any complicated safety range.

I'm not sure how partial words are related to the safety range. We need to break words partially to avoid a very long word to break the limits.

The purpose of the safety range is to avoid situations like one or two character crop (where the ellipsis gives the impression that there was actually room to display the content completelly). For example, given a 15 char limit, are we ok for the "worthwhilenesses" to be abbreviated as "worthwhilenesse..." or we prefer it to be displayed fully?

I think the safety range makes sense, but it is useful in few cases so if it brings major complication we can live without it.

The current limits are:

  • usernames (in header messages): 20
  • usernames (as link labels): 15
  • page names (in header message): 50
  • page names (as link labels): 15
  • section title, topic title: 50

Should I add 3 to all of them, some of them?

Another option for the link labels is to truncate only based on width (with text-overflow: ellipse). It makes the number of characters hard to predict but it guarantees that we are showing as much information as possible without breaking the UI.

Pau writes;

I'm not sure how partial words are related to the safety range.

If we don't allow partial words, then a name like Big Lebowskimama becomes just Big... So, partial words brings us Big Lebowskimam... which works well enough for me. Especially since the programming for the safety range doesn't yet exist (though Stephane doesn't seem to indicate that it's a big deal?)

So, with that proviso, I'd be comfortable just adding three characters to the secondary link labels and calling it a day. But @Pginer-WMF might have different thoughts. Pau?

But @Pginer-WMF might have different thoughts. Pau?

This seems definitely good enough. I'm totally fine in leave it as it is until we found further issues in practice if any.

The safety range is a nice touch to have but as I said previously, only if it is really trivial to support (here is an example in case it helps to clarify things).

Another option for the link labels is to truncate only based on width (with text-overflow: ellipse). It makes the number of characters hard to predict but it guarantees that we are showing as much information as possible without breaking the UI.

That would be a great option, but I suspect it may get complicated (at leas when not using flexbox) since there can be several variable length elements next to each other.

The safety range is a nice touch to have but as I said previously, only if it is really trivial to support (here is an example in case it helps to clarify things).

The algorithm is indeed pretty simple. It's having it reviewed and merged into Core that's a bit more tricky ;) I'll take a stab at it.

Another option for the link labels is to truncate only based on width (with text-overflow: ellipse). It makes the number of characters hard to predict but it guarantees that we are showing as much information as possible without breaking the UI.

That would be a great option, but I suspect it may get complicated (at leas when not using flexbox) since there can be several variable length elements next to each other.

It can be complicated if we want shorter labels to make room for longer labels. It's simpler if we allow each of them 200px max. It would show "as much as possible" of each of them in those 200px but it wouldn't "show as much as possible" overall.

@SBisson, you've named a number of possibilities here. As we said, we're fine with just adding three characters to the current scheme. But it sounds like you feel you can do more without too much effort. What are you proposing? Are you looking at abandoning the character count altogether and going for a combination of fixed width + safety range?

Change 274481 had a related patch set uploaded (by Sbisson):
Make link labels longer by 3 character

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

@SBisson, you've named a number of possibilities here. As we said, we're fine with just adding three characters to the current scheme. But it sounds like you feel you can do more without too much effort. What are you proposing? Are you looking at abandoning the character count altogether and going for a combination of fixed width + safety range?

I will:

  • Bump link labels max length from 15 to 18 characters to account for the length of the ellipsis. This is 0 effort and we seem to agree that it would be good enough. (https://gerrit.wikimedia.org/r/274481)
  • Implement safety range in Core and see what happens during review. If it's accepted, we'll use it. Otherwise, it's not the end of the world.

Sounds good. Pls answer one question though: currently, for secondary links, are partial words allowed?

Sounds good. Pls answer one question though: currently, for secondary links, are partial words allowed?

Yes they are.

I will:

  • Bump link labels max length from 15 to 18 characters to account for the length of the ellipsis. This is 0 effort and we seem to agree that it would be good enough. (https://gerrit.wikimedia.org/r/274481)
  • Implement safety range in Core and see what happens during review. If it's accepted, we'll use it. Otherwise, it's not the end of the world.

Actually, I found that there is some form of "safety range" already available. Not as configurable as we'd like but may still be good. Will check with @Pginer-WMF tomorrow morning if it's the preferred option. Otherwise, will go back to the steps above.

Sorry for all the back and forth about this.

Change 274481 abandoned by Sbisson:
Make link labels longer by 3 character

Reason:
Will use built-in safety range (length of ellipsis) instead.

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

Change 274699 had a related patch set uploaded (by Sbisson):
Notifications: truncate without adjust length

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

Change 274702 had a related patch set uploaded (by Sbisson):
Notifications: truncate without adjust length

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

Change 274703 had a related patch set uploaded (by Sbisson):
Notifications: truncate without adjust length

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

Change 274704 had a related patch set uploaded (by Sbisson):
Notifications: truncate without adjust length

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

Confirmed with @Pginer-WMF that the safety range in Core will do. 4 new patches to review and merge and we should be done!

Change 274702 merged by jenkins-bot:
Notifications: truncate without adjust length

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

Change 274699 merged by jenkins-bot:
Notifications: truncate without adjust length

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

Change 274703 merged by jenkins-bot:
Notifications: truncate without adjust length

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

Change 274704 merged by jenkins-bot:
Notifications: truncate without adjust length

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

Re-checked in betalabs with several variations of usernames - e.g. Testinglongusername A (21 char), L tolloremipsum LLL21(21 char) to test truncation with different word length in usernames.

  1. a user with 21-char username (to check intelligent truncation for the last word in the user name) will have the name fully displayed in the header - Testinglongusername A , and truncated to 15 chars in the secondary link:

In cross-wiki notification the truncation is the same: 21-char user name will be displayed fully in the header and truncated to 15 chars in the dotdotdot menu.

Another example of 21-char user name
21-char - L tolloremipsum LLL21

  1. The following shows that

User name 74-char long is truncated to 23 chars (with ellipses) in the header; in the secondary link to 18 chars (with ellipses)
Page name 229-char long is truncated to 53 chars (with ellipses)
Page name 100-char long is truncated to 23 chars (with ellipses) in the secondary link
Topic name 2280 char long is truncated to 53 (with ellipses)


I'm looking at this screenshot and see that Lorem ipsum dolor etc. is truncated in secondary link to

  • Lorem ipsum dol...

So, that truncation is 15 chars plus ellipses, which sounds right EXCEPT that the word that was truncated is "dolor". Which means we dropped two chars. Which means, if understand the safety range properly, it's not working.

@SBisson, isn't the safety range meant to preserve the whole word if it can be done with 3 or fewer chars? I.e., shouldn't that be Lorem ipsum dolor... ? Or did I misunderstand?

.

If I understand it correctly, the safety range is applied to the whole text string, not on individual words. That is, "Lorem ipsum dolor" won't be truncated, but "Lorem ipsum dolor whatever" will become "Lorem ipsum dol..." when truncated.

Exactly, the safety range applies to the string.

Have we considered the risk to have words truncated exactly at the wrong moment?

  • "A compliment! You have a nice assessment on that case, I really appreciate your approach!"
  • "A compliment! You have a nice ass..."

Exactly, the safety range applies to the string.

Great. In that case the code is working as planned and I will close the ticket.

"A compliment! You have a nice ass..."

@Trizek-WMF, you have identified a potential, shall I say, infelicity of the truncation system. I imagine it could be countered with a blacklist of words that should never be allowed to be formed, or some similar technique. @SBisson, please comment as to whether that is part of the truncation code already? If not, I think it's beyond the scope of our efforts here; Benoit, if you want to follow up, please introduce as a separate ticket.

jmatazzoni closed this task as Resolved.Mar 7 2016, 9:25 PM

@Trizek-WMF, you have identified a potential, shall I say, infelicity of the truncation system. I imagine it could be countered with a blacklist of words that should never be allowed to be formed, or some similar technique. @SBisson, please comment as to whether that is part of the truncation code already? If not, I think it's beyond the scope of our efforts here; Benoit, if you want to follow up, please introduce as a separate ticket.

It is not part of the code. And good luck doing it in Chinese as words are not separated by spaces...

That's really a minor side effect. We will see if we have feedback.