Master thesis Product data management information in PDA browsers Carl Tamleht Handledare KTH: Kerstin Severinson-Eklundh Handledare Technia: Jan Thunqvist

Product Data Management information in PDA browsers

Abstract The business area of PDM, Product Data Management, involves management and distribution of information produced when developing products. For example, the information could be CAD drawings, assembly structures and market reports. PDM is a business area that consists of computerized tools for managing product information and organizing the product development process. In this report, the term PDA, personal digital assistant, refers to a palm-sized handheld device. Foremost, PDAs with one of the operating systems Symbian/EPOC, Palm OS or Pocket PC are discussed. Technia is a consulting company that develops PDM systems and services. According to Technia, the use of PDA’s within the industry increases and such applications related to PDM, Product Data Management, business are expected to be a desire from Technia customers in the near future. The Master project has included an investigation of appropriate services based on interviews with Technia customers. The investigation lead to a conceptual design including guidelines for interaction and a graphical user interface for information and services. This was performed along with a brief reflection on relevant technologies and system architecture. Also, a demonstration application with limited functionality was developed.

Product Data Management i handhållna datorer

Sammanfattning Affärsområdet PDM, Product Data Management, innefattar organisation och distribution av information som genererats vid produktutveckling. Till exempel kan informationen bestå av CAD-ritningar, sammanställningar och andra dokument. PDM är ett datorstött verktyg som kan användas till att hantera produktinformation och organisera produktutvecklingsprocessen. I denna rapport definieras PDA, Personal Digital Assistant, som en handhållen dator. Främst diskuteras PDA:er med operativsystemen Symbian/EPOC, Palm OS eller Pocket PC. Technia är ett konsultföretag som utvecklar PDM-system och PDM-tjänster. Enligt Technia ökar användningen av PDA:er i industrin och dylika applikationer kopplade till PDM-lösningar förväntas inom en snar framtid bli ett önskemål från Technias kunder. Examensarbetet har innefattat en kartläggning av lämpliga tjänster baserat på intervjuer med några av Technias kunder. Kartläggningen ledde till några designförslag och riktlinjer för interaktion samt förslag till grafiskt gränssnitt för PDM-information och PDM-tjänster. Parallellt med detta gjordes en begränsad undersökning av relevanta tekniker och systemarkitektur. Slutligen utvecklades en demonstrationsapplikation.

Contents

1. Introduction 1 1.1 Technia AB 1.2 Problem description 1.3 Goals 1.4 Boundaries 1.5 Method 1.6 Disposition

2. Product Data Management 3

2.1 Product development and collaboration 2.2 Product Data Management systems 2.3 The eMatrix platform

3. Literature review 9

3.1 The mobile office environment 3.2 Information architecture 3.3 Graphical user interface 3.4 Summary

4. PDA’s and mobile systems 15

4.1 The first PDA 4.2 PDA 4.3 WDA 4.4 Wireless connection 4.5 Operative systems 4.6 Wireless communication 4.7 System architecture

5. Interviews with visionaries 21

5.1 Scope 5.2 The character of the interviews 5.3 Respondents 5.4 Interview schedule 5.5 Method 5.6 Results 5.7 Summary

6. Scenario building 32

6.1 Scope 6.2 Scenario building method 6.3 Respondents 6.4 Scenario building schedule 6.5 Scenario building results 6.6 Summary

7. Prototype 36 7.1 Tools 7.2 Prototype design 7.3 Prototype content 7.4 Prototype test 7.5 Recommendations

8. Demonstration application 40

8.1 Tools 8.2 GUI modifications 8.3 Application structure 8.4 Application content

9. Conclusions 41 10. Future work 43 11. References 44 Appendix 1. Interview schedule 2. Scenario building schedule 3. Scenario building mock-ups 4. Tag support in Pocket Internet Explorer 5. Prototype information hierarchy 6. Prototype test schedule 7. Demonstration application request/response

1

1. Introduction

1.1 Technia AB Technia is a consulting company that develops systems and services for global collaboration within development and service of products for the entire product lifecycle. The company has about 100 employees in the offices in Stockholm, Helsinki and Oslo. The major part of the customers consists of Nordic industrial companies. 1.2 Problem definition According to Technia, the use of PDA’s1 within the industry increases and such applications related to PDM2, Product Data Management, business are expected to be a desire from Technia customers in the near future. There are several issues that have to be investigated before Technia can satisfy the expected PDA needs. The first issues to be investigated should be the application suitability and the user interaction with the information and services on the limited PDA display. This Master thesis is a pre-study that investigates the customers’ needs and desires referring to a PDA integration with a PDM system. Based on the investigation, a demonstration application with the desired services has been developed and tested. 1.3 Goals The Master project should lead to:

- Investigation of appropriate services based on interviews with Technia customers

- Conceptual design including guidelines for interaction and a graphical user interface for information and services along with a brief reflection on relevant technologies and system architecture

- Development of a demonstration application with limited functionality

1.4 Boundaries System design for mobile scenarios covers a wide range of issues, ranging from mobile networking to plain user interface design for mobile devices and mobile contexts of use. Mobile applications often run distributed on several connected devices, used by many users simultaneously. This report concentrates on concepts and customers´ needs for access to PDM information in PDA’s. System architectural design has an important effect on mobile system concepts and usability [7]. However, the system architecture aspect is not a major issue in this report. The system architecture part is just an overview of options available when developing mobile interfaces for collaborative systems. The development and progress of mobile systems and networks is also only briefly described in the system architecture part.

1 In this report, the term PDA refers to a palm-sized handheld computer device. 2 The term PDM will be defined and explained in chapter 2.1

2

Another issue connected to system design for mobile scenarios is security. Security is not reviewed at all in this report. 1.5 Method 1.5.1 Literature study First, the author performed a literature study. There is not much literature available about PDA’s and PDA services except for articles and seminar reports. Many articles and reports have been found at sites related to Human-Computer Interaction conferences and seminars. The literature study succeeded to reveal some useful information for the interviews and prototype development. 1.5.2 Interviews Interviews with four Technia customers were performed. In this report, the Technia customer representatives are called “the visionaries”. They were supposed to be persons with deep and overall knowledge of PDM together with knowledge of workflows and processes integrated with the PDM system at their respective company. They should also have overall work assignments, for instance as project leader or business developer. The visionaries were expected to contribute to aspects and ideas on possible PDM services that users might want mobile access to in a PDA in the future. Interviews with Technia employees were also accomplished. The scenario building method3 was used. The reason for the interviews with the Technia employees by using the scenario building method was to get ideas on the design of the graphical user interface for PDM services in a PDA. The respondents consisted of five Technia employees with experience of development and use of PDM systems. Referring to their knowledge of PDM they were viewed at as presumptive users of PDM services in PDA’s. 1.5.3 Prototype A prototype was developed in order to visualize and test the ideas concluded from the scenario building sessions together with the results from the literature study. The prototype was programmed in HTML with active links. A usability test was run on the prototype. In this report, usability is defined as desires, aspects and ideas related to the layout and visual design of the prototype and how well the prototype matched the presumptive users ́conceptual model of the test tasks4. 1.5.4 Demonstration application The graphical user interface was modified and a demonstration application with PDM services and PDM information was developed.

3 The scenario building method is thoroughly described in chapter 6.2. 4 The usability concept is thoroughly described in chapter 7.4.1.

3

2. Product Data Management

2.1 Product development and collaboration This introductory part is based on material presented in a book written by David G. Ullman [23]. Ullman is a product designer who has researched and written about design for over twenty years. He is Professor of Mechanical Design at Oregon State University, USA. When designing new products or modifying old products, a huge amount of information is produced. Such product information describes the characteristics of a product and may consist of design drawings, documents describing mechanical construction and market plan. The definite way to store product information is in electronic format. The storage system must involve applications that allow access to information requested. A major problem with electronic storage of information is that there are new and modified file formats introduced all the time, especially for design drawings. The first industrial tools developed for support of information management within product development and production were introduced in the 1960s. Such tools were supposed to improve the effectiveness for design, mechanical construction and manufacturing. For design and mechanical construction, tools for drawings, for instance CAD/CAM software, were developed. For the manufacture departments ERP, Equipment Resource Planning, systems, were introduced. The tools were effective and costs and lead times were reduced. When the industrial tools described above were developed and introduced, industrial companies were more or less divided in isolated groups responsible for marketing, design, manufacturing and overall management. This divided organization structure led to a product development process known as the “over-the-wall” development process. In the simple structure shown in fig 1, the engineering development process is walled off from the previous functions in the product development chain. Basically, people in marketing communicated a perceived market need to engineering either as a simple, written request or, in many instances, orally. This was effectively a one-way communication and was therefore represented as information that was “thrown over the wall”. Engineering interpreted the request and developed concepts and specifications. This information was then thrown over the wall to be produced. Manufacturing then interpreted the information passed to it and built what it thought engineering wanted. Unfortunately, the products that were manufactured were not always what the customer had in mind. The major reason for this was the lack of communication described above. In the late 1970s and early 1980s, the concept of concurrent engineering began to break down the walls. This philosophy emphasized the simultaneous development of the manufacturing process with the evolution of the product. Concurrent and simultaneous engineering was accomplished by assigning manufacturing representatives to be members of the development teams so that they could interact with the development engineers throughout the development process. The goal was the simultaneous development of the product and the manufacturing process. The use of teams including all the stakeholders5 eliminated many of the problems with the “over-the-wall” method. Today the concurrent engineering methodology has developed from integration of human resources and knowledge to integration of departments and people acting in different cities and even different countries. This makes a continuous team member dialogue more

5 In this report, a stakeholder is defined as a person who has overall concern for a product.

4

complicated. There is a need for a tool for communication and collaboration in product development projects. Good communication involves increased product quality and reduced lead times. This is the major purpose of implementing a PDM system. 2.2 Product Data Management systems The following chapter is primarily based on a report produced by CIMdata, USA [4]. CIMdata is a pioneer PDM company that provides consulting services and in-depth research within the constantly evolving PDM business area. PDM, Product Data Management, involves management and distribution of information produced when developing products. For example, the information could be CAD drawings, assembly structures and market reports. PDM is a computerized tool for managing product information and organizing the product development process. PDM systems allow access to and control of product data for construction, manufacturing and maintenance. To many companies effective management of product information is a question of survival. Searching for and re-using information must not take time, irrespective of the type of information requested. Furthermore, the information must be consistent and available. A PDM system provides adaptable database applications for storage, management and control of product and project information together with related documentation. PDM systems are useful for companies that manage large amounts of information, for instance companies within the fields of product development, mechanical construction and manufacturing. The more products and information to manage, the more use of a PDM system. A PDM system can be used by all parts within an organization, but also by external partners such as customers and vendors. The advantages are most often reduced lead times, available information and better control of projects referring to engineering change management and workflows. It is possible and recommended to integrate other systems that produce and consume information, for instance ERP, CAD/CAM and word processors. 2.2.1 Requirements on PDM systems There are some basic requirements and some core functionality that PDM users are supposed to be provided with. Access to information most often involves different restrictions for different users, but generally the concepts below should be included in the core functionality.

- Data vault and file management - Process management - Product structure management - Program and project management - Communication - System administration

2.2.1.1 Data vault and file management The most important function of a PDM system is the system’s function of an electronic vault. The system manages all information produced and controls the access to ditto. The information management is performed in the two ways presented below. The two ways are most often combined with each other.

5

- Meta-data, which is data about controlled information. Meta-data is small packages of information stored in a database. It supports the functions performed by the core functionality.

- Product data generated by various applications, such as specifications, CAD

models, maintenance records and operating manuals.

