A further development of MONGO - NTNU report contains the documentation of the project “A further development of MONGO ... (MONGO) 2 Chapter 1 Introduction ... research project supported

A further development of MONGO

SIF8094 Systemutvikling, fordypningsemne

NTNU, November 2002

Bernt Skjemstad

A further development of the MObile Nagging Geek Organizer (MONGO)

ii

Abstract This assignment is a continuance of a diploma thesis by Øystein Hoftun (spring 2002) [B1]. A software prototype, the MObile Nagging Geek Organizer (MONGO), has been developed. This assignment has been to evaluate this prototype, and then to suggest possible improvements. The convergence of a number of technologies is creating the opportunity to provide remarkable services in the future. Mobile is already considered to be the next big thing. Everyone is supposed to perform their work from everywhere, and whenever they want to, and the technology to support this is available today. One problem however, is connecting the different technologies together, in what is to be considered a highly advanced and heterogeneous environment. The background of this project tells a story of an IT-support department with some problems managing the tasks they are supposed to perform. Their daily work conisists of fixing problems reported by the users of the computers on campus. Some of the problems are end reports not always being written, and tasks “disappearing” in the big amount of registered problems. An important issue is to organize and manage efficient to-do lists for the service personnel, and the time spent on doing this increases with the amount of registered problems. Without an effective method of managing these lists on the move, important issues may be ignored and forgotten. MONGO is developed to solve these problems. The initial objective of this project has been to test and evaluate the developed system, with the help of service personnel working at the IT-support department. Advantages and disadvantages has been thoroughly noted, and the focus has mainly been on a heterogeneous environment. The second objective has been to suggest improvements for the system. This includes thinking of how to solve some of the found and known problems, making a preliminary design in order support future development.

Is MONGO a good and useful solution?

The results show many areas with room for improvement; among them are suggestions of a design profile, support for new kinds of technology, fixing flaws in the existing code and changing the way of communicating with the users reporting their problems. Some of them are more complex than others, but they could all be improved in some way or another.


iii

Preface This report contains the documentation of the project “A further development of MONGO” with the background in the course “SIF8094 Fordypningsemne Systemutvikling” at the Department of Computer and Information Science, at the Norwegian University of Science and Technology, during autumn 2002. This course is part of the 9th semester in the Master of Science degree. The student responsible for this report is Bernt Skjemstad. I would like to take this opportunity to thank my supervisors, Doctor Alf Inge Wang and PhD Fellow Carl-Fredrik Sørensen, for an intriguing problem description and for helping me with both practical and theoretical guidance. I would also like to thank the helpful people at the IT-support department for participating during the test phase.

Trondheim, november 2002

__________________________ Bernt Skjemstad


iv

Table of contents

Abstract................................................................................................................................ ii Preface................................................................................................................................. iii Table of contents ................................................................................................................ iv List of figures...................................................................................................................... vi

PART 1: INTRODUCTION .........................................................................................1 Chapter 1 Introduction....................................................................................................... 2

1.1 MOWAHS....................................................................................................................................2 1.1.1 The ICT-2010 program........................................................................................................2 1.1.2 MOWAHS (Mobile Work Across Heterogenous Systems) ...............................................2

1.2 Motivation ....................................................................................................................................3 1.3 Problem statement........................................................................................................................4 1.4 Report outline...............................................................................................................................4

PART 2: PRESTUDY ...................................................................................................6 Chapter 2 The story behind MONGO .............................................................................. 7

2.1 The scenario .................................................................................................................................7 2.2 RUST............................................................................................................................................7 2.3 Task Reporting System................................................................................................................8 2.4 The chosen solution ...................................................................................................................10

Chapter 3 MONGO .......................................................................................................... 11 3.1 The technology...........................................................................................................................11

3.1.1 Server technology ..............................................................................................................11 3.1.2 Client technology ...............................................................................................................11 3.1.3 Data presentation and representation.................................................................................12 3.1.4 The database.......................................................................................................................13 3.1.5 Other software....................................................................................................................13

3.2 The architecture..........................................................................................................................13 3.2.1 The MVC pattern ...............................................................................................................13 3.2.2 The MVC pattern in MONGO...........................................................................................14 3.2.3 Three tiered architecture ....................................................................................................15

3.3 Description and use....................................................................................................................16 3.3.1 Functional requirements.....................................................................................................16 3.3.2 Non-functional requirements .............................................................................................17 3.3.3 The different use cases.......................................................................................................18 3.3.4 MONGO in practice – the Web solution...........................................................................20 3.3.5 MONGO in practice – the PDA solution ..........................................................................23 3.3.6 MONGO in practice – the WAP solution..........................................................................26

PART 3: OWN CONTRIBUTION .............................................................................27 Chapter 4 Evaluating MONGO....................................................................................... 28

4.1 The test .......................................................................................................................................28 4.1.1 Why and who .....................................................................................................................28 4.1.2 Equipment ..........................................................................................................................28 4.1.3 The cases ............................................................................................................................29 4.1.4 Installing and preparing .....................................................................................................30 4.1.5 Execution............................................................................................................................30


v

4.2 The evaluation scheme...............................................................................................................31 4.3 The results ..................................................................................................................................33

4.3.1 Portable keyboard ..............................................................................................................33 4.3.2 Invisible editing..................................................................................................................33 4.3.3 Lack of confirmation..........................................................................................................34 4.3.4 Random order.....................................................................................................................34 4.3.5 Central UNIX.....................................................................................................................34

4.4 Test conclusions.........................................................................................................................34 Chapter 5 Preliminary design .......................................................................................... 36

5.1 Layout.........................................................................................................................................36 5.1.1 Fix flaws.............................................................................................................................36 5.1.2 A design profile..................................................................................................................37

5.2 Removing staff/queue ................................................................................................................37 5.3 Email support .............................................................................................................................38 5.4 Combi device .............................................................................................................................38

5.4.1 Implementing – new servlets .............................................................................................39 5.5 Invisible editing..........................................................................................................................40 5.6 Lack of confirmation..................................................................................................................40 5.7 Random order.............................................................................................................................40

Chapter 6 Anytime, anywhere – a wireless future? ....................................................... 42

PART 4: CONCLUSION............................................................................................44 Chapter 7 Conclusion ....................................................................................................... 45

7.1 Conclusion..................................................................................................................................45 7.2 Suggestions for future work.......................................................................................................45 7.3 Personal experiences..................................................................................................................46

Chapter 8 References........................................................................................................ 47 Chapter 9 Glossary ........................................................................................................... 49


vi

List of figures Figur 1. The three-tier architecture used in the Task Reporting System ...........................................9 Figur 2. A combi device...........................................................................................................................12 Figur 3. General MVC pattern, components and interactions...........................................................14 Figur 4. The MVC pattern used in MONGO .......................................................................................15 Figur 5. The three tiers of MONGO......................................................................................................16 Figur 6. The TaskInitiator use case diagram .......................................................................................18 Figur 7. The TaskExecutor use case diagram ......................................................................................19 Figur 8. The TaskAdministrator use case diagram .............................................................................19 Figur 9. Web - the start page..................................................................................................................21 Figur 10. Web - the login page ...............................................................................................................21 Figur 11. Web – the registered tasks page ............................................................................................22 Figur 12. Web – the page for resolving a task ......................................................................................23 Figur 13. PDA - start page ......................................................................................................................24 Figur 14. PDA - the page for adding a task ..........................................................................................24 Figur 15. PDA - synchronization message ............................................................................................25 Figur 16. PDA - task details....................................................................................................................25 Figur 17. WAP - the login page ..............................................................................................................26 Figur 18. Compaq iPAQ .........................................................................................................................28 Figur 19. Palm Vx ....................................................................................................................................29 Figur 20. Palm with a portable keyboard .............................................................................................29 Figur 21. Setting up equipment at the office ........................................................................................30 Figur 22. Working on location ...............................................................................................................31 Figur 23. An example of a combi device - the Treo 180 ......................................................................39 Figur 24. Wireless possibilities ...............................................................................................................42


1

PART 1: INTRODUCTION The introduction contains one chapter. Chapter 1 presents the motivation and context for the project, as well as the problem

statement. An outline of the report is also introduced.


2

Chapter 1 Introduction This chapter introduces the context of the project, including a survey of the superior project, MOWAHS. My motivation for this thesis follows next, and the problem statement is discussed. The chapter concludes with an outline for the report.

