Создание интерфейса приложения для Nokia Series 40

Series 40 Web Apps UX Guidelines

Key information on the interaction models and visual styles of Series 40 web app

Document created on 9 June 2011 Version 1.0

Series 40 Web Apps UX Guidelines 2

Table of contents 1. Introduction 4

1.1 Audience 4 2. Key UX considerations 5

2.1 Displays 5 2.1.1 Screen size 5 2.1.2 Selectable object size 6 2.1.3 Screen orientation 9

2.2 Navigation 10 2.2.1 Non-touch device behaviour 10 2.2.2 Location of basic navigation controls 11 2.2.3 Scrolling 11 2.2.4 Focus on discrete tasks 13 2.2.5 Consistent interactions 14

2.3 Text and graphics 15 2.3.1 Consistent use of text 15 2.3.2 Align elements 16 2.3.3 Clear visual hierarchy 16 2.3.4 Richer visual elements 17 2.3.5 Use a common set of icons 18

2.4 Device consistency 19 2.5 Common application flow models 20

2.5.1 The models 20 2.5.2 Examples 22

3. Touch gestures 38 3.1 Tap gesture 39 3.2 Swipe 40

4. UI graphic elements 41 4.1 Lists 41 4.2 Tabs 42 4.3 Text fields 43 4.4 Buttons 44

5. Styles and specs 45 5.1 Top header bar and navigation icons 45 5.2 Buttons 47

5.2.1 Primary and secondary buttons 47 5.2.2 Tertiary icons- buttons 48

5.3 Form elements 49 5.3.1 General elements 49 5.3.2 Input fields 49

6. Specs for standard components 51 6.1 Header and sub-header components 51 6.2 List items 53 6.3 Content 56 6.4 Tabs 56


Change history 9 June 2011 1.0 Initial document release


1. Introduction This guide provides developers and designers with the key information required to create Series 40 web apps that are consistent in look and feel as well as functional behaviour. This is achieved by describing the common Series 40 device characteristics and features of Series 40 web apps.

1.1 Audience The primary audience for this guide is experienced web developers and designers who are capable of creating

good quality applications from scratch, but are not yet doing so commercially, as shown in Figure 1. By

following these guidelines, adopting the interaction patterns described in the examples, and using the assets

defined in Chapter 4, ‘UI graphic elements’, developers and designers will be able to create commercial quality

web apps that offer an outstanding UX on Series 40 devices.

Figure 1: This guide’s target audience is shown.


2. Key UX considerations This chapter introduces the key factors that need to be considered when developing Series 40 web apps:

Displays — the resolution and physical size of screens on Series 40 devices and their effect on UX.

Navigation — use of clear and consistent navigation to support the user in understanding the features

and functions of the web app. Also, considering whether the user has a keyboard or touch screen with

which to interact with the application.

Text and graphics — use of sophisticated graphics to build the users trust and confidence in the web app.

Also consistency in the use of text and graphics and the layout of these elements to ensure UI components

are easy to identify and thereby easy to use.

Device consistency — ensuring web app behaviour is consistent with the device behaviour, to offer the

users a familiar and consistent UX.

2.1 Displays This chapter discusses the characteristics of the displays on Series 40 devices and how they affect UX.

2.1.1 Screen size Series 40 devices that support web apps, whether they support keyboard only or

Touch and Type UIs, offer screens with a resolution of 240 x 320-pixels. Typically

the physical size of the screen, as shown in Figure 2, is 39.2 x 52.2 mm. Compared

to the size of screen offered by a typical smartphone, this is small. Web app designs

need to account for the screen size in two ways, by ensuring that the content is

easy to see and read, and that controls are sized so they are easy to select —

particularly on Touch and Type devices.

Figure 2: Typical physical Series 40 screen size is shown.


2.1.2 Selectable object size Care has to be taken in creating selectable objects for Series 40 devices offering the Touch and Type UI. An

