共用方式為


Press, Click, Select or Choose?!?

This might be useful for Windows Mobile developers. Does your application display an error or informational message that begins with "Click here to...." ? You might have noticed similar messages often begin with "Click" or "Press". Which is the right word to use? Here are some variations of the same message:

  • "Click New to create a new message"
  • "Press New to create a new message"

The distinction always used to confuse me and I finally checked with someone on our content publishing team. The guideline is to use "Press" when referring to a hardware button and "Click" when referring to an item in the UI (e.g. soft keys, list items, push buttons etc.) Don't use "Select".

Examples:

  • Click Talk to place a phone call [WRONG! Talk is a hardware button]
  • Press OK to continue [WRONG! OK is not a hardware button]
  • Select New to create a Contact [WRONG! Use "Click" or "Press". Don't use "Select"]

What about "Choose" vs "Select"? Use "Select" for your soft key label and dialog box title when picking an item from a list. For example, if you have a dialog box that allows the user to pick a time zone, the left soft key should be labeled "Select", and the title should be "Select Time Zone". Using "Choose" in the title bar will cause localization issues and also be inconsistent with the soft key.

I hope this explanation helps developers use the most consistent terminology in your Windows Mobile apps.

-Mel Sampat

Comments

  • Anonymous
    November 18, 2008
    So what should be used when there is a hardware button AND a UI element?  OK/Close is a common example because most (but not all) Pocket PC's have a hardware button for that, as well as UI.  On some, the hardware button is only visible if the keyboard is extended.

  • Anonymous
    November 18, 2008
    I'm sure you all debated around the right terminology is, but I just have to disagree that "Click" is the right thing for UI buttons. I don't Click on-screen buttons. I press them. Buttons are pressed, despite whether some piece of plastic actually goes in or not. I think most users don't understand what clicking means without a mouse.

  • Anonymous
    November 18, 2008
    Also, why would "Choose" cause localization issues? FWIW, the iPhone uses "Choose" in some places, and I think they don't have issues with localization. Also, I think another guideline is that often times if your UI is done right, you don't even need to explain to the user to press/click/choose/select an item. For example, when selecting wallpaper on an iPhone, it's obvious that you should press the thumbnail of the wallpaper you want to use. The best UI shouldn't try to think for the user. The best UI should think like the user.

  • Anonymous
    November 18, 2008
    Grant: If OK is visible on the screen (i.e. on a softkey or a button), use "Click". Also, some devices may not have a hardware OK button, so "Click" seems to be the safer choice. -Mel

  • Anonymous
    November 18, 2008
    I tend to agree with Kevin. "Click" is terminology we reserve for desktop applications using a mouse. "Press" seems more natural and encompassing. I'll also point out that we've used "Tap" in our PocketPC applications as well (to describe stylus interaction).

  • Anonymous
    November 19, 2008
    Are you sure Click is used? if you check a WM 6 device and tap Help > Start Using your device > Write a note You will see...

  1. Tap New. Actually in all Help text, Tap is used instead of Click, there is no Click term at all in Help. So the correct terminology is 'tap' NOT click. No wonder WM is in limbo, the WM team is even contradicting themselves with such trivial terminology as to whether to use Press, Click, Select when it is none of the aforementioned but tap instead.
  • Anonymous
    November 19, 2008
    I philosophically agree as well.  The word "Click" actually broke the "button" paradigm and arose because of mice and in small part the sound effect that became common with buttons in UIs. However, the point of this is to trigger subliminal responses in the user so that they know what to do when reading the word and MelSam's proposal follows that.  The mobile phone users of this generation were brought up using PCs that do have you "click" buttons and "press" keys.  So users probably do associated "click" with the screen and "press" with a physical keyboard. (What you do with the letter A on a virtual keyboard, I have no idea.) When tablets and touch PCs and PDA phones are the norm and how people are introduced to computers, perhaps "press" and "tap" will become a better choice (if it isn't already). "Hit" is right out...

  • Anonymous
    November 20, 2008
    WM: Funny.  I wonder how that same message appears on Smartphones that are not touch-screen sensitive?  Clearly, one cannot "tap" on such a phone.  Therefore is "select" used in that application?

  • Anonymous
    November 20, 2008
    According to the old Pocket PC 2003 User Interface Guidelines the correct terminology is "Tap" and the term "Click" is explicitly listed as incorrect. This is found in the Pocket PC 2003 SDK help file under "Pocket PC User Interface Guidelines" > "UI Guidelines" > "UI Text" > "Instructional Text". Unfortunately this part of the documentation is not available online on msdn, it only exists as a help file.

  • Anonymous
    January 09, 2009
    I always thought "click" referred to pressing down a button with a pointing device, like a mouse. I agree that a stylus is a pointing device but if you're not using a stylus but navigating with the 5-way (which you can also use in touch-screen devices) the word "click" doesn't sound quite right. In this case, I would think that "select" is a better word to use. IMHO, it also helps using "select" because it applies to both touch-screen and non-touch-screen devices which means that we use a single set of strings for both.

  • Anonymous
    July 27, 2009
    The Windows Mobile blog has moved. Comments on this blog will be disabled soon. Let's continue these discussions on the new site. http://windowsteamblog.com/blogs/windowsphone/default.aspx http://developer.windowsmobile.com Thanks!