by András Velvárt and Peter Smulovics

Summary: Monicomp is the largest maintainer of banking equipment in Hungary. The organization installs, maintains, and repairs Point of Service (POS) terminals, Automatic Teller Machines (ATM) machines, and other similar banking equipment using hundreds of technicians scattered all around the country. Any company that needs to perform these duties and has to follow ISO 9000 needs all the IT help it can get. The organization has to track where every meter of a two kilometer cable has been used, so that if there’s a problem with the cable, it can go back to each and every shop that the cable was used in, and perform repairs before more problems arise. In addition, clients require up-to-the-minute information on the Web—which can range from how the country-wide software updates are going right down to the faulty POS terminal in Mr. Smith’s pet shop.

As you may expect, a paper-based way of working can’t keep up with these requirements. It would be unrealistic for technicians to go out to the field, and send paper worksheets in for processing at the end of the work week. You need a 21st century solution. The “MÛVÉSZ” system, developed by a software development and consulting company called Response, covers the full range of the service operation from inventory to billing; from trouble ticketing to distribution and verification of work for more than 100 technicians performing the maintenance and installation tasks. In the article, we will show how the architecture of this system is designed and describe the challenges and solutions of creating mobile subsystems.

Contents

Worksheet Workflow
Architectural Overview—What and Why?
User Interface with WPF
Conclusion
About the Authors

Worksheet Workflow

Before we look at the architectural overview for the application, let’s begin with an overview of the important workflow processes in the organization. For Monicomp, the most important entity in a mobile workflow is the Worksheet. The worksheet is a work item that needs to be performed by a field technician. Let’s examine the key concepts of a simplified workflow:

Creating the worksheet. The worksheet is usually created by the dispatcher. When a worksheet is created, it has the following key attributes:

• Type of worksheet which categorizes the work to be performed: installation, repair, or uninstallation
• A reference to the partner or address where the work is to be performed
• Information from the original trouble ticket that the dispatcher recorded (if any)
• Identifiers and additional data of the devices to be installed or uninstalled
• The identifier of the worksheet itself
• Deadline of the work

Assigning the worksheet. To start the workflow, the dispatcher assigns a technician to the worksheet after reviewing the workload and the geographical position of the available technicians. To make this easier, technicians’ geographical positions are gathered via Global Positioning System (GPS) tracking devices and displayed on an integrated Virtual Earth map, with color-coded icons indicating their current workloads. (See Figure 1.)

Figure 1. Using Virtual Earth Services to select the technician closest to the target with the smallest workload

Downloading the worksheet. After the worksheet has been assigned to the technician, a Short Message Service (SMS) message is sent. The SMS notifies the technician and the Ultra-Mobile PC (UMPC) device that there is new work to be done. With a synchronization through General Packet Radio Service (GPRS), Edge, 3G, or a wireless network (depending on the availability in the technician’s area), the new worksheet is downloaded to the Worksheet application running on the UMPC.

Filling out the worksheet. The technician reviews the received worksheet, travels to the location where the work is to be performed, and does his job. During the repair, installation, maintenance, or uninstallation work, he records the details of the device he’s working on (such as serial number), and assigns equipment and materials from his inventory to the device. He can also use the Worksheet application to review technical specifications of the device in question if the repair turns out to be difficult. These specifications can also be annotated with Ink, and these annotations are shared in a knowledgebase.

Other data to be recorded includes the time of arrival to the scene, the number of hours it took for the technician or technicians to perform the job, and travel distance to and from the location. You can learn more details about the Worksheet application in the “User Interface with WPF” section later in this article.

Closing the worksheet. After the worksheet is filled, it is printed on a mobile printer, and signed by the client. The signature could also be captured on the touch-sensitive display of the UMPC using Ink (so that technicians would not have to carry printers with them), however, due to legal issues, this functionality has not yet been used.

Uploading the worksheet. The database on the UMPC is synchronized, uploading the changes on the worksheet to the central server. The business logic on the server registers the work undertaken, removes the used-up materials from the technician’s inventory and performs all other necessary housekeeping. The synchronization mechanism is also very handy to create up-to-date backups of the technicians’ databases. In case a UMPC is broken or lost, the technician can quickly resume his work because his database can be recreated as it was at the time of his last synchronization.

Two Types of Synchronization