Since a PDM system usually has many users, there will be situations when two or more persons want the same information at the same time. A PDM system controls the access to information and to what extent the information is available. This is usually regulated with so-called “check in/checkout” functionality. The first person to access the current information, for instance a Word document, checks it out and becomes the temporary owner of the information. If another person tries to access the same information, the information will either be blocked or available as a read-only copy. This state is maintained until the first person checks the original information back in again. This type of workflow is managed differently in different companies, but the basics are general. The users of a PDM system should not have to be aware of where and how the PDM information is stored by the system. They are only supposed to know what type of information they search for when browsing in the PDM system user interface. 2.2.1.2 Process management A PDM system should provide control of changes in product information and product configurations. Processes that occur frequently can be modelled in the PDM system and the workflows within the organization can be structured. For instance, process management functionality is used for reviewing and approving product data. Such workflows are most often company specific and must therefore be methodically defined before they are structured and implemented in the PDM system. Such definition processes might also involve investigations of workflow effectiveness. 2.2.1.3 Product structure management Product structures consist of parts in product assemblies. Also, the structures usually contain attributes and information about part location. A product structure is often integrated with ERP and CAD systems. The control of product structures should be effective and it should be possible to manage variations in mechanical construction and structure versions. 2.2.1.4 Program and project management Program and project management issues might involve planning and work performance control. Project leaders can overview the effort and performance of a project team and check if the progress is within the time schedule. 2.2.1.5 Communication When business critical events occur in a product development process it is important that affected persons are notified. In PDM systems there are often specific applications for such communication issues. For instance, there might be email systems with some extended functionality. A PDM system itself is a communicative tool that provides possibilities for worldwide collaboration. The users may concentrate on productive matters instead of administrative matters.

6

2.2.1.6 System administration A PDM system is supposed to be easily administrated and controlled. The administrative functions could be changing restrictions for information access and approval of processes and workflows. It should be possible to change the graphical user interface and modify processes together with changes in the real workflows. Also, it must be easy to integrate other systems with the PDM system and to add or improve upon functionality. 2.2.2 Economical benefits One can state that a PDM system is a communicative tool. Most often companies invest in tools that involve economical benefits. With extended communication a PDM system is supposed to lead to better products and reduced lead times, which should involve increased sales and reduced costs. 2.2.3 PDM and the Internet The major current issue having the greatest impact on the PDM industry is undoubtedly the Internet. The movement has gathered momentum rapidly, driven by the surge of interest in Internet technology throughout society and business. For users, the distinct advantage of client/server model is that it gives them application power on their desktops and lets them choose how and when the applications are run. Instead of having all software running on the central mainframe, systems for this distributed arrangement have core PDM software residing on a server. The server is connected over an internal or external network to multiple workstations running client software to perform actions such as content display of the product structure, information browsing or workflow task execution. The idea of a PDM system providing available information managed in a structured and safe way is easier accomplished with Internet technology. Possibilities for eBusiness solutions are created and the collaboration with customers and vendors increases. 2.3 The eMatrix platform This part provides the reader with some information on the eMatrix platform as the PDM solutions Technia develops are based on that software. MatrixOne, USA, develops the PDM platform eMatrix. The platform consists of four main applications and the system architecture can be built up by several components that provide possibilities for collaboration and eBusiness. The eMatrix platform also includes a number of specific applications that support different processes in companies. These applications are, by way of some examples, suitable for document management, engineering and project management. In eMatrix terminology the applications are called “Centrals”. 2.3.1 The eMatrix platform applications The four main applications of eMatrix have different functions. Together they cover all necessary functionality from system administration to the end user. The applications are presented below.

- System Manager - Business Modeler - MQL - eMatrix

7

2.3.1.1 System Manager The System Manager application allows the system manager to select the computers on the network that will act as servers for metadata and files. It is also possible for the system manager to manage disk storage requirements and provide for ongoing system maintenance. 2.3.1.2 Business Modeler The Business Modeler has dynamic modelling capability and enables users to create and change business information, content, definitions and processes. The application that reads these definitions adjusts automatically. 2.3.1.3 The Matrix Query Language The program language for querying the Matrix database is called MQL, Matrix Query Language. The MQL language has similarities with SQL. The actual MQL application is a command prompt window for executing MQL commands and is most often used for import and export of complete data structures to and from the Matrix database. 2.3.1.4 The eMatrix application The end users use the eMatrix application. The application provides possibilities for creating objects and object relations. The users can also search and navigate in the data structure. 2.3.2 The eMatrix platform components An eMatrix system architecture core can be built up by several components. The components below provide possibilities for eMatrix collaboration services in different ways. 2.3.2.1 Web Collaboration Server There are a variety of web server architectures available for deployment of eMatrix collaborative solutions. Furthermore, enterprises can base their solutions on several combinations of distributed software architectures, including Enterprise Java Beans (EJB), Java 2 Enterprise Edition (J2EE), Remote Method Invocation (RMI) and Common Object Request Broker Architecture (CORBA). 2.3.2.2 The Centrals The Centrals are navigation applications with Java Server Page (JSP) architecture. They are used for accessing all information stored in the eMatrix repository. The Centrals contains eMatrix database schema and business objects that enable information to be found in a secure Web-based operating environment. Every Central deals with specific fields of application for instance engineering and project management. 2.3.2.3 Web Navigator The Web Navigator is a Java-based general-purpose browser delivers eMatrix functions through standard web browsers. Web Navigator offers end users secure and high-function access to enterprise information.

8

3. Literature review

According to Jörgen Roth [21], system design for mobile scenarios covers a very wide range of issues, ranging from mobile networking to plain user interface design for mobile devices and mobile contexts of use. Mobile applications often run distributed on several connected devices, used by many users simultaneously. Considering all issues related to mobile scenarios, one might be overwhelmed. Most often, a design focuses on a specific problem area and neglects others. Furthermore, Roth claims that especially in the complex field of mobile computing, neglecting problems can cause an entire design to fail. On the other hand, taken into account all issues in early design stages may be overwhelming. 3.1 The mobile office environment According to Hölj [15] geographical movement of people has always changed by various modern technologies. The deployment in office environments today is making the employees more mobile, both inside and outside of office. The offering and use of mobile services and products have increased rapidly in the last few years. Email can be read on the way to work and time reports can be managed on the way back home. Furthermore, Hölj claims that the growth of Internet related business is lower today than a few years ago, but still, it seems to be an ongoing mobile revolution. This revolution might be more important than the Internet revolution. The wires from the walls to the desks are being cut and the stationary PC, the natural office environment, is being replaced by hotel rooms, airport lounges or simply living-room sofas. White [25] and Kakihara [18] both define mobile technologies as tools for making the personal life style and personal activity mobile. Such tools and the dynamic interactivity they provide are generally appreciated in office environments. In a few years, the employees will expect access to updated and relevant information independently of their position. The power of the networks and the central business systems should therefore be accessible in the mobile devices available. The next logical step is to let employees decide how and from where they want to work and thus the individual will be a competence instead of a resource. The mobile office evolution is expected to free the human power that earlier has been anchored by the wall via network wires. 3.2 Information architecture Hoyoung [13] considers mobile Internet browsing as different from stationary Internet browsing in two major aspects. First, mobile Internet can be used in various contexts, whereas stationary Internet is mostly used in predetermined environments. Second, mobile Internet usually comes with more limited system resources than the stationary Internet. For example, mobile Internet devices have much smaller screens, less convenient input devices and much slower networks. The limited resources tend to make mobile Internet more difficult to use. 3.2.1 Mobile information architecture According to Hoyoung [13], the concept of mobile information architecture consists of four elements:

9

- Representation - Structure - Navigation - Content

Representation refers to the visual presentation of information. It consists of several aspects, such as how efficiently the information is shown on the screen and how easy it is to read the presented information. Structure means how well the service is organized. It includes subcomponents such as the relevance of menu categorization, the appropriateness of menu labels and the adequate order of menu sequence. Navigation indicates how efficiently the procedures of the service are designed. The subcomponents of “Navigation” include how easy it is to learn the procedure, how easy it is to move between different sub services and how many different ways that are provided to move to other than current services within the graphical user interface. Content indicates how relevantly the information is provided under particular contexts. Subcomponents of “Content” include how efficiently the information is given, how reliable the information is and how often the information is updated. 3.2.2 Mobile information architecture in PDA’s In a Palm technique white paper [24] it is claimed that in PDA’s the information should be presented in as simple hierarchy as possible based on importance to the presumptive user. Only the absolutely required services, procedures and features should be implemented and the most frequently used services, procedures and features should be the most easily accessible. The white paper also suggests that it is appropriate to, when it comes to search functionality, help the user formulate precise queries so that the results downloaded and visualized are small in size and to the point. This is necessary because of the limited screen size and slow networks. For online connection it is appropriate to use local, on-device, hyperlinks to present additional information when possible. This is a possible solution for simple help and support services. The number of icons and additional graphics should be limited as such information takes more time to download than text. Björk [2] points out that it is necessary to strive to fulfill the basic tenets of interface design: clarity, consistency and utility. Good interface design is even more important when developing content for the small screen size of a PDA. All pages and views should have consistent look and feel to enable users to easily navigate between pages and across applications. Recognition is important so that users do not have to relearn an interface. Whenever possible, design elements such as terminology, fonts and icons should be similar to those used in known interfaces. 3.2.2.1 Navigable Spaces In a PDA service, the amount of information might be too large to be reasonably presented in a single view. Björk [3] means that the content should be presented so that the users can explore it at their own pace, in a way that is comprehensible and not irritating. The information can be organized into distinct conceptual spaces of working surfaces that are semantically linked to each other, so that is natural and intuitive to go from one to another. Björk also claims that the users want to know where they can, or should, go next, and how it is related to where their current position is. The users also want to choose where to go next and they do not want to get lost in the graphical user interface.

10

Tidwell [22] means that a good general solution is to start out with at least one top-level “home” space, an entry point, to which the users can easily return. Furthermore, in each space it should be clearly indicated how to get to the next space and how to return to the previous space. 3.2.2.2 Hierarchy and structure Except for graphical user interface matters, Tidwell [22] also has some ideas on information hierarchy worth considering. This part and the next part refer to her recommendations. If there is a large amount of information to show the user, and if the information is interrelated in a hierarchy, there are several possible ways to visualize this. The users should see the structure of the data, the structure should be easy to understand and easily navigated. Furthermore, the hierarchy should be quick to traverse, if the user knows where something is in the hierarchy. A tree-like structure gives the users a good overview of the information hierarchy. The users should be allowed to control how much of the tree that is shown. It is appropriate to allow the users to zoom in and out in the tree structure. Though, the limited screen size of a PDA can make the visualization of a tree structure difficult, especially if the amount of information is so large that the width of the tree is bigger than the width of the screen. If there are many homogeneous things, each of which has similar additional information or subparts, to show the users, it is appropriate to visualize the information in a tabular or list set. The data should be ordered according to some appropriate organization principle, such as by the value of some column. There should be some white space between columns to set them apart, but not too much. The users should not have to work too hard with their eyes to go from one column to another. This kind of presentation provides the users with a quick overview of the information available. It will probably make it easier to find a specific piece of information while putting similar information into columns facilitates quick comparison of values. 3.2.2.3 Disabled information Information or procedures that have become temporarily irrelevant in the current view can be made unavailable to the users. This action is performed to prevent the users from doing something erroneous with information that cannot or should not be used. The graphical user interface is supposed to present navigational choices, for instance as text or icons, in such a way that the users form a correct mental model of its underlying information or action states. The graphical user interface should also be responsible for what is valid and what is not, to avoid giving the user an unnecessary cognitive burden. All navigational choices accessible must be valid. If the users can trust the graphical user interface to not let them do invalid actions, they will feel more comfortable and secure about the service the interface represents. There are two general ways to solve the information presentation above graphically. It is possible to hide a navigational choice entirely if the users should not be aware of it. It is also possible to gray the choice out, with its main features barely visible, if the users should know it is there but it is not useful at the moment.

