This is a new browser window. When finished viewing, just close this window.

User-Interface Review:
Telelink Software and iComm Cellular Phone

Prepared for WiredWorld, Inc. by UI Wizards, Inc.
Author: Jeff Johnson,
UI Wizards, Inc.
Creation Date: 17 July 1996

This document shows a typical user-interface review. The yellow boxes are annotations (not included in actual review reports) that explain the report's various sections. For your convenience, listed below are the annotated sections of this report.

Annotated Sections of this Report:

Executive Summary

We usually provide an Executive Summary for the benefit of busy managers who don't have time to read the entire document. [Back to Top]

This document summarizes the result of a user-interface review (also referred to as an "audit") that was performed of the TeleLink software and the corresponding phone and information services.

Overall, the software, phone, and services seem usable, but there is definitely room for improvement. Critical comments and recommended improvements are provided for many different aspects of the user interface and functionality. A more coherent set of design recommendations would require a longer evaluation period, some discussion and iteration with development engineers. Usability testing could also expose further problems and suggest solutions.

Conditions Of This Evaluation And Disclaimers

Usability reviews are often performed under a limited budget and schedule. This limits the feedback we can provide about the usability and usefulness of the software. We therefore usually explain in our reports the limitations of our findings and recommendations. [Back to Top]

WiredWorld engaged my services to evaluate the user interface (UI) of its TeleLink software and, to a lesser extent, the cellular phone that uses the software. A ICOMM prototype cellular phone was loaned to me for the period of this evaluation, intentionally without any user-documentation. Two system-reference documents were also provided to me (the TeleLink Developer's Guide and the HDML Reference manual), but I did not see a need to refer to them to perform this user-interface evaluation. I spent two and a half using the phone and software and writing this report. During that period, I taught myself how to use the phone without referring to documentation, and used the phone as much as I could. All the while, I took notes to keep track of what I'd tried and not tried, and what problems I'd seen.

I made special note of aspects of the user interface that proved difficult to learn or seemed overly tedious. The reason for this is that users are adaptable and can learn many things, but some designs seem to defy learning: users keep making the same mistakes over and over, despite prolonged experience. Looking for this sort of trouble spot was an important focus of my evaluation.

There are certainly some areas of the phone's functionality I have missed. A fully comprehensive evaluation would require more than two and a half days. However, I do feel confident that I have managed to try out the bulk of what the phone can do. I have made phone calls, edited and added phone directory items, checked stock quotes and sports news, read and sent email, faxed messages to my home fax, set bookmarks, searched for info by topic, and tried the movie and airline demos.

In using the device for these few days, I believe I have found many areas where its user interface could be improved. In this report, I describe those areas and also make recommendations regarding how to correct the usability problems. Careful readers of this report will notice, however, that some of my recommendations are tentative, contingent (on other design decisions), and even contradictory. Without much more time and without significant design discussions and iteration with the engineers who will implement the recommendations, it is impossible to develop a comprehensive and coherent redesign of the UI for the device and its services.

Overall Impressions

This section of the report describes our overall impressions of the product. [Back to Top]

Overall, I think this phone, coupled with the right services, could a very useful tool for a business professional such as myself. I think that its user interface is reasonably good, especially given the strong constraints under which it was designed and implemented (e.g., small number of keys, small amount of resident memory, small display, the fact that some of the software in the phone was developed by companies other than TLink).

As is to be expected in a product prototype, there are rough edges. Discovering and understanding how to smooth them out is the reason for this UI evaluation. The big areas I think need improvement, because users will spend so much time in them, are: 1) navigation in the information space, and 2) typing text. I will summarize each of these briefly before presenting detailed comments below.

