Handheld (PDA) Application Design Guideline

Introduction

Purpose

This document describes the necessary requirements for being able to build handheld applications and different design guidelines to follow and keep in mind when developing the applications. The content is valid for Comflow 2.20 or later.

This document is intended for Corzia partners and customer who use Comflow for developing solutions for handhelds.

Handheld applications

The primary purpose of a handheld application is to support administrative flows which demands mobility – such as stock taking, service execution, production reporting, or goods receiving. Generally the idea is to “work with gloves on”. The advantage of the handheld applications is that they enable their users to carry out the actual work and do the reporting at the same time. This minimizes administrative work and increases efficiency and accuracy.

The concept of Comflow handheld applications is specifically to capture data by scanning or easy keying, check the data against administrative systems in the background and perform real time updates against these systems. The applications should be robust and easy-to-use, and provide the user and the using organization with real time information in synchronization with mobile business activities.

The applications are aimed for handheld devices (PDA’s) with touch screen, with or without keyboard. The technology is on line web applications via web browsers with a “push” interface, meaning easy to use in working environments. This can be complemented with keyboard and to some extent key-mapping to functions in the applications. 

Applications are designed with the same tools as Desktop applications, though with some limitations due to the small size of the devices and screens. A principal design consideration is that the handheld rendering always uses the full width of the screen, and let the height take as much room as needed. – Simply because it is easier to scroll up and down on a handheld device.

Handheld Application Framework

Comflow’s handheld application framework is used to build these kinds of browser-based applications in Comflow. The developed applications can then be connected to a Comflow server via LAN:s or WAN:s. The handheld framework consists of

• Generic platform functionality (such as Portlet Designer)
• A specific handheld core plug-in (net.comactivity.core.pda)
• The design guidelines provided in this document.

This means that you do not use any specific handheld tools, but only the standard platform tools, such as Portlet Designer. The guidelines, that you should apply when developing the applications, emphasize the fact that handheld devices have very small screens and are often used in rough environment. Consequently, the guidelines provide solutions that optimize the user interfaces for these types of devices.

The table below provides you with a brief summary of the content in the chapters.

This chapter describes the requirements and settings that are necessary in order to be able to build handheld solutions in Comflow.

The following settings are available specifically for handhelds:

• Page header
• Header picture
• Navigator.

Page header

You can use a top pane, a kind of page header, when working with handheld portlets. The header includes a picture selected by you, a button for logout, and a button to go back to the menu.

To use the page header, set the following property to true in the site definition:

<Property name =”portal.showPDAPortletTopPane” value=”true”/>

Header picture

If you use page header when working with handheld portlets, you can add a picture to the header. An example of a useable page header picture is a company logo.

To use a picture, setup the following property in the site definition, after the other properties for company logos:

<Property name =”company.logo.pda” value =”somePicture.gif”/>

Navigator

There are 2 types of navigation settings:

• Version 1 (old version for backward compatibility)
• Version 2 (new version)

Version 1

The version 1 PDA is a navigator of its own, where defined tasks are rendered as buttons. You are limited to show 10 items/tasks in the navigator, without any hierarchy, since they in advanced browsers can be related to numbers on the keyboard (1-0), and by pressing a number you start the related task.

To set up the PDA navigation, you create a NavigatorHandheld.xml-file, where the tasks are defined according the example below. Note that you can only have one navigation tree for PDA and that you do not need to set it up in sitedef.:

<?xml version="1.0" encoding="UTF-8"?>

<tasks>

                      <task index="1" id="PDARefillGoodsReceipt"/>

                      <task index="2" id="PDARefill_Manage"/>

</tasks>

With this navigation, there is no checking of function authorization.

To enable numbers for each menu button, in order to start task via pressing the related number on the keyboard, you set the following property in the sitedef:

<Property name="portal.pda.numberedMenu" value="true" />

This only works for the specified hardware and browser configuration that enables hotkey mapping.

Version 2

The version 2 is new in Comflow 2.18 and is very similar to the desktop version of the navigator, though rendered for PDA. This menu gives you the opportunity to work with hierarchical structure like in the desktop. 

On the top level you only see the logo and the logout icon at the top. A menu folder is rendered with an arrow to the right.

On lower levels, you also get an icon for going back to the top menu. Tasks are rendered without arrows. At the bottom you have a button for navigating back to the previous menu.

To enable this version of the menu, you have to define one of several navigation trees for PDA and do settings in the sitedef.

In the sitedef you separate the desktop and pda navigations via different id’s on the navigation trees, so you can have one set of navigations trees for desktop and another for pda

<Navigations id="desktop">

                                   <Navigation name="MyWorkLists.navtree"/>

                                   <Navigation name="MySettings.navtree"/>

                                   <Navigation name="ApplicationBase.navtree"/>

                                   <Navigation name="Core.navtree"/>

                       </Navigations>

                       <Navigations id="pda">

                                   <Navigation name="ApplicationBasePDA.navtree" />

                       </Navigations>            

You specify the pda navigations in the same manner as desktop.

This version of navigation has the same function authorization as the desktop version.

This version of the menu does not support hotkeys for navigating to tasks by pressing numbers on the keyboard, even if they can be own with the following sitedef property:

<Property name="portal.pda.numberedMenu" value="true" />

This chapter provides you with design guidelines to follow and keep in mind when developing handheld applications.

When using handheld applications, you use another servlet than desktop, and therefore enter another URL in the browser than the normal one. This is due to the fact that there is another rendering mechanism that is doing the buildup of the screens for the handheld. For example, you get no scroll bar icons and very stripped look and feel. This is done to use the limited screen size of the handheld in an optimal way.