1.1 MOWAHS

MONGO is a part of MOWAHS, a project taking place at IDI. MOWAHS is a basic research project supported by the Norwegian Research Council through its ICT-2010 program [R3]

1.1.1 The ICT-2010 program The “Norvegian Research Council” gives advise regarding research and political questions, in addition to managing about 4 billion NOK for research purposes. One of the divisions is the division for science and technology, and this is where we find the program for basic ICT research. The program offers support within communications technology, distributed systems and large information and software systems. The program has got a duration from the year 2000 to 2007, and it’s main goal is to produce and make available new knowledge within these areas of research.

1.1.2 MOWAHS (Mobile Work Across Heterogenous Systems) With the enormous growth within mobile computing which is expected the next years, the research environment must see its responsibility. The infrastructure and tools for carrying out projects in virtual organizations are immature. Mobility of devices combined with the partial lack of connectivity will require regular synchronization of such devices against PCs and stationary servers. A big research challenge is to provide both an efficient and user-friendly environment, making it easy to work using these technologies. MOWAHS is going to last for four years, starting in 2001. The project has its root in an earlier project at IDI called Cooperative Agents in a Global Informationa Space (CAGIS), which had an overall objective to offer a generic platform for example given concurrent engineering [R12]. The budget of MOWAHS is 5,0 million NOK, two postdocs and two PhD-students. The project is carried out jointly by the IDI’s groups for software engineering and database technology, and it is split up in two different parts: Process support for mobile users using heterogeneous devices (PC, PDA, mobile phones) and support for cooperating transactions/workspaces holding work documents. This assignment, MONGO, will relate to the first of these two segments. The threefold superior goals of the MOWAHS project are:


3

1. Helping to understand and to continuously assess and improve workprocesses

in virtual organizations 2. Providing a flexible, common work environment to execute and share real

workprocesses and their artifacts, applicable on a variety of electronic devices (from big servers to small PDAs).

3. Disseminating the results to colleagues, students, companies, and the community at large.

This means that the focus of the MOWAHS project is to investigate how to provide process support for mobile work, using different equipment as WAP phones, PDAs and desktop PCs. The subordinated MONGO project is a result of goal number two in the superior goals stated above. It strives to provide a highly flexible work environment, applicable for a variety of different devices, and ready for including the technologies belonging to the future. It is meant as a replacement for the rather outdated RUST system, which is currently used at the IT-support department.

1.2 Motivation

The IT-support department at the university is responsible for maintaining the computer park at campus, considering both hardware and software. They implement changes that reflect both the current situation and the future growth estimates. Everyone at the university can report their problems to this department, in which case they will try to fix it. Today, the big problem is that the amount of reported problems is beginning to get out of hand. The IT-support department is not capable of handling this many problems at the same time, and the consequence is tasks disappearing in the system, and people having to fight for their attention. Because of the IT-support employees not reporting properly at the end of every case, changing the state of registered problems and writing end reports, the department does not have a good or up to date knowledge database. MONGO is developed in order to be a solution for the IT-support department. Tasks can be solved and finished all over campus, instead of having the personnel going back to their office after each completed task, just to complete their report and change the state of the task. Now they are able to use a PDA or WAP-phone, and then move on to the next assignment, preferable the nearest one. If the service personnel working for the IT-support department can access the system through mobile devices, the work can be done at the location of the problems. When this is a useful reality, much of their current problems are solved. It is therefore a big motivation factor to be able to provide something that could help others, and at the same time learn something about exciting new technologies. In addition to being a useful solution for an existing problem, it is also interesting when regarding the mobile revolution. This has become quite a hot topic the last couple of years, and it still is. When writing this report, the latest is a wireless LAN network covering Gardermoen airport in Oslo. It seems like an increasing number of sites is covered by such networks, and a lot of people becomes owners of PDAs,


4

powerful laptop computers and combi devices (a mixture between a PDA and a WAP phone). No one can no longer say that they can not be reached, or that they can not perform their work from where they are located at the moment. The big challenge which follows this new techology and this new way of thinking, is how to make this easy and understandable for the common man. One thing is the technology being ready, but another is if anyone understands how to use it. It is not a matter of course making a desktop computer cooperate with a WAP phone or PDA, or even a laptop computer. Someone will have to make this heterogenous environment work. This is probably the most interesting aspect working on this project; trying to make e.g. a PDA communicate effortlessly with an application on the network at campus.

1.3 Problem statement

The original statement goes as follows: “This thesis is a continuance of a diploma thesis, where a prototype of a

system for handling tasks related to mobile IT-support was developed. The thesis is about further developing this system, making it easier for the IT-support department to perform and report its work, with the help of mobile equipment; example given PDA or WAP phones. The candidate should test the system in practical use (with the help of personnel from the IT-support department), in order to be able to evaluate the system, and its value of use. The candidate should then propose changes and improvements, for making the system better, and eventually implement the changes.”

This was the starting point for this project, and two objectives or goals where stated:

1. The first objective of this project is to test and evaluate the developed system, with the help of service personnel working at the IT-support department.

2. The second objective is to suggest improvements for the system. This includes thinking of how to solve some of the found and known problems, making a preliminary design in order support future development.

In addition to these statements, a lot of time has been spent getting to know the background and structure of the already developed prototype of MONGO.

1.4 Report outline

The report consists of four parts: Introduction Prestudy Own contribution Conclusion

This part, the introduction, includes the motivation for the project, the context and background of MONGO, and a problem statement.


5

The prestudy contains two chapters. The first one tells about what has been done up until the prototype of MONGO was finished. This includes the current system at the IT-support department, RUST, and the predecessor of MONGO, the Task Reporting System. Chapter three is about the developed prototype, the technology and the used architecture, ending with a description and a survey of how to use the system. Part three, the own contribution, consists of three chapters. Chapter four is about the testing of MONGO. This includes the preparations, the actual test, and the results. This resulted in chapter five, which includes the most important suggestions for future work, and on some of them a preliminary design. Chapter six is a scenario describing a wireless and connected future, which may be the road where MONGO will have to be in the years to come. The last part includes the conclusion, some personal experiences, references and a glossary.


6

PART 2: PRESTUDY The prestudy consists of two chapters. Chapter 2 tells about what has been done up until the prototype of MONGO was

finished. This includes the system currently in use at the IT-support department, RUST, and the predecessor to MONGO, the Task Reporting System.

Chapter 3 is about the developed prototype, and its technology and architecture. The

chapter concludes with a description and a survey of how to use the system.


7

Chapter 2 The story behind MONGO Today the IT-support department uses a system called RUST (Request, Users, and Sys-admin To-do Ticket System). MONGO is based on both a scenario from this department and the functionality offered by this system. MONGO offers the same functionality as RUST, but adds support for a mobile heterogeneous environment.

2.1 The scenario

MONGO and the preceding solutions are all based on a scenario from the IT-support department at NTNU, and on the original functionality offered by the RUST system (see details in section 2.2). The IT-support department has a lot of responsibilites; among them are implementing changes to reflect current and future growth estimates, installing new hardware, installing and maintaining computer labs, managing user reported problems, maintaining and upgrading the different software used, as well as taking care of the administrative items needed to keep the networks going. They currently use a slightly customized version of RUST, which does not have any organizing and management tools providing support for mobile work. As the to-do lists and problem reports increase, so does the time required to organize and maintain them. Without an efficient method for managing these, also when moving around, issues could be ignored and forgotten. Another problem with todays system is to write a report when a task is completed. Tasks are normally resolved on some location, and when this is done the service personnel are supposed to write a few words about how they solved the task. This is meant for creating a powerful knowledge database over time. The problem is that the personnel often solve more than one task at a time when they are away from the office, and when they return some of the knowledge is bound to be forgotten. As a result of this, the database will not be updated with the required information, and an even less effective system is gained. If it was possible to access RUST on every location, this would not be a problem.

2.2 RUST

RUST [R4] was developed by Craig Ruefenacht during the years 1995-1996. His own background as a student, part-time operator and system programmer at the Computer Science computer facilit staff at the University of Utah made him see a lot of typical problems, and he wrote the following in his report as a background for developing RUST:

“E-mail is a tool commonly used to report problems on a network. In addition, problems are also reported in the hallway, on sticky notes stuck to doors, and over the phone. Without an effective way of managing these problem reports, some of the important problems go unaddressed for long


