3 SCREEN LAYOUT

Whichever UI configuration is used, the basic screen layout is the same. The screen is divided into four areas. One area, the status bar area, is used by the system and is therefore not available for application developers. The other three areas are used by the application. Two of these areas, the title area and the soft-key label area, are controlled by the system but are used for the active application. The fourth area, the application space, covers most of the screen and is controlled by the application.

These four areas have the same function independent of the UI configuration. However, to simplify use of the phone, the areas are placed in different positions on the screen.

The screen is divided into a number of areas. Each area occupies the full width of the screen.

Screen area Softkey style Pen style Status bar Contains important system indicators, for example, new message and battery level. Contains a short-cut to the Application launcher (Pen style). The short-cut is changed to a link to the start screen when the Application launcher is displayed. The content of the status bar is determined by the mobile phone manufacturer. Placed at the top of the screen for Softkey style. Placed at the bottom of the screen for Pen style. Status bar in softkey style Status bar in pen style Title bar and View context area The Title bar displays the name and icon of the current application. It also contains a View context area. Tapping on the label opens the menu in Pen style. The width of the menu is adjusted after the longest label. An icon can be displayed on the right-hand side of the Title bar to access the category menu in Pen style. See section 9.1 for details regarding categories The View context area can contain controls, for example icons, text labels and tabs. If there is enough space to the right of the tabs, other application specific data or controls can be added. An application may choose to hide the Title bar. Title bar with View context area in softkey style Title bar with View context area in pen style Application space Displays an application's views and data. A toolbar can be placed in the application space in Pen style. The toolbar is an application-specific control containing frequently used options. Controls are laid out by using building blocks; see section 3.4. Application space in softkey style Application space in pen style

Displayed at the bottom of the screen. Two softkeys with labels: Left softkey (LS), Right softkey (RS) and an Action key with a softkey label (Center softkey). A menu that is launched from a softkey always uses the full width of the screen. When the right softkey contains a menu the label "More" is displayed. The label is changed to "Close" while a menu is opened. See section 10.1 for commonly used labels. Softkey labels

A Back button is displayed in non-editable views. The Back button has an icon that indicates the action of the button. In editable views, Save and Cancel buttons are displayed instead of the Back button. The button bar can contain three text buttons. The minimum size of each text button is 1/3 of the width minus the margins. If three buttons are displayed in the button bar, each label should not contain more then approximately seven characters. More buttons can fit into the button bar if they contain icons instead of text. In general, the most important application command is placed as a button. Buttons are left justified. The Save or Back button is the left-most button. Cancel (if present) is normally immediately to its right. Buttons are never hidden. When temporarily unavailable, buttons are dimmed. For example, in Messaging, SMS edit view, as long as there is no address in the “To” field, the “Send” button is dimmed. The button becomes active as soon as data is entered in that field. Screen commands that are displayed on buttons are normally duplicated in the application menu, for example, the New command. If the Action key acts on a button in the dialog, this is indicated by a prominent border around the button. Button bar

Pen style UI supports a landscape screen layout.

In Landscape mode, the Title area is displayed in the top left corner of the screen. The width of the title areas is maintained. The Status bar is displayed to the right of the Title area; the width is reduced to 80 pixels and three rows instead of one are used to display indicators. The Button bar is displayed at the bottom of the screen.

A View-dialog behaves and looks just as a standard view in landscape mode. For CEik and Simple dialogs:

• A dialog that is launched in landscape mode uses the full screen width.

• The height is adjusted automatically according to the content of the dialog. The dialog does not cover the status bar.

• The application space and the application title area are dimmed and unavailable when a dialog is opened.

It is possible for an application to remove screen areas. Full screen is achieved when all screen areas except the application space have been removed.

Applications that have support for full screen should have a menu command called "Full screen" located at the bottom of the menu and separated from the other commands with a divider.

In Pen style, a short-cut button with a "switch to full screen" icon (icon.framework.fullscreen) can be placed in the button bar if space is available. The application can also, when appropriate, provide a full screen short-cut when the user taps the application space. For example, an image application could switch to full screen when the user taps on an image when not in full screen and switch back again on a subsequent tap.

The application can add a user setting where the user can select whether a specific view is to be displayed in full screen or not.

Applications displayed in full screen should not use tabs, even if the application makes use of tabs otherwise.