The following special features apply for handhelds:

• Select menu items by entering a digit 
• Select a row in a brose by entering a digit 
• Menu and log out buttons displayed at the top
• Support for automatically adding enter or tab to entry
• Log on via scanning

  Select menu items by entering a digit

Every menu item on the handheld is automatically assigned a digit (0 to 9) that is displayed to the left. You can select the desired menu item in the handheld navigator by entering the applicable digit. Supported only by version 1 of the navigator and via hotkey mapped configuration of the handheld.

Each row in a browse on the handheld is automatically assigned a digit (0 to 9) that is displayed to the left. You can perform an action on the desired row by entering the applicable digit. Supported only via hotkey mapped configuration of the handheld.

If you have setup the site definition to display page headers for the handheld screens, two standard buttons are automatically displayed in the page header at the top of the screen: The Menu and Log out buttons. These buttons takes you to the navigator screen (which means that the application is closed down) or log you out of the server.

In the portlet, you can define that each data entry is followed by a tab or an Enter. Thereby, you do not have to set this in the handheld for scanning.

You can log in by first scanning a barcode for the user and the password, and then hit Enter.

Handheld devices have very small screens and are often used in rough environment. Therefore, the handheld applications need to be designed differently than other Comflow applications. For example, you can often design the applications to use only scanning as input. If you complement the scanning with keyboard entry, try to use only one digit as input. Keep in mind to design buttons that can be activated by pressing the finger, often with gloves on. The user seldom wants to use the stylus.

The following limitations, that is, features not supported by Comflow, apply for handhelds:

• No scrollbar
• Limited paging
• Max ten records in a browse list
• Browses only support output mode
• Row-clicks and right-clicks not supported for browses
• Maximum seven menu items
• Limited data type support
• Limited Internet Explorer support
• No skin support
• No toolbar icons
• Custom segment
• Autostart of tasks
• Personalization
• Workflows transition to tasks
• Tasks
• Error messages
• Forced authentication on action 
• Dynamic rules
• Tabs
• Segments
• Segment groups
• Combo field

  No scrollbars

There is no support for horizontal or vertical scrollbars. This is due to the fact that scrollbars take far too much space and is very hard to control for the user.

You can use paging for browsers, but the buttons are then displayed at the top of the screen and overrides the page header that displays the Menu and Log out buttons. You cannot use “show all” or “page count features”.

You can only use ten rows. This is due to the facts that the rows take up lot of space and that it should be possible to select a row by using a single digit.

There is only support for output mode in browses, since it is so hard to enter data in browses on such small screens.

Due to the limitations in size, there are no options to right-click and get a menu in browses.

Due to the screen size, you can only see seven items as buttons in the task menu without scrolling and due to the connection of numbers on the keyboard to tasks in the navigator, you can only have 10.

There is limited support in view functionality for the data types. Examples of data types are pop up’s, pickers or advanced rendering, such as flex identities or M3/Movex text identities. Due to the limitation in screen size, there is no support for clob’s or pictures. The same goes for uploading and downloading files.

There is basic support for Internet Explorer when it comes to pure interaction in the browser, like viewing and pushing buttons. There is no support of mapping function keys though, due to the very limited support for scripting in the PDA Internet Explorer.

There is no skin support in the handhelds. All look and feel has to be customized.

Due to the screen size, there is no support for tool bar icons.

There is no support for custom segments, for example the possibility to style segments based on style sheets.

There is no support for autostarting functions.

There is no support for personalization, for examples saving favorites in the navigation tree.

Due to the lean structure of PDA, you cannot use Workflows that has transitions to tasks. Thereby the workflow needs to incorporate all portlets that shall be used in the PDA-workflow.

The task has to be named exactly as the pinpointed Workflow, except for the file ending. Otherwise you will get a rendering problem.

You can only have tasks that pinpoint the entry point portlet of a Workflow. That means that you cannot define a task that pinpoint another portlet in the workflow than the one that the entry point has its transition to.

Error messages are only shown at the bottom of the screen. No top or pop up messages are supported, due to that you do not want a message that will prevent your processing and force you to any action except scanning again. 

The recommendation is thereby that you do not fill the screen fully if an error message can be used.

The possibility to force an authentication (assign password) via an action (“Authentication required” property on an action) is not supported in handhelds.

Since the browsers on PDA/Handhelds do not always have support for AJAX, Dynamic rules are not supported.

There is no support for tabs in a handheld.

Segments are only supported in expanded mode. There is no way to collapse a segment or expand a collapsed one.

Segment groups are not supported.

Fields that can be displayed as a combo box, like foreign key combo or constant combo, can only be displayed as combo and not in another mode, like radio button.

Keep the following Comflow design recommendations in mind when designing handheld applications:

• Use max six rows in browses
• Use max 12 fields in detail screens (four rows by three fields)
• Use max one detail segment and one browse segment. Always place the detail segment on top
• Use as few entry fields as possible, preferably only one in order to support scanning with mapped enter
• Use screens with relatively little information on, which leads to workflows with relatively many portlets
• Design for using tab and enter keys when navigating via keyboard
• Use only three buttons: like Back, Option, OK.
• Use the option to add tab and/or enter to scan operations
• Have room at the bottom of the screen for error messages if used.

Corzia strongly recommends you to not build complex portlets. Focus on displaying as little information as possible on each screen. Try to solve information overload by navigating to other screens with Enter or a mapped Enter in the scan operation.