11

3.3 Graphical user interface The goal with this chapter is to detect and define guidelines and recommendations for optimal information presentation for browsing PDM information on a small screen. The major part of the content below was found in technique white papers from Microsoft [6] and Palm [24]. 3.3.1 Screen size and resolution The graphical user interface must be developed with the limited screen size in mind. Even though both vertical and horizontal scrolling is possible, all information should fit in the screen without forcing the users to scroll. This is suggested while the overview in a PDA is bad and interaction with the graphical user interface is difficult. The screen size limits the amount of information and the number of user interface controls that can be displayed on a single screen. Small fonts, graphics and user interface controls contribute to poor usability and potential eye fatigue. Limited screen resolution restricts the designer’s ability to render graphics6 that require similarity with the real world. Since user interface controls may be smaller than desired, consistent and predictable placement of controls is important. For instance, if the users are not able to read a label, they may associate button functionality with its size and placement. In the tiny PDA screen it is obviously impossible to navigate and enjoy a traditional PC graphical user interface. It is also uncomfortable to view reformatted content. If the width or height of the information visualization is larger than the width and height of the screen, the scroll bars will appear and reduce the screen width and height with about 10 pixels, no matter what PDA is used. 3.3.2 Browser The browser should support both online connection and local information browsing. A web browser involves the most flexible ways to visualize information. 3.3.3 Frames Frames consume a large amount of space on the screen because of the borders and the margins and are therefore generally not recommended. If frames must be used, the number of them should be limited to no more than two per screen. 3.3.4 Text Fields and Text Areas It is recommended not to use text fields and text areas, primarily because of the limited input devices. If text fields and text areas must be used, they should absolutely not be wider than the width of the browser. It might involve problems with the usability of the graphical user interface if the users must be able to manipulate the difficult text input process together with horizontal scrolling of the browser. The issues discussed above are also important when it comes to forms, such as search functions. The text field and the “submit”-button should be placed on separate rows rather than one of them disappearing to the right of the screen. The width should always be kept in mind.

6 In this report, the term “graphics” is used in a broad sense covering all kind of graphical representations that can be displayed on a 2D screen.

12

3.3.5 Buttons A button is defined as a rectangular graphical object and is named with text that describes the action performed when tapped. Oftentimes buttons are named “submit” or “cancel”. Ideally, buttons should be designed and placed in such a way that they are consistent, both within a particular page and across other pages. There is a limited amount of the screen space for the placement of buttons, so judgment should be used when deciding how many buttons to include on the screen. 3.3.6 Tables The use of tables to display information can greatly enhance the way users view certain data. Tables are appropriate when large amounts of information are to be visualized. The users get a good overview and it gets easier to find specific information. A table should not be wider than the width of the browser to avoid horizontal scrolling. If necessary, the table height may be bigger than the height of the browser. Vertical scrolling is more intuitive than horizontal ditto when browsing a table. 3.3.7 Icons As there are many different PDA’s and browsers with different support for color and gray scale available in the market, it is appropriate to use icons with distinct borders and large color contrast ratio. For the same reason, icons that are specifically made for PDA browsers should be used. If one wants to use existing icons designed for PC browsers it might be a good idea to simply redraw them. Icons instead of buttons and text links can make the users more comfortable with the graphical user interface. Icons should be used when they are valuable to the users. However, the impression of the graphical user interface might get diffuse if too many icons are used, so they should be used sparingly. Icons in PDA’s should be avoided if it is possible to provide the users with the same message with buttons or text links. 3.3.8 Upper left corner In the western civilization it is most common that pages are read from the upper left corner to the lower right corner. It is therefore recommended to place the most important information, such as the headline of the service or the company logo in the upper left corner. 3.3.9 Adding space with GIF files Sometimes the amount of space between elements on a page is not enough. If the graphical user interface looks dense it might be a good idea to increase the space between icons, headlines or text areas. A simple way to do this is to “design” a 1x1 pixel transparent GIF and to insert it on the page where the space is needed. The height and width of the GIF file can then be set to appropriate dimensions. The GIF can also be used to get extra space between rows. 3.3.10 Online connection If one uses an application that involves online connection, for instance with mobile Internet as transaction medium, it is appropriate to download and store static information such as help documents, locally on the PDA. Local access to those pages will then be much faster than access over mobile Internet. 3.4 Summary There is not much printed literature available about PDA’s and PDA services except for articles and seminar reports. Many articles and reports have been found at web sites related to Human-Computer Interaction conferences and seminars. Some reports produced by

13

companies within the PDA business, or immediate business, have been used. However, such material should be used carefully as the content might be very subjective. This report only includes material from articles and reports that I have considered being objective. The literature study failed to reveal any specific trends in PDA research. Research related to PDA issues covers many areas. However, the most frequent issues in academic research seem to be the actual concept of mobility and graphical user interface. Articles and reports produced by enterprises often discuss and present mobile office environments and PDA connection to business systems. The most common problems and challenges seem to be the lack of PDA standards, slow networks and the difficulties related to designing a reasonable graphical user interface.

14

4. PDA’s and mobile systems

4.1 The first PDA In 1993 the Newton Messagepad, developed by Apple, USA, was released as the first commercial PDA, Personal Digital Assistant. It was a bit bigger than a paperback, had a weight of half a kilo and included classic filofax functions as address book, to-do-list and calendar. The sales result was bad though and in 1996 Palm released their first PDA. The PDAs from Palm were simpler and faster. In 1998 the Newton Messagepad was out of the market [8]. 4.2 PDA In this report, the term PDA refers to a palm-sized handheld device. Foremost, PDAs with one of the operating systems Symbian/EPOC, Palm OS or Pocket PC are discussed. The first PDA’s included digital calendars and contact lists. In the last few years many new applications and features have been introduced, such as connection to the Internet, multimedia functionality and lots of other software. The modern PDAs have a memory of 16-72 MB. Today there are no wireless authoring tools that are built on emerging standards. If the next generation of PDA’s has a slightly different-shaped screen, applications and content optimised for different dimensions, the earlier versions will either look bad or not work [26]. In figure 1 a PDA is presented.

Figure 1: Palm m505. Taken from www.palm.com. 4.3 WDA More and more of the discussions about PDA’s are now involving WDA’s, Wireless Digital Assistants. A WDA is a combined mobile phone and PDA with the functionality of both devices implemented. A WDA will, obviously, allow the users to connect to wireless networks without being forced to make a configuration between the PDA and a mobile phone. The WDA objective is to cover the whole chain of devices from the stationary PC on the desk, to the PDA, which is brought when the user is on the move, and of course the constantly present mobile phone. In the future, the WDA might replace those office features with its concept of a single device [27]. In figures 2 a WDA is presented.

15

Figure 2: Handspring Treo. Taken from www.mobil.se. 4.4 Wireless connection There are some different ways to connect to wireless networks with PDA’s and WDA’s. One option is to use an infrared connection between a PDA and a mobile phone and let the mobile phone dial up a wire line connection to a network server. It is also possible with wireless connection to network servers. Another option is to connect the PDA directly to a fixed WLAN (chapter 4.6.2) within office buildings and other public shared spaces. With a WDA wireless connection is easily accomplished as the WDA itself can dial-up and connect to a network server because of the mobile phone character. 4.5 Operating systems Today there are three dominating operating systems in the European market [1].

- Symbian/EPOC - Palm OS - Pocket PC

Symbian is a company that was founded after some collaboration between Nokia, Ericsson, Panasonic, Psion and Motorola. EPOC is Symbian’s operating system for PDAs and WDA’s. The EPOC operating system is Java-based and right now (15 March 2002) the best selling one in Europe. The Palm operating system is the real pioneer system for PDAs in the market today. The operating system is the best selling worldwide (15 March 2002). PDA’s with the Palm OS have earlier had low memory capacity and have not been so powerful. This is changing, though, and now there are PDAs with Palm OS that have good support for mobile Internet and multimedia. As the Palm OS is the oldest commercial operating system there are a lot of third part software available for PDAs with Palm OS. Pocket PC is a Microsoft product and was earlier called Windows CE. The operating system requires more memory and a more powerful processor than EPOC and Palm OS. The most common Microsoft formats, as Word, Excel and Internet Explorer are available as Pocket versions.

4.6 Wireless communication This chapter is supposed to give an overview of the concept of wireless communication. The reader is given a short introduction of how networks for mobile Internet are in progress

16

in Europe. There are no advanced descriptions of underlying technologies and concepts [19]. 4.6.1 GSM, GPRS, 3G Wireless network connection is about to step into the next generation of network technology. Today the data carrier is almost always GSM, Group Speciale Mobile. GSM technology requires users to be constantly connected to the netpass independently of data being sent or not. The connection time is usually paid for per minute. GPRS, General Packet Radio Service, is the opposite of GSM technology. The users are connected without allocating space in the network. The network is therefore shared by all users and is only used when data is transmitted. For the first services with GPRS support, users will pay per MB of data downloaded from the network. The transfer speed for GPRS is up to ten times higher than for GSM. The Third Generation, 3G, is technology that will increase the transfer speed additionally. The speed will possibly be twice the transfer speed of GPRS. This will be made possible by increasing the bandwidth of the networks. The 3G-technology is expected to be commercially introduced in Europe in the end of 2002 [14].

Figure 3: The figure gives an overview of the difference in transfer time between GSM- GPRS- and 3G-technology. Taken from Larry Woods’ presentation 2002-03-07, Telecom and Media event, Grand Hotel, Stockholm 4.6.2 WLAN A LAN, Local Area Network, is a network for computer-based communication and is normally used within companies and organizations. A WLAN, Wireless Local Area Network, is the same thing but without wires. The reach of a normal access point is about 100 meters indoors and a bit more outdoors. The data transfer speed is high and can be compared with the speed of 3G networks. The WLAN concept is now being introduced to public shared spaces, such as restaurants and airport lounges [14].

4.7 System architecture There are three major ways to develop a service or application for PDA integration with a PDM system [5].

- Thin client – online connection

17

- Thick client – PC synchronization - Combination of thin and thick client

4.7.1 Thin client – online connection The PDA can operate as a simple interface between the actual data on a server and the user. This client functionality is called “thin client”. The PDA only visualizes the information in a graphical user interface, most often a web browser, while all handling of the data is done on a server. Only the data representation and user interaction are provided in the thin client. This solution is enough for an application that does not require advanced functionality on the client side. There are different operating systems and many different third party applications, such as web browsers, in the PDA market. This means, there is different support for conventional web technologies. Conventional web technologies are for example HTML, DHTML, XML and ActiveX technology. One should have the PDA, the operating system and the web browser in mind when developing an application or service presented in a thin client. Below, the advantages and disadvantages of a thin client are presented. Advantages of a thin client:

- Users may have the same data at a given point of time - The information available is up to date - The WDA market is growing and wireless PDA connection is soon a matter of

course - A general solution with the services’ core technology on the server side is

possible - Communication with other clients is possible

Disadvantages of a thin client:

- In case of online connection failure, the PDA service is disabled - If the network is not powerful, effectiveness of navigation decreases