8

periods of time. The longer a request goes without being looked at, the higher the chance for it to be forgotten. This creates an unhealthy atmosphere for users, staff, and researchers.”

He points out that they have experienced several sites with similar problems, and without having a system for managing these issues, some of the reported problems are overlooked and sometimes end up in a black hole. A license for the RUST System is provided by the GNU Public License [R5], and it is freely distributed. The system can be downloaded via anonymous ftp [R6]. In 1997 the IT-support department at IDI started to use RUST. During the last five years they have made a lot of adjustements, and the source code is therefore partly not documented and confusing to understand. This is one of the reasons for MONGO not being only a further adjustement of RUST. RUST is a Web-based application, configurated to support the IT-support department in their work to maintain software and IT equipment. The users of the computers on campus can report their need for support or other problems to the department via this system, and the service personnel can then work with this. When working they can inquire the users for more information, trying to solve the tasks. The RUST system is also used to allocate service personnel to the different tasks. Three essential keywords for RUST are:

• Requests - Requests reported either from the users or the personnel working at the IT-department. The users send a request as a mail, while the IT personnel usually use a web form when reporting.

• Queues - The different kinds of requests are separated into the matching problem domains; example given win-nt or hardware. The RUST system consists of 18 different queues.

• Tickets - When a request is submitted to the system, and then assigned to a queue, it is called a ticket. A ticket includes different attributes; example given status, owner and subject.

RUST does not use a relational database format, but plain ASCII text files to store the data. Each ticket is associated with its own file, and each file contains the contents of the orignal ticket. New information is simply appended to this text file. The IT-department still uses RUST, despite its flaws, and it is of good help in their working day.

2.3 Task Reporting System

The Task Reporting System is a prototype based on RUST, which was implemented by Kenneth Aron C. Bjørkhaugen and Øystein Hoftun [B2] during autumn 2001. It is a system for handling management of tasks for mobile workers, based on the scenario from the IT-support department. The prototype provides adjusted functionality for WAP and PDA environment, as well as for the Web. The mobile support in the Task Reporting System gives the service personnel the opportunity to bring with them the


9

system on handheld devices, and they are able to update the task status and write small reports on the location when they finish a task. The Web solution is more extensive than both of the solutions for PDA and WAP, due to its screen size and general capabilities for writing and beeing online. The handheld units are mainly used for checking information and for the PDA you can also write example given end-reports and comments. The Task Reporting System is based on a three-tier architecture:

Figur 1. The three-tier architecture used in the Task Reporting System

The client tier consists of a Web or a WAP browser depending on what device is being used. For PCs, usual browsers, example given Internet Explorer, will provide the user interface. For a mobile phone this will be taken care of by a WAP browser, and for the PDAs it wil be the AvantGo Web browser. Java servlets are used to generate WML and HTML pages, and it is what the Web tier is all about. It detects the client types interacting with the system, and provides the correct client data based on the type of device beeing used. For small screens on handheld devices like PDAs, the HTML is adjusted to small screen. On WAP phones WML is used, and for PCs ordinary HTML is used. In the data tier the task information is stored as XML files, independent of the client type. This format was chosen because it is easy to transform into both WML and HTML, and probably also other formats which may come along in the future. It is also easy to change the definition of task information using XML.


10

2.4 The chosen solution

When deciding how to develop this new system in full scale, there were three alternatives:

• The extended Task Reporting System solution • The extended RUST solution • The zero solution

The zero solution is to access the existing web based RUST system using mobile devices. This was tested and found impossible to carry out in practice. This because of firewall problems, unadjusted HTML pages for smaller screens and RUST using the HTTPS protocol, not compatible with example given an iPAQ with a WLAN card, as this combination is supposed to access a Web page directly. The extended RUST solution is based on developing the system already in use even further. Both the HTTPS trouble and the firewall problem will still be an issue here, and the code of the system in use is messed up and therefore difficult to work with. There is little or no documentation of the changes made since the IT-department started to use and adjust it. A further development of this system will therefore be rather uncertain. The extended TRS solution was chosen as the better of the three alternatives. It was better to focus on implementing an own clean system, being more flexible and not locked to any premade system, than trying to patch up the old RUST system.


11

Chapter 3 MONGO MObile : The mobile devices supported by the functionality of the system Nagging Geek: The typical users that are always nagging until they get some help Organizer: The system organizes the requests The MONGO system was finally developed from the extended solution of the Task Reporting System, and it is supposed to offer the same functionality as RUST, together with the new mobile support. This is not entirely true, as a couple of functional requirements are still not implemented. It is not possible to remove a queue or a member of the staff with todays implementation. The communication with the users through email is supported for any email client in RUST, while in MONGO only email clients with the ability to view HTML inside emails are able to see the content of the email being generated by MONGO.

3.1 The technology

To implement and use MONGO, the following technologies have been used:

3.1.1 Server technology Tomcat [R7] is a servlet engine developed by the Apache Software Foundation. It can

also be used as a standalone Web server. Tomcat (version 3.2.4) is used both as a servlet container and as a standalone Web server in the MONGO system.

Servlets [R8] are Java technology's answer to CGI (Common Gateway Interface)

programming. They are programs that run on a Web server and build Web pages. The advantage of Java servlets over CGI applications is that they can execute more quickly. This is because rather than causing a separate program process to be created for each user, the requests are invoked as threads in a single daemon process, meaning that the amount of system overhead for each request is small.

Java Server Pages (JSP) [R8] is a technology that lets you mix regular, static HTML

with dynamically-generated HTML. It lets you control the content or appearance of Web pages through the use of servlets. During the execution the JSP file is interpreted and compiled into a servlet; the JSP file can then be run on the Web server.

3.1.2 Client technology


12

AvantGo, Inc. [R2] is a company providing mobile enterprise software. They deliver solutions for both wireless and offline use. Their mobile Internet service is a free service, providing personalized and interactive content as well as applications for handheld devices. In order to use these services, a channel has to be created on their Web site.

Wireless Application Protocol (WAP) [R9] is an open, global specification that

empowers mobile users with wireless devices to easily access and interact with information and services instantly.

Figur 2. A combi device

Mobile devices as WAP phones and PDAs are an essential part of the MONGO

system. During the last couple of years something called a combi device has been developed; this is both a PDA and a WAP phone. The combi device will have the advantages of both the PDA and WAP phone, and an own implementation for this kind of device could perhaps be an idea for further development.

3.1.3 Data presentation and representation Standard Generalized Markup Language (SGML) [R10] is a standard for defining

markup languages. Authors mark up their documents by representing structural, presentational, and semantic information alongside content. Each markup language defined in SGML is called an SGML application. HTML is one example of a markup language.

Extendible Markup Language (XML) [R10] is a simple and very flexible text format

derived from SGML. XML is simpler than SGML, but it has got most of the power. Tags are used as directives to the different applications reading XML files, and these tags describe what the data represents.

HyperText Markup Language (HTML) [R10] is a language for presenting pages on the

Web. It is made up of predefined tags which say something about how the data will be presented (nothing about what the data represents).

Wireless Markup Language (WML) [R10] is a mark-up language inherited from

HTML. A difference is that WML is based on XML, and it is much stricter than HTML. WML is used to create pages that can be displayed in a WAP browser on example given a WAP phone, or on other narrowband devices.


13

3.1.4 The database The data in RUST is stored as pure ASCII text files, while MONGO uses Microsoft Access 2000 as its relational database. The data is divided into seven tables:

• Task – contains all the tasks registered in the system • Staff – contains all the service personnel registered in the system • Queue – contains all the queues a task can be assigned to • Priority – contains the different priorities a task can be set to • Status – contains the different statuses a task can be set to • Config – contains the configuration data used for generating email • History – contains the registered history events attached to the tasks

3.1.5 Other software Java Software Developer Kit (1.3.1) has been used during the implementation. Java Servlet API (2.3) has been used during the implementation. The com.oreilly.servlet (cos-19Jun2001) [R11] package had been used for sending generated emails from the system.

3.2 The architecture

MONGO is built upon a Model-View Controller (MVC) architecture, which separates data presentation, data representation and application behaviour from each other. The architecture is further divided into a Client tier, a Web tier and a Data tier, just as the Task Reporting System was.

