It's 4:45 PM on a Friday and I know I am going to spend my weekend remoting into a mail server that has absolutely combusted. Google searches are pulling up knowledgebase articles that have nothing to do with what I'm looking for and the forums are caustic, at best. I am desperately searching for the specific command that alters Carbon Copy Cloner's access parameters for OS X Mountain Lion. After that, I need to know if it will apply to the other server that runs Snow Leopard.
I get on slack, I get on jabber, I email and I text my colleagues...we are all in the same boat. We just can't find what we need.
This is a case study of an application that I am developing to alleviate this situation. Being in the field can feel isolating and the ultimate objective of the product is to go beyond simply finding information and create a sense of community. I hope the application will provide an ever-growing environment where technicians of any experience level feel welcomed and valued. Instead of forcing humanity into the context of technology, I want technology to operate within the context of humanity. Beyond the servers, there are people out there!
The Status Quo and Opportunity for Change
Every technical support engineer I know has a notebook like the one above. We scrawl useful commands and diagrams in them and then we tear out the pages when we realize they are obsolete or inaccurate. We discover useful commands and share them with each other. We warn each other when a bad command turns a laptop into an expensive paperweight.
We find something useful in the field - it goes into the notebook. Apple updates something - pages become useless. Apple updates something again and, suddenly, you just threw away information you won't be able to find again for months. Knowledgebase articles aren't updated yet, and people are arguing about best practices on the forums.
Finding accurate and viable information on the internet efficiently while under pressure is an arduous task for anyone. Add to this the pressure that your job, and the jobs of others, hangs in the balance of your hurried scouring of forums and online vendor resources, and the challenge becomes a desperate struggle. The technical support role is a rare instance where exact strings of text are needed quickly and in a specific order.
IT Consultants, Network Engineers, On-site and Remote Technical Support professionals need a fast and dynamic catalog of these commands. Further, they need to share the information and track it as it becomes obsolete. However, they also need a way to retain an archive of older commands. Enterprise organizations are often the last to move to newer operating systems. "Shadow IT", groups or individuals within organizations that do not follow their subscribed IT protocols, often push ahead in upgrades without telling anyone until something is badly broken. Because of this, it is typical to find a mosaic of different operating systems when supporting enterprise clients.
Understanding the Situation
The first logical step was to discuss the problem with my colleagues and conceptualize possible solutions. Through these conversations, I began drafting functional requirements for an application to support me and my colleagues in the field.
Often, an Apple technician carries the lightest laptop possible - a Macbook Air. Cables, power bricks, and adapters add up to a heavy bag. These machines typically have smaller hard drives and less RAM than their stronger (and heavier) counterparts.
My colleagues remarked that, as a technician, you run more concurrent processes and initiate more threads per hour than the average user. Data from our device management framework shows that it is common for an onsite technician's machine to run at 110% processor capacity for two hours at a time. After this, root memory issues begin to appear as memory pressure rises leading, ultimately, to failure.
Furthermore, advances in web technology and offsetting server load to the client has been detrimental to the onsite technician. Specifically, the graphics acceleration found in Google Chrome and Safari can utilize more resources than one would like while visiting certain websites, causing machines to hang in the middle of intensive processes and scripts. Having your machine crash while remotely logged in to a server that is itself on the brink of failure is a frightening situation.
I propose a lightweight, streamlined application called TerminalPOP that simply tells you what to pop in the terminal. Most of the overhead processing is performed by the server, and the site will serve mostly text. There is a huge opportunity here for a self-sustaining community that is built to share through experience, not to teach through scolding and admonition, as I have seen on other forum-based sites.
The information architecture hinges on treating this information like any other tangible object. When we go to a forum, we see what date the post hit the forum, but we don't necessarily know when the information, itself, was published. The forum post is an intelligent object but the information stored is naive.
Further, I propose a bilateral search capability. There are times, as a tech, that you are looking for something in a very granular way - you need to know if Carbon Copy Cloner's access rights are the same default settings for Snow Leopard as for Mountain Lion (they aren't). Other times, you have gone through your typical troubleshooting steps and you are looking for new avenues to explore.
If we treat the information the same as say, a notebook, we can truly own, search and share these objects. If the metadata is in place, we can make this information tangible and personal. Users can explain their own experience with the information, thereby giving the technical data much-needed context.
Software engineers need to be careful when contemplating how the database objects will be exposed to the front-end. In enterprise environments, an application that makes too many requests per minute may get locked out of the firewall. Conversely, overloading a technician's computer at a mission-critical moment could cost dozens of man-hours to remediate the damage. The technician's reuptation may never recover with the client.
The original concept was to split the application between those who consume the data and those who create the data - to "Get Help" or "Give Help". After talking to a friend of mine in the tech industry, she pointed out that the last thing she wants to do when she goes to a website is to decide who the information is for. I cannot be too attached to my own ideas, and I have to analyze what the real objective of the application is. It is not to display a string of characters, it is to help people troubleshoot.
Below are screenshots from a prototype Django project. It is living in a virtual environment and operating off of my local postgres database. Objects are dynamically exposed from the database to the front end with Python. For example, the calendar and search pages below are displayed purely by server-side logic. On page load, the python asks itself what day to start the calendar and pulls a stack of objects for that given date, picks a random one, displays the date and loads both the URL for the placeholder image as well as the URL for the article, itself.
The Code...and its Problems
Maintaining most of the logic on the server end opens up myriad possibilities for usability...and also opportunities for massive security vulnerabilites. Essentially, users will be able to upload and store strings of code as independent objects. However, this also opens up the possibility of malicious users executing their own code on the server.
The information architecture should focus solely on the application's objective - to help people troubleshoot!
Closing the Loop
There are many opportunities for application growth. These include club-type functionality, in which users can create their own groups and clubs, integration and portability, in which the application is ported via an API or hooked into an existing help-desk ticketing system, or an extension of the core services with features like voice and video chat.
The ultimate goal for the application is a completely community-based maintenance model and a truly social environment. Before any testing can happen with the application, the next steps are storyboarding, challenge maps and more planning. I need to stay ahead of any bottlenecks and create as many personas' user journeys as possible, before moving on to a working prototype. After this, the next steps are testing, testing and testing - in that order.