Design best practices

Designing for different character sets

Uppercase usage

Applying uppercase to any alphabets except Latin, Cyrillic, Greek, Armenian and Georgian does pretty much nothing. This means that for usernames in Chinese, Thai, Hindi, Arabic and many other languages this style definition is meaningless (the same letter is shown).

There is almost a consensus among researchers that, when other factors are controlled, lower-case characters are more legible than upper-case .

In some languages such as German, forcing words to uppercase or lowercase can have grammatical effect or look odd. Try to avoid forcing case unexpectedly; allow the translators leeway to make something lower or uppercase if it needs to be.

Finally, in Turkish and Azeri the letter 'i' changes somewhat unexpectedly with the uppercase transform. It's a minor issue, but an issue nevertheless.

Bear in mind that usernames are case sensitive, so the user Jdlrobson is different from the user JdlRobson. Never uppercase a username.

Designing for multiple projects

Article VS Page

The word 'article' is meaningless on various wikis and the word 'page' should be used wherever possible. That said in sometimes the word page itself is too ambiguous - for example when describing pages in the main namespace on Wikipedia the word 'articles' would be more meaningful. There is on going discussion about how to use this better. See https://bugzilla.wikimedia.org/show_bug.cgi?id=47841

Designing for multiple languages

Enforcing string limits on UI elements

Wherever possible, any design should take into account that text when translated might grow. Designs should reflect this but in some cases - for instance tabs on mobile, buttons this can be problematic and can be restricted.

If a string needs to be kept short, you should say so in the qqq message. Note a translator is not guaranteed to notice this (see bug https://bugzilla.wikimedia.org/show_bug.cgi?id=57867).

Adaptable designs

In addition to ask for strings to be short, we can also prepare our designs to accommodate longer text. Here are some ideas:

• Make lists expandable if all elements do not fit where expected, add dynamically an option to access the rest. I made a quick modification of the mockup as an example. Note that this (a) keeps the design the same as the original when there is room for it, and (b) also allows for other kinds of growth such as more items being added later to the menu.
• Make font size smaller if text exceeds a certain length You should make sure that the smaller font size is legible, and that similar elements do not appear next to each other with different font sizes (e.g., in the case of the list you should apply the font size reduction to all the elements of the list or none based on total length). Similarly, other layout parameters (margin/padding...) can be adjusted.
• Crop long texts Showing part of the text with an ellipsis at the end may be enough in some cases. This is the most risky approach since you are never sure on how much of the words you are missing and, although sporadically acceptable, nobody likes to see ellipsis everywhere. So that should probably be the last attempt once you tried to make the most room for text to grow.

Right-to-left languages

VisualEditor formulas icon for left-to-right languages

VisualEditor formulas icon for right-to-left languages. Notice that most of the image is just flipped, but the Σ icon is not flipped

Some languages are written right-to-left (Arabic, Hebrew, Persian, etc), which makes your life as a designer more interesting.

In general, in an RTL language context the entire UI layout will be flipped -- compare Arabic Wikipedia versus Spanish and you'll see the sidebar appears on the right instead of the left, the search box is on the left instead of the right, etc.

Much of this flipping happens automagically for you; some in the browser layout engine (such as default text direction for the given language) or by ResourceLoader's CSS style sheet processing. BUT NOT EVERYTHING IS MAGIC!

Best practices:

• Avoid specifying left/right at all if you don't really need to.
  • A particular case when you usually do have to specify 'right' or 'left' is writing background images, so your "background-position" rule should say "left 16px center" rather than just "16px".
• Make sure that the CSS flips correctly; if you aren't sure, ask a person who speaks a right-to-left language.
  • a lot of non-content UI designs can be tested simply by slapping ?uselang=ar or ?uselang=he on your URL
    • if it doesn't make sense flipped, apply /* @noflip */ annotations as necessary
• Icons sometimes need to be flipped, or partially flipped. Any icons that are not horizontally symmetrical may have to be flipped. Icons that imply directions, for example arrows, almost always need to be flipped, but there are exceptions here, too; for example, they "Play" button for audio or video is usually not flipped. If in doubt, ask an RTL language speaker.
  • Of images specified from CSS contain the "-ltr" suffix before the extension, like "menu-ltr.png", the flipping code will automatically replace it in RTL mode with an "-rtl" version, like "menu-rtl.png". This allows designers to provide flipped versions of the CSS.
  • Beware when using symbols such as question marks ("?") -- the standard ? is flipped in Arabic but not in Hebrew, for instance, so this should be considered a language-dependent symbol and not a directionality-dependent one.