The Power of Prompts on GUIs

I came across the idea of "prompts" on GUIs when I asked this question on UXExchange.com. Two people answered that "Share This" buttons prompt readers to share.

I have never used a "Share This" button or anything of that sort. Whenever I find something interesting online, because of the highly ergonomic setup of my computer, I always had the impression that sharing content on the web would always be more convenient if I do it manually than through an automated process, which could even compromise my social networking accounts. I haven't tested this so I don't have the numbers, but it's logical that "Share This" buttons can prompt people to share information, whether they are going to use the sharing service or not.

Recently, I have notable "prompting experiences" on mobile operating systems. On the iPhone, because of the limited hardware buttons, opening menus are done through the GUI. I appreciated this when I started being an Android user. On Android; going back to the previous screen, opening menus, and searching are all done with the use of hardware buttons. How are you going to know if and how those buttons are going to work on a certain screen? You have to test. There's nothing to prompt you.

Prompting and the lack of it largely influence the world. They're the advertisements of activities.

My Blog's Ironic Shortcoming

I intended this blog to be a source of reliable information on human experiences with technology. The quality of my entries had always been my primary concern. I wanted to write entries that aren't far from journal articles. With that mindset; I tended to postpone posting because of the lack of time to write something lengthy, desire to share only big ideas, and reserve sharing great thoughts in more profitable venues. As expected, I rarely post and my few entries aren't as presentable as I want them to be.

This blog is relatively new and it probably doesn't have an audience that is committed enough to read lengthy posts about highly technical things. I'll keep in mind that I'm not blogging about pop stars so I'll have to make my posts as usable as possible for varied personas.

UX of Android OS Buttons

Typical Android devices have four buttons: "back ", "menu ", "home ", and "search ". I find them very useful on my Nexus One. They're too useful that they have to be much more accessible. On my hardware, they're just soft keys that seemingly lack calibration. I just found out on XDA that they should be touched on the upper part.

To those who aren't familiar, here is a table of what the buttons are for from Google's User's Guide

Button	Press	Press & hold
Back	Opens the previous screen you were working in. If the onscreen keyboard is open, closes the keyboard.
Menu	Opens a menu with items that affect the current screen or application.
Home	Opens the Home screen. If you're viewing the left or right extended Home screen, opens the central Home screen.	Opens the most recently used applications screen.
Search	In some applications, opens Quick Search Box for searching the phone and the web. In other applications, opens a search box for just that application. Press twice to open Quick Search Box from any application.	Opens Google search by voice.
Power (top left)	Turns off the screen.	Opens a menu with options for Airplane mode, for Silent mode, and for powering off the phone.
Volume Up / Down (left side)	When a call is in progress, increases or decreases the call volume. When the phone is ringing, silences the ringer. On the Home screen when no call is in progress, increases or decreases the ringtone volume, or sets the phone to be silent or to vibrate instead of ringing. In other applications, controls the volume of music, spoken directions, and other audio.	Quickly increases the ringtone volume to maximum or minimum.

This may sound good because those buttons don't have to be in the screen, unlike in the iPhone, which only has a "home" hardware button. Yes, this lessens the number of elements on the screen, but I see having those hardware buttons as a disadvantage.

On the iPhone, the back button, usually on the upper left, tells what the previous screen is. You'll know what you'll get when you go back. On Android phones, you have to remember what the previous screen is because nothing, other than your memory, will tell you. It is also inconsistent in some cases. If you open your browser from the home screen, clicking the "back " button will bring you to the previous webpage, if there is. If there isn't, you'll go back to the home screen. This way, you will have to guess what your back button will do.

The "menu " button is also confusing. Some apps don't have menus so pressing "menu " will not display a menu in some cases. I also love how menus are displayed on the iPhone. having a button on the screen that tells you there's a menu prompts you to see what the menu contains. On my Nexus One, some apps like Facebook preach the usage of the "menu " button. Their devs probably know that many people will likely miss features that they put on their app because of being hidden under the "menu " button.

I have no problem with how the "home " button works. I know that when I click it, I'll go back to my home screen.

The "search " button is confusing like the other two. On the home screen, it's given that "search " will open the "Quick Search Box" of Android. However, some apps have search functions so "search " will open the search box for the specific app. When there isn't a search function for the active app, clicking "search " will open the "Quick Search Box". How would you know if you're going to get the "Quick Search Box" when you click "search " while on an app? You test it.

In general, people have to guess if a button is going to work in a particular context the way they expect it to. The screen does not give any clue on how the buttons are going to work. The user has to rely on logic and memory. It is even harder for an app that the user is unfamiliar with. People will likely miss features of applications because they are impossible to find if the user didn't realize to press a button that isn't on the screen.

I suggest that Google and other parties come up with ways to show on the screen which buttons are useful in every context and give a clue on how they're going to work. Having those extra GUI elements means more use of the screen real estate, but those are too necessary to miss. They also have to make sure that those buttons are going to be easy to press, because of how often the user has to use them.