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

Series 40 Web Apps UX GuidelinesKey information on the interaction models and visual styles of Series 40 web app Document created on 9 June 2011 Version 1.0

Table of contents1. Introduction 4 1.1 Audience 42. 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 223. Touch gestures 38 3.1 Tap gesture 39 3.2 Swipe 404. UI graphic elements 41 4.1 Lists 41 4.2 Tabs 42 4.3 Text fields 43 4.4 Buttons 445. 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 496. 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 56Series 40 Web Apps UX Guidelines 2

Change history9 June 2011 1.0 Initial document releaseSeries 40 Web Apps UX Guidelines 3

1. IntroductionThis guide provides developers and designers with the key information required to createSeries 40 web apps that are consistent in look and feel as well as functional behaviour. This isachieved by describing the common Series 40 device characteristics and features of Series 40web apps.1.1 AudienceThe primary audience for this guide is experienced web developers and designers who are capable of creatinggood quality applications from scratch, but are not yet doing so commercially, as shown in Figure 1. Byfollowing these guidelines, adopting the interaction patterns described in the examples, and using the assetsdefined in Chapter 4, ‘UI graphic elements’, developers and designers will be able to create commercial qualityweb apps that offer an outstanding UX on Series 40 devices.Figure 1: This guide’s target audience is shown.Series 40 Web Apps UX Guidelines 4

2. Key UX considerationsThis 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 DisplaysThis chapter discusses the characteristics of the displays on Series 40 devices and how they affect UX.2.1.1 Screen sizeSeries 40 devices that support web apps, whether they support keyboard only orTouch and Type UIs, offer screens with a resolution of 240 x 320-pixels. Typicallythe physical size of the screen, as shown in Figure 2, is 39.2 x 52.2 mm. Comparedto the size of screen offered by a typical smartphone, this is small. Web app designsneed to account for the screen size in two ways, by ensuring that the content iseasy 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.Series 40 Web Apps UX Guidelines 5

2.1.2 Selectable object sizeCare has to be taken in creating selectable objects for Series 40 devices offering the Touch and Type UI. Anobject’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 areasThe recommendations for object sizes when using fingers and thumbs are listed in Table 1.Dimension 2.4” QVGA screenDiagonal 2.4”Height 320 pixelsWidth 240 pixelsFinger activated object size, equivalent to 6.1 mm 40 pixelsVertical finger activated object gap, equivalent to 1mm 7 pixelsHorizontal finger activated object gap, equivalent to 1.23 mm 16 pixelsThumb activated object size, equivalent to 8 mm 52 pixelsVertical thumb activated object gap, equivalent to 1.25 mm 8 pixelsHorizontal thumb activated object gap, equivalent to 3 mm 20 pixelsTable 1: Recommended object and gap sizes are listed.Series 40 Web Apps UX Guidelines 6

2.1.2.2 Collection of touchable areasWhen dealing with a collection of touchable areas think of the screen as a 6 x 8 grid of touchable slots, as shownin 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.Series 40 Web Apps UX Guidelines 7

2.1.2.3 ButtonsThe recommended dimensions of buttons on a 2.4” QVGA screen are listed in Table 2. Dimension (pixels) Physical dimensions (mm) Height Width Height WidthStandard button 40 40 6.1 6.1Minimum size for rectangular 48 30 7.0 5.0buttonTable 2: Physical and pixel sizes for standard and rectangular buttons are listed.Series 40 Web Apps UX Guidelines 8

2.1.3 Screen orientationScreens 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. Webapp designs need to accommodate these two orientations and ensure that full use of the available screen realestate is made. Guidance on how to detect and set CSS files based on screen orientation are provided in theAccommodating 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.Series 40 Web Apps UX Guidelines 9

