Using text in the user interface

I would like to ask you if there is a reason to use all the items in the menu, etc. in the application user interface, for example

  • File-> Page Setup
  • Edit-> Select All
  • Help-> Technical Support

Why shouldn't I just mark these items as File-> Page Setup, etc.? This type of capitalization seems wrong to me, but I am not a native speaker of English, so I just can’t dig it out.

// (clicked Submit your question to do this)

+6
user-interface capitalization
source share
4 answers

In English, in general, names have all words, capital letters, with the exception of conjunctions (from, for, etc.) and prepositions (for example, p.) User interface elements (buttons, headers, menu items) are formatted as headers.

I have a piece of software that I'm using right now that has a Tasks menu and 3 items:

  • New challenge
  • Delete task
  • Task Properties

The difference in capitalization for the "new task" stands out for me by a mile - it just does not look "right."

+6
source share

In terms of ease of use, a capital uppercase letter (a capital letter of each letter) increases the visibility of non-original words in the title. This can help users quickly find keywords in the title to identify and distinguish between menu items. For example, compare:

  • Page Setup
  • View page

In contrast:

  • Page Setup
  • View page

Ideally, this is not necessary because your menu labels should start with their distinguishing keywords, but sometimes it just doesn't make valid captions.

In the Apple manual of the Human Interface Guide, a header style is standard for menu items (and commmand / push). The title style was also standard for MS Windows until Vista, when the Windows Vista user guide switched from recommending a title style to a sentence style (use only the first letter of the source word) for many situations, including menu labels ( http: // msdn .microsoft.com / en-us / library / aa511502.aspx ). I think this was part of an effort to have applications use an inductive interactive web interface, "where the parameters are formulated as sentence commands (for example," Create a nutrition plan, "" Do this for all current items ").

Personally, I would avoid such Wordier user interfaces for applications, especially for those that are regularly used by users, and thus using the extension button with a title. More words add clutter, and more reading slows users down. In fact, users tend to skip large blocks of text since reading takes a lot of time, so adding words often functionally reduces clarity.

+6
source share

Because the menu is usually formatted as titles in English. In the title, the first word is always capitalized, as well as any nouns, adjectives, verbs, adverbs and pronouns. Unless they are the first word in the heading, articles and prepositions are usually not capitalized.

+5
source share

I am currently working with a colleague about this. I’m probably at Apple’s camp in terms of user interface standards, and it’s right at Microsoft’s camp. Microsoft has recently been pushing Downstyle (from time to time I see a time when it comes to practice, especially with headings, only the first letter of the first letter). My colleague claims that he "checks well." Users (which is not surprising) can read the text faster when there is no “Tables on every word” to stumble. However, I believe that this should not be the basis for using it for user interface elements. I think there is a reason for this, but it would be difficult to verify.

When users test a piece of software (or a website) that they have never seen before, they primarily read everything (including the user interface). They read Show All Answers faster than Show All Answers. However, after a certain period of time, I believe that users switch to not reading user interface elements, but rely on faster methods to get the goal they will click on, such as a location or form. In this case, “Show all answers” ​​is easier to choose because it appears as a less ambiguous form than “Show all answers” ​​(your eyesight will probably show this). The argument is that it checks better, because users can read it faster, it falls apart, because users do not read buttons and menus, but agree on something they want in the memory of this thing. Probably the right way to check this is to see if users are starting to run slower in Upstyle than with Downstyle , but have an easier time with re-access, ultimately superior to Downstyle .

If you want to see a site that uses a lot of Downstyle in the user interface, check out Outlook.com or OneDrive.com, both of which are Microsoft products. It seems pretty obvious that using Downstyle is a grim crash on these sites, and I'm not talking about it because I'm "used" to UpStyle (after all, seeing 20 + years in the opposite can create quite a strong cognitive "noise" in my perceptions). However, I think this fails because using thin text Helvetica Extra Light for everything, relying on rollover, indicates almost every clickable thing (all this is inaccessible to the tablet user) and the general plane to the extreme (not one drop shadow, even if this helps eliminate the bilingual drop-down menu) make an interface that is much more difficult to use than it should be.

So, my advice, stay with the cover page ( Upstyle ) if you do not want your site to look like a Microsoft site until they see the error of their paths and revise it to look at which they are used to (which was like everyone else the rest).

0
source share

All Articles