3.2.1 The MVC pattern This pattern is considered to be a pattern within the topic of graphical user interfaces on the list of architectural patterns [B3]. It consists of a model (abstraction), a view (presentation) and a controller (control), originally developed to map the traditional input, processing and output roles. The primary reason for using a pattern such as the MVC pattern is to improve maintainability and flexibility/modifiability, and this was two of the priorities when implementing MONGO from scratch. It was introduced already in the Smalltalk-80 programming language, and over time it has become a widely used pattern in designing user interfaces.


14

Figur 3. General MVC pattern, components and interactions

The figure above shows the three components, and the basic communication between them. The model is used to perform operations on and hold the data. It represents the state of a system or process. The model manages data elements, responds to queries about its state, and it responds to instructions to change state by updating the data and notifying its observers. The arrow pointing to the view allows it to send the view notifications of change, but it should not know anything about the kind of views that actually observe it; that is what I try to emphasize with the arrow being grey, not black. The controller is representing how the user interacts with the application. It interprets input from example given a mouse or a keyboard, and instructs the view and model to perform their respective actions based on this input. The controller knows the type of the two other components, therefore I have used black arrows. It actually has to know the types to be able to translate the user input into the correct application response. The view is the component presenting the data to the user. It does this through a combination of text and graphics. The black arrow that points towards the model component allows it to call any of the query functions this component provides, which is visible to the view. The grey arrow towards the controller indicates that it can call functions, but only those defined in the base class; this because you should be able to swap to another controller without to much trouble, keeping dependencies minimal.

3.2.2 The MVC pattern in MONGO When applying this pattern to MONGO, the thought was of an even broader use than the original intention of using it for graphical interfaces. The MVC pattern is here


15

used in a way that involves the complete application; all of the components in the system are part of either the model, view or controller. The primary reason to use this pattern in MONGO is to keep the system modifiable and extensible, making it easy to add other future clients when this comes along. When this happens you should be able to include the device by only implementing a view for presenting the data on the new client.

Figur 4. The MVC pattern used in MONGO

There are a lot of similarities with the general MVC pattern, but this spesific use does not notify views when it changes the state. The reason for this is that the information displayed to the user is static once it is received. The view queries the model for the data it needs, and sends events to the controller in reply to user interactions. It presents information to the user in the browser. The model holds all of the data used in MONGO, in addition to the business logic performed on them. The controller calls methods in the model in order to perform updates.

3.2.3 Three tiered architecture As told in this chapters introduction, the architecture is further divided into three tiers which describes the physical network configuration. When the application is deployed to the different nodes, the only thing to consider is how to distribute functionality among them; what are the connection between the nodes, and what are their respective processing capabilities. This partition also give the opportunity to choose the best suited technology for the given situations.


16

Figur 5. The three tiers of MONGO

The Client tier presents the data to the user and interacts with the user, and in MONGO there are three clients represented: WAP, PC and PDA. The WAP client uses WML pages, while the PC and PDA uses respectively HTML pages and HTML pages adjusted for small screens. These clients can be named thin clients as they limit them selves to view functionality, in contrast to the fat clients, which can include both controller and model functionality, referring to the MVC design. In the middle of the figure we find the Web tier. This tier is responsible for performing all of the Web-related prosessing, example given executing servlets or serving WML and HTML. The Web tier detects what kind of client that is interacting with the application, and provides the correct data for this device. These kind of tasks are carried out by the Tomcat servlet engine. At last the Data tier is used for storing the data. The Web tier gets access to the data by directly updating and retrieving from the Microsoft Access database. This database contains seven tables, and it represents a part of the model in the MVC design.

3.3 Description and use

The first part of this chapter will describe the functional and non-functional requirements of MONGO, while the second part will focus on MONGO in practical use, involving the different clients with a main focus on the Web and the PDA functionality.

3.3.1 Functional requirements There were originally seventeen specific functional requirements involved in the implementation of MONGO, but they are all a part of the more general requirements.


17

These are ment not to be directly related to the work processes in the IT-support department, but to say something about the superior goals of the functionality. The four general functional requirements are the following:

• Offer the same functionality as RUST MONGO should at least offer the same functionality as RUST, as it is supposed to be an upgrade from this system.

• Offer additional functionality Since MONGO is an upgrade, it must offer something more than RUST does. One example of such functionality is attaching a task to a spesific location and item by stating the respective information when a task is added.

• Offer mobile support Mobile support is an essential part of MONGO, and one requirement is to offer functionality on mobile devices, in addition to the Web.

• Offer adjusted functionality for the specific client type MONGO should offer different functionality for the different kinds of clients; example given PDA or WAP phones. This is important because of the different limitations on handheld devices, such as small screens and decreased input opportunities

3.3.2 Non-functional requirements A non-functional requirement is one that defines system properties and constraints [B5]. They can sometimes be more critical than functional requirements, so they are not to be taken easy upon. The non-functional requirements can be divided into technical factors and product factors. A technical factor is related to technologies used during the development of MONGO, and these are discussed elsewhere in this report. On the other hand a product factor is related directly to the qualities of the software product being developed. The requirements with the highest priority in MONGO are the following:

• Extensibility To achieve the possibility to extend the system without much effort, the project will be implemented using an object-oriented language. Extensibility has a strong relation with integrability, modifiability and reusability.

• Modifiability This refers to the possibility to make changes quickly and cost effective. Since this is a project being developed by different students over time, modifiability is a very important factor. The architecture should make it easy for other developers to make changes to the system

• Portability The ability to run the system in different computing environments without much effort is called portability [B6]. This is the top priority in this project


18

since support for mobile work requires computing on different mobile equipment; this is the main focus of MONGO.

• Usability Different attributes of usability are learnability, speed of operation, robustness, recoverability and adaptability [B5]. This is important for user interface systems because the satisfaction of the users relies on it. The user interface of MONGO should be efficient, but at the same time friendly and easy to understand.

Other non-functional requirements are reusability, maintainability, integrability, performance, persistence and security. These are also important, but not the ones which will have top priority in the development of MONGO.

3.3.3 The different use cases There are mainly three different actors in MONGO; these are the TaskAdministrator, the TaskInitiator and the TaskExecutor. An actor represents a role a user can play with respect to the system.

Figur 6. The TaskInitiator use case diagram

The TaskInitiator is the actor responsible for adding new tasks to the system. Both users of the data systems on campus and the service personnel working at the IT-support department can play the role of this actor. When someone from the service personnel reports a problem, they would take advantage of logging in on the Web, while the “ordinary users” send their problems by email. The task initiator is also able to respond on additional questions sent out via the system


19

Figur 7. The TaskExecutor use case diagram

The TaskExecutor is responsible for executing a task. This is a role that the personnel in the IT-support department can take, allocating time for solving a task. To become a TaskExecutor a service person has to have the ownership of an analyzed task; the service person can take the ownership of an unassigned task, he or she can steal the task from another service person or the task can be given from another service person. When the task is finished it is the TaskExecutors responsibility to resolve it, writing a final comment. It should be possible to perform the duties of a TaskExecutor from all kinds of supported devices, including both a WAP phone and a PDA.

Figur 8. The TaskAdministrator use case diagram


20

The TaskAdministrator is responsible for performing both system and task administration operations. This includes example given adding new service personnel and queues to the system. Another responsibility is to analyse the incoming tasks before they are assigned to TaskExecutors. Every personnel working for the IT-support department can play the role as TaskAdministrator. As mentioned earlier there has to be decreased functionality on a device like a WAP phone, due to its limitations in screen size, input possibilites and online capability. There will always be differences between a desktop computer and a PDA, but the big point is to take advantage of what the respective devices are good at – where do they perform well? MONGO provides different functionality on the different devices. This table shows what options are available on the respective client types: Included in Web solution Included in PDA solution Included in WAP solution

CommentTask CommentTask CommentTask GiveTask GiveTask GiveTask

OngoingTask OngoingTask OngoingTask ResolveTask ResolveTask ResolveTask RespondTask RespondTask RespondTask UntakeTask UntakeTask UntakeTask

AddTask AddTask - Login - Login

AddQueue - - AddStaff - -

ArchiveTask - - EditTask - - OpenTask - - StealTask - - TakeTask - -

3.3.4 MONGO in practice – the Web solution This section will give a brief introduction to using the Web solution of MONGO, and it is not ment to be a complete tour in any way. The intention is to show some of the possible Web pages, and describing the use of them as an example of using MONGO. The first page that will pop up when you open the Web solution of MONGO, is the start page. There will be three different options; the first two will be for adding a task, and the last one will be for task administration. The difference between the two for adding a task is that it separates between the users of the system, and the service personnel, the latter having a username and password to login with. The option at the bottom of the screen is only a possibility to test the adjusted PDA solution.