4.7.2 Thick client – PC synchronization The second alternative is to connect the PDA to a PC connected to the PDM system. Then, data is streamed from the PDM system to a local relational database in the PDA. The information is then completely on the client side. This is called a “thick client”. The thick client can be used as a slave to whom data is downloaded for read-only browsing. Also, the information can be changed and re-synchronized to the PDM system, as earlier described, by connecting the PDA to a PC. Several users may apply data changes to different devices, even simultaneously. A single user carries around a database stored in the PDA. The database has originally been copied from a central server. While on the move, the user is not connected to the home database. This means that the local data will “run out of sync” when users apply modifications on the home database. Though, this might not matter if data stored on different devices does not have to be strongly up to date. Examples of relational databases adapted for PDAs are Sybase SQL Anywhere and Oracle Lite. A PDA relational database requires approximately 1-3 MB of the memory capacity. Most often, the database has no actual limits for how much data it can store. The limits come with the memory capacity of the PDA.

18

When synchronizing and downloading data from a PDM system to a PDA, the limited memory capacity of a PDA must be considered. It might be appropriate to adjust the PDM system so it is possible for users to choose what and how much data that should be downloaded to the PDA. Below, the advantages and disadvantages of a thick client are presented. Advantages of a thick client:

- Independent of network connection - Faster information browsing

Disadvantages of a thick client:

- All users may not have the same information at a given point of time - Limited memory capacity - The implementation is dependent of the specific device referring to both

hardware and software 4.7.3 Combination of thin and thick client The discussion on thin or thick client is basically a question of whether the computing power should reside in the PDA right in front of the user or whether it should reside somewhere else, usually working on servers. It is possible to combine the client options. This could involve online connection to the PDM system from the PDA together with possibilities for downloading data to the PDA for offline use. 4.7.4 Middle server When designing for a multiplicity of PDA appearances, a middle server will know what device that connects and adjust the interface accordingly. A middle server is most often placed between an internal and an external network and will replicate the external network as if it was a workstation on the external network. Middle server delivering web information often has a cache functionality implemented. This means that the middle server stores external web information, such as graphics, so that the information access in the local network gets faster. A middle server is usually physically represented by a traditional workstation [16]. The screen size and resolution of a PDA is currently poor, thus, elements such as graphics and tables can be difficult to display. In addition, rendering complex elements requires powerful computational resources, which are often unavailable on such devices. The PDA does not connect directly to the required service end point, but asks another device, a middle server, to perform the tasks desired. The middle server accepts service requests from devices and connects to the actual service provider and performs the requested tasks. Furthermore, the middle server processes the results and sends them back to the initiating PDA. The middle server downscales graphics and pre-computes the appropriate layout. As a result, the amount of data transferred to the PDA is drastically reduced and the device is relieved from heavy rendering tasks. This solution is useful in various mobile scenarios. Often, the PDA’s used by the end-users have poor system capabilities. Nevertheless, users always want to execute demanding tasks. A middle server has to have a fixed network address or the PDA must be able to, with help of a service discovery mechanism, resolve the network address. The middle server also has to be online whenever a PDA requests services.

19

In the case of middle server failure, task execution is disabled, even if the requesting device and the service provider are online. In the case of a broken communication link between the requesting PDA and the middle server, the task cannot be performed, even if the middle server has successfully executed the task. Examples of middle server solutions are 9i AS Wireless from Oracle and ProxyWeb from Intellisync [7].

20

5. Interviews with visionaries Regardless of the method chosen to gather requirements and task data for an application, the first thing to do is to identify the objectives for gathering data. The reason for this is to determine which method best fits the needs and to create a more focused agenda and gather more useful data [11]. 5.1 The character of the interviews The current data collection method was of a qualitative character. Qualitative data collection is an excellent tool for gathering information that is difficult to get with help of, for instance, questionnaire surveys. With qualitative data collection one can examine phenomena before they have reached a quantified size. The current type of method is therefore appropriate for phenomena and fields where there are only a few persons with enough knowledge to provide the interviewer with essential information within the scope of the interview.

5.2 Scope The main goals with these visionary interviews were to investigate and detect visions, attitudes and fields of application for access to PDM services in PDA’s. The current interview method was chosen primarily because the data type that was supposed to be collected was difficult to define. It was difficult to define “visions” and “attitudes” as specific data types. The qualitative interview method allows open-ended questions and discussions. In this report, an open-ended question is defined as a surveying or out-mapping question where the respondents’ answers are not imposed with restrictions [17]. 5.3 Respondents Four representatives of Technia customers and one Technia employee were interviewed. The respondents are called “the visionaries”. They were supposed to be persons with deep and overall knowledge on PDM together with workflows and processes integrated with the PDM system at their respective company. They should also have overall work assignment roles, for instance as project leader or business developer. The visionaries were expected to contribute to aspects and ideas on possible PDM services that users might want mobile access to in a PDA. The respondents, the visionaries, were important because of their experience. That experience will be a part of the development of fields of application referring to the scope of the interview. The respondents were desired to have some PDA experience, but it was not a requirement 5.4 Interview schedule An interview schedule for the interviews with the visionaries was formed (appendix 1). The complete interview schedule was a result of literature and information research on interview methods, graphical user interface issues and mobile Internet concepts. Also, preparing interviews and discussions with Technia employees contributed to the interview schedule. The interview schedule had a static form in order to be a template for the interviews. The data collection was qualitative and the questions were supposed to be

21

followed by complementary questions and open discussions on the scope of the questions. If an answer was not useful or not within the actual scope of a question, the question was complemented with one or several prepared hypothetic questions. The reason for this was to gain possibilities for discussions on the questions. The visionaries received a summary of the interview schedule a couple of days before the interview with purpose of anchoring the scope of the interview. The interview schedule was divided into three sections. The first section dealt with the respondents’ overall PDM view. This section was supposed to make the respondents comfortable. The second section dealt with PDA’s and was supposed to introduce the PDA concept. The third section represented the actual scope of the interview and dealt with aspects on PDA integration with a PDM system. The term integration was used while the respondents’ conceptual model of the scope was unknown. A major part of the third section deals with the aspects of communication within the current scope. Aspects on PDA graphical user interface were not thoroughly discussed. The graphical user interface issue was more exhaustively discussed in the scenario building sessions (see chapter 6). 5.5 Method The interviews were performed with the respondents one at a time. The respondents were informed on the scope of the interview, what issues were supposed to be discussed and what the result of the interview was expected to be. The goal with the interview was described as to get aspects and ideas on services and interface for PDM information in PDA’s. Furthermore, the respondents were informed on anonymity in the report. The respondents were allowed to set restrictions for the presentation of the results. The character of the interview, open-ended questions with no restrictions on the answers, was described to the respondents. The respondents were asked to answer the questions considering their own work environment and the assignments of which they had experience. The respondents were informed on the definition of a PDA (see chapter 4) and were told to consider the small screen and limited input devices when answering the questions. Slow networks were not mentioned. The reason for that was to avoid technique signification of the answers of the respondents. User contexts had been delimited from the report and were therefore not mentioned. Every question was supposed to be given to every respondent, but some questions in some interviews were forgotten. Those questions were later discussed via email or telephone. The answers of the forgotten questions are included in the interview results. 5.6 Results The scope of the interviews was to investigate and detect attitudes and fields of application for access to PDM services in PDAs. Thus, it is interesting to view the respondents’ comments in a common context. The presentation below is a summary of the respondents’ answers and ideas on the questions. Some of the answers are general descriptions of the respondents´ answers. However, all of the results are based on the respondents´ answers. 5.6.1 PDM overview -Can you give an overview of what you think PDM does for your company? What concurrent benefits does the business area of PDM involve?

22

The unanimous answer of the respondents was that the main target with a PDM system is to build and maintain collaborative value chains and knowledge base. Furthermore, the PDM system is an excellent tool for keeping information in order. For example, the company becomes independent of single individuals when it comes to document management. Several respondents commented that the system involves control over products and documentation. The idea is that lead times in product development and concurrent engineering are to be reduced by better communication in the company. In other words project management gets easier. The scope and resources can be moved from administrative objectives to productive objectives. Some respondents also claimed that the communication and collaboration with partners, vendors and customers get better if they are provided with access to the PDM system. PDM is not a single application, but more of an e-commerce enterprise solution. -What are the most common problems/challenges with PDM in the beginning before the employees have got any consciousness of PDM together and integrated processes and methodology? Below, a summary of the respondents ́answers is presented. Every stated problem or challenge is based on at least two respondents´ answers. To begin with, it is always a challenge to change workflows and processes. Some people are positive and some people have “over my dead body” attitude when it comes to changes. One scenario when implementing a PDM system is that some documents in some processes change from being word documents and paper copies to be represented and visualized in electronic ways in the PDM system. This can be confusing for the users in the beginning of a live roll out of a PDM system. The whole organization must be prepared for the implementation of PDM. The concept must have the support of all the presumptive users of the PDM system in the company, starting of with the management and ending with the single individual. This establishment process gets easier if the management in the first stage primarily focuses on processes and routines instead of results of work performance. It might be difficult to supply new users with the fundamental semantic concepts. The largest challenge is to change the way of work when implementing a PDM system. It is important to realize that the PDM system is a support system. Most often users have considered the work with the PDM system more as an obligation and a single work assignment rather than a tool that is supposed to be integrated with the daily work. Problems with terminology and semantic concepts may also conduce to the fact that process changes take time. - Can you give an overview of your visions for development and improving upon your PDM system and integrated processes and methodology? The overall target, according to several respondents, is to make the PDM system more global and accessible from other sites than within the four walls of the company or the single office. The collaboration and integration with partners, vendors and customers referring to PDM must be developed and improved. Some respondents wish to increase the subdivision of the PDM system. The users should not be affected by unessential information in the system. It should also be easy to change the processes, procedures and structures in the system as the real workflows and processes

23

change. The eMatrix platform allows these changes with simple manipulation, but there will always be a need for improving upon the system’s ability to handle such events. “Trial and error” in an easy way is a methodology that must be supported in the whole system. 5.6.2 Handheld devices - PDA’s -Do you use PDA yourself? In what purpose and scope? Four respondents were PDA users. All of them used PDA for synchronizing calendar, time accounting and email. -What advantages do you think a PDA has compared to other alternatives? All of the respondents who were PDA users claimed that a PDA is an invaluable tool for personal organization. For instance, the calendar and time accounting are impossible to coordinate if one keeps them separated in a personal calendar book and in the stationary PC in the office. Synchronising a personal calendar with the information and assignments in the PC is the only alternative. There were some comments on that the functionality for downloading and reading email is way better in the PDA than the procedure of a laptop configuration with a mobile phone together with connection to an email server. Also, the PDA is highly portable and relatively easy to use. -Do you think there are any usability problems considering the small screen and the limited input devices? No respondent had any problems with the PDA usability. However, there were several thoughts considering the problems with the small screen size. The overall opinion was that the development of a graphical user interface for a PDA takes careful consideration. A creative system developer can do it, but probably it is necessary with a dialogue with users. Several respondents thought that the major disadvantage is the fact of the limited input devices. If one attaches a keyboard to the PDA it is possible to make some brief notes, but to produce larger documents in a mobile situation is more or less impossible referring to the time spent. Another disadvantage that was mentioned is the fact that there is no overall PDA standard. Today, it is more or less impossible to develop or download existing applications that can be used independent of operating system. This is a problem with PDA applications that are supposed to be used by users who have different hardware and operating systems. 5.6.3 PDA integration with PDM system -If you think of your own work situation, what would it look like with PDA integration with a PDM system? According to all of the respondents it would be extraordinary to be allowed to select and bring information from the PDM system in a PDA. For instance, one could bring an electronic product catalogue, perhaps combined with related documents. It would also be very appropriate to have access to information related to the agenda or business order before and during meetings. Some respondents’ desire was to integrate or synchronize a list with the personal time schedule and tasks between PDA and PDM system. On the whole, the simplicity and comfort with a small sized device such as a PDA, was viewed as advantageous in mobile situations as when one, for instance, is on the move. A laptop is most often handy but could be difficult to use in situations when there is no plain tabletop.

