by András Velvárt and Peter Smulovics

Summary: Monicomp is the largest maintainer ofbanking equipment in Hungary. The organization installs, maintains, and repairsPoint of Service (POS) terminals, Automatic Teller Machines (ATM) machines, andother similar banking equipment using hundreds of technicians scattered allaround the country. Any company that needs to perform these duties and has tofollow ISO 9000 needs all the IT help it can get. The organization has to trackwhere every meter of a two kilometer cable has been used, so that if there’s aproblem with the cable, it can go back to each and every shop that the cablewas 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 howthe country-wide software updates are going right down to the faulty POSterminal in Mr. Smith’s pet shop.

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

Contents

WorksheetWorkflow
Architectural Overview—What andWhy?
User Interface with WPF
Conclusion
About the Authors

Worksheet Workflow

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

Creating the worksheet. The worksheetis usually created by the dispatcher. When a worksheet is created, it has thefollowing 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 theworkload and the geographical position of the available technicians. To makethis easier, technicians’ geographical positions are gathered via GlobalPositioning System (GPS) tracking devices and displayed on an integratedVirtual Earth map, with color-coded icons indicating their current workloads. (SeeFigure 1.)

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

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

Filling out the worksheet. The technician reviewsthe received worksheet, travels to the location where the work is to beperformed, and does his job. During the repair, installation, maintenance, oruninstallation work, he records the details of the device he’s working on (suchas serial number), and assigns equipment and materials from his inventory tothe device. He can also use the Worksheet application to review technicalspecifications of the device in question if the repair turns out to bedifficult. These specifications can also be annotated with Ink, and theseannotations are shared in a knowledgebase.

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

Closing the worksheet. After the worksheet isfilled, it is printed on a mobile printer, and signed by the client. Thesignature could also be captured on the touch-sensitive display of the UMPCusing 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 theUMPC is synchronized, uploading the changes on the worksheet to the central server.The business logic on the server registers the work undertaken, removes theused-up materials from the technician’s inventory and performs all othernecessary housekeeping. The synchronization mechanism is also very handy tocreate up-to-date backups of the technicians’ databases. In case a UMPC isbroken or lost, the technician can quickly resume his work because his databasecan 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 thedata directly related to the technician’s worksheets. The full synchronization(docking) downloads a complete set of data to the UMPC (for example, changes inthe people force or software updates); therefore it is usually only performedvia Internet connection at the technician’s home.

Architectural Overview—Whatand Why?

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

In this section, we summarize some key issues that weconfronted in planning and implementing this mobile, high-complexityarchitecture. To start, let’s look at Figure 2, which shows the main componentsand 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-connectedarchitecture is synchronization, be it one way, two way, dealing with conflictresolution logic, and presenting this through the user interface. Not dealingwith these issues can cause consistency problems; solving the problems makesthe business logic much more complicated than a pure offline or onlinescenario. In order to decrease the time to market we selected the ADO.NETSynchronization Services, which were introduced along with other parts of thetoolset to create a fully automated, less error prone, and standardizedsolution.

Key System Components

At the heart of the system is a multilayered applicationserver, which performs data storage and business logic functionality. Severaldifferent 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 tobe an ideal solution for Software + Services scenarios like this one—primarilybecause it is capable of hosting Windows Communication Foundation (WCF)services to serve and queue HTTP requests at the kernel level, while at thesame time being easy to manage from an infrastructure perspective.

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

Dispatcher, Storage, and Billing Application

To aid the work of storekeepers, group leaders, anddispatchers at the headquarters, an easy-to-use application was needed to haveall 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), anddisplaying maps (using Virtual Earth Live Services).

External Web Site

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

UMPC Application

We found that the application created for the UMPC devicewas our opportunity to add the most innovated thinking. The UMPC device and theWorksheet 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 developerside, it was really a matter of putting well-defined building blocks together,such as Enterprise Library, WPF, ADO.NET Synchronization Services, SQL Server2008 Compact Edition, WPF, and the .NET Framework. Since the UMPC is afull-featured PC with an x86 compatible processor, running familiar operatingsystems like Windows XP Tablet PC Edition or Windows Vista, we found that theactual development process is much like a normal desktop applicationdevelopment. From the designer and software ergonomics side however, we didfind 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 thechance to reconsider old habits of UI design and offers the opportunity forsome out-of-the box, lateral thinking.

Had we taken a traditional view of the UI, we would haveprobably enumerated the functions of the software, created groups, and thendisplayed a main menu after the program had started, most likely with the mostfrequently used options first. We decided instead however to eliminate the mainmenu altogether—the software starts in the most used view, with the worksheetoverview screen. The additional functionality of synchronization, versionupgrades, reference repository, and access to the inventory of the user wereimplemented as complementary, slide-out panels.

