Waste Management, Teenagers and User Interface Design

Several years ago when my son, Alex, was a sophomore in high school we were having our morning breakfast with his best buddy, Dillon, at a bagel shop prior to the start of their school day. The shop bustled with folks rushing to grab a coffee before work while more leisurely groups enjoyed a bite as they discussed the day ahead. In the midst of this scene, Alex says “Dad, we’re going on a field trip today with my science class.” Intrigued, I naturally inquired where he was going. “To the waste treatment plant on Falls Lake,” he replied. “Oh! Do you need some money for the souvenir shop?” I quipped. He casually replied “No” as the adults sitting around us laughed out loud. Alex and Dillon continued to eat as if nothing humorous had happened.

Adding a bit more levity to the story, Alex approached me that night and said, “You know, there really is no souvenir shop at the waste treatment plant.” To which my wife and I had another good chuckle.

So why did the adults find humor at the situation while the teenagers didn’t get it? It has to do with how we view the world. People see things in different ways based on many factors: age, culture, education, etc. These all affect the way people perceive their environment. It particularly impacts how different people interact with technology.

Time and again, I’ve seen scenarios where a CFO purchases a financial system because he loves the sophisticated user interface. But the chosen system falls flat at implementation because his operational staff – those who sit in front of their workstations for 8 hours each day – hate the interface because it is too laborious; they can’t get their work done effectively.

As software developers, we face the difficult task of designing applications for a myriad of users, each with different value systems. Our daily challenge is to build a user interface that allows the casual user and the expert to perform their tasks on the same system. It isn’t always easy!

The casual user wants a simple, intuitive interface that walks them through the process and enables them to complete their task without any confusing or ambiguous icons, links or instructions. The expert, or power user, deals with the application for hours each day and wants quick shortcuts and easy access to functions.

There is no middle ground; the novice expects to be led step by step through each function and feature while too many clicks and too much detail will frustrate the expert. As we start a new decade (another topic for debate: is 1/1/2010 or 1/1/2011 the start of the new decade) the challenge we face as developers is designing an interface that satisfies all.

To illustrate how difficult this can be, I went to Barnes & Noble and looked at books about Microsoft Excel. What I found was staggering. Excel 2010: The Missing Manual is over 800 pages and Excel 2010 Inside and Out is more than 1,000! And Excel is only a software tool to help you get your real job done. Has anyone ever read the entire text? Original versions of Excel, I’m sure, were simpler and required shorter manuals. But as the software evolved and more people started using it for different functions, it became more complex. Today, as the CFO uses it to balance a company’s budget, the project manager uses it to track a multitude of tasks. Different types of professionals need to know how to navigate the same software; therefore the 1,000 + page How To guide is born.

Our society today is filled with technology that has great benefits. We can get more done with our limited time each day. The cost, however, is frustration and, at times, the feeling of stupidity with the surfeit of user interface models we encounter in our daily activities.

My experience with a self checkout machine at a local mega hardware store last month is an example. Accustomed to the self checkout interface at the grocery store closest to my house, imagine my surprise when I accidentally pressed the French button on this unfamiliar system. Since I don’t know a lick of French, I had no idea how to cancel the transaction and start again. Five people were waiting impatiently behind me in line and I had this thing speaking French to me. I eventually got through the transaction, and all the people waiting were likely expecting me to speak in my most alluring French accent. They were a bit surprised when I turned to them and, in my best New York inflection, said “Sorry for taking so long.”

This embarrassment brings to mind the story of a new computer user who had just received a PC-DOS computer (remember them?) with a rather vaguely written installation guide. As he attempted to assemble the components, his frustration at the manual got the better of him. He called customer support for help, which only reinforced his feelings of ignorance. After several fruitless attempts to solve the problem, the support rep – who was obviously on a different experience level than the caller – claimed to have identified the problem.

“Great,” replied the customer.

The support rep said “Stand up in front of the computer parts.”

“Okay, I am,” replied the customer.

“Is your front door to the right or left?”

“To the left,” the customer replied.

“Good, start walking to the left and tell me when you are by your front door.”

“I’m there now.”

“Open the front door,” the support rep commanded.

“Door is now opened.”

“Good,” the computer expert on the other end of the phone paused. “Now step outside and shout: DOES ANYONE OUT THERE KNOW HOW TO USE A COMPUTER?”

