RSS Feed
Jul 28

Tech Support for Mere Mortals

Posted on Wednesday, July 28, 2010 in Uncategorized

If you use computers, then you have most likely been in need of tech support at one point or another. Whether it be professional technical support from your computer vendor or the geek in the family.

Technical support is easy when you have the machine in front of you. Basically, you can just do what you need to do without having to explain a thing. The person whose computer you’re fixing only needs to keep the cookies and juice coming. When you’re done, you announce “The computer is fixed”. The user doesn’t care what you did or how you did it. It is only important that the computer be restored to working order.

An alternative to having the machine in front of you is to login to the machine remotely and fix the problem. Windows® comes with the Remote Desktop feature, but only for the Professional versions and above. There is also the Remote Assistance feature, but I have never been able to get either of them to work reliably through the public internet. There was always something in the way – be it a firewall, network policy or whatever.

Remote assistance may not always be the best way, especially if it is necessary to reboot, or connect stuff to the computer, or do anything which requires physical presence. This brings us to the most painful form of technical support (for both user & coder): phone support.

When the user knows their way around computers, then it can be easy to deal with tech support. But sometimes, dear coder, you have to deal with users who are not as skilled as you. At such times, asking the user for their MAC address won’t cut it. You need to walk them through the steps to find it and read it to you.

This usually goes something like:

User: “Hello, my internet is not working

Support: “Ok. We need to open the Network and Sharing Center. Click Start and ….

User: “Wait, wait, please! Where is ‘Start’? I can’t find it

Support: “Oh sorry. Click the round blue button at the bottom of your screen

User: “Ok done

Support: “Now ……..”

And so it continues.

Scott Hanselman proposed FizzBin as a passphrase to inform tech support that you know your way around computers. But there is still the issue of abuse of the passphrase.

A recent incident at a student hostel in the Technical University of Aachen (RWTH Aachen) illustrates the point. A student’s computer was infected by a virus and the network administrator cut-off network access for the machine. In order for access to be restored, the student had to answer some questions.

Imagine a user suddenly losing their internet connection at home for no apparent reason. The next day at work/school, they check their email and see a list of questions. Here is a rough translation of the questions and answers you might get from your user.

1. What Operating system are you using? What is the patch level?

User: “I don’t know. It is Windows…erm… something! What is patch level?”

2. What virus was found on the computer (give the installation date)?

User: “Virus? Does my PC have a virus? I saw something like: [email protected] Is that a virus? I didn’t install anything!!”

3. What product did you use to get rid of the virus?

User: “I use Antivirus.”

4. What did Sophos say about the virus?

User: “What is Sophos??”

5. How did you get rid of the virus?

User: “I don’t know. Antivirus??”

6. How did the virus get onto the machine.

User: “Dude!!! I don’t know.”

7. What did you do to prevent future infection?

User: “I will use Antivirus”

You end up confusing your user more than helping, and you have not learned anything new in the process. Take this to heart, dear coder, during you next support call and tread gently with your users.

Jul 19

Well, this is embarrassing.

Posted on Monday, July 19, 2010 in Uncategorized

It is a well known fact in software development that users do not read. Whether it be your nicely formatted error dialog box or some long introduction on your website. Your users generally just scan the text, click ok (or cancel, whichever is convenient) and move on. But when they do scan your text, you want to make sure they get the message right.

Getting the message right is not as trivial as it sounds. Sometimes, you the developer just forget that your user interface text is not aimed at programmers. (That’s what code comments are for). Other times, some text can be interpreted to mean something else. Let’s examine an example in Firefox.

Most modern browsers have a session recovery feature. This is the feature which makes sure that after a browser crash, you can get back to where you were on the Interwebs, tabs and all. Firefox has had this feature for a while now. If you are a regular Firefox user, then you have probably seen this page before.


Now most geeks or techie types will think nothing of this page. You have probably read about it on many different blogs before the feature was ever released and already know the message written there by heart. You will either click ‘Restore’  or ‘Start New Session’ and get going.

But I recently happened to be able to observe the reaction of a normal (non-techie) user when seeing this page for the first time. My cousin switched on the computer and opened the browser. It seemed the computer had been force shutdown, so the page that came up first was the one above. I noticed the look of horror on my cousin’s face and the question “What did I do?”. I quickly rushed over and when I noticed the page, I went on the reassure her that it was ok and clicking restore would do the trick.

This was an interesting experience for me. I personally had never given second thought to the message before. What about you? Think about the displayed message for a bit.


Most users will only ever read the text in bold. “Well, this is embarrassing.” Without the explanatory text below, it seems to be telling the user that they have done something embarrassing which is causing Firefox not to display the page. Therefore, by implication, the crash is their fault. So while Mozilla may have meant this to be some fun, tongue-in-cheek message (and I personally like it), it may convey a totally wrong meaning and blame to some users.

Let’s look at how Chrome communicates a tab crash to the user.


The icon already informs the user that something went wrong, and the explanatory text tries to be as simple and direct as possible (although users may still not read it). The message above is shown when a single tab crashes, due to Chrome’s multi-process architecture. What about the case where the whole browser crashes? This is what you see.


This view simply offers the choice to restore the tabs and spares the users the details. It both crash cases in Chrome, note the use of language which avoids blaming the user (or inferring blame).

Hopefully, next time you are writing any text in software which is to be seen by a mere mortal, you will think a bit more about it. Always remember that the more words there are, the less likely your users will read them. So let your words be few, and direct to the point!