object’s optimal size is influenced by the nature of the object, specifically whether it’s a:

discrete touchable area.

part of a collection of touchable areas occupying all or part of the screen.

button.

Note: These recommendations apply to the current Touch and Type devices, which offer a 240 x 320-pixel screen of 2.4” in size. Series 40 web apps should be developed to allow for the release of devices with alternative screen resolutions and sizes.

2.1.2.1 Discrete touchable areas

The recommendations for object sizes when using fingers and thumbs are listed in Table 1.

Dimension 2.4” QVGA screen

Diagonal 2.4”

Height 320 pixels

Width 240 pixels

Finger activated object size, equivalent to 6.1 mm 40 pixels

Vertical finger activated object gap, equivalent to 1mm 7 pixels

Horizontal finger activated object gap, equivalent to 1.23 mm 16 pixels

Thumb activated object size, equivalent to 8 mm 52 pixels

Vertical thumb activated object gap, equivalent to 1.25 mm 8 pixels

Horizontal thumb activated object gap, equivalent to 3 mm 20 pixels

Table 1: Recommended object and gap sizes are listed.


2.1.2.2 Collection of touchable areas

When dealing with a collection of touchable areas think of the screen as a 6 x 8 grid of touchable slots, as shown

in Figure 3, with each element being 40 x 40-pixels in size.

Figure 3: The dimensions of touchable elements within a 6 x 8 grid are shown.


2.1.2.3 Buttons

The recommended dimensions of buttons on a 2.4” QVGA screen are listed in Table 2.

Dimension (pixels) Physical dimensions (mm)

Height Width Height Width

Standard button 40 40 6.1 6.1

Minimum size for rectangular button 48 30 7.0 5.0

Table 2: Physical and pixel sizes for standard and rectangular buttons are listed.


2.1.3 Screen orientation Screens on Series 40 devices are offered in portrait (240 x 320 pixels) and landscape (320 x 240 pixels)

orientations, as shown in Figure 4. The majority of Series 40 devices employ a screen in portrait orientation. Web

app designs need to accommodate these two orientations and ensure that full use of the available screen real

estate is made. Guidance on how to detect and set CSS files based on screen orientation are provided in the

Accommodating screen orientation chapter of the Series 40 Web Apps Best Practices Guide document.

Figure 4: A selection of Series 40 devices, with portrait and landscape screens, are shown.

http://www.forum.nokia.com/info/sw.nokia.com/id/d8319f16-ea03-4eec-9c4f-a899401a68c5/Series_40_Web_Apps_Best_Practices_Guide.html�


2.2 Navigation

2.2.1 Non-touch device behaviour The main difference between non-touch and Touch and Type devices is that non-touch phones have three

softkeys (a left, middle, and right key) and a navipad which the user uses to interact with the web app.

On non-touch devices permanent soft keys replace all actions that occur in the chrome of Touch and Type

devices, as shown in Figure 5.

A Touch and Type application view without the bottom category bar, showing the icon used to open the category bar on the bottom-right of the screen.

A Touch and Type application view with the bottom category bar and its ‘Options’ and ‘Back’ icons shown,

A non-touch application view showing the softkey bar. The user can invoke Options by pressing the left softkey and Back by pressing the right softkey.

Figure 5: The UI differences between touch and non-touch devices are shown.


2.2.2 Location of basic navigation controls To provide clear and consistent web app navigation it’s recommended that all basic navigation functions should

appear at the top of the application view, as shown in Figure 6.

The app logo should always be in the top bar. This logo should link to the web app’s home page.

Paging controls should be displayed directly below the app header.

The icon in the top right of the header can be contextual.

Figure 6: Various layouts for web app navigation are shown.

Note: If the app has no need for basic navigation functions, when the app consists of a single screen for example, the navigation options should be omitted from the header.


2.2.3 Scrolling When page content exceeds the size of the screen, its content can extend outside the screen, however it should