On the worksheet overview screen, worksheets are visualizedas 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 tappingit on the touch screen (Figure 4). We also placed the “Edit Worksheet” buttoninside the folder, thus ensuring that no worksheet is opened for editing beforethe user has a chance to look at the details.

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

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

Taking Advantage of Spatial Memory

According to Wikipedia, “Spatial memory is the part ofmemory responsible for recording information about one’s environment and itsspatial orientation.” For example, spatial memory helps you by remembering thatyou 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 thesame thing on the same side of the screen, your users will instinctivelyremember where to find it. To implement this in our case, the bottom slide-outpanel contains the reference materials, and the right side slide-out panelcontains the inventory—all the equipment they have in the backs of theirtrucks, 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, thetechnician checks whether he has the replacement parts with him. Later, whenfilling out the worksheet, he records the parts he has actually used for therepair by dragging and dropping items from the inventory onto the worksheet. Inboth 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 usertesting, we found that most of the technicians are right-handed, thus they holdthe UMPC in their left hand, and the pen in their right hand. With this beingthe case, the drag-and-drop operation required to add an item from theinventory onto the worksheet is more convenient.

We chose to include a pie menu on the worksheet editorscreen (Figure 6). We found that first time users quickly understand how themenu 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 helpwhen the menu is used with a finger—your finger is not very precise compared toa mouse or a stylus, but it is always at hand. The pie menu also takesadvantage of the user’s spatial memory, since it is much easier to rememberthat the “Close worksheet” icon is on the right side, than to remember that itis the third item in a dropdown menu.

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

In real life, placement of items is a way of organizing themand 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 yourdesk, and less important ones on the right. We have allowed the same for ourtechnicians in the worksheet overview: the folders can be moved, rotated, andeven resized (Figure 7).

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

Natural Interaction

However accustomed you or I may be to the mouse, it is not anatural 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 theintended destination. When it comes to interactions like point-and-click,drag-and-drop, or drawing, using a touch screen is much more intuitive andproductive, even for seasoned mouse-users. With this said however, a finger oreven a pen or stylus tends to be a lot less precise than a mouse. Toaccommodate this when we designed the user interface, we were keen to keep thebuttons large and to make sure they don’t touch each other. For the samereason, when using a scrollbar, we had to make sure that it was much wider thanusual.

During our user testing we found that a scrollbar issomething 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 topress a down arrow or drag a small thumb downwards, when you want the scrolledcontent to move upwards. When you are scrolling a document, it is actuallymoving in the opposite direction than your mouse or scroll-wheel. A much morenatural way of scrolling is to drag the content itself in the direction youwant it to move. Leaving behind this unnatural way of scrolling is part of whatmakes the most recent generation of mobile devices so enjoyable to use.

Using Ink for Input

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

Using the Ink API in Windows Presentation Foundation (in theSystem.Windows.Ink namespace) made using digital ink a breeze in the abovescenarios. In just a couple of hours, we were able to add the drawing canvaswith the ability to store, edit, and resize the ink strokes—with most of thetime spent on creating the icons that switch between drawing modes. (Figure 8shows 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 ofgraphical information

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

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

Conclusion

Creating occasionally-connected mobile applications comeswith many challenges. Luckily, hardware and software technologies that makesuch an application feasible are starting to become more mainstream—UMPCs withthe hardware capabilities of PCs from a few years back, GPS trackers, mobileInternet connectivity, sophisticated software libraries, ink and speechrecognition built into the operating system, and multiple online services; thelist goes on. With the system that we put together for Monicomp we find thatit’s all coming together; enabling developers to build mobile solutions thatonly 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 sharpenthe axe.” In the past, he was one of the few who helped spread the idea of theWorld Wide Web in Hungary. He has always enjoyed trying and implementing thenewest technologies—many of his proof-of-concepts ended up being usefuladditions to projects, from the UI/usability side to the development processside. He has been working with Microsoft technologies for 12 years. He was LeadDeveloper, Architect, and Project Manager on many of Web, desktop andenterprise projects, until he founded his own software development andconsulting company, Response. András can be reached at andras.velvart@response.hu.

Peter Smulovics is a Microsoft guy, searching for theneedle in the haystack for more than 10 years. He worked on projects like SQL 2005Analysis Services, Visual Studio .Net 2005, Microsoft Business Framework andPortal, ADO.Net Entity Framework, Dynamics Great Plains and Solomon, doingtesting, developing, group leading, and architecting. Meanwhile, being part ofuser 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 givingarchitectural aid and workshops for Enterprise customers on many differentproducts. Peter can be reached at smulovics.peter@microsoft.com.

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

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