21

Figur 9. Web - the start page

If you choose one of the two options that require login, you will be taken to the login page. Both the Web and WAP solution supports this, while it is not required when using a PDA.

Figur 10. Web - the login page

When you are logged in as one of the service personnel, you can perform a lot of different operations. One of them is to view all the registered tasks in the system. The Web solution offers two ways of viewing the tasks; either viewing a list of all the registered tasks in a specific queue, or a complete list of all the registered tasks. In


22

contrast to the PDA and WAP solutions, the Web solution suits well for getting a good overview of such lists. To the left is the menu from which you can choose to add a new task, view the registered tasks or perform administration operations. You can also view the different tasks with respect to the different queues, or you can view the resolved or archived ones.

Figur 11. Web – the registered tasks page

When resolving a registered task you are supposed to write a final comment on how you solved the problem, so that this can be added to the database of solution suggestions for later use. You write your final comment in the text field displayed on the middle of the page, and then you push the “resolve” button to submit the changes. Below you can see the description of the current problem as well as the history of what has been done trying to solve it. As often you can find the menu on the left side, from which you can choose to add a new task, view the registered tasks or perform administration operations. You can also view the different tasks with respect to the different queues, or you can choose to view the resolved or archived ones.


23

Figur 12. Web – the page for resolving a task

These were just a few examples of the different Web pages in the MONGO system. The complete descriptions and listings are to be found in [B1].

3.3.5 MONGO in practice – the PDA solution This section, as the last one, will give only a brief introduction to using the PDA solution of MONGO, and it is not ment to be a complete tour in any way. The intention is to show some of the possible PDA pages, and describing the use of them. The complete description of the PDA opportunities is to be found in [B1]. Since a PDA is ment as a personal device, connected through a personal account at AvantGo [R2], the PDA solution does not include a login session. You will have to include the username in the URL for the MONGO start page when you create a MONGO channel at the AvantGo Web site (see section 4.1.4). The start page will therefore include two options; one for adding a task and one for displaying your registered tasks. The start menu will allready be adjusted to the service person which is registered on the current PDA.


24

Figur 13. PDA - start page

If you choose “Add task” you will be taken a new page where this can be performed. This will not be as easy to view as the Web solution, but you will be able to scroll down. The alternatives for adding the actual task are the same, the difference is that the layout is adjusted to the PDA environment. Due to the scrolling the figure below is divided into three screenshots.

Figur 14. PDA - the page for adding a task

When you are finished editing on the task you would like to add, you press the “add” button. If you change your mind you can press the “Reset” button to clear the page. After you have pressed the “add” button you will get a message from MONGO telling you that the information will be sent during the next Synchronization. You will not be able to view the submitted information before this synchronization with the current version of MONGO (see section 4.3.2).


25

Figur 15. PDA - synchronization message

As for the Web solution you can view a list of the registered tasks for the current service person. When you click on on of these you will be able to look at the details for the chosen task. The Web solution offers eleven actions that can be performed on a task, while the PDA and WAP solution offers six of these; Resolve, Comment, Respond, Give, Untake and Ongoing. As with every change you make on the PDA, this will also be updated to the rest of the system when the PDA is synchronized.

Figur 16. PDA - task details

This was just a couple of the functions demonstrated and illustrated, as it is not this sections intention to go in details. For a complete coverage on the topic, this is to be found in [B1].


26

3.3.6 MONGO in practice – the WAP solution

Figur 17. WAP - the login page

The WAP solution has not been the focus of this thesis, and this section will therefore not include any survey over how the solution works. It should be mentioned however, that the functionality for a WAP phone is limited, due to its poor ability to both receive input and display information on a small screen. But the solution will of course work as a small device, showing information for registered tasks. And it is possible to do almost everything which is possible on the solution for a PDA, just in a way that is somewhat more cumbersome. For spesific functions, see section 3.3.3.


27

PART 3: OWN CONTRIBUTION The own contribution part consists of three chapters. Chapter 4 is about the test phase, where the developed prototype of MONGO is put

to the test. This includes the preparations, the actual test, and the results. Chapter 5 includes the most important suggestions for future work. Some of the

sections include a preliminary design, to help with future development. Chapter 6 is a scenario describing a wireless and connected future, which may be the

road where MONGO will have to be in the years to come.


28

Chapter 4 Evaluating MONGO For any given evaluation, there is a range of possible approaches. One is to evaluate for the purpose of improvement, which is what this chapter will include. In order to know what we have to improve or include next, the system has to be evaluated in context of its probable use. Since we really don’t know who will be the users in the end, we chose to cooperate with some of the people who are working with the old system (RUST), at the IT-support department. This evaluation contains a practical part including working with handheld devices, and the participants also completed a questionnaire. The results are then analysed, pointing to the next chapter where some possible improvements are proposed.

4.1 The test

4.1.1 Why and who A main phase in this thesis is testing MONGO, finding weaknesses and problems. Of course we would also like to understand what good sides the system has, as well as to point out what issues we should work on when developing the system even further. At the moment MONGO is only a prototype, and there are probably some flaws to be discovered. When working on a project you are likely not to see your own errors, and therefore we have chosen to include external people to participate in this session. Since MONGO is built upon RUST, which the people at the IT-support department use at a daily basis, it was natural to ask someone working there. There were three external people included in the testing, all of them working at the IT-support department. They were men between 19 and 35 years old, and they had been working for the IT-support department for 1,5-5 years. Their daily work includes operating and maintaining the network and machines on campus. They all have prior experience with the RUST system. In addition to these three there also was myself and my two co-supervisors, guiding the test persons and also participating ourselves.

4.1.2 Equipment We provided the test persons with two different handheld devices;

Figur 18. Compaq iPAQ


29

• Compaq iPAQ H3800 Series Pocket PC, 64MB, with Microsoft Windows for Pocket PC 2002.

Figur 19. Palm Vx

• Palm Vx, 8MB, with Palm OS v3.5

The devices both had a synchronization program included, respectively ActiveSync 3.5 for the iPAQ and Hot sync for the Palm. They also came with docking stations. In addition we equipped the Palm with a portable keyboard, making it easier to provide input for those who are not used to the pen based input.

Figur 20. Palm with a portable keyboard

When performing the test we used the machines belonging to the test candidates for syncronizing the handheld devices and browsing the MONGO system. This was done because it was convenient, and the user then knew the environment except from the borrowed device.

4.1.3 The cases Before the testing could begin we added two tests to the database in MONGO. The cases were both real problems, but they were located at the same place, not by chance, in an office where we had an opportunity to watch while the test candidates were working. One case was for Windows (2000) and the other one was for UNIX. The reason for choosing these two operating systems was the fact that these are the two most familiar systems on campus. We wanted to test them both because problems on the UNIX operating system probably can be solved from a terminal, and not necessarily where the case actually is, while most problems in windows have to be solved where the problem is located. This is a point because our system is meant for solving problems where they are, not having to go back to write the report.


30

4.1.4 Installing and preparing To perform the test we added two test users to the MONGO database, named “Windows” and “Unix”. The cases for windows were going to be solved by the Windows user, while the Unix user was set up for the problems in UNIX. The test candidates got an introduction to MONGO and its background. They got to know what this test was all about, why they were the asked candidates, and what we expected from this test and them. This was done so that they had more background for actually doing their assigned task, and at the same time providing us with the information we were hoping to get. Installation of the software for the handheld devices also had to be done:

1. We installed programs (which came with the iPAQ/Palm) to be able to synchronize the handhelds with the desktop computers. These were “ActiveSync 3.5” for the iPAQ and “Hot sync” for the Palm.

2. We set up users at the AvantGo site [R2], for those who didn’t have their own user there already.

3. We added our own MONGO site to the AvantGo accounts, being able to include our system in the synhronization of the handheld devices. To add this site we used the adresse http://giotto.idi.ntnu.no:8080/mongo/servlet/LoginPDA?userName=testperson, which refers to the server MONGO was running on when this test was performed. “testperson” was replaced with either “Windows” or “Unix”.

4. We set up the correct test users, Windows or Unix, corresponding to their assignments in our system.

