User Interface Reading

"X marks the spot"


Learning how to read a user interface, or at least trying to actively see the interface you are using rather than accepting blindly "I click on this button and X happens..." is a good skill to develop.

What do I mean by actively seeing the interface?  Actively seeing is the act of trying to understand why the particular user interface, you are using to do your given administrative task, is designed the way it is and also inferring relationships and meanings from groupings or hierarchies as displayed.

For example on a given tree node snapin such as Computer Management (compmgmt.msc) we see a logical grouping of nodes :

The trick here is thinking to yourself why these nodes are arranged as such, the benefit is if another node is added, say Microsoft Message Queuing (MSMQ) you should have a good idea where to find the added node (Services and Applications for the unfamiliar).  It also allows you to collapse and ignore the items not relevant to your task.

But the basic thrust of what I am trying to get at is a user interface designer, hopefully, sat down and thought out this design and relationships and did so for a reason.  Once you learn to read the interface like a pro, coming into a new possibly unfamiliar layout these skills will allow you to orientate yourself quickly and look like the uber admin you always wanted to be.

Lets take a more complex example, the Exchange 2007/2010 Exchange Management Console (EMC) interface :

Now the initial reaction of a lot of administrators coming from the old Exchange System Manager is that they have repeated the nodes a few times, "Huh, there are two Hub Transport options, what gives?" etc...

The trick again here is to think why (always why).  In this case it is to allow tasks at different levels to be performed or even delegated.  One set of nodes allow you to perform actions that affect the entire Exchange organisation (Transport Rules for example) and one allows you to manage the Connectors for a given Hub Transport role.  Same for mailbox, one allows you to (in Exchange 2010) manage the Database Access Group (DAG) on that abstract level, the other allows you to manage the individual databases making up the smoke and mirrors that is the DAG to users.

This design also allows for the separation of roles and their installation to separate servers, pretty flexible, huh?  Even with the brief explanation above it is a good idea to sit down and have a think, especially if you interact with the EMC on a daily basis, it will give you a hopefully deeper understanding of how Exchange works and how the architecture of this system has changed in the newer versions.

Not all designs are great though, take the delete and refresh buttons on Disk Management :

I don't know about you but for me those buttons are way too close together for my liking.  The thing to take from this is again active seeing, make sure you are not clicking wildly on buttons and just OK-ing dialog boxes or you may have an interesting night trying to rescue a server...

Communication

"Hello, Is there anybody in there? Just nod if you can hear me. Is there anyone home? "


Communication in a busy support environment is vital.  Nothing happens in isolation and the free flow of information from you to your co-workers and back can make for an efficient environment and also help present a unified front to customers.


There is nothing that makes you and your company look unprofessional to external customers and suppliers more than someone calling or emailing them about something a) you have already been notified about, such as planned downtime, b) having to repeat the exact same information to yet another tech about the problem they logged earlier in the day, or c) two techs calling about the same problem within minutes of each other.


They may not say it to you on the phone, and if they do count yourself lucky that they have as you are now aware of it and can catch this bad habit and hopefully with managements cooperation nip it in the bud. But you have no idea what they are thinking and saying to the right people in their company that could affect the next contract renewal when it comes around. Sure you are just a "low level support grunt" how can this affect you, yeah it is going to suck for the sales guy but hey that comes with the territory, right?  Well if enough companies decide to do business elsewhere than your current workplace, there goes your livelihood (as with most of the people in this world you probably rely on one income source) and replacing that is not going to be as fast or as easy as you imagine from within "safe" employment.


So how can you improve communication, well in a support environment, be it the traditional internal IT department or an outsourced help/service desk, you should have four (well five) lines of communication.


So what are these lines you speak of?


1. Talking


Yep that old fashioned get up and go talk to someone and tell them something technique (or if you want to tech it up and save burning a few calories, telephone them).  But nothing beats a quick face to face information dump and you also make sure that they have got the information.  Though just to be sure you should follow it up with the next line of communication.


2. Email


Email is great for two things, the communication is asynchronous, you can fire and forget and carry on with what you are doing. Say for example you have a router down to site a quick email fired off to your team even with a one liner subject like "Main Campus Building A router down, working on it" will alert your team that the servers behind this router are inaccessible so they don't need to waste time problem solving that. It also allows your first liners to smoothly handle calls or even call designated department contacts to stem the inevitable flow of "is the network down?" calls.  Another advantage of email is it gives you an audit trail (always good if you need to talk to management post outage) and also covers your butt as you have something with a time stamp showing when you were aware of the problem and working on it (though of course this would have been logged in your ticketing system, as any good sys admin would).  Which brings us to our third line of communication.


3. Your ticketing system


Not a lot of people think of the ticket/case/incident logging system as a form of communication but it is, say you are working on a complex case and encounter a bus incident.  No I don't mean the bus in your PC dies, I mean you get hit by a bus and are not able to communicate with your co-workers, having good call notes that are able to communicate the problem and the steps and logic you have used up until the bus incident will go a long way to help your colleagues out while you are mending and not thinking about work (you aren't thinking about work, right?) It also ensures continuity of service to the customer even if you experience a less catastrophic event such as a long boring, er... I mean productive meeting that you absolutely can't get out of.  Someone else can pick up where you left off and carry on providing that gold level of service you and your team are renowned for.


4. Instant Messenger (or IM to the internet generation)


Instant messengers are really useful in a support environment as they are for gossiping or organising that night out on the town with your buddies or gal pals. They can allow you to fill someone in live while they are on the phone to the customer with helpful information so y'all can look smooth to external clients.  Much like a news reader reading autocue while listening to their director over the in ear thingy.  IM is also great for asking quick questions or pointing people at useful technical articles and other on-line resources.  IM is pretty easy to set up, there are even some free Jabber based servers and clients if you are on a tight budget.  I would not recommend using a public based IM service such as Google Chat or MSN Messenger simply because you may need to send things like server IPs and names, and other bits of sensitive information via IM and you want to control where this flows through. I should not have to mention that you should never send a user name or password via IM (or even email for that matter, but secure thinking is whole other topic).


But wait you said there were five lines of communication, and I sure did.  The final line of communication is your documentation.  You do document the systems you support?  Of course you do. Having good, or even some documentation can go a long way to fill in the gaps without the newly hired staff and administrators needing to trek up guru mountain to ask those on high how it all hangs together.  Duct tape and bits of string normally, if anyone asks.  So having a good, well populated documentation system can go a long way and save money and time in the long run.  Something as basic as a network share with sub directories of documents is better than nothing.  Or you could use SharePoint from Microsoft for an on-line collaborative project. Another option going down the open source route would be Mediawiki, the same technology that powers that great source of movie and comic book lore, Wikipedia. As this was designed for the common man on the street to contribute to editing and updating for System Administrators should be a breeze. And for the text config file editing averse Windows admins out there it can even be set up on Ubuntu server (sudo apt-get really is not scary at all) with the very friendly Cherokee web server (no need to edit Apache or Nginx config files in Vim or even *shock* Nano).  Pop that into a VM on your ESXi/Vsphere set-up and you are good to go.


Communication does not need to be hard and there are multiple ways in the technical support sector to achieve this, if you take away one thought from this article I would want it to be communicate well and communicate early. If you think something is going to bite someone in the ass, give them a heads up, they'll appreciate it and you.