extend below the screen only. This is to ensure the pages in a web app are easy to read; as such scrolling should

be limited to vertical scrolling (up and down), as shown in Figure 7. This approach fits well with typical usage, as

most users are naturally familiar with reading below the page fold. Horizontal (left and right) scrolling should be

avoided, as this could make navigation within the app cumbersome and unfriendly.

Figure 7: The use of vertical scrolling only is shown.


2.2.4 Focus on discrete tasks Because of the small screen size on Series 40 devices, web apps screens are limited in the content that they can

display without requiring scrolling. It’s therefore recommended that each screen should focus on one task at a

time. In addition, the minimum number of interface elements required to complete the task should be used to

keep interactions simple.

Where a task is inherently complex, it should be divided over several screens. The key is to avoid clutter, so

consider using tabs and expandable lists to keep the UI clean and simple, as shown in Figure 8.

Screen 1: Start the task Screen 2: Choose a

category Screen 3: Choose a sub-category

Screen 4: Browse the results

Figure 8: Dividing a complex task into simple, single task steps is shown.


2.2.5 Consistent interactions Consistent interaction patterns make it easy for users to understand how to use your web app. For example,

style all buttons similarly by using common button size, text size, and text case, as shown in Figure 9. This will

enable users to distinguish buttons from icons or other interactive elements easily. You can use visual highlights,

such as colour, to emphasise different outcome types that can result from pressing a button.

Figure 9: Common styling of buttons, so they are easily recognised, is shown.


2.3 Text and graphics This section provides recommendations for the use and layout of text and graphics.

2.3.1 Consistent use of text When using text it’s desirable to keep the font size, case, and weight consistent for text with similar purposes,

for example, the same font size for all titles or all rows on a list. Recommended text size and effects are listed in

Table 3. Note that the Nokia font on Series 40 6th Edition and earlier devices, including Lite variants, provides for

sizing the font as small, medium, and large only.

Use Nokia font (Series 40 6th Edition and earlier)

Nokia font (Series 40 6th Edition, Feature Pack 1 and later)

Web app title Large Regular (20px) Large Regular (24px)

List item text Medium Regular (14px) Medium Regular (20px)

Label title Small Bold (10px) Small Bold (16px)

Other important text elements Small Regular (10px) Small Regular (16px)

Instructions or less important text elements Small Regular (10px) Small Regular (16px)

Table 3: Recommended font sizes and effects for various uses are listed.

Note: In Series 40 web apps version 1 the font available on the device, the Nokia font, is the only one available for use in web apps: Additional fonts cannot be downloaded. The font does, however, offer several point sizes and text effects such as bold and italic.


2.3.2 Align elements Element margins, sizes, and spacing should be aligned and consistent throughout a web app. For example,

margins on the left and right of a content area should be consistent, as shown in Figure 10,. Inconsistent

margins and spacing can create visual clutter, while consistent spacing is more visually appealing.

Figure 10: A clean look achieved by use of consistent font size and margins is shown.

2.3.3 Clear visual hierarchy When presenting lists that incorporate a hierarchy, such as products in a product category, use font sizes, colours

and graphic elements to make the information hierarchy clear, as shown in Figure 11. Where expandable lists

are used there should be a clear indicator to show how the list is expanded or contracted and the expanded

items should be distinguished with colours and indents.

Figure 11: A list, list with labels, category list, and category sub-list are shown.


2.3.4 Richer visual elements Because the screens on Series 40 devices are relatively small, images should be displayed using all of the

available space below the header and navigation bar, as shown in Figure 12.

Figure 12: An image using the entire screen is shown.


2.3.5 Use a common set of icons Use of consistent icons will assist your user in understanding the features available or information being

presented in your web app. Therefore, the icons you use should be common in design and size. In addition, one

icon should be used to convey the same concept, for example, use the same icon to indicate refresh on all

screens, as shown in Figure 13.