The UMPC clients can perform two types of synchronization. To save bandwidth and battery life, the quick synchronization only moves the data directly related to the technician’s worksheets. The full synchronization (docking) downloads a complete set of data to the UMPC (for example, changes in the people force or software updates); therefore it is usually only performed via Internet connection at the technician’s home.

Architectural Overview—What and Why?

The architecture, whether it’s defining connections between black and white boxes, displaying characters in a command line, calling Web services, or using an Office Business Application, is by nature determined by the type of quality of the connection. Mobile computing, despite today’s always-connected ideology, in reality is occasionally-connected. Given this, how do you plan an architecture for occasionally-connected scenarios?

In this section, we summarize some key issues that we confronted in planning and implementing this mobile, high-complexity architecture. To start, let’s look at Figure 2, which shows the main components and communication links of our mobile architecture.

Figure 2. Overview of the main components and their communication links

Occasionally Connected

The major consideration for an occasionally-connected architecture is synchronization, be it one way, two way, dealing with conflict resolution logic, and presenting this through the user interface. Not dealing with these issues can cause consistency problems; solving the problems makes the business logic much more complicated than a pure offline or online scenario. In order to decrease the time to market we selected the ADO.NET Synchronization Services, which were introduced along with other parts of the toolset to create a fully automated, less error prone, and standardized solution.

Key System Components

At the heart of the system is a multilayered application server, which performs data storage and business logic functionality. Several different types of clients utilize its services:

• A Windows Forms application that is used at the headquarters by the storekeepers, the dispatchers, and technicians performing repair jobs that cannot be done at the locations. The application is deployed using ClickOnce, which helps ensure seamless version upgrades.
• An extranet Web application with fluid and responsive interface used by the biggest clients to place hundreds of orders in a single batch, prioritize, and track the progress of these orders.
• A Windows Presentation Foundation (WPF) application running on hundreds of UMPCs used by technicians who perform installation, repair, and maintenance tasks throughout the country.

The Server Configuration

As a backend server, we found the new Windows Server 2008 to be an ideal solution for Software + Services scenarios like this one—primarily because it is capable of hosting Windows Communication Foundation (WCF) services to serve and queue HTTP requests at the kernel level, while at the same time being easy to manage from an infrastructure perspective.

We used an instance of SQL Server 2008 running on the server to provide capabilities like spatial data storage, and to serve as the data store as a reporting solution for the dispatcher application and the external website. The previously mentioned synchronization problems were tackled by the ADO.NET Synchronization Services, along with Microsoft’s “Database in the Cloud” solution called Astoria, which you can read about in Issue 13 of the Architecture Journal. Using Astoria we created a WCF service and through the service, using Representational State Transfer (REST) and Plain Old XML (POX) protocols, read and modify the underlying database. To establish the needed business logic in the appropriate places, we found that the synchronization services, Astoria, and database triggers worked together well.

Dispatcher, Storage, and Billing Application

To aid the work of storekeepers, group leaders, and dispatchers at the headquarters, an easy-to-use application was needed to have all required information instantly available. This Line-of-Business (LOB) application integrates with positioning systems (using spatial data storage), creating a good user experience (using a mixture of WPF and Windows Forms), and displaying maps (using Virtual Earth Live Services).

External Web Site

As this was a new solution, we had some flexibility to look at technologies without incurring great risk of having to maintain any existing applications. We implemented a custom workflow step to be able to approve, reject, or modify records that were visible to the end customer, primarily to avoid displaying stale data. The solution for this was derived from the “Windows Workflow Foundation Web Workflow Approvals Starter Kit“, which we were able to customize with little effort. Another opportunity for widening the technology horizon was fast prototyping offered by the “Jasper” scaffolding solution that came with ASP.NET Futures: starting with a simple interface, we found that it was easy to go into deep customization without losing the investment in the original forms. The ASP.NET Ajax Futures’ user-friendly back button and history support made interface changes fluid.

UMPC Application

We found that the application created for the UMPC device was our opportunity to add the most innovated thinking. The UMPC device and the Worksheet application perform many different tasks:

• Recording the work performed by the technician, thus filling out the worksheet
• Communicating with the server over 3G, Edge, or WiFi, using ADO.NET Synchronization Services and a local SQL Server 2008 Compact Edition instance for data storage
• Voice recording and camera for documentation, with additional annotation via Ink
• Displaying XPS format handbooks using the Microsoft News Reader SDK for the ATMs/POSs, featuring annotation and collaboration capability, with voice-, soft-button-, or stylus-based navigation
• Showing map and route information for the next target to visit.