24

Four of the respondents thought that some procedures involving query and update of eMatrix should be possible to implement in a wireless performance in a PDA. However, it is important that the procedures implemented are simple. For example, simple procedures such as approval of Word documents or meeting protocols could be useful. The general view of a mobile PDM solution was that it would increase the availability to access information, increase personal mobility and involve possibilities for better customer service. -What advantages and possibilities could PDA integration with the PDM system involve for the collaboration and communication within and between different levels in the company? Several respondents discussed the use for a PDA in stressful and time sensitive environments. For production lines and similar stressful environments and work surroundings where mobility is required, it would be optimal to be able to search and find relevant and up to date information from the PDM system. For instance, one could search for component assemblies, single components and also related documents in the PDM system. This could also involve processes for tracability, both on a component and on an individual level, if every single person works with a PDA integrated with the PDM system. Another PDA related process, discussed by two respondents, could be the scenario when people affected are supposed to comment on shared issues, for instance, an Engineering Change Order, ECO. This could be applied in real-time with an alert in the PDA that a new issue is supposed to be discussed and commented on. The person alerted opens the issue and comments on it. If the issue could be of interest for some person in the PDA contact list, the issue gets forwarded to that person by simple manipulation. For this scenario with new and important issues it would be very interesting to involve some tools for extended dialogue. There could be connected chat functionality or some software for making a combination of graphical user interface navigation and audio communication possible. It was also said, that the last part of the scenario above does not have to involve shared issues. The scenario could be some other simple mobile out of office situation where two, or more, persons discuss on tasks and time schedules as they navigate in the PDM system. This scenario could be applied to many types of professions, roles and situations in the daily work. Some alert functionality and a following bi-directional messaging session may, for instance, include simple approval of documents, such as meeting protocols etcetera. The communication must be efficiently performed for users to appreciate it. For instance, the dialogue functionality should determine the order of user interaction. -What advantages and possibilities could PDA integration with the PDM system involve for the customer relations? A few respondents had some brief ideas involving contact networks like customer contacts, perhaps as user shared contact lists. -What advantages and possibilities could PDA integration with the PDM system involve for the sales department? This is probably a wide field of application, according to several respondents. Product catalogues could be applied to work processes involving PDA integration with the PDM system. A product catalogue should provide the user with access to information such as component parts data and simple bills of material information. One respondent discussed the idea to provide sales department or customers with product catalogues in Memory sticks that are available for some PDA’s on the market.

25

It was pointed out by several respondents that sales representatives most often have assignments, such as business trips, that involve mobility. Every employee with similar assignments would probably have the same use or need for PDM services available in a PDA. It was commented that this is not a question of profession or role, it is rather a question of work related mobility in general. One respondent claimed that a PDA could be used for promotion purposes for demonstrating the capacity of the eMatrix platform. It could lead to value for customer and vendors who consider an implementation of eMatrix to increase the collaboration with the company. Effective and user-friendly search functionality would also increase the reliability of the system. -What advantages and possibilities could PDA integration with the PDM system involve for the product development and concurrent engineering? Referring to product development, several respondents claimed that it could make collaboration with customers easier if one had the possibility to access information in a PDA. PDA users could be provided with access to a portal where it would be possible to navigate in existing component structures and to view documents related to components in progress. “When is the product released?” “What milestones are related to the product development project?” Such information could be available in the portal. The customer could even subscribe to such information. Updated information is continuously sent to the customers’ mobile telephone configured PDA’s. Two respondents thought that service and support could be a possible field of application. Service staff could navigate for information on products when on support errands. Moreover, it was commented that the greatest field of application probably is the use of a PDA when it comes to the project management part of a product development project. -What advantages and possibilities could PDA integration with the PDM system involve for document management? The major part of the respondents thought that a great field of application would be the possibility to view documents, preferably supported by some PDF solution. Editing and management such as approving commands etcetera can be difficult to support because of the limited input devices. Furthermore, some respondents claimed that procedures such as approval are most often only a part of a more complex process that can be difficult to manage in a PDA. Management of simple protocol notifications in a PDA is a possible process that could be supported and managed by the PDM system. However, every respondent who was positive to PDA document management commented that because of the small screen size, it might be difficult to get an overview of and read documents except for in a general and summarizing view. There were some ideas that it would be appropriate to implement PDA adapted documents such as mini reports. Alternative solution could be linked documents to avoid scrolling. This concept should, for instance, provide quick drill down navigation in the documents. This would probably be a more user-friendly way to present extensive documents. Document access would be a handy information tool before and during business meetings. -What advantages and possibilities could PDA integration with the PDM system involve for integrated business and management systems, resource planning by way of example?

26

Two respondents thought that barcode readers maybe could be integrated. There are such devices that can be connected to PDA’s. The PDA user could register components and store information in the PDA and upload it to the PDM and the business system. Resource planning could be integrated while it could involve possibilities for PDA use when it comes to product development. -What advantages and possibilities could PDA integration with the PDM system involve for project management and project guidance? One respondent thought that if human resource planning is integrated it could involve great possibilities for project management. Moreover, the respondents were generally very positive to mobile access to statistics, tasks, activities and general project plans would be valuable. In particular, it would be of interest to be able to overview deadlines for tasks. -Would there be any advantages in integrating/synchronizing typical PDA services such as time schedule, calendar, to-do-list, network of contacts as lists of telephone numbers and email addresses (upload to the PDM system/download to the PDA)? Generally, the respondents thought that a solution for synchronization between PDA services and some corresponding domain in the PDM system would probably be too system specific. If this kind of service is supposed to be implemented, workflows and processes have to be involved. - Would there be any advantages in sharing/synchronizing a private domain involving the PDM system and PDA with search results, lists of sets of objects and connected documents? Some respondents thought that synchronization of a set of metadata objects and related physical documents is desired. However, one must be able to pick objects and documents to limit the amount of information. The object management should be synchronized and downloaded to a local relation database to keep the current information structure. -Which persons in the company should primarily get access to mobile PDM and PDA? The major part of the respondents thought that there should be no limits for what persons are provided with mobile access to the PDM system, while the number of fields of application probably increases in the future. -Referring to the first PDM questions dealing with problems/challenges before the users have got PDM awareness, do you think PDA integration would cause the same, other or no problem/challenges? PDA integration will probably be a painless extension of the PDM system if the current PDM terminology, symbols and conventions are used. Of course, novice PDA users might find the input limitations difficult to manage in the beginning. It is important to anchor the PDA as a tool and support device rather than a specific activity. -What are the advantages and disadvantages with online and offline connected PDA to a PDM system? This question seemed to be the most engaging question to all respondents. Generally, one respondent thought that offline connection was an optimal solution, while the rest of the respondents based their belief in PDM information in PDA’s on online connection to the stationary PDM system. Below is a summary of the most important and frequent upcoming parts of the respondents’ answers.

27

An advantage with online PDA connection to the PDM system would be that the need for a laptop outside the office would be minimized. Furthermore, an online connection should at least be a part of PDA integration with PDM. The integration would also be made easy if there is not too much equipment. It is desired to avoid configurations between mobile phone and PDA. Equipment such as communicators or PDA’s configured with bluetooth mobile phones are preferred. When the wireless technology enhance, fluid interaction with the PDM system and among people can dissolve activities into minute, instantaneous and ad-hoc events. Also, online connection allows users to share rich content. From a communicative perspective, for instance a scenario with real time dialogues, an online connection is necessary. Also, if the information one wants to access is business critical and must be up to date, an online connection to the PDM system is very handy. Furthermore, wireless technology is considered to be growing at an astonishing rate, which means that a PDA integration or application in a few years is required to provide online connection to the PDM system. Mobile networks are growing faster and more reliable. Offline information management is considered to be a bit old-fashioned. If a user will be on the move or simply just forgets to download updated information, a local PDM application can get inapplicable. Correct information in real time is only available through online connection. The major advantage with offline browsing is that one becomes independent of the server side and server connection. One simply synchronizes the PDA to the PDM connected PC in the office and brings the information desired. Search functionality was pointed out as very important irrespective of online or offline browsing. When browsing online, the users probably have access to a large amount of information that is to be visualized on a small screen. This requires user friendly and powerful search functionality that provides the users with possibilities to limit the amount of information and focus on the information requested. Also, offline browsing in a disconnected PDM application requires powerful and user-friendly search functionality. During the discussions on connection there were desires on PDA integration with PDM. It was pointed out that a general system architecture is appropriate, while there still are no PDA standards for hardware, software or applications. If one would implement PDA integration with PDM today, one could just be forced to provide all users with the same PDA device. Also, the users will require different fields of application and connection for their PDM integrated PDA application. They will probably want a general solution for multitask use of the PDA. In a company where the employees are not provided with the same PDA’s and software, there will probably be users of different hardware and operating systems. However, the perspective of processes should not be general. Referring to the several limitations of a PDA, it will be important to implement simple processes or parts of scalable processes. One alternative could even be to simplify processes to fit in the field of application of PDA use. -Do you believe in a PDA integration, or application, with a PDM system? The general view was that there are other more important issues related to the PDM system than PDA integration. There will probably not be a demand from PDM users for PDA features in the next few years. The wireless technology must also improve. For instance, the technology should be invisible from the end users perspective. If the users connect to the PDM system online, they should not have to be aware of if it is a WLAN or a 3G network they connect to. Mobile technologies play an important role to create and organize

28

effective fluid work environments, but extending that role to be a part of the PDM system will take a few years. Still, PDA’s, or similar future mobile devices, will assume an important role in e-commerce for companies because of future requirements on system access in mobile situations and environments. Such tools can give companies a competitive edge over others and may be helpful in future business in situations where immediate information exchange becomes more and more essential. A PDA will greatly facilitate joint working between and within teams of people widely dispersed across the extended enterprise. The PDA solution needs a scope of its own. It has to be clearly specified which processes and procedures to integrate and implement. The solution must be general, but focused in such a way that it handles clearly defined processes and procedures. 5.6.4 Graphical user interface - What do you think a good graphical user interface is when it comes to usability? Above all, according to a majority of the respondents, the overview of information displayed must be considered. This is probably made easier if the amount of information that is accessible in a PDA interface is limited. The information hierarchy should not be too deep either. A well thought-out plan for presentation of objects, attributes, tables and lists etcetera is required. The importance of simplicity was generally commented on. The graphical user interface should not be more complex than an extended WAP7 interface. If symbols and icons present the information in the graphical user interface, they should be the same as in the graphical user interface presented in stationary terminals. The users should not have to do wide reinterpretations of known conventions. The use of web technology is desired because the flexibility is high and the possibilities for development and improving upon the interface increase. The focus on usability has top priority when discussing PDM services accessible in PDA’s. Some desires on personalized graphical user interface were expressed, but it was also commented that such a feature would probably never be a requirement. 5.7 Summary It is difficult to draw a uniform conclusion from the interviews. It is more interesting and useful to weed out reactions and focus on the issues that were raised, both specifics and generalities 5.7.1 PDM overview The respondents thought that the PDM system is an excellent tool for keeping information in order. The scope and resources may be moved from an administrative objective to a productive objective. A general target is to make the PDM system more global and accessible from other sites than within the four walls of the company and the single office.

7 WAP, Wireless Application Protocol, was developed for simplifying communication between wireless services and mobile devices. The WAP technology is developed with a similar architecture as the Internet architecture.

29

