Make WordPress Core

Opened 9 years ago

Closed 21 months ago

#32826 closed defect (bug) (maybelater)

"Custom Link" text in languages other than English

Reported by: afercia's profile afercia Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: needs-patch
Focuses: ui Cc:

Description

Languages other than English often have strings that are remarkably longer than the English ones. Worth considering some extensive testing in as much languages as possible and maybe try to prevent some visual edge cases. See the "Custom link" case in the screenshot below:

https://cldup.com/0_UkWBETNf.png

Attachments (1)

patch.3.diff (607 bytes) - added by daniluk4000 9 years ago.
Please delete all attachments, exclude this... My bad internet -_-

Download all attachments as: .zip

Change History (18)

#1 @daniluk4000
9 years ago

Sorry sorry sorry, download is not in .diff format, is my private file, delete it please

Last edited 9 years ago by daniluk4000 (previous) (diff)

#2 @daniluk4000
9 years ago

Sorry for spam, created new diff file

Last edited 9 years ago by daniluk4000 (previous) (diff)

@daniluk4000
9 years ago

Please delete all attachments, exclude this... My bad internet -_-

#3 @SergeyBiryukov
9 years ago

  • Milestone changed from Awaiting Review to 4.3

#4 follow-up: @celloexpressions
9 years ago

  • Keywords needs-patch added
  • Summary changed from Customizer in languages other than English to "Custom Link" text in languages other than English

This also illustrates why we should really just use "Link" instead of "Custom Link". That would fix this issue in most of the languages above.

Let's use "Link" for the custom menu item type label and restore "Link" as the section heading, and then we could also make css adjustments if they're still needed. We can't afford to be excessively verbose, especially when translations can be even longer, when there is zero evidence that adding the word "custom" improves usability (other than specifically telling someone to add a custom item).

#6 in reply to: ↑ 4 @samuelsidler
9 years ago

Replying to celloexpressions:

Let's use "Link" for the custom menu item type label and restore "Link" as the section heading, and then we could also make css adjustments if they're still needed. We can't afford to be excessively verbose, especially when translations can be even longer, when there is zero evidence that adding the word "custom" improves usability (other than specifically telling someone to add a custom item).

No, as I said #32732, we need to user test which term is better. We've been using "Custom Link" for years. Before we make a change, we need to ensure that the change is actually an improvement. To use your language: there is zero evidence that "Link" has better usability than "Custom Link." Why change it now? Test it and see which is better. Provide data.

Whichever wins from a usability perspective is the one we should be using, regardless of the issue in this ticket. If we end up using "Custom Link," we'll need to figure out another solution for this ticket.

#7 @helen
9 years ago

Should other languages look to translate shorter? Just because it's shorter in English doesn't mean it will definitely be shorter in another language.

#8 @westonruter
9 years ago

Not to re-open #28504, but it seems that this would be a strategic place to introduce icons for the different menu item types. The icons could then have tooltips for the full translated strings. This would help a lot given the constrained space.

#9 @valendesigns
9 years ago

+1 I like the idea of an icon and tooltip. Is this something we should do? I don't want to waste time working on a patch if it's not.

#10 @helen
9 years ago

How would you handle tooltips for users without hover?

#11 @westonruter
9 years ago

If the icon is interacted with via a touch event, that there could instead be a ballon instead of a native tooltip, such as this: http://ux.stackexchange.com/a/35774

#12 @celloexpressions
9 years ago

I don't think icons or tooltips are things that we can realistically accomplish for 4.3 at this point. That leaves us with looking at simplifying the string and/or its translations as probably the best/only approach given the current timeline. That being said, the length of the string in most of the translations above, as well as in English to an extent, really diminishes the menus experience in the Customizer.

Many (possibly all?) of the user tests that were run previously used the term "Links" in the add-items panel. I'm not sure whether or not we can design a usability test that targets changing this string in particular in both places, or who may have the resources to coordinate such testing. But that is probably going to be the easier route to explore at this point. @designsimply, would you be able to look into this?

The translations look pretty direct to me, and I don't think there's a good way to inform translators that there's a maximum length to the string. Also not sure whether we should encourage them to simplify it to one word in a translation if we don't think it can be simplified to one word in English.

#13 @designsimply
9 years ago

Here are some clips where testers were asked to add a link to Twitter to a menu: 5m39s
(Note: there are clearly visible bugs in the first few clips which have been fixed now, some of these tests are from very early feature development)

In the first test, the links section was above the search section and the tester overlooked it completely for a while and it really frustrated them. The links section was moved below the search box as a result.

At 1:51, the tester looks directly at the links section and decides it's not the right thing because it says "URL" inside.

At 4:02, the tester misses "Custom Links" completely at first even though she was asked to "add a link to Twitter."

At 5:17, the tester has no trouble with the "Custom Links" label.

It's worth noting that every tester eventually completed the task of adding a link, even though some of them were more frustrated with the flow than others (particularly the first tester).

Even from these few early tests, you can see that there is a subset of users who have difficultly with both the "Links" and the "Custom Links" label. What I took away from this is that those two particular labels are either equally good or equally confusing :) depending on the tester's basic understanding of what a link is to begin with. My opinion is that the label is less important than one step back where users who may not understand what item types are yet are asked to select an item type as the first step when adding a new item.

Before we make a change, we need to ensure that the change is actually an improvement. […] Test it and see which is better. Provide data.

Take a look at the data in the highlight reel linked above and see what you think.

Based on the space constraint for translations alone, my opinion would be to change from "Custom Links" to "Links." I don't feel terribly strongly about either label though, and I care more about the other pats of the flow.

Version 0, edited 9 years ago by designsimply (next)

#14 @obenland
9 years ago

  • Milestone changed from 4.3 to Future Release

It doesn't look like we'll come to a consensus on this soon. Let's do it right, with user tests, in a future release.

(Although user tests are done only in English and don't always apply to translated versions).

#15 @karmatosed
8 years ago

I would note caution using just icons (even with tooltips), this isn't always as easy for people as sometimes you think. I would add a +1 to doing this right with user testing.

#16 @celloexpressions
4 years ago

  • Keywords close added

Are translations still using the long text as shown in the original screenshot on this ticket?

I would suggest closing at this point unless this has become an ongoing issue. I don't presently mind the length of the string in English and have similarly been fine with longer names for custom post type and taxonomy menu item types.

#17 @desrosj
21 months ago

  • Keywords close removed
  • Resolution set to maybelater
  • Status changed from new to closed

Found this ticket looking through a list missing a milestone.

I'm thinking that this can probably be closed out. This issue is totally valid, but Customizer is not deprecated by any means, but with the introduction of the site editor, the priority is there.

If anyone feels particularly passionate about this and is willing to lead the effort, it can be reopened.

Note: See TracTickets for help on using tickets.