Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Make your BlackBerry application more user-friendly

by BlackBerry Development Advisor on ‎02-16-2010 10:08 AM (4,752 Views)

Summary


This article applies to the following:

  • BlackBerry® wireless devices based on Java™
  • BlackBerry Java Development Environment (JDE)


Description


User Interaction


While the BlackBerry device keyboard is user-friendly, it is good practice to minimize the amount of typing and scrolling required by the user. Requiring a lot of user input and interaction breaks up the overall flow of the program and makes it more difficult to use. The following are ways to decrease the amount of user interaction:

  • Use radio buttons or option fields when there are a limited number of choices available to the user; it is easier for a user to scroll and select an option then it is to type.
  • Prepopulate fields when there is an expected input (for example, prepopulate the user's name on a request form, but still provide the ability to change it if required).
  • Make frequently used data persistent. Save the user's name and email address if it is required each time the program is run, and only require the user to type them the first time.
  • Pay attention to the order in which menu items appear. Place the most frequently used menu items at the top of the menu and use standard menu item positions in all programs (for example, most users expect the Close menu item to appear at the bottom of the menu).
  • Limit the use of key combinations. Although ALT key combinations can be useful in your application, they should always have menu alternatives for those who do not know the shortcut keys or do not want to use them.
  • If your application requires data that does not all fit on one screen and you want to make the screen scrollable, turn on the scrollbars so that the user knows that there is more data.

Standardize Functionality


Learning a new application is simpler for a user when other applications on the device have a similar look and feel. Users expect certain functionalities in every application.


Standard keys

  • The ESCAPE key should always exit or return to the last screen, depending on what is more applicable.
  • Clicking the trackwheel should always cause a menu to appear, even if there is only one menu item.

Non-blocking programs

  • Any action that takes a lot of time should not block the program, that is, users should not have to wait for a time-consuming process to finish before they can perform another task. It is a good idea to create a thread for these types of events and to perform the necessary processing in the background. This is especially true when accessing data wirelessly.

UI Speed


Ideally, there should be no delay after a menu selection, or similar event, before the UI is changed to reflect the command. Occasionally, there is a significant amount of processing involved in creating a new screen. Here are a few tips on how to make the UI appear to be faster.

  • Perform lengthy processes at times when the user is more tolerant of delays.


    While most users do not tolerate even a one second delay after selecting a menu item or choosing from a list, they are more likely to tolerate the same delay at other points in the program. Pre-instantiate any screen objects that must be displayed quickly. Although this procedure is more memory-intensive, the UI appears to run much faster.

  • Paint as little as possible.

    If you add a small graphic object to the screen, there is no need to repaint the entire screen. Invalidate only the region of the screen in which the graphic appears. A XYRect can represent this. If a large amount of the screen has been changed, it is more efficient to repaint the entire screen than it is to repaint several smaller areas of it.

  • Do not create a new screen when only one field is being changed.

    The RIM UI is automatically double-buffered so that no flicker occurs when a field on a screen changes. Changing only one field also requires less repainting.

Note: Any filed handles repainting itself and only repaints what is required.

Contributors