5. We synchronized the PDA’s, and began testing.

4.1.5 Execution When everything was set up and the candidates were prepared for their tasks, they set out to work with their respective cases. We, my two co-supervisors and myself, followed them around to observe reactions. We also helped them when they asked spesific questions regarding the use of the handhelds or MONGO.

Figur 21. Setting up equipment at the office

They used MONGO to take notes during their work, both to note what they had done and the questions they thought would be useful to look at later. We also gave one of


31

them an assignment during another case, just to see how he hopefully could handle this administrative task using MONGO.

Figur 22. Working on location

When they either solved their case, or had to do something else to be able to solve it, we concluded the session by going back to their own desktop computer and synchronizing the PDA. We also had a look in the MONGO database to see if the tasks they had been working on now where included with eventual additional comments. At last the participants had to spend some time filling out the evaluation scheme we had prepared; so that we were able to read the experiences they had using our prototype.

4.2 The evaluation scheme

To evaluate a system by making someone try it, will probably provide some practical information. But to be able to see what the test persons really thought of it, one should provide a test scheme. With this we could hope to read the personal thoughts of the test candidates about our system, both regarding the pratical use and the relevance to the real world. When making such a form, it is important to provide good and insightful questions. An evaluation will be of no use if the answers don’t give any useful information for further development. First it is essential to know the background of the persons participating in the test, to see if they correspond to the people who are actually going to use the system, both regarding experience with PDAs and general experience. It is important to develop for the actual target group. Our system is built on RUST, and their prior experience, or lack of experience, with this tool can be useful. We also wanted to know if they thought we have added useful functionality to the PDA version of MONGO, and if it was intuitive to use. We included every functionality in the hope that they commented on most of them. In the end we included a general section where they could write both general problems and positive comments, not restricting what they put down. This was done because we wanted the test persons to write freely what they really had on their minds, no matter what it was.


32

One point on which we could have improved was that the evaluation scheme could have been provided on the Internet. People working with computers are much more comfortable writing on a keyboard, not using a pen. Maybe we would have got more and better answers? A thought for future testing. The following questions were included: 1. About you 1.1 How old are you? ____ Years 1.2 Are you a man [ ] or a woman [ ]? 1.3 For how long have you been working at the IT-support department? ____ Years 1.4 Can you describe your work with just a few words? 1.5 Do you have any prior [ ] None experience with a PDA? [ ] Tried it once [ ] Used one for some time [ ] Used one for a long time; comfortable [ ] What I don’t know isn’t worth knowing 2. RUST 2.1 Do you have any prior experience with RUST, which is a system used at the

IT-support department? Yes [ ] No [ ] 2.2 (If yes at 2.1) Can you, with a few words, describe your impression of this

system as regards how useful it is in your daily work? 2.3 If you could have some changes done to RUST, what would they be? 3. Specific PDA functionality We would like you to write a comment under every task, commenting if you think the current feature is useful in any way – and why / why not. 3.1 Add task (add a new task) 3.2 See your registered tasks (see what tasks are registered to you) 3.2.1 Resolve (write a final comment, and the case is removed from the task list) 3.2.2 Comment (add a comment regarding the case) 3.2.3 Respond (respond to the person who reported the case)


33

3.2.4 Give (give the responsibility for the task to someone else) 3.2.5 Untake (deny the ownership of the case) 3.2.6 Ongoing (set the status to ongoing = a case in work) 4. Useful functionality Do you think the functionality for use on a PDA is good and something you probably would like to have in addition to RUST, or is this feature less useful? [ ] Absolutely. This is a big step in the right direction for mobile work. [ ] Some of it is useful, but some things would have to be adjusted [ ] The thought is good, but the way it’s done is not good [ ] Nothing of interest A further explanation of your choice can be written here: 5. General problems Did you run in to any problems while testing our system? If that is the case, please describe what you experienced here: 6. Positive comments We would love to have some positive comments on what parts of the system you liked, so we know what to keep when developing MONGO even further.

4.3 The results

The following points came up during the evaluation:

4.3.1 Portable keyboard Using a PDA is quite slow if you are not used to the pen-based input. One of the test persons was equipped with a portable keyboard, and that came in handy for more efficient working. Will this extra gadget work against the idea of being portable?

4.3.2 Invisible editing When you have used the function called “Add task”, and pushed “Add”, you can not work with this case before you have synchronized your PDA. This is the case both when you assign it to yourself and to others. This problem also occurs with everything else you do when you are outside your office; e.g. when you comment on a case, you


34

will not be able to see that particular comment before the next synchronization. The reason for this is that the new task is added to the buffer which will be included during the next synchronization, and it is not added directly to the MONGO system on the handheld device. This means that the additions are invisible to the system until the user synchronizes his or her PDA. Of course, this is a rather irritating problem when you wish to work with the task you just added, before you go to your office. There is a solution to this, namely accessing the buffer directly. But since this is not an obvious solution for the users of MONGO, it will probably be an idea to include this option in our system in some way, making it easy to use. This problem will only be a problem when you are not connected in any way to the network, and it will therefore vanish if the PDA uses a wireless LAN.

4.3.3 Lack of confirmation If you have been writing something somewhere in the system, you will finally press “ok” to submit changes. When this button is pressed everything blanks out, as in every field you have completed goes back to being blank again. This is not satisfactory since the user doesn’t know if the changes are saved or just forgotten. The system should either give you a confirmation that the new information has been saved, or you should be taken back to the main menu or wherever suitable. The best solution would probably be if you both got a message and was taken back to a menu.

4.3.4 Random order When the user gets back to the office and synchronizes the handheld device, every new editing is added to the MONGO system. During the test some of the participants did more than one change, and these were added to the system in the wrong order. The cases should probably have some kind of time stamp or some other solution, so that the new additions are added in the correct order.

4.3.5 Central UNIX People working on any kind of IT-support will have noticed a difference between Windows and UNIX when it comes to flexibility. When a problem is reported in the Windows operating system, someone will in most cases have to go to the actual site to fix it. But when this happens in UNIX, this can often be solved from a terminal machine sited at the office of someone working in the support departement. The point is that problems in UNIX not necessarily will take the advantage of a mobile system like MONGO, at least not as much as problems in Windows.

4.4 Test conclusions

The results from the test phase were as expected, but they included a couple of problems not foreseen before starting out. These are included in chapter five. We got to know what has to be done in order for MONGO to be of practical use for the people working at the IT-support department. They had some suggestions and proposals for further development, including a take on wireless LAN for the PDAs, as well as a wish for an improved user interface.


35

Now it is time to systematically analyse the results, focus on the most important and extreme discoveries, and making improvements. When the analyse is done, it could be an idea to discuss the result with the test personnel before actually doing any changes. This to get feedback if the right assumptions were made, and if the proposed alterations will make a positive difference. When new implementations are completed, a new test phase should be carried through, including both the same and new test personnel. The latter to get some new angles of view.


36

Chapter 5 Preliminary design This chapter tries to outline suggestions for how to solve some of the known problems of the MONGO system. Some solutions are more complicated than others, and some has got a better solution.

5.1 Layout

The diploma thesis by Hoftun [B1] did not have a high focus on layout or design for the Web, WAP or PDA solutions. It was therefore suggested as a topic for future work. During the testing (see chapter 4) we got to notice a difference in layout depending on what PDA was used, and the layout is overall rather simple. This is not necessary a bad thing, but a smart and easy layout is a rather big advantage when a system is to be presented for external people. This depends on the system below the fancy design being solid, but this should not be a problem for MONGO.

5.1.1 Fix flaws The PDA solution for MONGO was developed for a Palm Vx with a Palm OS. When we tested the system togheter with some of the service personnel at the IT-support department we also used a Compaq iPAQ with a Pocket PC 2000 operating system. What used to be a nice and structured table on the Palm now turned out to be a rather messy structure on the iPAQ.

Resolve Comment Respond

Give Untake Ongoing (on the Palm)

(on the iPAQ) There is more than enough space for a table like the leftmost one to be drawn also on the iPAQ, so that is not the problem. This is a result of the written HTML code, and it should be possible to write it in a way eliminating such problems. This was probably just one example of a “bug” in respect to how pages are displayed on different devices and operating systems. What happens if the number of queues on the left in the Web solution increases to a number that does not fit on the page? Do the problem regarding rows and columns apply to other devices as well? Has the layout been tested on Web browsers like Netscape or Opera, not to mention Mozilla or Grail? To conclude, the layout should be tested systematically on all the widespread devices and browsers there is, and the HTML/WML code should be looked through and written in a standarized way that does not give surprises like the unstructured table.