Navigation: The intended users' conceptual model of a Web-browser doesn't seem to be particularly strong or compelling. In using the phone and services, I was reminded more of a traditional menu-hierarchies with some "interactive screens" than of a web-browser. My recommendation here is to consider how much difference it makes whether users think of this as a web-browser or as a traditional menu-hierarchy. If the web-browser model is important (e.g., because it suggests certain behavior or functions that you want users to assume are provided), then you need to do something to strengthen it. In addition to the lack of a strong web-browser model, I noticed some difficulty in determining, at any point, what key would take me where. OK, PREV/BACK, P/HOME, HELP, and END all take me to places other than I am, and I found it difficult to consistently go where I wanted to go. In particular, PREV/BACK seemed unpredictable. I also missed having a Cancel function distinct from PREV/BACK.

Typing Text: Overall, the text typing method is clever. While using it (mainly to type email messages), I started out very slow, but got faster with practice. However, there were a few things that didn't get easier with practice, i.e., I kept stumbling over them again and again. I found that I had great difficulty getting used to having to wait for the cursor to move to the next character slot when two successive characters I wanted to type were on the same key (e.g., double letters). I found that I had difficulty inserting spaces into the middle of text, since the key moves right rather than typing a space when pressed in the middle of text. I found it difficult (in some cases impossible) to figure out how to type certain important characters (e.g., underscore) that are not shown on the keys. All of these things need to be improved to make typing acceptably smooth.

In the remainder of this report, I provide detailed comments and recommendations. The areas covered are: physical device, software general, menu structure and navigation, menu-item labeling, text typing, phone directory, email, stock service. Areas of the user interface not mentioned in this report are areas of it that I either missed or in which I found no area-specific problems.

Physical Device

This product included both a physical device (the phone) and software. Here, we review the phone. [Back to Top]
  1. The Power button takes about 1 second to respond when the user wants to turn the unit on. That seems too long. Users will assume they didn't get it fully pressed and so will press it several times.
    Recommendation: If the power-on sequence can't be speeded up, something should be done to provide immediate feedback that the keypress was successful. E.g., when power is turned ON, immediately either emit a beep or turn on the display light.
  2. Turning the phone on requires a quick press on the Power button, and turning it off requires a sustained press. This is good because it shouldn't be too easy to turn it off. However, users may have trouble figuring out how to turn it off at first. It may not occur to them to hold the button down.
    Recommendation: Leave as-is, but be aware that this may be a problem for some users (and may result in customer-support calls and complaints).
  3. The lack of descenders in characters makes the display look cheap and invites confusion between certain characters. On this ICOMM phone's display, characters are 7 pixels high with 1 pixel between lines. Other devices I've seen (e.g., the HP 95LX) use the same character height and line-spacing as this phone (i.e., 8 pixels per line, including spacing), but achieve better looking displays by using a clever trick: characters with descenders have their bases one pixel higher than other characters, and the descender extends into the 1-pixel inter-line space. Because most text contains relatively few characters with descenders, lines don't look run together. This looks good enough that I did not notice until now that characters with descenders are one pixel higher than other characters and actually intrude into the interline space, despite having used this palmtop for several years.
    Recommendation: Using the same trick in this phone would eliminate the "cheap" look of the current display and also improve its legibility.
  4. When I first turn the phone on, the screen is backlit and is easy to read, but this only lasts a couple of seconds before the backlighting goes off and it gets much dimmer. I have trouble seeing it in a dimly-lit room. This is true even with a newly charged battery.
    Recommendation: Leave the backlighting on unless power is low or unless the user turns it OFF, as many laptop computers do. Alternately, if backlighting consumes power too quickly, why have it at all? You could simply not have it, as in the HP palmtops.
  5. When the battery gets low, the phone simply shuts off. The user could be in the middle of an important call or composing a long email message.
    Recommendation: Some sort of auxiliary battery should be provided to bridge such situations and to allow users to change the main battery without loss of data, e.g., a small watch battery. The HP palmtop has this, and it works well.
  6. The prototype ICOMM phone has an awkward shape for making phone calls. When I hold it against my head, my cheek is pressed against the upper keys and display screen. I am worried that I might press some keys by accident. Also, if a user has oily skin, these parts of the phone would get gunky over time.
    Recommendation: The display and keypad should be recessed, i.e., the ear-speaker and mouthpiece should stick out.
  7. Apparently, the phone must be powered ON and in PHONE-mode to receive calls. The requirement that the phone be ON is unfortunate but understandable, but the requirement that it be in PHONE mode seems intolerable since users will (hopefully) be spending a fair amount of time interacting with NET services (e.g., reading and typing email messages is very time-consuming). Users won't want to be prevented from receiving phone calls when they are using NET services.
    Recommendation: Change the power-OFF mode so that it is really just a low-power (sleep) mode that can still receive calls. Also, when a call is received while the user is in NET-mode, provide a way for the user to suspend NET mode, switch to phone mode, take the call, and then return to NET mode where s/he was. Eventually, the phone may contain enough memory that various modes can remain in RAM once they have been started, and just go to sleep when other apps are invoked, as in the HP 95/100/200 LX palmtop series.
  8. Bitmap of lower-case h seems not to match other characters: the "hump" seems one pixel too short.
    Recommendation: Make "hump" on 'h' 1-pixel taller.
  9. Bitmap for cursor should be different from bitmap for underscore. On the HP 95LX, the cursor is two pixels thick and blinks, while underscore is one-pixel thick and of course doesn't blink.
    Recommendation: Do it the HP way.