What is the infrastructure under this? From the developer side, it was really a matter of putting well-defined building blocks together, such as Enterprise Library, WPF, ADO.NET Synchronization Services, SQL Server 2008 Compact Edition, WPF, and the .NET Framework. Since the UMPC is a full-featured PC with an x86 compatible processor, running familiar operating systems like Windows XP Tablet PC Edition or Windows Vista, we found that the actual development process is much like a normal desktop application development. From the designer and software ergonomics side however, we did find development a bit more complex. We explore this in the next section.

User Interface with WPF

Moving Away from a Traditional User Interface

Windows Presentation Foundation gives UI designers the chance to reconsider old habits of UI design and offers the opportunity for some out-of-the box, lateral thinking.

Had we taken a traditional view of the UI, we would have probably enumerated the functions of the software, created groups, and then displayed a main menu after the program had started, most likely with the most frequently used options first. We decided instead however to eliminate the main menu altogether—the software starts in the most used view, with the worksheet overview screen. The additional functionality of synchronization, version upgrades, reference repository, and access to the inventory of the user were implemented as complementary, slide-out panels.

On the worksheet overview screen, worksheets are visualized as folders. The folders already show the most important data on the outside (Figure 3), but further details are displayed when you open a folder by tapping it on the touch screen (Figure 4). We also placed the “Edit Worksheet” button inside the folder, thus ensuring that no worksheet is opened for editing before the user has a chance to look at the details.

Figure 3. The user is taken immediately to the most used part of the application

Figure 4. Opening the folder reveals further details and access to editing its contents

Taking Advantage of Spatial Memory

According to Wikipedia, “Spatial memory is the part of memory responsible for recording information about one’s environment and its spatial orientation.” For example, spatial memory helps you by remembering that you have last seen the pen you are looking for on the right side of the table.

If you take advantage of spatial memory, and always put the same thing on the same side of the screen, your users will instinctively remember where to find it. To implement this in our case, the bottom slide-out panel contains the reference materials, and the right side slide-out panel contains the inventory—all the equipment they have in the backs of their trucks, ready to be used when installing or repairing devices (Figure 5).

Figure 5. The inventory is always accessible on the right side

The inventory panel has two functions. Initially, the technician checks whether he has the replacement parts with him. Later, when filling out the worksheet, he records the parts he has actually used for the repair by dragging and dropping items from the inventory onto the worksheet. In both cases, the inventory can be found on the right side, accessed, filtered, and sorted in the same way. We have chosen the right side because, during user testing, we found that most of the technicians are right-handed, thus they hold the UMPC in their left hand, and the pen in their right hand. With this being the case, the drag-and-drop operation required to add an item from the inventory onto the worksheet is more convenient.

We chose to include a pie menu on the worksheet editor screen (Figure 6). We found that first time users quickly understand how the menu works with the help of subtle, but fast animations when opening the menu, submenu or selecting a menu item. The large sensitive areas of the menu help when the menu is used with a finger—your finger is not very precise compared to a mouse or a stylus, but it is always at hand. The pie menu also takes advantage of the user’s spatial memory, since it is much easier to remember that the “Close worksheet” icon is on the right side, than to remember that it is the third item in a dropdown menu.

Figure 6. Pie menus are ideal for taking advantage of spatial memory. Huge sensitive areas help with finger interaction.

In real life, placement of items is a way of organizing them and we wanted to take this concept across to the user interface. For example, you may have the habit of keeping important documents on the left side of your desk, and less important ones on the right. We have allowed the same for our technicians in the worksheet overview: the folders can be moved, rotated, and even resized (Figure 7).

Figure 7. Customizable placement of folders allows spatial grouping to suit the habits of the individual user

Natural Interaction

However accustomed you or I may be to the mouse, it is not a natural way of interaction. You have to move an odd-shaped object on your desk, while looking elsewhere for feedback to see whether your cursor has reached the intended destination. When it comes to interactions like point-and-click, drag-and-drop, or drawing, using a touch screen is much more intuitive and productive, even for seasoned mouse-users. With this said however, a finger or even a pen or stylus tends to be a lot less precise than a mouse. To accommodate this when we designed the user interface, we were keen to keep the buttons large and to make sure they don’t touch each other. For the same reason, when using a scrollbar, we had to make sure that it was much wider than usual.