When there are no active controls to receive application commands on a touch screen enabled mobile phone, the Full-screen floating menu is displayed. The user can access all available commands via this control. This control is, by default, displayed in the top right corner of the application space. The control floats on top of the application space and is not affected when the view scrolls. The control is rotated in landscape mode and accordingly displayed on the top right corner from a landscape perspective. The control can be dragged anywhere within the application space to prevent it from covering relevant information.

This control cannot be displayed when the application uses direct screen access, for example, if a camera view finder is displayed in full screen.

At a minimum, a command to return from full screen should be added to the control. The control should then display the icon (icon.framework.normalscreen.overlay) indicating that full screen will be terminated when the control is act upon.

If an application has more commands available in full screen, the Full-screen floating menu control launches a pop-out menu. This menu can contain all the commands or a subset of the commands that are available for the application when full screen is not used. It is up to the application to remove commands that are not desired in full screen. The menu should have a marked menu command called "Full screen" located at the bottom of the menu. A different icon (icon.framework.menu.overlay) is used on the Full-screen floating menu control when it opens a menu.

A command to launch the virtual keyboard is added by the framework above the "Full screen" command when required. When the virtual keyboard is closed, full screen is still displayed.

An application can enlarge the application space by removing screen areas even in Softkey style. However, the softkey bar should normally be left on the screen in Softkey style. Otherwise, the guidelines for Pen style are valid for Softkey style.

The Cancel hardware key takes the user back in the navigation hierarchy regardless if full screen is used or not, that is, full screen is not a state in the navigation model. When the view is entered again, the view should normally not be displayed in full screen, unless a setting has been made to display the view in full screen.

If the user leaves an application via the application launcher, the view state will be kept. This means that if a view is displayed in full screen when the user navigates away via the application launcher or via a DNL, the view is displayed in full screen when the user returns to the application.

Dialogs are not displayed in full screen. A dialog that is displayed over a full-screen view, in landscape mode, is displayed the same as a dialog in landscape mode without full screen.

Building blocks are used to lay out the controls in a view. Each building block has a number of slots where controls can be inserted and a view can consist of multiple building blocks. The row height of building blocks is adjusted after the font size and the available application space.

A view that looks like the one below contains six building blocks:

View layout using building blocks Outline of the building blocks that are used

Applications can, and should, use a common set of system building blocks. UIQ provides such a default set of building blocks that can be used by any application. Each building block has a defined layout and handles the placement of the controls to achieve the right margins and alignment.

The building blocks can be mixed and will work irrespective of which building blocks that are used together. But to achieve a clean and consistent layout the following guidelines should be used.

• Choose a building block that displays as much information as you think is necessary. For example, in the Contacts application a TwolineBuildingblock is used to display phone numbers and email addresses, because it is important that the user can see all of the information.

• The text in a view is normally aligned vertically on the left-hand side. In the example below, the building block IconCaptionedOnelineBuildingBlock is used to achieve alignment. Also, the Name control, which does not have an icon, makes use of the same building block with the first slot left empty.

  

  Example of using a building block to achieve alignment

• Avoid mixing building blocks with different heights in a view in order to achieve good scroll behavior. If you use building blocks with different heights, try to group them together as much as possible. If the building block is able to receive focus, the highlight covers the whole building block. When more building blocks than fit on the screen are added, the view becomes scrollable and building blocks with different heights will cause the highlight height to increase and decrease.

• The MediumThumbnailDoubleOnelineBuildingBlock and the LargeThumbnailThreelineBuildingBlock are normally placed at the top of the screen where they are never given focus.

  

  Example mixing building blocks to achieve a header

OnelineBuildingBlock IconCaptionedOnelineBuildingBlock TwolineBuildingBlock IconCaptionedTwolineBuildingBlock ManylinesBuildingBlock OnelineIconBuildingBlock HalflineHalflineBuildingBlock TwolineIconBuildingBlock CaptionedHalflineBuildingBlock IconOnelineIconBuildingBlock CaptionedOnelineBuildingBlock IconTwolineIconBuildingBlock CaptionedTwolineBuildingBlock IconIconOnelineBuildingBlock IconOnelineBuildingBlock MediumThumbnailDoubleOnelineBuildingBlock IconTwolineBuildingBlock LargeThumbnailThreelineBuildingBlock