Figure 13: The use of a common refresh function icon is shown.

It’s recommended that you use the icons defined in Chapter 5, ‘Styles and specs’.


2.4 Device consistency Series 40 web apps should be designed to align closely with the Series 40 platform UI style, for more

information on the Series 40 UI style see the Series 40 UI style guides. A key item to be aware of is the

placement of labels on button pairs that offer choices. As shown in Figure 14, in all Nokia devices these buttons

offer:

Positive commands on the left or middle softkeys (commands such as select, yes, save, and alike).

Negative commands on the right softkey (commands such as back, no, cancel, and alike).

Figure 14: The assignment of positive action to the left button and negative action to the right button in standard Series 40 and Symbian dialogues is shown.

http://www.forum.nokia.com/info/sw.nokia.com/id/73e935fe-8b59-43b2-ab3e-1c5f763672db/Series_40_UI_Style_Guide.html�


2.5 Common application flow models This chapter presents details on a number of application flow models that can be employed in your Series 40

web apps. After presenting each of the models, examples of their use are provided also. It’s worth noting that

these models can be combined together where appropriate.

2.5.1 The models The suggested models for application flow are provided in Table 4.

Table 4: The suggested application flow models are listed.

Model # Description Schematic

Tree structure 1

A hierarchical structure is ideal for presenting content that is categorised. Typical examples of this type of content include guidebooks product catalogues, and alike. Examples: Travel Guide, News

Expandable list 2

A special version of the tree, where elements in a list can be expanded to show more detailed information. This model can be used for any list information such as news, locations and alike. Note: Any important interaction should not be expandable. Examples: Social, Stock Tracker


Model # Description Schematic

Dynamic looping 3

A looping pair of screens that consist of a form for the display of information and a user input screen that enables the entry of parameters that control the content of the form. Examples: Tic Tac Toe, Translate

Tabbed pages 4

Where two or three categories need to be presented for the user to swap between regularly, a tabbed page should be used. This model can be used for social networks (to show messages, contacts, and profile), product information (to show basic information, specifications, and reviews) and alike. Examples: Social

Carousel 5

Where content consists of items of equal importance or relevance the carousel model can be used. Typical examples of the content that can be presented in a carousel include photo albums, news items, and alike. Examples: Photos, Travel Guide


2.5.2 Examples This chapter describes a number of example web apps that illustrate the practical use of the application

flow models.

2.5.2.1 Photos

This example, shown in Figure 15, illustrates a photo gallery for content from an online picture service.

01 Main 01 Main and search 02 Search results list 03 Content (image) 04 Content (image)

Figure 15: The screens of the Photos example are shown.

The example enables a user to view pictures that match an entered search term and is described in detail in