Resolve Comment Respond

Give Untake Ongoing


37

5.1.2 A design profile When browsing the Internet, one see a lot of different pages with regard to the colors and layout. This also applies to different programs, example given any program produced by the Windows Corporation. They use a lot of money making their programs look good. Why do they do this? So that customers will prefer buing something they made, and not some competitor product. But also to provide the best possible functionality combined with something that looks good. What is good design? That is a subject of discussion, and it is without any conclusive answers. But on some points most people seem to agree:

• Minimalism • Browser independence • Good spelling and good grammar

In order to develop any product, e.g. MONGO, two major activities have to be undertaken [B7]: The designer or developer has to understand the requirements of the product, and he or she must develop the product. Understanding the requirements involves looking at similar products, discussing the needs of the people who will use the product, and analysing any existing systems to be able to discover problems with the already developed designs. The most important of all design requirements is that the design really shows what the application is supposed to do. Just like a bottle of coca cola says “hold me”, the user interface in the MONGO system should be clear, distinct, and easy. But, this should not be on behalf of the actual functionality. So far MONGO has got a very functional layout, not far from satisfying the above points, but without any colors or logo making it personal. The pages are a bit messy, since they all look the same with respect to colors and general layout. The system will of course be able to perform what it is supposed to do without any fancy design, but it would not do any harm introducing an overall design profile for the system, with regard to fonts, colours, frames, logo, and so forth. The design profile could consist of four or five similar colors, e.g. shades of blue, with spesifications given in either html syntax (e.g. white = “FFFFFF”), or with respect to the three colors red, green and blue (with numbers ranging from 0 to 255). There could be a selection of fonts and headings specified, and a guideline for how the pages should look is a safe way to go. And, of course, MONGO should have its own unike logo made.

5.2 Removing staff/queue

As mentioned in the introduction to chapter three, it is not possible to remove a queue or a member of the staff with todays implementation. This is meant to be a part of the system, but it has just not been implemented yet.


38

Developing these features involves implementing some new servlets, example given RemoveTaskWebUser and RemoveTaskPDA. These servlets will have to communicate with a general RemoveTask servlet, which again must communicate with the database using the DatabaseAccess class. This should be rather uncomplicated to include in the next version of the system.

5.3 Email support

The primary limitation in MONGO compared to RUST is the one attached to the generated emails from the system, to the users of the data systems, notifying about tasks. The current version of MONGO sends out emails using a HTML format, and this means that only email clients being able to view HTML inside emails are able to reply through the attached HTML form sent from the system. At the university the major part of the users is using an email client named pine. This is a text based client which is not able to view HTML inside an email. When an email containing HTML code arrives, the client will display the actual HTML code, and not the HTML form for replaying additional information about the task back to MONGO. This limitation is enough for MONGO being rather useless in an environment where the majority of the users are using the Pine email client. If RUST is going to be replaced by MONGO on campus, it is necessary to solve this problem. There are only two ways to do this:

• MONGO have to support text based email clients • The Pine client will have to be replaced by an email client which supports

HTML code. The natural solution is to develop MONGO even further, to support email clients like Pine. It will be a step in the wrong direction if text based email clients restricts the ability for using MONGO. But to have MONGO support text based email clients is not an easy problem to solve. Today MONGO communicates only with the help of servlets, also when answering emails. Its predecessor, RUST, listens for email, sorting out what is sent for the involved areas. When it discovers email meant for RUST, they are stored in the system. This is the reason why any email client can be used communicating with the old system. In MONGO the email client has to be able to run web pages, so that the responses from the users can be gived via communicating with a servlet over the HTTP protocol. In short terms, this means that if MONGO is to be developed further to give support also for text based email clients, it has to include some kind of software listening to a socket; this to be able to sort out the emails which are meant for the MONGO system.

5.4 Combi device


39

A goal during the development of MONGO has been to make it easy to modify and to extend. This has been a priority in order to have the ability to employ the system on future mobile devices. As described in chapter 6, the future is moving faster than ever before. New kinds of devices are surprising the world around every corner, and some of them could be relevant for use in the context of our system. One of such is the combi device; a mixture between a WAP phone and a PDA.

Figur 23. An example of a combi device - the Treo 180

The Treo 180, shown in the figure above, is able to communicate with a local LAN using its integrated Bluetooth, in addition to functioning as both a WAP phone and a PDA. It is marketed as a smartphone. Another similar device, except from the integrated bluetooth, is the Nokia communicator 9110i (shown in section 3.1.2).

5.4.1 Implementing – new servlets In order to employ the system on such a device, or any other client being developed, some servlets will have to be implemented. With the combi device in mind, MONGO will probably have to be adjusted by making the following servlets:

• AddTaskCombi – making the service personnel able to add new tasks on the device

• CommentTaskCombi – making the service personnel able to comment a task on the device

• LoginCombi – the combi device has to present the login pages of MONGO • ResolveTaskCombi – making the service personnel able to resolve a task using

the combi device • ViewTaskDetailsCombi – making it possible to view the details of a task • ViewTasksCombi – making it possible to view a list of all the registered tasks

These are just the basic servlets, making the combi device able to perform the most important functions. It is of course possible to implement more servlets, example given GiveTaskCombi or RespondTaskCombi, to perform even more different actions. The new servlets will make use of the classes DatabaseAccess and FetchData, as well


40

as the existing servlets, example given AddTask and UpdateTask, in order to add, retrieve and update the task data in MONGO.

5.5 Invisible editing

During the performed test of MONGO one, annoying problem was discovered; the invisble editing. When you submit information to the system, by e.g. you push the “add” button when adding a task, the text you added will not be available until you synchronize the PDA. This is not an optimal solution if you want to work with the information you just added before you go by the office to synchronize. There is a solution to this, namely accessing the buffer directly. This has been tested on the Palm Vx, but it is not an obvious or even satisfying solution for the users of MONGO. Accessing the buffer will be a quite cumbersome action outside our system. It would be ideal to include this possibility in MONGO in some way, making it easy to use as a part of the application, but how this could be done is still to be discovered. This will of course be a problem only when the PDAs are not connected to a network in any way. With the probable future foreseen in chapter 6, with every handheld device connected through a wireless LAN, this will cease to exist as a problem.

5.6 Lack of confirmation

When using MONGO, a big part of the functionality is to add information when work is done, or questions arise. If this is done on a PDA, and the “add” button is pressed, the fields will go blank, but the user will still be on the same page where he or she recently added the information. The question the user then will ask is if the information was added, or if it just disappeared. Of cource, the information did not just vanish. As section 5.5 is all about, the added text is moved to a buffer, pending until the next synchronization. This way of handling user interaction is not satisfactory, since the user does not know if the changes are saved or just forgotten. MONGO should provide good feedback to its users, regarding what is done with the provided information. The following improvements should therefore be implemented in the next version:

• The user should get a confirmation from MONGO, telling he or she that the new information has been saved

• The user should be taken back to the main menu or wherever suitable, from the page where the information was added

This is not a complicated issue to implement, as it involves some additions in the written code, including a popup window and a pointer back to some suitable menu.

5.7 Random order


41

When MONGO is used out on location, the possibility for doing several changes on the same task excists. This means that the history could contain more than one new addition under the same heading when the user comes back to his or her office and synchronizes. Every new addition is now included in the MONGO database, but the problem is that the order in which they are added seems to be random. One possible complication involved is that one addition solving an issue could come before the actual problem, or before the last question. This is not a big problem, but it could lead to some confusion if someone who did not participate during the process of solving the task tries to understand what has been going on. This could be solved by having some kind of time stamp, or just by numbering them in increasing order, for every new addition. This would make every addition unike, and by using this solution it should be possible to sort the additions in the correct order automatically when they are included in the MONGO database.


42

Chapter 6 Anytime, anywhere – a wireless future? When planning and building a system like MONGO, there are a lot of uncertain factors - some more important than others. Who are really going to be the end users? Is the foundation strong enough to support further development? Is the future going to be wireless, and is MONGO prepared for this?

"Intelligent wireless handheld devices are going to explode, absolutely explode

over the next several years." (Steve Ballmer, CEO, Microsoft)