Software General

In this section, we discuss usability problems that aren't local to any specific part of the software, but rather pervade its entire user interface. [Back to Top]
  1. The audio feedback for power ON and OFF is clear and cute (although too delayed, as described above). I assume there must be an easy way to adjust the volume of this and other audio feedback, since I'd expect that some users might sometimes be in situations where they wouldn't want the phone to make much noise. But if such a volume control is provided, I haven't yet come across it.
    Recommendation: Provide a control for audio feedback volume. It should be independent of the telephone audio volume control.
  2. Startup is not interruptable. If I turn it on and want to turn it off immediately, I have to wait until the startup sequence finishes. Any software function that takes more than two seconds should be interruptable.
    Recommendation: Allow users to abort the startup sequence, to turn the phone OFF.
  3. Poor feedback when battery runs out. Once, when I was in the middle of typing a reply to an email message, the phone turned off without warning and with no feedback other than the screen going blank. Apparently my laboriously-typed message was lost. When I tried to turned the phone back on, then it informed me that the battery was nearly expired and turned itself off again.
    Recommendation: Warn the user when power is about to go out. As described above, a back-up battery would help prevent loss of data.
  4. Unclear labeling on some keys. The key labeled 'P' is completely mysterious. (I now understand that it will be labeled "HOME".) CLR is clearly "clear" but it seems to do different things in different places (so the problem on this key is more the function in the software than the label). The red END key looks ominous, but is used mainly in PHONE mode; all it does in NET mode is exit back to PHONE mode. The SEND key would seem to apply to sending all sorts of things, e.g., e-mail messages, but all it does is start phone calls.
    Recommendation: Provide clearer labeling and more consistency. Also, don't assume that certain keys are for PHONE-mode only or for NET-mode only. Instead, consider keys to be object-oriented messages that can have sensible meanings in multiple contexts. You don't have many keys, so don't waste them!
  5. The battery indicator glyph is good: I knew immediately what it was. The "B" and martini glass with a barchart next to it on the left of the top of the display are less clear: I had no idea what they are for (signal strength indicator) until it was explained to me, and now that I know, I still don't find it very useful.
    Recommendation: Change the indicator to look more like the "Sending )))))))" feedback so users will associate the two. E.g., good signal: "(((i)))", med signal: "((i))", low signal: "(i)", no signal: "i", where 'i' should actually be a graphic that looks like the top of the phone's antenna.
  6. Pressing the NET soft function key gives no audio feedback.
    Recommendation: It should beep, as all other keys do.
  7. When I switch from PHONE functions to NET functions, it just switches. In contrast, when I switch from NET functions to PHONE functions, it always says "Exiting...". This is a software-centric view that exposes the fact that the PHONE side is dominant and "always running" and the NET side is subordinate software that has to be run and terminated. This model is unnecessary: users should be able to think of just switching back and forth without having to be aware of concepts like "this software is running now" or "this software is exiting now".
    Recommendation: Look at the HP 95LX (or 100 or 200 LX); it allows switching between apps, and doesn't require users to think in terms of invoking, exiting, etc. Even though the phone currently has insufficient RAM to allow multiple programs to be simultaneously resident and simply go to sleep when they are not in use, it should be possible to change the presentation so that users can think of the PHONE and NET as peer-level modes that they can switch back and forth between.
  8. The term "Send" has several different conflicting meanings on this phone. In some contexts (e.g., the SEND key) it means initiate a phone call. In other contexts, it means send an email message. In still other cases (which unfortunately are common) it just means "Busy transmitting stuff you don't care about in order to communicate with the host". As an example of the last meaning, I wanted to type a new message. I selected Create Message. It prompted me for an address. I typed the address and pressed OK. It said "Sending))))))". I thought, "Why is it sending the message? I haven't given it a subject or text yet." I figured out that this is just its way of saying it is requesting the next stage in the message composition process. I then entered the subject and message body, and pressed OK. It said "Sending)))))))" again, but this time it meant it was sending my message. The word Sending should refer only to transmission of user-created info (e.g., email messages) not to transmission of information as part of the device's normal communications protocols.
    Recommendation: The term "SEND" should mean only one thing: "send user-generated info", and other terms should be used for other situations. Change the status message "Sending" to something else, e.g., "busy" or "working". Granted these terms don't distinguish between whether the phone is attempting to send data to the host or vice versa, but that level of detail is a geeky-engineer thing -- like front-panel lights on computers -- that most users won't care about. All users care about is that the phone is busy communicating with the host, and they will want to know when it is sending their data vs. simply engaging in its own internal communication protocols.
  9. The P (Home) key doesn't always return the display to the home page. If I am viewing a HELP screen, pressing P just gets me out of the HELP page back to where I was.
    Recommendation: The Home key should always return to the home "page".