5.7.2 PDA overview The limited input devices are an important disadvantage with PDA use. Moreover, the lack of overall standards for PDA’s might involve complications when developing PDA applications for PDM systems. With this in mind, it should be appropriate to develop general system architecture solutions that can be improved and perhaps more specific in the future. This is probably made easier by using thin clients. 5.7.3 PDM information in PDA’s According to the respondents, processes should not be viewed at in a general way. There might be some need for specific PDA processes when dealing with PDM systems. Such processes must clearly match the existing PDM workflows and must not exclude important processes. Also, the designer and the customer must be clear about the pros and cons of specific PDA solutions. Some scenarios for PDA integration with a PDM system can be detected. One scenario would be the possibility for downloading a set with metadata and related physical documents. For example, this could be applied as a product catalogue. Furthermore, a list with one’s own tasks and time schedules with deadlines etcetera would be a useful scenario when it comes to information access in a PDA. There is a convergence of information processing and communication that could include a communicative scenario where users discuss shared issues. This scenario requires technologies for terminal alert and bi-directional messaging. Moreover, another field of application seems to be project management. It is obvious that the respondents generally have a conceptual model of PDM information in PDA’s that is more information oriented than process oriented. Invisible technology and easy user control of PDM information in PDA’s are also desired. The respondents agree on the importance of a limited amount of information accessible in a PDA, no matter if the browsing in the PDA is online or offline. The majority of the respondents thought that online connection to the PDM system is optimal. PDA access to PDM information should not depend on company role. It is rather a question of work related mobility. The PDA will primarily enhance the individual work performance and satisfaction with the work situation and that might lead to better business performance in a wider perspective. For the next few years, PDM users will not feel that they are behind the times if a PDA solution is not implemented. However, some kind of mobile access to PDM information will become a requirement when faster networks and overall PDA standards are introduced to the market. 5.7.4 Graphical User Interface Powerful and user-friendly search functionality is required. A PDA application will be integrated with a complex system and therefore simplicity is also required. Terminology and graphics should be the same as in the existing PDM system. Some specific navigational issues are also interesting, for example the suggestion on documents allowing quick drill down navigation. 5.7.5 Critical views of the interview results In some interviews one or more questions were forgotten. Those questions were discussed later with the respondents via email or telephone. This could have lead to that some answers were not given within the context of the interview.

30

Sometimes the answers were more of technical character than the scope of the questions. The reason for that is probably that the respondents giving such answers had technical work assignments.

31

6. Scenario building

6.1 Scope The reason for the interviews with presumptive users by using the scenario building method was that they might give ideas on the design of the graphical user interface for PDM services in a PDA.

6.2 Scenario building method The description of the scenario building method below is “refererad” from a report written by Fuccella[12]. The scenario building method is a relatively inexpensive and quick method for collecting requirements and task information. The reason for using the scenario building method should be to collect requirements, desires and tasks from presumptive users of a service visualized in a graphical user interface. The method allows respondents to create a context for their requirements and tasks. Furthermore, this context allows respondents to be more creative and to identify requirements and tasks that other methods may not bring to the surface. The interviewer can either ask the respondents to create their own scenarios or give them prepared scenarios. The process of building a scenario consists of asking respondents to complete three steps where they are supposed to be specific and detailed as possible in their course of action. Respondents are asked to be as detailed as possible in their descriptions, as this detail will directly influence the quality of the data. This is because of the qualitative character of the scenario building method. Below, the steps that should occur when performing a scenario building interview are presented. Step 1: Identify the reason for browsing the service. What information is desired? Step 2: Identify the goal to be accomplished by browsing the service. How does one know that this goal is accomplished?

Step 3: Describe the specific steps one would expect to follow to achieve the goals that are supposed to be accomplished.

The analysis of the data is qualitative. First, each scenario is read through and tasks, requirements and actions contained within the scenarios are highlighted. Next, every action in each scenario is read through, highlighting any terms, phrases or specific user expectations on information architecture and graphical user interface. Trends among the data are also noted. 6.3 Respondents The respondents were five Technia employees with experience of development and use of PDM systems. There were several professions represented: web design, quality assurance and system development. The respondents obviously had a lot of experience of development and use of PDM systems. Referring to their knowledge of PDM they were

32

viewed at as presumptive users of PDM services in PDA’s. The number of respondents was set according to an article describing the current method [20].

6.4 Scenario building schedule An interview schedule for the scenario building interviews was produced (appendix 2). The basis of the scenarios was the presumptive processes detected from the visionary interviews. The complete interview schedule was also a result of literature and information research on scenario building, graphical user interfaces and mobile Internet. 6.5 Method The interviews were performed with the respondents one at a time. The respondents were informed of the scope of the interview, what issues that were supposed to be discussed and what the result of the interview were expected to consist of. The goal of the interview was described as getting ideas on a graphical user interface for PDM information in PDA’s. Furthermore, the respondents were informed on confidentiality and anonymity in the report. The scenario building technique was also described to the respondents. The respondents were informed on the definition of a PDA (see chapter 4.2). The size of a web browser on the current PDA, 240x320 pixels, was described to the respondents. They were also asked to consider the issues and aspects below when discussing the graphical user interface:

- Limited input devices - Overview - Main navigation components - Views – one or more at a time? - Links – icons or text?

The respondents were supposed to create a PDA mock-up for every scenario discussed. The scenarios below were discussed. 1. Tasks including deadline and status. Suppose you need to view your tasks structured in a PDM system in your PDA. How would you like to overview them? 2. Product catalogue. Set with objects and related documents. Suppose you are able to view a product catalogue in your PDA. Navigate from index page to an object that represents a specific product and view an attribute list for the product. Also, consider search functionality. How is it visualized and how do you use it? 3. Communication on a shared issue. Suppose you have been alerted with a shared issue in your PDA, for instance an Equipment Change Order, ECO. How would you proceed to view the issue and discuss on it wireless with your colleagues?

33

6.6 Scenario building results There is great importance attached to the mockups (appendix 3) produced during the discussions on the scenarios. The presentation below is a summary of the respondents’ comments and ideas on the scenarios.

6.6.1 Main navigation, overview and limited input devices There was a common requirement on a main menu with the most important functionality. Furthermore, the information architecture should be scalable to make addition or subtraction of new functionality easy. There was also a common requirement that icons instead of text should represent links. Several respondents hesitated on text links, as they thought the graphical user interface would be messy and it would be difficult to overview the functionality. However, the users must recognize the icons. A smaller version of the icons in the existing PDM system was desired. 6.6.2 Scenarios 1. Tasks include deadline and status. Suppose you need to view your tasks structured in a PDM system in your PDA. How would you like to overview them? There was a common requirement that the tasks should be presented in lists. Furthermore, a description of the task and related documents should be available. It would be appropriate if the deadline status was highlighted.

2. Product catalogue set with objects and related documents. Suppose you are able to view a product catalogue in your PDA. Navigate from index page to an object that represents a specific product and view an attribute list for the product. Also, consider search functionality. How is it visualized and how do you use it? For several respondents, good search functionality was top priority in a set of objects application, especially if there are a large number of objects. There were suggestions on a scalable search function where the user chooses the search criteria, some kind of an advanced search. Furthermore, it might be appropriate to visualize only the search results of the criterions chosen. For product catalogue search functionality, it is appropriate to be given the possibility to choose a list of the top-level objects. It was claimed by some respondents, that if one has many product objects it might be appropriate to divide the catalogue into categorized sub catalogues. 3. Communication on a shared issue. Suppose you have been alerted with a shared issue in your PDA, for instance an Engineering Change Order, ECO. How would you proceed to view the issue and discuss it wireless with your colleagues? According to the general comments of the respondents, the most important issue except, for some graphical user interface matters, was the possibility to view objects related to the shared issue.

6.6.3 Other desires It was generally commented that the graphical user interface should be clean and simple. To avoid navigational errors, the links should not be positioned too close to each other. Some respondents proposed that applications where information content or a form must be displayed over several screens, navigation and contextual feedback become important. The designer must provide the user with easy navigational buttons such as “home”, “next” and “previous” and adequate contextual feedback so that the user does not get lost within the pages. Also, it should be avoided to have people go through too many screens.

34

Several respondents claimed that the small screen size forces the designer to be selective with the information and user interface controls displayed. This can be an opportunity to streamline processes and eliminate redundant or unnecessary information. Limited system resources also necessitate information-oriented applications to provide data filters that allow the user to specify and restrict types or classes of data to download. In other words, good search functionality is an important requirement. Some individual comments worth considering are presented below:

- Email or icon mail should be easily accessible from the index page and should be an option in the main menu.

- Prepared templates and forms for input would be a handy feature. It should not

be possible to check in free text documents that have been produced in the PDA, while the quality of such documents probably is affected by the limited input devices.

- The last navigation should be saved and the users should be provided with a link

to it in the index page.

- A typical questionnaire screen may contain two questions, 2-3 miscellaneous variables, basic navigational controls and a menu.

6.7 Summary The reason for using the scenario building method was to collect requirements, desires and tasks from presumptive users of a PDM service visualized in a graphical user interface in a PDA. There is obviously great importance attached to the mockups produced during the discussions on the scenarios. There were both wide and specific requirements and desires collected from the respondents. The aspects and ideas collected are very useful when developing a prototype.

35

7. Prototype A prototype was developed in order to visualize and test the ideas derived from the scenario building sessions. 7.1 Tools The prototype was programmed in HTML. The HTML pages were viewed in a Pocket PC emulator. An emulator is a virtual PDA displayed on the PC screen. Still, an emulator keeps the same functionality as a real PDA. The Pocket PC web browser, Pocket Internet Explorer, does not support all of the standard HTML tags. In the prototype, Pocket Internet Explorer 2.0 was used. Tag support is listed in appendix 4. Also, Pocket Internet Explorer does not fully support DHTML, such as style sheets and JavaScript. The reason for the use of an emulator instead of a real PDA is that today there are no PDA standards (see chapter 4.2). Also, the interviews with the respondents (see chapter 5.6) revealed that a general solution is desired and that the prototype should not depend on the handling of specific properties and settings of the PDA. 7.2 Prototype design The graphical user interface was formed based on the results from the scenario building sessions. The results from the literature study (see X.X) were also considered. Icons and colors are general and not company specific in any way. Below, the basics of the graphical user interface are presented.

- Top menu with the main functionality - “Back” and “Home” links always present - Icons used when limited space constrains the contents - Virtual search functionality - The graphical user interface clean and not cramped - Active links, but no text input or other dynamic features

The reason for the lack of dynamic features, such as response on text input, was that it was not possible to test such features properly, as an emulator on the PC screen does not allow other input than via the PC keyboard. 7.3 Prototype content A simple information hierarchy (appendix 5) based on the scenarios from the interviews was developed. Below, the scenarios and their content are presented. 7.3.1 MyTasks The scenario that includes “MyTasks” should provide the user with the users’ own tasks and task deadlines. The scenario includes:

- Tasks presented in list format - Link to description of task - Link to task related documents

7.3.2 Product catalogue The scenario that includes “Product catalogue” involves a set of objects, for instance a set could represent a product assembly. The scenario includes:

36

- Assembly presented in list format with hierarchy level visible - Virtual search functionality - Virtual search results

7.3.3 Communication on shared issue The scenario that includes “Communication on shared issue” involves bi-directional messaging on shared issues. The scenario includes:

- ”Read issue” and ”Issue discussion” possibilities - Virtual threaded discussion - Virtual link to related Matrix object