During our user testing we found that a scrollbar is something that you may not want to have at all in a touch-screen environment. If you think about it, using a scrollbar is somewhat unnatural — you have to press a down arrow or drag a small thumb downwards, when you want the scrolled content to move upwards. When you are scrolling a document, it is actually moving in the opposite direction than your mouse or scroll-wheel. A much more natural way of scrolling is to drag the content itself in the direction you want it to move. Leaving behind this unnatural way of scrolling is part of what makes the most recent generation of mobile devices so enjoyable to use.

Using Ink for Input

When it comes to recording information, we found that nothing beats the versatility of pen and paper from a usability standpoint. Using ink gives the technicians a way to draw diagrams, write text, or annotate part of a document freely. In the digital world, Tablet PCs, UMPCs, and Pocket PCs with touch screens can work similarly. We found that using digital ink was useful for creating drawings, annotations, and recording the customer’s signature confirming that the work was performed.

Using the Ink API in Windows Presentation Foundation (in the System.Windows.Ink namespace) made using digital ink a breeze in the above scenarios. In just a couple of hours, we were able to add the drawing canvas with the ability to store, edit, and resize the ink strokes—with most of the time spent on creating the icons that switch between drawing modes. (Figure 8 shows an example of an annotated picture.) Text recognition (or Ink Analysis) is also very straightforward, and works for many languages, including English (UK or US), French, Spanish, Korean, German, Japanese or Chinese.

Figure 8. On the drawing canvas, the technician can record any type of graphical information

Without using Ink Analysis, the way the technician is filling out the form would be fairly cumbersome without a mouse and a keyboard.

A good example is the field where they record how many hours they spent with the repairs. We found that the user had to point (click) at the proper textbox, select its contents if there is any, click to pop up the on-screen-keyboard, enter the number of hours and close the keyboard. That’s five clicks, and a lot of context change in the user’s mind (“I want to enter a number. I need to select where I want it. I need to bring up a virtual keyboard. I need to use the keyboard, close the keyboard, return to the main task of filling out the worksheet”). Compare this with the act of writing the number “3” in the proper field with the pen (Figure 6), and you will appreciate the natural simplicity of this new-old way of interaction.

Conclusion

Creating occasionally-connected mobile applications comes with many challenges. Luckily, hardware and software technologies that make such an application feasible are starting to become more mainstream—UMPCs with the hardware capabilities of PCs from a few years back, GPS trackers, mobile Internet connectivity, sophisticated software libraries, ink and speech recognition built into the operating system, and multiple online services; the list goes on. With the system that we put together for Monicomp we find that it’s all coming together; enabling developers to build mobile solutions that only sci-fi writers dared to dream about a decade ago.

About the Authors

András Velvárt approaches software development the Lincoln way: “If I have six hours to chop down a tree, I will use four hours to sharpen the axe.” In the past, he was one of the few who helped spread the idea of the World Wide Web in Hungary. He has always enjoyed trying and implementing the newest technologies—many of his proof-of-concepts ended up being useful additions to projects, from the UI/usability side to the development process side. He has been working with Microsoft technologies for 12 years. He was Lead Developer, Architect, and Project Manager on many of Web, desktop and enterprise projects, until he founded his own software development and consulting company, Response. András can be reached at andras.velvart@response.hu.

Peter Smulovics is a Microsoft guy, searching for the needle in the haystack for more than 10 years. He worked on projects like SQL 2005 Analysis Services, Visual Studio .Net 2005, Microsoft Business Framework and Portal, ADO.Net Entity Framework, Dynamics Great Plains and Solomon, doing testing, developing, group leading, and architecting. Meanwhile, being part of user groups, presenting at Developer Days, TechEds and Microsoft Forums, leading .NET introduction in the country—these were all part of his daily job. Currently, he is working in the Development and Platform Adoption group and giving architectural aid and workshops for Enterprise customers on many different products. Peter can be reached at smulovics.peter@microsoft.com.

Disclaimer: Although the solution described in the article is based on the actual working system at Monicomp, due to the nature of the topic, some details have been changed to protect company interests, while others are currently in the planning or implementation phase.

 

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.