Table 5. This example implements the tree structure (#1) and carousel (#5) models.

Table 5: A description of the Photos example is provided.

Screen layout Model node Description

The application opens displaying a default photo. The user clicks the search icon to open the search dialogue.



The Search box slides in from the right and the user can enter a search term. Clicking the search icon performs the search.

A list of images matching the search criteria are displayed, the user can now:

Scroll through the image grid.

Select an image to open in the carousel.

Perform a new search.

The image selected from the grid is displayed. The user can now:

Navigate the photos.

Return to the list by clicking the grid icon.

Perform a new search.

By swiping or clicking the navigation controls (or using the navipad on a non-touch device) the user can move to the next photo.


2.5.2.2 Travel Guide

This example, shown in Figure 16 illustrates a travel guide web app.

01 Main 01 Main and search 02 Search results list 03 Content, location 04 Content, location

Figure 16: The screens of the Travel Guide example are shown.

This example enables a user to select a type of travel destination and view descriptions and photos of places

retrieved from an online travel information service. The example’s behaviour is described in detail in Table 6.

This example implements the tree structure (#1) and carousel (#5) models.

Table 6: A description of the Travel Guide example is provided.


The application opens displaying a list of search categories; the user clicks a category, such as Travel inspiration.

A grid view is displayed offering a selection of travel sub-categories. The user clicks a sub-category, such as Beaches.



A list displays offering geographical areas, the user clicks a geographical area, such as Anywhere.

The first search result displays. The user can now swipe or click the navigation arrows (or use the navipad on a non-touch device) to select the next or previous destination.

The next destination is displayed.


2.5.2.3 News

This example, Figure 17, illustrates a news web app that provides a list of news items.

01 List view

02 Content (story)

03 Content (last story)

Figure 17: The screens of the News example are shown.

In this example, the user selects a news item from a list and can then navigate through the news items without

having to return to the list. This example is described in detail in Table 7. It implements the tree structure (#1)

and carousel (#5) models.

Table 7: A description of the News example is provided.


The app opens displaying a list of the latest news. The subheading bar shows the time of the last update. The list can be refreshed by clicking the refresh icon shown in the top right of the screen. Individual news items are opened by clicking them in the list.



In a detailed news item, the subtitle bar is replaced by a navigation bar, with which the next and previous detailed news items can be opened. Clicking the back button returns the user to the news item list. By clicking Read full story, the new services website page for the news item opens in Ovi Browser to display the full news article.

The user can use the navigation bar, swipe on a touch screen device or use the navipad on a non-touch device to display earlier or later news items. When the user gets to the beginning or end (as shown here) of the list of items the navigation arrows should be updated to exclude the invalid navigation option.


2.5.2.4 Social

This example, shown in Figure 18, illustrates a social networking application

01 List of feed items 02 Expanded feed item 03 List content in the profile tab

Figure 18: The screens of the Social example are shown.


This example provides tabs for access to three key social networking features — message feed, friends list, and

the user’s profile. The lists then offer the option to expand items in place to view more details, as described in

detail in Table 8. This example illustrates also how web apps behave when the web app needs to make use of a

Series 40 platform component, in this case for text entry. This example implements the tabbed pages (#4) and

expandable list (#2) models.

Table 8: A description of the Social example is provided.


The app opens to display a list of the most recent messages for the user’s social network. The user can update the list any time by clicking the refresh icon in the upper right of the screen. A message can be sent by typing in the status text box and clicking UPDATE to send the message. Details of the user’s friends and their personal profile can be opened by clicking FRIENDS and PROFILE.

By clicking in the status field, the user activates the text-field. This opens the standard platform component for text entry.



The user can expand an item in the messages list by clicking it. The expanded item shows more details from the messages, such as the full message text and associated picture.



By clicking the PROFILE tab the user can view their personal profile and a list of their updated posts.


2.5.2.5 Stock Tracker

This example, shown in Figure 19, illustrates a web app designed to provide stock price and sales information.

01 List view of stock feeds 02 Expanded list view

Figure 19: The screens of the Stock Tracker example are shown.


The application enables a user to select a stock of interest from a list and displays details of the stock’s current

prices and a graph of historic prices, as described in detail in Table 9. This example implements the expandable

list (#2) model.


The application opens showing a summary of stock prices, and the day’s change for symbols the user has added. The user adds symbols by clicking Add symbols. Price changes are highlighted in green for gains and red for losses. Details for any stock can be viewed by clicking the stock item. The information can be updated at any time by clicking the refresh icon in the top right of the screen.

When a stock item is clicked the list item snaps to the top of the list view, to provide maximum screen space for the expanded list information making it easy for the user to focus on their task. On expanding the list item, the user is displayed more detailed information on the stock’s trading. The individual stock’s information can be updated by clicking Refresh quote or the symbol can be removed from the list by clicking Remove this. The entire list can be updated at any time by clicking the refresh icon in the top right of the screen.

Table 9: A description of the Stock Tracker example is provided.


2.5.2.6 Tic Tac Toe

This example, shown in Figure 20, illustrates the implementation of a tic tac toe or noughts and crosses game.

01 Form view

02 User input

Figure 20: The modes of the Tic Tac Toe example’s screen are shown.


In this example, the screen loops between no game and game playing states, as described in detail in Table 10.

This example implements the dynamic looping (#3) model. Also note that, because the app consists of two

looping pages only the standard navigation icons and controls have been omitted from the header.


The application opens displaying the last score and a blank playing field. Play stats are provided in the sub-header bar, which identifies the user’s character also. A game can be started straight away. A new game is started by clicking PLAY AGAIN while clicking ? opens help information.

When the user clicks on an empty square in the playing grid, the clicked square is filled with the user’s character and the application responds by filling a vacant square with its character. This continues until the game is completed. When the game is complete the user can elect to play another game by clicking PLAY AGAIN.

Table 10: A description of the Tic Tac Toe example is provided.


2.5.2.7 Translate

This example, shown in Figure 21, illustrates an application that uses an online service to translate a text string.

01 Form view 02 List view 03 User input

Figure 21: The screens of the Translate example are shown.

The application enables the user to select languages by clicking the ‘from’ and ‘to’ buttons and selecting

languages from a list and the entering text before clicking TRANSLATE to obtain a translation, as described in

detail in Table 11. This example implements the dynamic looping (#3) model.

Table 11: A description of the Translate example is provided.


The application opens showing two buttons to indicate the language the source text is in and the language it will be translated into. Below is a text field for the text to be translated and two buttons, TRANSLATE to request translation and RESET to clear the source text.



Clicking either of the ‘language’ buttons opens a list of the available languages. Clicking a language on the lists selects it and updates the button name on the main screen. Clicking the ‘back’ icon, in the top right corner of the screen, returns to the main screen without the language being updated.

After entering text and clicking TRANSLATE the sub-heading displays the type of language translation and the translated text displays below the text field. The user can edit the text and perform another translation if they wish. Clicking the ‘back’ icon at the top right of the screen or the RESET button returns to the main screen.


3. Touch gestures Series 40 web apps support two touch gestures, as listed in Table 12.

Symbol Stroke Touch event combination Description Non-touch equivalent

Tap Touch and release

Users touch the screen to trigger actions by ‘tapping’ (clicking) a control or link.

Softkey and navipad select button

Swipe Touch, move, and release

Users place a finger on the screen and move it in the desired direction. The finger is released once the subsequent piece of content has snapped into position.

Navipad direction controls

Table 12: The touch gestures supported by Series 40 web apps are listed.


3.1 Tap gesture The tap gesture enables a user to touch the screen and trigger actions by tapping interactive content — such as

buttons, controls, or links — as shown in Figure 22.

Figure 22: Examples of tap gestures and their outcomes are shown.


3.2 Swipe The swipe gesture enables a user to touch the screen and trigger a transition to items that are in subsequent

screens, as shown in Figure 23.

Figure 23: Examples of swipe gestures and their outcomes are shown.


4. UI graphic elements This chapter provides visual examples of the UI graphic elements available to Series 40 web apps.

4.1 Lists Figure 24 to Figure 32 show examples of the list formats available in Series 40 web apps.

Figure 24: A plain list is shown. Figure 25: A list with icons is shown Figure 26: A list with labelled titles is shown.

Figure 27: A list with labelled titles and icons is shown.

Figure 28: A list inside table is shown.

Figure 29: A list inside a table with icons is shown.


Figure 30: An expandable list is shown.

Figure 31: Expanded categories with links in a list-view is shown.

Figure 32: Expanded categories with icons and links in a list-view is shown.

4.2 Tabs Figure 33 to Figure 38 show examples of the tab formats available in Series 40 web apps.

Note: Tabbed screen should contain two or three tabs only.

Figure 33: A full width tab group is shown.

Figure 34: A full width tab set with icon is shown.

Figure 35: A full width tab set with text-fields is shown.


Figure 36: A tab in a table is shown. Figure 37: A tab in table with icons is shown.

Figure 38: A tab in table with text-fields is shown.

4.3 Text fields Figure 39 to Figure 41 show examples of the text entry options available in Series 40 web apps.

Figure 39: A text field used with a button is shown.

Figure 40: Text fields used with icons and buttons are shown.

Figure 41: Text fields used as part of a form field with labels is shown.


4.4 Buttons Figure 42 to Figure 46 show examples of button formats available in the UI graphics toolkit for Series 40 web

apps.

Figure 42: Various buttons are shown.

Figure 43: Individual radio buttons (for exclusive choices) are shown

Figure 44: Individual check boxes (for multiple choice) are shown.

Figure 45: Grouped radio buttons (for exclusive choices) are shown.

Figure 46: Grouped check boxes (for multiple choices) are shown.


5. Styles and specs This chapter presents a recommended iconography for use in Series 40 web apps.

5.1 Top header bar and navigation icons This chapter lists, in Table 13, the header and navigation icons recommended for use in Series 40 web apps.

Table 13: The header and navigation buttons are show.

Button Size Name Meaning

40 x 40 pixels Search Shows search results

40 x 40 pixels Refresh Refreshes contents

40 x 40 pixels Back Goes back to the previous screen

40 x 40 pixels Grid view Opens images in a grid-view

40 x 40 pixels Close Closes the content

79 x 24 pixels Previous item Navigates to previous item in a

slide show

79 x 24 pixels Pause item Pauses a slide show

79 x 24 pixels Next item Navigates to next item in

slideshow


79 x 24 pixels Play item Plays item in slideshow

120 x 24 pixels Previous item Navigates to previous item in

content

120 x 24 pixels Next item Navigates to next item in

content

18 x 113 pixels Next image-item Navigates to next image-item

18 x 113 Previous image-item

Navigates to previous image-

item

Many of the recommended icons can be used in combination, as shown in Figure 47.

Figure 47: Examples of the combined use of the navigation items are shown.


5.2 Buttons

5.2.1 Primary and secondary buttons Table 14 defines the recommended button sizes for use in Series 40 web apps. Remember that the text on a

button should accurately describe the function that clicking the button caused to be performed.

Button Size Name

125 x 35 pixels Large single

102 x 35 Mid-size

66 x 35 Small size

81 x 35 Button size 4

140 x 35 Dual buttons SQ

Table 14: The primary and secondary buttons are show.


5.2.2 Tertiary icons- buttons Table 15 defines the recommended tertiary button graphics and sizes for use in Series 40 web apps. Remember

that the graphic on a tertiary button should visually describe the function that clicking the button caused to be

performed.


12 x 12 pixels ADD - inside content

16 x 16 pixels Close - inside content Closes content in context, for example, loading a URL field

16 x 16 pixels Down arrow Collapses list items

16 x 16 pixels Right arrow Expands list items

32 x 32 pixels Swap Replaces one with the other

32 x 32 pixels Download Transfers to a custom

location

32 x 32 pixels Tips Opens a pop-up that

provides an explanation

32 x 32 pixels Favourites Allows users to add the item

as a favourite

32 x 32 pixels Re-tweet Re-sends posts

Table 15: The tertiary buttons are listed.

When buttons are used in a combination where the label is not a verb (action) but a noun, it is recommended

that the button labels are formatted in sentence case, as shown in Figure 48.

Figure 48: Example of the combined use of buttons is shown.


5.3 Form elements

5.3.1 General elements Table 16 defines the general elements and their sizes available to Series 40 web apps. These elements should be

presented centre-aligned to row height.


21 x 21 Radio button selected Exclusive selection

21 x 21 Radio button active Active exclusive

selection

21 x 21 Radio button inactive Inactive exclusive

selection

21 x 21 Check-box selected Multiple choice selection

21 x 21 Check-box active Multiple choice selected

21 x 21 Check-box inactive Multiple choice non-

selected

Table 16: The general elements are shown.

5.3.2 Input fields Table 16 defines the available input fields and their sizes for use in Series 40 web apps.

Table 17: The input fields are listed.

Input field Size Name Usage notes

210 x 40 Form input

field

Used to enter form text. Actual size of input field is 161 x 28-pixels. To be used preferably with a label.

240 x 40 Full-width

input field

Used to enter text upon which an action is to be performed. Actual size of input field is 185 x 28-pixels. To be used preferably with a label.


Input field Size Name Usage notes

210 x 40 Form multi-

input 3 part

Used to enter form data such as dates. Actual size of each input field is 60 x 28-pixels. To be used preferably with a label.

210 x 40 Form multi-

input 2 part

Used to enter form data, such as short dates (MM/ YYYY). Actual size of each input field is 94 x 28-pixels. To be used preferably with a label.

210 x 86 Description input field

Used to enter multi-line text, such as descriptions. Actual size of each input field is 94 x 28-pixels. To be used preferably with a label.


6. Specs for standard components This section provides detailed size specification for the recommended standard components for use in Series 40

web app.

Note: In all cases the vertical and horizontal space around all elements is 8 pixels.

6.1 Header and sub-header components This section provides detailed specifications for the elements displayed in the web app header, these items are:

Standards header module, shown in Figure 49.

Header module with input field, shown in Figure 50.

Sub-header with a subtitle, shown in Figure 51.

Sub header module for a slideshow, shown in Figure 52.

Sub header module for previous-next navigation, shown in Figure 53.

Figure 49: The standard header module is shown.


Figure 50: Header module with input field is shown.

Figure 51: Sub header module for a subtitle is shown.

Figure 52: Sub header module for a slideshow is shown.

Figure 53: Sub header module offering previous-next is shown.


6.2 List items This section provides detailed specifications for items displayed in a list, these items are:

single line list item, shown in Figure 54.

single line list item with icon, shown in Figure 55.

list item in a table, shown in Figure 56.

list item in table with icon, shown in Figure 57.

double line list item, shown in Figure 58.

double line list item with icon, shown in Figure 59.

expandable list item, shown in Figure 60.

list item with image and text, shown in Figure 61.

list item without image and text, shown in Figure 62.

Figure 54: A single line list item is shown.

Figure 55: A single line list item with icon is shown.


Figure 56: Specification for a list item in a table is shown.

Figure 57: The specification for a list item in table with icon is shown.

Figure 58: Specification for a double line list item is shown.

Figure 59: Specification for a double line list item with icon is shown.


Figure 60: Specification for an expandable list item is shown.

Figure 61: A list item with image and text is shown.

Figure 62: A list item without image and text is shown.


6.3 Content This section provides detailed specifications for content with headline, date, and body text, shown in Figure 63.

Figure 63: Content with headline, date, and body text is shown.

6.4 Tabs This section provides detailed specifications for content with headline, date, and body text, shown in Figure 64.

Figure 64: The specification for tabs is shown.


Copyright © 2011 Nokia Corporation. All rights reserved.

Nokia and Forum Nokia are trademarks or registered trademarks of Nokia Corporation. Oracle and Java are

registered trademarks of Oracle and/or its affiliates. Other product and company names mentioned herein may

be trademarks or trade names of their respective owners.

Disclaimer

The information in this document is provided ‘as is’, with no warranties whatsoever, including any warranty of

merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,

specification, or sample. This document is provided for informational purposes only.

Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to

implementation of information presented in this document. Nokia Corporation does not warrant or represent

that such use will not infringe such rights.

Nokia Corporation retains the right to make changes to this document at any time, without notice.

Licence

A licence is hereby granted to download and print a copy of this document for personal use only. No other

licence to any other intellectual property rights is granted herein.

Design

Создание интерфейса приложения для Nokia Series 40