Hands-on with Android: Building a Ticket Responder, Part 1

The Motivation

Over the past few weeks we have had a look at some mobile platforms and tools from a high-level. These “survey” topics have been fun, but I think it is time to stop talking about mobile development and get back to building some applications. We’ll start by building a simple application and then adding more advanced functionality over the coming weeks. We’re going to start by working with Android and then branch out to Palm webOS, BlackBerry and iPhone. Along the way we’ll try to mix in some mobile software development practices because it is important to remember that building applications for mobile is different than other platforms — we don’t want to simply port applications, we want to create applications that are right-sized for mobile. This doesn’t mean simply that the applications fit on the mobile screen, though that is important — it really means that the application is right-featured for a mobile user. A desktop or web application is often very “click and click” oriented, meaning there are lots of features including right mouse menu or control-click enabled functions lurking everywhere. That’s great (and even expected) for those desktop applications, but a mobile application is all about mobile-usability. Packing in too many features is often not a good idea — the fewer the features at first the better. So as we contemplate adding features to a mobile application, we should ask a few questions:

• Is a particular feature really needed in a mobile application? Is it really going to be used? Expense report entry is a popular mobile application functionality that doesn’t always get utilized unless its design is well thought out and stream-lined with a bigger overall process. Contrast that with capturing a signature which can be made easy to use and is a useful feature for everyone involved.
• What information is really needed for a specific function? Databases usually have loads of tables each numerous fields, but most of those fields can be defaulted to commonly used values, thereby limiting the choices necessary for the mobile user to select from. The lower the barrier to use, the higher the compliance and the more successful the mobile application. If a particular field must be entered, try to put it in a “drop-down-list” rather than requiring textual entry.
• Do we cache information for the user locally or should it come from the server every time? Making the user wait on every transaction for information from the server that rarely changes is bad form — if you want your target user to actually use your application, stream-line the experience and speed up data entry tasks.

There are many subtle things that can be done in an application to increase its likelihood of adoption and ultimately be more rewarding to you, the mobile developer. At the end of the day, you want your application to be used and your clients to be asking for more features, not refunds. Careful attention to mobile application design can make or break a development shop. Speaking of mobile design, Bring Fling has written an excellent title on writing mobile applications which is soon to be published by O’Reilly.

The Mission

OK, let’s figure out what we’re going to build for our mobile application. During my “day job”, I run a network services business. In English, this means “sales, service and support of Local and Wide Area Networks and the computers that run on them”. In the unlikely event that you’ve not guessed this already, network support is a ridiculously competitive arena. In addition to competing with companies that are similar to ours in size and focus, we compete with large companies pushing down into the Small/Mid-Sized Business market on one end and the lone ranger/work for food small operator who can offer price points my team just cannot touch. Running a business like this is not rocket science, though running it well can be a real challenge. We attempt to differentiate ourselves by maintaining a stellar response time record and keeping lines of communication open and clear to our customers. So how does mobile fit in to this? We offer 24/7 support for many of our clients though we do not run more than a single, Monday – Friday shift. To meet this 24/7 service requirement, we’ve got support engineers “on call” during the off hours with an automated system to alert us to problems, big and small. When a support ticket comes in, we triage the situation and take appropriate action. Sometimes the alert is simply a notification that a backup “failed” because a file was in use while other times a support incident may indicate that a client’s server is down or no longer processing email, etc.

While there is one technical staff member responsible for the off-hours trouble tickets, the entire technical team receives every after-hours notification. The primary on-call engineer acknowledges the tickets in such a way that everyone else on the team knows the ticket has been “picked up” and they can resume their leisure time. If a ticket is not acknowledged within a certain amount of time, some of the more paranoid among us (that would usually be me), will contact the “on call” team member and try to determine what is happening with the ticket. The application we are going to build will address a slice of this functionality by giving the on-call technician a means to acknowledge the ticket and update its status. This focus on acknowledging every ticket in a timely manner is both a key to our network services business and an opportunity to let a mobile application help us meet our goals. Let’s have a look at the application.

The Application

When a support ticket comes in at say 8 PM local time, our office is closed, but a notification goes out to everyone on the team via email. For some users, this email address is an SMS email gateway — allowing the message to get through even if you’re on the phone. For example, on the AT&T network with EDGE communications, I cannot receive emails while I’m on the phone, but an SMS will come through loud and clear. Also, SMS notifications can be setup with a unique sound, different than emails which are usually silent anyway. I (and everyone in my family) know that when the phone makes that certain beep, something’s up and needs attention. I have actually setup an alias so the notification comes through as both an email and an SMS message. This way if I am working at my desk at home (common occurrence) I can simply click on the desktop email and check out the problem and/or listen to the attached voice mail which often accompanies an after-hours incident.

The first thing the support engineer does is review the contents of the ticket when it comes in and then selectively may connect to the client’s network and/or pick up the phone and contact the client. The specific action depends on the nature of the problem, the time of day and a host of other secret-sauce decisions we make on each ticket. The important aspect here and the one we’re going to focus on building in upcoming articles is how to acknowledge the ticket to not only the other team members but also to our ticketing system which captures all of our data. We’re not going to get into any coding today, but I do want to provide a couple of screen shots of the application in action to get us started.

Up Next

The first shot is of the application which the user (one of our technicians) sees. The first step is to enter the ticket number he is responding to. In the future, we’ll remove even this step because remember, we want to reduce the amount of data entry wherever possible!

You will note that the status is defaulted to “In Progress”, which saves a step for the technician. At minimum the status of this ticket will be “In Progress” just by acknowledging the ticket. This status is used when the technician is researching the problem and plays an important role in our KPI tracking – the time it takes us to record a response to a new support incident. The technician may come back later and change the status to “Waiting on Client” or even “Completed” if the problem has been resolved.

For now, the application simply displays a message to the user indicating that the specific action has been requested. Next week we’ll dive into the code to bring this application to life for Android. Over the subsequent weeks we will add new features for this application and then bring the same functionality to other popular mobile platforms.