7.4 Prototype test A usability test was run on the prototype. In this report, usability is defined as desires, aspects and ideas related to the layout and visual design of the prototype and how well the prototype matches the users ́conceptual model of the test tasks. The prototype test was supposed to be an eye-opening experience for future modifications of the prototype. 7.4.1 The concept of usability testing This part briefly describes the concept of usability testing. Usability testing is primarily about behavioral data – performance – what people actually do when working with, for instance, a graphical user interface. If the users are not watched when working, the current session is not a usability test. The behavioral aspects make usability testing different from other techniques, such as interviews and focus groups [9][10]. Usability testing should always include qualitative notes. It almost always includes reporting some numbers, such as percentage of respondents who had a particular problem or who took a particular path to completing a task. It does not usually include quantitative data such as time and errors. Usability testing often includes opinions. Objective data is what is seen or heard. Subjective data is what is inferred from the observations. In this usability test, the subjective opinions of the users were of interest, what the users actually thought about the layout [9][10]. 7.4.2 Concerns and goals There were several concerns about the prototype. The prototype test would investigate which paths users took in the graphical user interface when trying to perform given tasks. Also, it was important to investigate if those paths seemed efficient enough to the users. Another important part of the prototype test was to collect aspects of the icons and links present in the graphical user interface. The goals for the prototype test were to diagnose problems and to learn how the users felt about the information architecture and the graphical user interface suggested. Furthermore, solutions were supposed to be developed based on the obvious problems and desires detected. 7.4.3 Respondents To avoid overwhelmed respondents who were not aware of the objective of the prototype, the same respondents as in the scenario building session were used.

37

7.4.4 Test schedule When performing a usability test it is important to select relevant tasks for the respondents. The questions asked should be tightly focused and essential to the concerns and goals with the test and how the test results are supposed to be viewed [9]. The test schedule planning primarily included preparation of the tasks, questions and approach. The type of data desired was opinions on the information architecture and the graphical user interface of the prototype. Thus, the data collection was of qualitative character. The test schedule (appendix 6) consisted of tasks based on the scenarios in the scenario building sessions. After the tasks had been discussed, a number of follow-up questions were asked. The test schedule also involved observation during the tests. It was observed where the users took the wrong path, where they felt unsure and where they reacted positively. 7.4.5 Method The prototype test sessions were performed with the respondents one at a time. The respondents were informed on the scope of the test, what issues were supposed to be discussed and what the result of the interview was expected to consist of. The goal of the interview was described as to get aspects and ideas on the information hierarchy and graphical user interface suggested in the prototype. Furthermore, the respondents were informed on confidentiality and anonymity in the report. The prototype test sessions were of informal character. The graphical user interface was discussed based on the test schedule issues. 7.4.6 Results For diagnostic testing, a qualitative list of aspects and problems is interesting. The data collected were notes about what the respondents said. The sessions did not reveal any actual aspects on the scenarios. Generally, the respondents thought that the scenarios were too fictive to be discussed. However, the prototype test sessions revealed a survey of the suggested graphical user interface. As the scenarios were not thoroughly discussed, it was difficult to detect any trends in the test results. Thus, the most relevant aspects on the graphical user interface are presented below. The graphical user interface was perceived positively, but it was emphatically pointed out that the information overview must be treated carefully. It was also commented that it is probably more important to consider structure and functionality than colors and fonts. The information hierarchy was desired to be presented more clearly than in the current list format. A tangible proposal to improve upon both overview and information hierarchy was to frame information, especially when there is a large amount of information to present, such as in tables or lists. It was also viewed as suitable to provide the users with an always-present main menu at the top of the page. The respondents found it difficult to discuss the scenarios in the test schedule thoroughly as they were fictive and did not have any underlying workflows.

38

7.4.7 Discussion The prototype test succeeded to weed out some individual reactions raised. The suggestion on framing information was the most applicable information received from the informal prototype test. The prototype test was not very comprehensive as the scenarios were viewed at as too fictive to be discussed. I should probably have concentrated the test on more specific graphical user interface issues.

7.5 Recommendations Developing a graphical user interface for a PDA screen was a challenging experience. Primarily, it is recommended to give priority to the most important information. If a view consists of a large amount of necessary information, the developer should try to divide the information into several views. Object names and titles should be kept short. Perhaps it is proper to give the objects in the eMatrix database a “PDA-title” attribute. Furthermore, table size should be set to about ten pixels smaller than the screen width in order to get a distinct border between the content and the hardware.

39

8. Demonstration application

A demonstration application with limited functionality was developed in order to visualize and test some ideas concluded from the interviews and the prototype. 8.1 Tools The prototype was programmed in Java and HTML and managed by JSP-pages8. The JSP-pages were viewed in a Pocket PC emulator with the web browser Pocket Internet Explorer. The demonstration application core consisted of the components below. Detailed information about the components is available at www.technia.com.

- eMatrix platform including Oracle database - Weblogic servlet engine - eMatrix Servlet RMI Business Object Server - eMatrix Framework - eMatrix EngineeringCentral

8.2 GUI modifications The results from the prototype test were considered when developing the demonstration application. The graphical user interface was modified based on the results. 8.3 Application structure The application consisted of a client/server model. Thus, the thin client concept was adopted. The user interaction with the information is performed by a user request to the JSP-page in the web browser. The JSP-page forwards the request, if necessary via communication with the eMatrix database by using JavaBeans9. The request is processed and sent back and presented to the user via a JSP-page. The request/response process is presented graphically in appendix 7. 8.4 Application content The demonstration application had limited functionality. The only actual function was a search function that lets the users search for meta-data in an eMatrix database. Below, a screen series from the demonstration application is presented.

8 A JSP, Java server page, uses HTML-like tags and Java code and generates the content of the page that is supposed to be visualized. 9 A JavaBean is a server-based Java component that contains the logic of a page.

40

Figure 4: Screen prints taken from the demonstration application. The figure shows a set of screen prints where a presumptive user, in this case the author, browses through the demonstration application from the login page to a simple product data information search example.

41

9. Conclusions

The conclusions of this thesis are presented along with the goals they are related to. The reason for this is to give the reader a better overview of the analysis of the thesis results. The Master thesis should lead to:

- Investigation of appropriate services based on interviews with Technia customers

- Conceptual design including guidelines for interaction and graphical user interface for information and services along with a brief reflection over relevant technologies and system architecture

- Development of a demonstration application with limited functionality

- Investigation of appropriate services based on interviews with Technia customers A PDM system is viewed at as an excellent tool for keeping information in order. The scope and resources may be moved from an administrative objective to a productive objective. A general target is to make the PDM system more global and accessible from other sites than within the four walls of the company and the single office. It is probably appropriate to develop general system architecture solutions that can be improved and perhaps more specific in the future. This should be made easier by using thin clients. Transparent technology is a requirement. There should not be any additional and uncomfortable workload related to browsing PDM information in PDA’s. Processes should not be viewed in a general way. There might be some need for specific PDA processes when dealing with PDM systems. Such processes must clearly match the existing PDM workflows and must not exclude important processes. Some scenarios for PDA integration with a PDM system can be detected. One scenario would be the possibility for downloading a set with metadata and related physical documents. Furthermore, a list with personal tasks and time schedules with deadlines would be a useful scenario when it comes to information access in a PDA. There is a convergence of information processing and communication that could include a communicative scenario where users discuss shared issues. This scenario requires technologies for terminal alert and bi-directional messaging. It is obvious that the respondents generally have a conceptual model of PDM information in PDA’s that is more information oriented than process oriented. The PDA will primarily enhance the individual work performance and comfort with the work situation and that might lead to better business performance in a wider perspective. Using computer resources while moving is a true benefit of mobility. It allows users to take a computer away from its usual workplace. Work assignment flexibility can also be improved by virtue of mobility.

- Conceptual design including guidelines for interaction and graphical user interface for information and services along with a brief reflection over relevant technologies and system architecture

42

The terminology and the graphics in a PDA should be the same as in the existing stationary PDM system. It is proper to employ some rules of thumb for visualization of PDM information in PDA’s. Powerful and user-friendly search functionality is required. A PDA application will be integrated with a complex system and therefore simplicity is also required. It is recommended to give priority to the most important information. If a view consists of a large amount of necessary information, the developer should probably try to divide the information into several views. Object names and titles should be kept short. Perhaps it is proper to give the objects in the eMatrix database a “PDA-title” attribute. Furthermore, table size should be set to about ten pixels smaller than the screen width in order to get a distinct border between the content and the hardware. When it comes to system architecture, there are three major ways to develop a service or application for PDA integration with a PDM system:

- Thin client – online connection - Thick client – PC synchronization - Combination of thin and thick client

When designing for a multiplicity of PDA appearances, a middle server will know what device that connects and adjust the interface accordingly. A middle server is most often placed between an internal and an external network and will replicate the external network as if it was a workstation on the external network. The most common problems and challenges when it comes to hardware and software PDA issues seem to be the lack of PDA standards and slow networks.

- Development of a demonstration application with limited functionality One would like to predict the performance for a PDA connected to the PDM system. However, such a PDM application will be a mission-critical feature. Thus, as the sole means of predicting performance in a mobile PDM environment the developed demonstration application is almost useless. The conclusions of the results related to this goal cannot be conclusive, as the demonstration application has limited functionality. However, the projection of the representative processes in the emulator confirmed that developing a graphical user interface for a PDA is a challenging experience.

43

10. Future work

Mobile technologies play an important role to create and organize effective fluid work environments, but extending that role to be a part of the PDM system will probably take a few years. According to the results of this thesis there are primarily other issues that are more important to the Technia customers. However, some kind of mobile access to PDM information will become a requirement when faster networks and overall PDA standards are introduced to the market. Thus, it is appropriate to be prepared for the future customer desires.

Technia has great experience in developing and delivering Internet based Business Collaboration Solutions. There is probably enough knowledge in the company when it comes to system development of mobile PDM solutions. It is recommended to consider some issues when planning and preparing for mobile features.

Derived from the visionary interviews, it is obvious that generally there is a conceptual model of PDM information in PDA’s that is more information oriented than process oriented. Though, processes should not be viewed at in a general way. There might be some need for specific PDA processes when dealing with PDM systems. Such processes must clearly match the existing PDM workflows and must not exclude important processes. It is also important to clearly define customer desires and needs when it comes to system architecture and multiplicity of PDA appearances. There are currently not any general PDA standards and the solution should be applicable for different hardware devices. If the customer requires a specific solution, it is possible that the solution will include hardware issues along with the software architecture issues. There is a convergence of information processing and communication that could include a communicative scenario where users discuss on shared issues. This scenario requires technologies and tools for terminal alert and bi-directional messaging. It is therefore appropriate to investigate and evaluate such tools. When it comes to graphical user interface it is appropriate to consider the rules of thumb employed in the previous part. Primarily, it is recommended to give priority to the most important information. Invisible technology and easy user control of PDM information in PDA’s are also desired. Considering development investigation there is obviously more work to be done since the demonstration application was not very advanced. An important issue is to investigate the functionality for selecting and downloading information from the PDM system to a PDA.

44

11. References

[1] Andersson P., 2002, Nokia Communicator (in Swedish), www.handdator.com (last visited 15 March 2002)

[2] Björk S., 2000, A web browser for small terminals, www.viktoria.se/~bjork (last visited 5 February 2002) [3] Björk S., Hierarchical Flip Zooming, www.viktoria.se/~bjork (last visited t 5 February 2002) [4] Collaborative Product Definition Management, 2001, www.cimdata.com, (last visited 28 March 2002) [5] Creating a mobilized business, 1999, Oracle white paper, www.oracle.com/mobile (accepted 30 March 2002)