Some aspects of our geek organizer will be utilized far better when the environment becomes wireless. Almost everyone who took part in the testing and evaluation mentioned that our system would be even more interesting when the PDAs could be online all over campus. Is this scenario going to become reality soon enough for MONGO to be a part of it? During the last couple of years the price we pay for mobility, it being mobile phones or PDAs has dropped significantly. At the same time the efficiency of such devices has been increasing rapidly, and a lot of new technology has been evolving; wireless LANs, 802.11b/g/a and Bluetooth, facilitating connectivity and access. The introduction of this wireless future has been blown up to enormous proportions, and it is an understatement to say that not everything has a foundation in reality. Nevertheless, some of it can be of high value for a system like MONGO.

Figur 24. Wireless possibilities

When the development of new technology is moving faster than ever before, it is important to be one or three steps ahead. For a project like MONGO it is important to be visionary. When new standards wait on every doorstep, and people changing views every other day, it will be essential not to fall behind, developing a product that is of little or no practical use. To increase the usability, and at the same time erasing a couple of the problems discovered during the test phase, MONGO should strive to become completely mobile, using wireless LANs.


43

This thesis is not about developing or building a wireless LAN, but it is not unlikely to assume that the campus will be fully covered by such networks in just a few years. Of course, this prediction does not only apply to our campus, but to most technical advanced areas. To make MONGO more interesting and applicable for potential customers, it should be based on, or at least fully prepared for, wireless LANs.


44

PART 4: CONCLUSION The conclusion part consists of three chapters. Chapter 7 includes the conclusion of the project, as well as a pointer towards the

future work to be done, and some personal experiences. Chapter 8 contains the web references and bibliography used in this project. Chapter 9 is a glossary of abbreviations used in this report.


45

Chapter 7 Conclusion This chapter contains the conlusions, some suggestions for future development in addition to some personal experiences.

7.1 Conclusion

There were two initial objectives when this project first started out. The first one was to test and evaluate the prototype of MONGO, cooperating with the service personnel working at the IT-support department. Further, the second objective was to suggest a preliminary design for possible improvements. Both of these objects are fulfilled. The first object is reflected in chapter four, evaluating MONGO. Thorough and experimental preparations laid the foundation for a good test. It was important that we got the most out of this, with valuable experiences and trustworthy results. The people working at the IT-support department were more than willing to participate as test candidates, and the result was good feedback. The evaluation scheme should be on the Web, and not on paper, if future tests are to be performed. The results tells of a good foundation in the MONGO prototype, but also of some critical flaws and possibilities for improvement. When making preliminary designs in chapter five, the test results had to be properly analyzed in advance. There were six or seven obvious possibilites for improving the system, some of them more complicated than others. The object was not to solve all of the problems, but to come up with ideas for what can be done in future assignments. The object is fulfilled, as the possibilites are analyzed and discussed, but the real development of the improvements still lies ahead. Much work was done to understand the concepts of MONGO, much of which is reflected in the prestudy. Hopefully this resulted in a good interpretation of the test phase, producing useful material in the evaluation of MONGO. By fulfilling the initial objectives, I hope that this project will be a contribution for future work both with MONGO, and in the superior MOWAHS project.

7.2 Suggestions for future work

Much of this thesis is about possibilities for future improvement of MONGO, and there are even more subjects for improvement now, than when starting out on this project. Some of the suggestions are more important than others, and I would like to point out which these are:

• The possibility to remove a staff member or a queue is something the system needs in order to be complete.

• The layout flaws on different PDAs should be corrected, both because it is

easy to fix, and because the user interface is let down without a correction..


46

• The (lack of) confirmation, e.g. when making changes on some registered

task, should be implemented, including the pointer to some suitable menu. Todays solution can easy confuse and mislead fresh users.

These are all relatively small changes, when compared to e.g. introducing an overall design profile for the system. One other important, but somewhat more complicated issue, is to make MONGO independent of which email client the users receive their emails on. One thing is to make the system work in an heterogenous environment, but it really should have functionality for text based email clients like Pine, which is what most of the students on campus uses. MONGO is a solid prototype, but it needs a good portion of work before it can compete with e.g. RUST. It is never enough for a new application on the market to be equal to the existing ones, so the future development of MONGO must continue until it can stand out in front of other similar systems.

7.3 Personal experiences

When we were supposed to choose a project some months ago, I had absolutely no idea what I wanted. The reason I ended up with MOWAHS as the superior project was because of the technology being used here. I have an interest in the future of digital communication, as well as the organisational challenges which are to be expected in the years ahead. With MONGO I got to cooperate with people working in a big organisation, advanced and new technology, and not to forget subjects included in the last years of my study. I feel that I have acquired several new skills during this project. The first thing to mention is to write a report in English. The first two months were slow and stuttering, but in the end the speed has really increased; probably also because of the deadline. The thesis has involved WML, servlets and PDA technology – all of which are new areas for me. In addition to this I could refresh and use my knowledge on UML, software architecture, java and database communication, as well as some small design issues. The latter is an interest of mine, not included in the last year of my study. As a last point, it is the first time I have been responsible for a project of this magnitude alone, which, of course, is a good experience to have the semester before my diploma thesis is due. When overcoming some of my barriers, the project turned out to be both fun and interesting, but also challenging and time consuming. I do not regret asking if I could work with this assignment, and I would have done it again.


47

Chapter 8 References

R – References from the Internet B – References from books and articles

[R1] The MOWAHS project, September 2001

http://www.mowahs.com

[R2] AvantGO, get the internet on your handheld, November 2002 http://www.avantgo.com

[R3] Norges forskningsråd, supporting MOWAHS, November2002

http://program.forskningsradet.no [R4] RUST: Managing Problem Reports and To-Do Lists, May 2002

http://www.usenix.org/publications/library/proceedings/lisa96/ruefenac.html [R5] The GNU Project web server, Oktober 2002

http://www.gnu.org/ [R6] Download the RUST system (/pub/sys-admin/rust/), 2001

ftp://ftp.eng.utah.edu/

[R7] Jakarta Tomcat, a Servlet/JSP container, 2002 http://jakarta.apache.org/tomcat/

[R8] A Tutorial on Java servlets and JSP, 1999

http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ [R9] WAP forum, 2002

http://www.wapforum.org/ [R10] The World Wide Web Consortium (W3C), November 2002

http://www.w3.org/ [R11] Home of the com.oreilly.servlet, November 2002

http://www.servlets.com/cos/index.html

[R12] The CAGIS project at IDI, 2000 http://www.idi.ntnu.no/~cagis/ [B1] Hoftun Øystein, MObile Nagging Geek Organizer

Diploma thesis, 2002


48

[B2] Aron C Kenneth. Bjørkhaugen and Hoftun Øystein, Task Reporting System Thesis in SIF8094, 2001

[B3] Bosch Jan, Design and Use of Software Architectures Addison-Wesley, 2000 [B4] Fowler Martin with Scott Kendall,

UML Distilled, a brief guide to the standard object modeling language Addison-Wesley, 2000 [B5] Sommerville Ian, Software Engineering Fifth edition, Addison-Wesley, 1996 [B6] Bass L., Clements P. and Kazman, Software architecture in practice Addison-Wesley, 1998

[B7] Preece Jenny, Human-Computer Interaction Addison-Wesley, 1994


49

Chapter 9 Glossary A SP – Active Server Pages C AGIS – Cooperative Agents in a Global Informationa Space GI – Common Gateway Interface D TD – Document Type Definition H TML – HyperText Markup Language I DI – Institutt for Datateknikk og Informasjonsvitenskap (Department of Computer and Information Science) T – Information Technology J SP – Java Server Pages M ONGO – Mobile Nagging Geek Organizer OWAHS – Mobile Work Across Heterogeneous Systems N TNU – Norges Teknisk-Naturvitenskapelige Universitet (Norwegian University of Science and Technology) P 2P – Peer-to-peer DA – Personal Digital Assistant R UST – Request, Users, and Sys-admin To-do Ticket System S GML – Standard Generalized Markup Language W AP – Wireless Application Protocol ML – Wireless Markup Language TA – Wireless Telephony Application X HTML – Extensible HTML ML – eXtendible Markup Language

Documents

A further development of MONGO - NTNU report contains the documentation of the project “A further development of MONGO ... (MONGO) 2 Chapter 1 Introduction ... research project supported