2.2 Navigation2.2.1 Non-touch device behaviourThe main difference between non-touch and Touch and Type devices is that non-touch phones have threesoftkeys (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 Typedevices, as shown in Figure 5.A Touch and Type application view A Touch and Type application view A non-touch application viewwithout the bottom category bar, with the bottom category bar and showing the softkey bar. The usershowing the icon used to open its ‘Options’ and ‘Back’ icons shown, can invoke Options by pressing thethe category bar on the bottom- left softkey and Back by pressingright of the screen. the right softkey.Figure 5: The UI differences between touch and non-touch devices are shown.Series 40 Web Apps UX Guidelines 10

2.2.2 Location of basic navigation controlsTo provide clear and consistent web app navigation it’s recommended that all basic navigation functions shouldappear at the top of the application view, as shown in Figure 6.The app logo should always be in Paging controls should be The icon in the top right of thethe top bar. This logo should link to displayed directly below the app header can be contextual.the web app’s home page. header.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.Series 40 Web Apps UX Guidelines 11

2.2.3 ScrollingWhen page content exceeds the size of the screen, its content can extend outside the screen, however it shouldextend below the screen only. This is to ensure the pages in a web app are easy to read; as such scrolling shouldbe limited to vertical scrolling (up and down), as shown in Figure 7. This approach fits well with typical usage, asmost users are naturally familiar with reading below the page fold. Horizontal (left and right) scrolling should beavoided, as this could make navigation within the app cumbersome and unfriendly.Figure 7: The use of vertical scrolling only is shown.Series 40 Web Apps UX Guidelines 12

2.2.4 Focus on discrete tasksBecause of the small screen size on Series 40 devices, web apps screens are limited in the content that they candisplay without requiring scrolling. It’s therefore recommended that each screen should focus on one task at atime. In addition, the minimum number of interface elements required to complete the task should be used tokeep interactions simple.Where a task is inherently complex, it should be divided over several screens. The key is to avoid clutter, soconsider 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 Screen 3: Choose a sub- Screen 4: Browse the category category resultsFigure 8: Dividing a complex task into simple, single task steps is shown.Series 40 Web Apps UX Guidelines 13

2.2.5 Consistent interactionsConsistent 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 willenable 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.Series 40 Web Apps UX Guidelines 14

2.3 Text and graphicsThis section provides recommendations for the use and layout of text and graphics.2.3.1 Consistent use of textWhen 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 inTable 3. Note that the Nokia font on Series 40 6th Edition and earlier devices, including Lite variants, provides forsizing the font as small, medium, and large only. Nokia font Nokia fontUse (Series 40 6th Edition and earlier) (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 Small Regular (10px) Small Regular (16px)text elementsTable 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.Series 40 Web Apps UX Guidelines 15

2.3.2 Align elementsElement 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,. Inconsistentmargins 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 hierarchyWhen presenting lists that incorporate a hierarchy, such as products in a product category, use font sizes, coloursand graphic elements to make the information hierarchy clear, as shown in Figure 11. Where expandable listsare used there should be a clear indicator to show how the list is expanded or contracted and the expandeditems should be distinguished with colours and indents.Figure 11: A list, list with labels, category list, and category sub-list are shown.Series 40 Web Apps UX Guidelines 16

2.3.4 Richer visual elementsBecause the screens on Series 40 devices are relatively small, images should be displayed using all of theavailable space below the header and navigation bar, as shown in Figure 12.Figure 12: An image using the entire screen is shown.Series 40 Web Apps UX Guidelines 17

2.3.5 Use a common set of iconsUse of consistent icons will assist your user in understanding the features available or information beingpresented in your web app. Therefore, the icons you use should be common in design and size. In addition, oneicon should be used to convey the same concept, for example, use the same icon to indicate refresh on allscreens, 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’.Series 40 Web Apps UX Guidelines 18

2.4 Device consistencySeries 40 web apps should be designed to align closely with the Series 40 platform UI style, for moreinformation on the Series 40 UI style see the Series 40 UI style guides. A key item to be aware of is theplacement of labels on button pairs that offer choices. As shown in Figure 14, in all Nokia devices these buttonsoffer: 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 instandard Series 40 and Symbian dialogues is shown.Series 40 Web Apps UX Guidelines 19

2.5 Common application flow modelsThis chapter presents details on a number of application flow models that can be employed in your Series 40web apps. After presenting each of the models, examples of their use are provided also. It’s worth noting thatthese models can be combined together where appropriate.2.5.1 The modelsThe suggested models for application flow are provided in Table 4.Table 4: The suggested application flow models are listed.Model # Description Schematic A hierarchical structure is ideal for presenting content that is categorised. Typical examples of thisTree type of content include guidebooks 1structure product catalogues, and alike. Examples: Travel Guide, News 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 listExpandable information such as news, locations 2 and alike.list Note: Any important interaction should not be expandable. Examples: Social, Stock TrackerSeries 40 Web Apps UX Guidelines 20

Model # Description Schematic A looping pair of screens that consist of a form for the display of information and a user input screenDynamic that enables the entry of parameters 3looping that control the content of the form. Examples: Tic Tac Toe, Translate 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 socialTabbed networks (to show messages, 4 contacts, and profile), productpages information (to show basic information, specifications, and reviews) and alike. Examples: Social Where content consists of items of equal importance or relevance the carousel model can be used. Typical examples of the content that can beCarousel 5 presented in a carousel include photo albums, news items, and alike. Examples: Photos, Travel GuideSeries 40 Web Apps UX Guidelines 21

2.5.2 ExamplesThis chapter describes a number of example web apps that illustrate the practical use of the applicationflow models.2.5.2.1 PhotosThis 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 inTable 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.Series 40 Web Apps UX Guidelines 22

Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 23

2.5.2.2 Travel GuideThis 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, locationFigure 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 placesretrieved 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.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 24

Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 25

2.5.2.3 NewsThis 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 withouthaving 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.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 26

Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 27

2.5.2.4 SocialThis example, shown in Figure 18, illustrates a social networking application01 List of feed items 02 Expanded feed item 03 List content in the profile tabFigure 18: The screens of the Social example are shown.Series 40 Web Apps UX Guidelines 28

This example provides tabs for access to three key social networking features — message feed, friends list, andthe user’s profile. The lists then offer the option to expand items in place to view more details, as described indetail in Table 8. This example illustrates also how web apps behave when the web app needs to make use of aSeries 40 platform component, in this case for text entry. This example implements the tabbed pages (#4) andexpandable list (#2) models.Table 8: A description of the Social example is provided.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 29

Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 30

Screen layout Model node Description By clicking the PROFILE tab the user can view their personal profile and a list of their updated posts.Series 40 Web Apps UX Guidelines 31

2.5.2.5 Stock TrackerThis 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 viewFigure 19: The screens of the Stock Tracker example are shown.Series 40 Web Apps UX Guidelines 32

The application enables a user to select a stock of interest from a list and displays details of the stock’s currentprices and a graph of historic prices, as described in detail in Table 9. This example implements the expandablelist (#2) model.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 33

2.5.2.6 Tic Tac ToeThis example, shown in Figure 20, illustrates the implementation of a tic tac toe or noughts and crosses game.01 Form view 02 User inputFigure 20: The modes of the Tic Tac Toe example’s screen are shown.Series 40 Web Apps UX Guidelines 34

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 twolooping pages only the standard navigation icons and controls have been omitted from the header.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 35

2.5.2.7 TranslateThis 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 inputFigure 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 selectinglanguages from a list and the entering text before clicking TRANSLATE to obtain a translation, as described indetail in Table 11. This example implements the dynamic looping (#3) model.Table 11: A description of the Translate example is provided.Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 36

Screen layout Model node Description 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.Series 40 Web Apps UX Guidelines 37

3. Touch gesturesSeries 40 web apps support two touch gestures, as listed in Table 12. Touch eventSymbol Stroke Description Non-touch equivalent combination Users touch the screen to Touch and Softkey and navipad Tap trigger actions by ‘tapping’ release select button (clicking) a control or link. Users place a finger on the screen and move it in the Touch, move, and desired direction. The finger Navipad direction Swipe release is released once the controls subsequent piece of content has snapped into position.Table 12: The touch gestures supported by Series 40 web apps are listed.Series 40 Web Apps UX Guidelines 38

3.1 Tap gestureThe tap gesture enables a user to touch the screen and trigger actions by tapping interactive content — such asbuttons, controls, or links — as shown in Figure 22.Figure 22: Examples of tap gestures and their outcomes are shown.Series 40 Web Apps UX Guidelines 39

3.2 SwipeThe swipe gesture enables a user to touch the screen and trigger a transition to items that are in subsequentscreens, as shown in Figure 23.Figure 23: Examples of swipe gestures and their outcomes are shown.Series 40 Web Apps UX Guidelines 40

4. UI graphic elementsThis chapter provides visual examples of the UI graphic elements available to Series 40 web apps.4.1 ListsFigure 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 Figure 28: A list inside table Figure 29: A list inside a table withand icons is shown. is shown. icons is shown.Series 40 Web Apps UX Guidelines 41

Figure 30: An expandable list is Figure 31: Expanded categories Figure 32: Expanded categoriesshown. with links in a list-view is shown. with icons and links in a list-view is shown.4.2 TabsFigure 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 Figure 34: A full width tab set with Figure 35: A full width tab set withis shown. icon is shown. text-fields is shown.Series 40 Web Apps UX Guidelines 42

Figure 36: A tab in a table is shown. Figure 37: A tab in table with icons Figure 38: A tab in table with text- is shown. fields is shown.4.3 Text fieldsFigure 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 Figure 40: Text fields used with Figure 41: Text fields used as part ofbutton is shown. icons and buttons are shown. a form field with labels is shown.Series 40 Web Apps UX Guidelines 43

4.4 ButtonsFigure 42 to Figure 46 show examples of button formats available in the UI graphics toolkit for Series 40 webapps.Figure 42: Various buttons are Figure 43: Individual radio buttons Figure 44: Individual check boxesshown. (for exclusive choices) are shown (for multiple choice) are shown.Figure 45: Grouped radio buttons Figure 46: Grouped check boxes(for exclusive choices) are shown. (for multiple choices) are shown.Series 40 Web Apps UX Guidelines 44

5. Styles and specsThis chapter presents a recommended iconography for use in Series 40 web apps.5.1 Top header bar and navigation iconsThis 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 Navigates to previous item in a 79 x 24 pixels Previous item slide show 79 x 24 pixels Pause item Pauses a slide show Navigates to next item in 79 x 24 pixels Next item slideshowSeries 40 Web Apps UX Guidelines 45

79 x 24 pixels Play item Plays item in slideshow Navigates to previous item in 120 x 24 pixels Previous item content Navigates to next item in 120 x 24 pixels Next item content 18 x 113 pixels Next image-item Navigates to next image-item 18 x 113 Previous image-item Navigates to previous image- itemMany 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.Series 40 Web Apps UX Guidelines 46

5.2 Buttons5.2.1 Primary and secondary buttonsTable 14 defines the recommended button sizes for use in Series 40 web apps. Remember that the text on abutton 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 SQTable 14: The primary and secondary buttons are show.Series 40 Web Apps UX Guidelines 47

5.2.2 Tertiary icons- buttonsTable 15 defines the recommended tertiary button graphics and sizes for use in Series 40 web apps. Rememberthat the graphic on a tertiary button should visually describe the function that clicking the button caused to beperformed.Button Size Name Meaning 12 x 12 pixels ADD - inside content Closes content in context, for 16 x 16 pixels Close - inside content 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 Transfers to a custom 32 x 32 pixels Download location Opens a pop-up that 32 x 32 pixels Tips provides an explanation Allows users to add the item 32 x 32 pixels Favourites as a favourite 32 x 32 pixels Re-tweet Re-sends postsTable 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 recommendedthat the button labels are formatted in sentence case, as shown in Figure 48.Figure 48: Example of the combined use of buttons is shown.Series 40 Web Apps UX Guidelines 48

5.3 Form elements5.3.1 General elementsTable 16 defines the general elements and their sizes available to Series 40 web apps. These elements should bepresented centre-aligned to row height.Button Size Name Meaning 21 x 21 Radio button selected Exclusive selection Active exclusive 21 x 21 Radio button active selection Inactive exclusive 21 x 21 Radio button inactive selection 21 x 21 Check-box selected Multiple choice selection 21 x 21 Check-box active Multiple choice selected Multiple choice non- 21 x 21 Check-box inactive selectedTable 16: The general elements are shown.5.3.2 Input fieldsTable 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 Used to enter form text. Actual size of input field Form input 210 x 40 is 161 x 28-pixels. field To be used preferably with a label. Used to enter text upon which an action is to be performed. Full-width 240 x 40 Actual size of input field input field is 185 x 28-pixels. To be used preferably with a label.Series 40 Web Apps UX Guidelines 49

Input field Size Name Usage notes Used to enter form data such as dates. Form multi- Actual size of each input 210 x 40 input 3 part field is 60 x 28-pixels. To be used preferably with a label. Used to enter form data, such as short dates (MM/ YYYY). Form multi- 210 x 40 Actual size of each input input 2 part field is 94 x 28-pixels. To be used preferably with a label. Used to enter multi-line text, such as descriptions. Description Actual size of each input 210 x 86 input field field is 94 x 28-pixels. To be used preferably with a label.Series 40 Web Apps UX Guidelines 50

6. Specs for standard componentsThis section provides detailed size specification for the recommended standard components for use in Series 40web app. Note: In all cases the vertical and horizontal space around all elements is 8 pixels.6.1 Header and sub-header componentsThis 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.Series 40 Web Apps UX Guidelines 51

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.Series 40 Web Apps UX Guidelines 52

6.2 List itemsThis 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.Series 40 Web Apps UX Guidelines 53

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.Series 40 Web Apps UX Guidelines 54

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.Series 40 Web Apps UX Guidelines 55

6.3 ContentThis 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 TabsThis section provides detailed specifications for content with headline, date, and body text, shown in Figure 64.Figure 64: The specification for tabs is shown.Series 40 Web Apps UX Guidelines 56

Copyright © 2011 Nokia Corporation. All rights reserved.Nokia and Forum Nokia are trademarks or registered trademarks of Nokia Corporation. Oracle and Java areregistered trademarks of Oracle and/or its affiliates. Other product and company names mentioned herein maybe trademarks or trade names of their respective owners.DisclaimerThe information in this document is provided ‘as is’, with no warranties whatsoever, including any warranty ofmerchantability, 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 toimplementation of information presented in this document. Nokia Corporation does not warrant or representthat such use will not infringe such rights.Nokia Corporation retains the right to make changes to this document at any time, without notice.LicenceA licence is hereby granted to download and print a copy of this document for personal use only. No otherlicence to any other intellectual property rights is granted herein.Series 40 Web Apps UX Guidelines 57

http://www.slideshare.net	345
http://habrahabr.ru	198
url_unknown	5
http://ehhu.ru	1

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

by nokiaru on Jun 28, 2011

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 549

Statistics

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