[6] Designing websites for Pocket PC, 2001, Microsoft white paper, www.microsoft.com/mobile/pocketpc (last visited 15 February 2002) [7] Dix A., 1999, Places to stay on the move, www.hiraeth.com/alan (last visited 30 March 2002) [8] Engström A., 2002, Från äpplet föll Newton (in Swedish), www.m3.idg.se (last visited 20 March 2002) [9] Fleming J., 1999, Conducting and using usability test, www.ahref.com/guide (last visited 30 March 2002) [10] Fleming J., 1999, Deciding which type of test to conduct, www.ahref.com/guide, (last visited 30 March 2002) [11] Fuccella J., 1999, Finding out what users want, www-106.ibm.com/developerworks/library (last visited 20 March 2002) [12] Fuccella J., 1999, Techniques for gathering requirements and tasks, www-106.ibm.com/developerworks/library (last visited 20 March 2002) [13] Hoyoung K., 2002, An empirical study of use contexts and usability problems in Mobile Internet, www.hicss.hawaii.edu (last visited 1 February 2002) [14] Hultqvist, J., 2002, 3G i Europa (in Swedish), www.computersweden.se (last visited 14 March 2002) [15] Hölj M., 2002, The mobile office, www.computersweden.se (last visited 26 February 2002) [16] Ince D., 2002, Developing distributed and e-commerce applications, Pearson Education, Essex, England [17] Jacobsen J., 1993, Interview, Hans Reitzels Forlag, Copenhagen, Denmark, pp. 100-120

45

[18] Kakihara M., 2002, An extended perspective, www.ls.ac.uk (last visited 4 April 2002) [19] Lövgren P., 2001, Surfa i din telefon (in Swedish), www.mikrodatorn.se (last visited 25 March 2002) [20] Nielsen J., 2001, Make it usable, www.zdnet.com (last visited 25 March 2002) [21] Roth J., 2001, Patterns of mobile interaction, www.cs.strath.ac.uk/~mdd/mobilehci (last visited 1 March 2002) [22] Tidwell J., 1999, Common ground, www.mit.edu/~jtidwell (last visited 1 February 2002)

[23] Ullman D., 1997, The mechanical design process, McGraw-Hill, Oregon, USA, pp. 2-13

[24] Web Clipping developers guide, 2000, Palm white paper, www.palm.com/developers (last visited 10 February 2002)

[25] White, J.E., 1998, Mobile agents, appeared in Wheeler, R., 1999, Mobility, Addison-Wesley, Reading, USA

[26] Yakobowicz E., 2002, Drive people wireless, www.pocketnow.com (last visited 1 March 2002) [27] Åsblom J., 2002, Handdatorer med inbyggda telefoner (in Swedish), www.computersweden.se (last visited 19 February 2002)

46

Appendix

1. Interview schedule 47 2. Scenario building schedule 49 3. Scenario building mock-ups 50 4. Tag support in Pocket Internet Explorer 52 5. Prototype information hierarchy 53 6. Prototype test schedule 54 7. Demonstration application request/response 55

47

Appendix 1 – Interview schedule

Formality and scope -Information on the objective, what are supposed to be discussed and what are the expectations. The purpose is to get aspects, ideas and visions on services and interface for PDM information in PDA’s. -Information/Ask on tape recording -Information on confidentiality and anonymity in the presentation of the interview results -Information on the respondents right to set restrictions considering the material to be presented -Information on the disposition of the interview: Exploratory and open-ended questions where the answers or the discussion have no restraints. The idea is to have more of an open discussion than an interview. PDM -Can you give an overview of what you think PDM does for your company? What concurrent benefits does involve? -What are the most common problems/challenges with PDM in the beginning before the employees has got any PDM awareness of PDM and integrated processes and methodology? -Can you give an overview of your visions of the future development of your PDM system and integrated processes and methodology? PDA, Personal Digital Assistant -PDA is defined as a handheld palm sized computer such as the Palm and iPaq PDA’s. -Do you use PDA yourself? In what purpose and scope? -What advantages do you see with a PDA due to other alternatives? -Do you have any problems or do you see any problems with the usability, the graphic user interface and limited input devices by way of example? PDA intergration with PDM system -If you think of your own work situation with a PDA, how would it look like with PDA integration with a PDM system? -What PDM information would you like to have access to with a PDA? -What advantages and possibilities could PDA integration with the PDM system involve for the collaboration and communication within and among different levels in the company? -What advantages and possibilities could PDA integration with the PDM-system involve for the customer relations?

48

Hypothetic guidance: -Would there be any field of application for Customer Relation Management, CRM? -Would it be valuable to build some contact network with shared lists of customer contacts? -What advantages and possibilities could PDA integration with the PDM system involve for the sales department? Hypothetic guidance: -Would there be any field of application for access to delivery time, Bill of Materials, price information etcetera? -What advantages and possibilities could PDA integration with the PDM system involve for the product development and concurrent engineering? Hypothetic guidance: -Would there be any field of application for parts, Bill of Materials and management of drawings? -What advantages and possibilities could PDA integration with the PDM system involve for document management? Hypothetic guidance: -Would there be any field of application for access, organization and document status? -What advantages and possibilities could PDA integration with the PDM system involve for integrated business and management systems, resource planning by way of example? -What advantages and possibilities could PDA-integration with the PDM-system involve for project management and project guidance? Hypothetic guidance: -Would there be any field of application for real time project management? -Would there be any field of application for real time planning and execution of projects? -Would there be any advantages in integrating/synchronizing typical PDA services as time schedule, calendar, to-do-list, network of contacts as lists of telephone numbers and email addresses (upload to the PDM-system/download to the PDA)? -Would there be any advantages in sharing/synchronizing a private domain involving the PDM-system and PDA with search results, lists of sets of objects and connected documents? -Which persons in the company should primary get access to mobile PDM and PDA? -What do you think about online vs. offline PDA browsing in PDM information? -Do you believe in a PDA integration, or application, with a PDM system? Graphic User Interface -What do you think a good graphic user interface is when it comes to usability?

49

Appendix 2 – Scenario building schedule

Formality and scope -Inform the respondent on the purpose of the interview, what is to be discussed and what is the expected interview result -Inform the respondent on anonymity in the presentation of the results -Inform the respondent on the character of the interview Scenario building -The scenarios are supposed to be presented in a service where users will interact with PDM information in a PDA. The screen used will have the size of 240X320 pixels (show picture of PDA, appendix XX). -These issues are supposed to be considered during the scenario building session: Limited input device Overview Main navigation components Views – one or more at a time? Links – icons or text? -Scenario 1, 2, 3 -How would you know the goal is accomplished? -Describe as detailed as possible the steps you expect to walk through to accomplish the goal of the browsing session. What links, text fields and buttons do you expect? Where on the screen do you expect to find those components? How many steps and views do you walk through? Be as specific as possible when you describe your browsing session. -Scenarios: 1. Tasks including deadline and status. Suppose you need to view your tasks structured in a PDM system in your PDA. How would you like to overview them? 2. Product catalogue. Set with objects and related documents. Suppose you are able to view a product catalogue in your PDA. Navigate from index page to a object that represents a specific product and view an attribute list for the product. Also, consider search functionality. How is it visualized and how do you use it? 3. Communication on a shared issue. Suppose you have been alerted with a shared issue in your PDA, for instance an Equipment Change Order, ECO. How would you proceed to view the issue and discuss on it wireless with your colleagues?

50

Appendix 3 – Examples of scenario building mock-ups

51

Appendix 4 – Tags support by Pocket Internet Explorer

This table lists the HTML tags supported by Pocket Internet Explorer versions 1.0, 1.1, 2.0, and 3.0.

HTML tag Version 1.0 Version 1.1 Version 2.0 Version 3.0 ------------------------------------------------------------------ A Yes Yes Yes Yes ADDRESS Yes Yes Yes Yes APPLET No No No No AREA Yes Yes Yes Yes B Yes Yes Yes Yes BASE No Yes Yes Yes BASEFONT Yes Yes Yes Yes BGSOUND Yes Yes Yes Yes BIG Yes Yes Yes Yes BLINK No No No No BLOCKQUOTE Yes Yes Yes Yes BODY Yes Yes Yes Yes BR Yes Yes Yes Yes CAPTION Yes Yes Yes Yes CENTER Yes Yes Yes Yes CITE Yes Yes Yes Yes CODE Yes Yes Yes Yes COMMENT No No No Yes DD Yes Yes Yes Yes DFN Yes Yes Yes Yes DIR Yes Yes Yes Yes DIV Yes Yes Yes Yes DL Yes Yes Yes Yes DT Yes Yes Yes Yes EM Yes Yes Yes Yes FONT Yes Yes Yes Yes FORM Yes Yes Yes Yes FRAME No No Yes Yes FRAMESET No No Yes Yes Hn Yes Yes Yes Yes HEAD Yes Yes Yes Yes HR Yes Yes Yes Yes HTML Yes Yes Yes Yes I Yes Yes Yes Yes IMG Yes Yes Yes Yes INPUT Yes Yes Yes Yes ISINDEX No No No No KBD Yes Yes Yes Yes LI Yes Yes Yes Yes LINK No No No No MAP Yes Yes Yes Yes MARQUEE No No No No MENU Yes Yes Yes Yes META Yes Yes Yes Yes NEXTID Yes Yes Yes Yes NOBR Yes Yes Yes Yes NOFRAMES No No Yes Yes NOSCRIPT No No No Yes OBJECT No No No No OL Yes Yes Yes Yes OPTION Yes Yes Yes Yes P Yes Yes Yes Yes

52

PARAM No No Yes Yes PLAINTEXT Yes Yes Yes Yes PRE Yes Yes Yes Yes S Yes Yes Yes Yes SAMP Yes Yes Yes Yes SCRIPT No No No Yes SELECT Yes Yes Yes Yes SMALL Yes Yes Yes Yes STRIKE Yes Yes Yes Yes STRONG Yes Yes Yes Yes STYLE No No No No SUB Yes Yes Yes Yes SUP Yes Yes Yes Yes TABLE Yes Yes Yes Yes TD Yes Yes Yes Yes TEXTAREA Yes Yes Yes Yes TH Yes Yes Yes Yes TITLE Yes Yes Yes Yes TR Yes Yes Yes Yes TT Yes Yes Yes Yes U Yes Yes Yes Yes UL Yes Yes Yes Yes VAR Yes Yes Yes Yes WBR Yes Yes Yes Yes XMP Yes Yes Yes Yes

53

Appendix 5 – Prototype information hierarchy

54

Appendix 6 – Prototype test schedule

Formality and scope -Inform the respondent on the purpose of the interview, what is to be discussed and what is the character of the expected result -Inform the respondent on anonymity in the presentation of the results -Inform the respondent on the character of the test Prototype test -In the prototype a service where users will interact with PDM information in a PDA. -Describe as detailed as possible the steps you expect to walk through to accomplish the goal of the browsing session. What links, text fields and buttons do you expect? Where on the screen do you expect to find those components? Be as specific as possible when you describe your browsing session. -Scenarios: 1. Tasks including deadline and status. Suppose you need to view your tasks in the PDA? 2. Product catalogue, set with objects and related documents. Suppose you are able to view a product catalogue in your PDA. Navigate from index page to an object that represents a specific product and view an attribute list for the product. Also, consider the search functionality. 3. Communication on a shared issue. Suppose you have been alerted with a shared issue in your PDA, for instance an Engineering Change Order, ECO. Proceed to view the issue and discuss on it wireless with your colleagues? -Follow-up questions: -How did you feel about the graphic user interface? -How did you feel about the information architecture? -Were the paths you chose efficient enough? -What words, icons and links did you look for that were not on the prototype layout?

55

Appendix 7 – Demonstration application request/response