Comments on Specific Aspects of UI

In the remainder of this report, we comment on specific functional areas of the software: Menus & Navigation, Menu Labels, Typing Text, Phone Directory, E-Mail, and Stock Service. [Back to Top]

Menu Structure & Navigation

  1. As I gained experience with the phone, I found that I made one particular navigation error more often (rather than less, which is what one would expect from experience): I now often press the middle soft function key when I intended to press OK. Somehow, my finger tends to rest there when I am using the NET functions of the phone, and I seem to press it reflexively when I want to say OK, without even looking at the key legend.
    Recommendation: Check with other test users and, if this is a common experience, consider moving OK to the middle key slot.
  2. OK gets me out of error screens (which act like dialog boxes), but it doesn't get me out of other places. In error screens, going forward and going back are the same thing.
    Recommendation: This is just one symptom of a larger problem having to do with navigation, so see next two items.
  3. PREV/BACK sometimes functions as "go out" and sometimes as "go back to where I was before", which is confusing. If I go down the menu hierarchy to a function that then presents several successive screens (e.g., compose an email message), when I press PREV/BACK, it takes me back from the "write text of message" screen to the "destination address" screen. On the other hand, when I mark a bookmark, when I've done it and indicated OK in the last screen of that sequence and returned to the place where I marked the bookmark, PREV/BACK takes me out a level, not back to the last screen of the bookmark sequence.
    Recommendation: Consider providing both "go out" and "go back". One possibility is to make "go back to a previous screen in the current interaction" be one of the soft function keys, and have PREV/BACK mean "go out". Another possibility is to have PREV/BACK mean "go back" and provide another way to get out.
  4. At most points in the NET menu hierarchy, the soft function keys are a mixture of explicitly navigation functions (e.g., OK, MARK) and non-navigation functions (e.g., FAX).
    Recommendation: Try not to mix navigation functions and other functions. I'd suggest having a fixed set of physical keys for OK, CANCEL, BACK (which are very commonly used), and use the soft function keys for context specific functions.
  5. The NET menu structure seems to have an extra level of hierarchy in which two different levels have the same "name": first there is the TeleLink "home" page, then, under Directory, there is the TeleLink menu item. This may cause users to get disoriented.
    Recommendation: Either rename item 1 under Directory to something else (e.g., Services), or flatten out the hierarchy by simply expanding that item into the items it contains (requiring users to scroll down to see "Demos" and "Find".
  6. Why is it possible to scroll up to menu headers, e.g., to TeleLink on the "home" page? Users can't select them.
    Recommendation: Scrolling up to the header shouldn't be possible.
  7. If I'm sitting in a menu with the cursor on a particular item, and I press Mark, it's unclear whether I am marking the current menu or indicated item as a bookmark.
  8. Unclear why Mark bookmark prompts "Edit name", and why so many of the bookmarks are named "directory". Why would I want to change the name of the bookmark?
  9. Seems strange that it needs to communicate with the gateway to mark bookmarks.
  10. I don't see why Mark is available for e-mail messages. They are usually very temporary, so why would users want to set bookmarks pointing to them?

Menu-Item Labeling

  1. Email is referred to as "Email" on the soft key legend, but as TLinkmail in the TeleLink menu. Why is it available in two ways? Why is it not called the same thing?
    Recommendation: Call it "Email" in both places, or perhaps "TLink Email" if you want your "brand" on it.
  2. References to WiredWorld appear in several places. These reference often use abbreviations, and the abbreviations vary: "TLink", "TeleLink". Also, sometimes abbreviations are used even though there is room to spell it out. "TeleLink" is a poor abbreviation in my opinion.
    Recommendation: Spell out "WiredWorld" wherever possible, e.g., the home page and item 1 of the Directory. If you must abbreviate, use "TLink" (which is in your company logo) instead of "TeleLink".
  3. One level of menu (TeleLink Directory menu) has ".." on the ends of items, but no other levels of the menu do.
    Recommendation: Either use ".." consistently for non-terminal menu items, or don't use it at all.
  4. Under the TeleLink services menu, the label "Packages" is unclear. I didn't realize until told that it pertained to postal package mailing services. I initially thought it had to do with software packages for this phone. "Packages" is a very overloaded term.
    Recommendation: Use a less overloaded term for this category, e.g., "Express Mail", "Express Mail Status", or "Postal Mail".

Text Typing

Overall, the text typing method is clever. I especially like the fact that it is somewhat smart about caps vs. lower case and about what about letter it expects me to want in the middle of a word (the latter only in the first version of the software I used). But it does have some drawbacks and bugs. I list them first, then, at the end of the section, I provide recommendations.

  1. I had trouble discovering how to backup to correct mistyped characters. Discovered by trial and error that CLR key functions as BACKSPACE-DELETE when at end of line and as DELETE in. Also, seems to work as BACKSPACE-DELETE in some contexts and as MOVE LEFT in others. This needs to be more consistent.
  2. I had trouble figuring out how to type a SPACE. Discovered by trial and error that it was on the # key in the version of the software I was first given. In the updated software, SPACE characters can be typed using the key, which is more sensible than having it on the # key. However, putting it on the key creates a different problem: It isn't possible to insert a SPACE into existing text, because the key moves the cursor to the right when there are characters to the right of the cursor. Users familiar with Windows and/or Macs will expect to be able to move the cursor to a point and insert text in front of it. They will be confused or annoyed by the way this works.
  3. It is easy to forget that the key you press may initially produce a different letter than the one you were thinking of. This is especially true given that some voice-mail systems and telephone-based database-search applications allow users to type user-names, keywords, etc. without requiring multiple presses on a single key to spell a name (because they search the name/keyword list for a match with any of the possible characters on a key). Even though your phone software has to be more flexible than the voice-mail and database situation because what users type is more free-form, some users may find it annoying to have to remember to press a key multiple times.
  4. Typing two letters in a row that happen to be on the same key (especially double-letter sequences) requires a bothersome (and hard to remember) pause.
  5. The text editor shows a different cursor (^) for the beginning of a sentence (i.e., indicating that a capital letter will be typed) than for other characters in a sentence. This caret character looks like it is indicating that the next character will be inserted into the line above rather than the current line. I like the idea of a special cursor for capital letters, but I think caret is the wrong choice. By the way, I assume that the normal cursor looks different from an underscore character. On the HP 95 LX Palmtop, underscore is one pixel thick, and the cursor is two pixels thick and blinks.
  6. It is unclear how to type a capital letter in the middle of a sentence. Is it even possible? I don't expect users to type lengthy or complex messages using this phone, but it does seem important to allow users to: type capital letters in the middle of sentences, e.g., for names or acronyms
  7. I haven't yet figured out how to type certain special characters, e.g., underscore and hyphen. Such characters are uncommon, but they are needed because they might be part of an email address.
  8. The phone directory video-inverts characters while they are still changeable to the next character on that key, but many text-editing contexts on the NET side (e.g., the email text editor) don't do this. Text editing needs to be completely consistent across contexts, because people develop expectations based on habits.
  9. Bug: Pressing SPACE (#) too quickly after finishing a word fails to add the space, even though it beeps as if the character had been added.
  10. Bug: If a sentence ends in the second-to-last column of the screen, and I type a space after the sentence, the insertion cursor appears at the beginning of the next line, but the next character typed appears at the end of the previous line (and then moves automatically to the next line).
  11. Bug: Somehow I got it into a state where the same word was displayed both at the end of one line and at the beginning of the next line, with two type-in cursors showing. It turned out that the word and cursor on the next line were the spurious ones: when I typed more characters, that extra word just disappeared when the previous line wrapped.

Recommendations for text typing:

  1. Consider an alternate typing scheme in which number keys cycle automatically through their characters, and "set" the character when the user releases the key. The characters should change approximately every .5 second by default (a way could also be provided for users to change this rate). This would eliminate the problem of having different waiting periods between characters on different keys vs. the same key. Of course, such a radical change would require coordination with the phone makers to assure consistency of the text typing method across contexts. Such a change should also be usability tested to make sure it is better than the current method.
  2. Consider putting SPACE onto a different key than to avoid the problem of not being able to insert spaces in text. One possibility is to use a soft function key if one is available. Another possibility is to use the * key, since now there are only two other characters on that key.

Phone Directory

  1. In Find mode, OK is on the right function key instead of its usual place on the left key.
    Recommendation: OK should always be in the same softkey position.
  2. Searching for phone directory entries is case insensitive, as it should be. But it could also be smarter about what characters are intended, since it can compare against the directory list on each keystroke and thereby guess right on the first keystroke more often (as phone voice-mail systems do).
    Recommendation: Consider using the existing list of entries to expedite typing.
  3. The visual feedback for typing is different when adding or editing a directory entry than elsewhere, e.g., typing an email message. In the phone directory, the current character is video-inverted during the time-period when it can still be switched to the next character on that same key. This is good, but it is different than in the email text editor.
    Recommendation: Leave this as is, and change the email editor to provide the same feedback as in the phone directory function.
  4. It is unclear how to get out of phone directory mode. Function keys are ADD, EDIT, FIND. None of the other keys seem appropriate. I finally discovered that PREV exits directory mode, but this is unintuitive.
    Recommendation: Consider allowing users to use END to exit the phone directory back to the Phone Ready screen.

Email

  1. Reading messages: Having both the concepts of scrolling and the concept of MORE seems confusing. It forces users to be aware of the concept that a certain amount of text is loaded into some sort of buffer, and if they want to see more, they have to load the next buffer. But once they've done that, they can't get back to the previous buffer.
    Recommendation: Eliminate MORE, and have it fetch more as necessary as user scrolls back and forth.
  2. In some contexts (e.g. reading the text of a message), lines longer than the screen width are wrapped, and in other cases they aren't.
  3. Bug: When I scroll down a line in the mail reader, the phone beeps audibly, which is OK. If the email message contains an unbroken line of characters longer than the width of the screen, the e-mail reader wraps it into several lines, and when I scroll down a line, the beep is much longer in duration. Users will notice the difference and might assume that something is wrong.
  4. Sometimes I accidentally get into the "compose new email message" or the "reply to message" mode. The first few times this happened, it wasn't clear to me what to do to get out of it. It took me a while to learn that PREV is the only way out of this situation. In the meantime, before I learned this, I sent several null messages by pressing OK.
    Recommendation: Provide another way than PREV to cancel functions, including mail messages.
  5. I expected the SEND key to have some meaning in the email application. It seems to be only for initiating phone calls. A waste of a good key.
    Recommendation: Consider assigning SEND key a sensible function in the email context.
  6. Users can't forward or reply to an email message unless they are reading it. Most mailers (e.g., Eudora) allow users to simply place the cursor on a message and then reply to it. Several times, after reading a message, I backed out of it, then decided to reply to it. I pressed OPT softkey, expecting to find Reply there.
    Recommendation: Add Reply and Forward as options along with Create Msg, and have them use the position of the menu selector.
  7. Audio signal announcing new email sounds to me (and probably to many new users) like an incoming telephone call.
    Recommendation: Make the sound more different from a phone "ring".
  8. Unclear what the Fax All function on the email options menu does. Does it fax all of my messages? Those in the archive too?
  9. Unclear distinction between messages in my in-box and those in the archive. For many users of computer mail systems, the in-box is the archive.
  10. I find it disorienting that newly arrived email are put in slot 1 in the list, causing older messages to be bumped down the list. I didn't realize this at first (since no other mailer I've ever used does this), and was confused as to why messages changed position in the list. I think that the message number/position is one way users remember what they've got sitting in their in-basket, so if you mess with that you are removing one of their memory crutches.
    Recommendation: Add newly arrived messages to the end, but scroll the list down to show the bottom message when that page appears. You could do this unconditionally, i.e., always show the bottom messages or you could show the bottom of the list only when there are new (unseen) messages there.
  11. Archive seems somewhat out of place on the message menu.
    Recommendation: If you eliminate Mark for email messages (see Menu Structure and Navigation, above), that soft-key slot could be used to invoke the mail archive, and then could take archive off of the inbox list.

Stock Service

  1. Bug? Tried to get a stock quote for HWP (symbol for HP), waited for a while, then got "service not available". Then tried same thing for HP; got quotes. Tried HWP again, got "gateway not responding." Tried HP again, got quotes. Tried HWP, "gateway not responding." Tried HP, got quotes. A day later, I tried HWP again, and this time it worked. Not sure why it wasn't working previously.
  2. The Find function could be eliminated if you simply built it into the Quote function's "Symbol" prompt. You'd have to deal with cases of multiple matches, but that could just be a menu saying "Multiple matches; which one?"
    Recommendation: Consider eliminating stock FIND and merge its functionality into Quotes.
  3. In stock Quote function, I left the stock symbol blank and pressed OK (partly because I keep forgetting that OK != cancel, but that's a separate issue). It displayed "SENDING ))))))))))))))))))))))" and, after a long pause, "Please enter a stock symbol." It should have told me this earlier.
    Recommendation: Either OK should just get me out of it if I haven't typed a symbol, or it should notice the lack of a symbol locally, before trying to communicate with the service.