Opened 9 years ago
Closed 21 months ago
#32826 closed defect (bug) (maybelater)
"Custom Link" text in languages other than English
Reported by: | afercia | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.3 |
Component: | Customize | Keywords: | needs-patch |
Focuses: | ui | Cc: |
Attachments (1)
Change History (18)
#1
@
9 years ago
#4
follow-up:
↓ 6
@
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
@
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
@
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
@
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
@
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.
#11
@
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
@
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
@
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 parts of the flow.
#14
@
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
@
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
@
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
@
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.
Sorry sorry sorry, download is not in .diff format