What’s the point? During our different ventures in software development, we will encounter both pro users and novices. The trick is to find a way to make both feel like they’re getting a great experience, one that’ll make them want to come back again and again. That’s what makes software development challenging – in a good way. Technology continually evolves, making new techniques and methods available so we can design a user experience that satisfies all participants.

The Lord of the Audits: Part 3 – The Return of ART (Anal Retentive Tony)

MediClick’s year-long journey into SAS70 taught us much about the auditing process, and we now feel well prepared for future audits. Toward the beginning of 2008, a few industry colleagues had tainted my view of the assessment standard. With great reservation and consideration, MediClick’s management team decided to embark on the daunting SAS70 voyage into the unknown. By December 2008, though, MediClick had navigated the sometimes perilous audit without incident, exceeding my expectations and enlightening my view of the auditing process.

To wrap up this trilogy, I will reflect on a few of the topics I’ve learned during MediClick’s SAS70 travels:

• What makes a SAS70 Type 2 audit successful?
• What are the important components of an audit report for the SaaS consumer?
• What is the fate of the SAS70 audit?

Successful SAS70 Audit

It’s now the end of 2010 and the dust has settled from three successful SAS70 Type 2 audits at MediClick. This begs the question “what exactly is a successful audit?” In the SAS70 report, each control objective is listed and test cases are described. Results are documented for each test case. From a pure report point of view, success is having no relevant exceptions reported from all test cases. That is the simple answer, but reality is more complex; it comes down to two key elements:

    1.       Management Awareness

Is management aware of the activities occurring within its company? Are there meetings to establish corporate direction and confirm results? Is there an approval process for software enhancements and access rights to operational systems? Are all access to networks and physical locations shut down when an employee is terminated? The bottom line is that management must be aware of and approve activities within the organization as revealed through paper or electronic documents.

    2.       Segregation of duties

I remember talking to an IT executive about his SAS70 process; he said his company had to revert to a SAS70 Type 1 audit rather than a Type 2 audit. If you recall from previous blogs, a Type 1 audit states the control objectives without any testing. His company failed the Type 2 audit process because the auditors discovered that developers had been deploying code directly into production from their desktops. As you might imagine fixes were lost when one developer overlaid changes by another. Source code control was nonexistent.

This illustrates the basic point of the segregation of duties, you need a separate team to deploy, test applications in a QA environment and install them into production systems.

Important Components of an Audit Report

I should also note that MediClick also receives SAS70 audits from our partners. The hosting sites for our production and hot fail-over servers provide us with their SAS70 reports. So what do you do if you are a recipient of a SAS70 report? The answer is simple: READ IT.

I recall a fellow Triangle Technology Executive Council member who complained about some loose practices of a SaaS provider he was using. He complained to the provider’s management team and their response was: “You shouldn’t be surprised; these exceptions are noted in our SAS70 report.” I asked him what he did with the report when he received it. His reply: “I filed it in my drawer without turning a page.” Lesson learned!

There is a section of the report to which you should pay particular attention. Titled User Control Considerations, the section essentially lists controls that the SaaS user must implement to mitigate any risks within his operations while using the application. In short: it’s your responsibility! Examples are:

• Ensuring your organization has adequate bandwidth to the Internet
• Providing secure access to each application user
• Creating your own policies and procedures for user access, such as disabling application access upon an employee’s termination

Reading the SAS70 report gives great insight into the SaaS provider’s operations. There were several incidents where I felt certain control objectives of importance to MediClick were missing from our providers’ report. Case in point: one of our hosting sites provides full back-up management services for MediClick. In their report, they tested the control objective regarding the back-up and transfer of the tapes to Iron Mountain. The missing element, which I felt was critical, was the test that validated if the back-up tapes were actually readable! The end result was to add these tests to our own control objectives.

Fate of the SAS70 Audit

Finally, what is the future of the SAS70 audit? It’s changing next year and will be SSAE 16, which is Statement of Standards for Attestation Engagements 16. All service providers with an opinion period ending after July 2011 will be under the new guidelines (please don’t hold me to this as these dates have a tendency to change). You can find further details at http://www.ssae-16.com/. In short, the goal of this process is to align the United States with international standards as designated by the IAASB standards on assurance engagements (http://www.ifac.org/IAASB/); ISAE 3402 (http://www.ssae-16.com/category/isae-3402/).            

It appears new challenges are forming on the horizon. But that’s another trilogy.