11 COMMON APPLICATION FEATURES

This section contains an overview and description of functionality typically available in applications.

Find searches through all the items stored in an application. This section describes how you implement find for applications that support it.

You make a Find command available in the application menu, in list and/or detail view.

Find searches through the text in items. If the user specifies the string "foo", a search is executed for all instances of "foo" anywhere in a word. The search is not case sensitive. So "foo" will match "Foo", "afOO", "food" and "petfood".

If you are writing a UI for an application engine that does not support Find directly, you should support Find as best you can.

Normally, find searches items in all folders, not just the currently selected folder.

The standard Find dialog contains a single text-edit control with two options, Find and Cancel. In Softkey style Find is displayed on the Action key and Cancel is assigned to the Cancel hardware key.

Find should be the default button. When the user activates the Action key or the user taps the Find button with the stylus, the find session should start.

If the user taps the Find button or uses the Action key without entering a search string, an Infoprint, “Enter search string”, is displayed.

Cancel closes the Find dialog.

The find string is persisted and highlighted as in shown in the image above. It is then available for a new search. This is only valid if the phone has not been turned off.

The text editor is limited to 30 characters. If the user tries to enter additional characters an Infoprint with the text “Maximum characters reached” is displayed. The search string within the text editor should be displayed with the regular font style.

If the user switches to another application when the dialog is opened, the dialog is closed and no search is performed.

If necessary, you can provide your application with a custom Find dialog, which the user can use to specify special criteria, for example, in Messaging, to search a particular email account. Do not make things complicated. Keep such dialogs down to a minimum of options.

Normally, Find should be application wide, that is, it searches all data managed by the application. This model works best, for example, for Contacts or Agenda. In some applications, for example Messaging, Find may be more complicated.

If the size of each message is potentially large enough, you may want to allow the user to restrict Find to the current message.

Categories are potentially much more significant, so you may wish to allow the user to restrict Find to the current category. In this and similar examples, you can add Find-where options in the More menu (the dialog menu in Pen style) to the standard Find dialog.

For example, the "Find where" options might include "This folder" and "All folders".

Do not add Find where or other features to your Find dialog unless you need to. Any feature you provide can be used incorrectly by accident. For example, the user could search the wrong folder. Cutting down the scope of the search will often not speed it up or decrease the number of hits. Keep it simple. The Find-where option, if present, is not persisted. When a Find dialog is launched, the Find-where option should always be initialized to the most generous setting.

When the user selects the Find option in the Find dialog, the application should create a Found dialog to display the results.

The Found dialog should be created before the Find dialog is dismissed, so as to minimize screen flicker.

The title should be in the form Found "foo", that is, Found followed by the text of the find string in quotes. If the string length is greater than 10 characters, it is truncated with an ellipsis (a single character code point 0x2026 in Unicode, not 3 period characters) so the title would read: Found "0123456789..."

The found items within the dialog are displayed using regular font style and are truncated if necessary.

The Found dialog should make use of the full height, even if no items were found.

If the number of found items exceeds the vertical space available in the result list, add a scroll bar.

The result list should display the items found in as clear a manner as possible.

• Do not emphasize the find string. Emphasize instead the title of the object. So, if the user is searching for “sue” and it is found in the notes field of a "Team Lunch" meeting, then display "Team Lunch" in the list, not the notes text.

• Add whatever is needed to clarify the result, for example, a date column for meetings, as well as a title.

The resulting information is not persisted for the next find.

If nothing is found, the result dialog should display the title "Nothing found" after the "Searching... " phase has completed.

The Action key is named "View" and opens the highlighted item in detail view, and the dialog is closed. If there are no items in the list, the Action key should be named "Done" and the dialog is closed when the user press the Action key. This is to prevent the softkey bar from being empty and to provide the user with an easy way to close the dialog. In Pen style the user can also tap on an item with the pen to open the detail view for that item.

There should also be a Cancel option assigned to the Cancel hardware key in Softkey style. Pen style has a single Cancel button.

Make the dialog fully responsive during the search.

If the search may take a long time, add items to the result list as they are found rather than waiting for the entire search to be complete.

Allow the user to cancel the dialog during the search.

Allow the user to select a found item during the search. This causes the item to be opened in detail view and closes the dialog.

Set the dialog title to "Searching..." during the search, to emphasize that the Find is still being processed. Change the title to Found "name of search string" when the search has completed.

UIQ has support for several different text input methods. Different input methods are used depending on the UI style. In Softkey style, the numeric keyboard is used to input text. Different text-input software can be used to facilitate text input via the numeric keyboard.

In Pen style, the main method for text input is handwriting recognition. Handwriting recognition requires that pen gestures are interpreted as letters, numbers or other characters, and sent to the application as text.

UIQ also supports a virtual keyboard, a pop-up keyboard on the screen. If text input is active, you can toggle between conventional recognition and the virtual keyboard by tapping a control on the status bar.

Text input can also be achieved via an internal or external keyboard.

Text input is only active when needed, that is, when the focus is on a text control or a stand-in control that holds a text control within an application view or dialog.

Normally, the text cursor is placed at the end of any existing text in a field, so that any characters that are entered will not delete the existing text. In the case of a find dialog, however, the text cursor selects the entire text of the field, so that the text can easily be replaced by entering characters. Otherwise, the text can easily be re-used for a new search.

All text-input methods are associated with the active application. If, for example, handwriting recognition is used in the active application, and the user switches to another application where handwriting recognition is not used, the handwriting recognition apparatus will disappear.

Undo is available to protect the user’s data.

The granularity of undo is important. Most user tasks are expected to be short in UIQ so the granularity of the undo is usually all the data contained in an item, that is, an item in a list view, or the entire item being worked on, in a detail view. For example, it is usually better to undo all changes to a view instead of undoing single text field edits. Deleting a large item such as a meeting shall also be possible to undo.

Applications support only a single level of undo. If the application supports deletions of multiple items, use a confirmation dialog.

• In a detail view, you would mostly use Undo changes, for example, Undo delete.

• In a list view, you might occasionally use Undo delete. An item that is brought back via the undo command gains focus in the list view.

• When there is nothing to undo, the Undo menu command is dimmed in Pen style and removed in Softkey style.

• If it is not possible to undo a destructive action, use a confirmation dialog. For confirmations, Query dialogs are used.

The plain text and rich text editors have an undo functionality that can undo actions like cut or paste within the control.

• Three zooming levels are defined: small, medium and large.

• Zooming affects the font size.

• Most views with text, including list views, should be able to zoom.

• The zoom setting is persisted per application and per view, even after reboot.

• The Application title bar, the View context area, the Menu bar, the Button bar, the Status bar and dialogs cannot zoom.

• Bitmaps and entire row configurations can be zoomed by implementing such support in the specific application.