Problems are usually reported by clients or end users.
After all, if you already knew about the problem, it would probably be fixed, right? 😉
In this article, I’ll show you some ways that you get info from end users to help solve your problems faster.
Imagine that you’ve just received a frantic message from a client:
“I just visited the site and it’s all messed up. Please fix ASAP!!!”
Next, you open your web browser and the site looks fine.
You try a second browser. The site looks just fine.
And a third. Looks fine.
What is the client talking about? Are they using another browser? Does the browser work differently on another Operating System? Are they viewing on mobile device?
The questions are unending because you have almost no data on the problem.
Collecting the Right Info
You email the client and ask which browser they’re using. The client replies, “Internet Explorer.”
You reply back and ask which version. The client replies, “Where do I find the version?”
You write back with instructions and the client replies, “OK, I’m using version 10.”
You then test the site in IE 10 and still cannot reproduce the issue that the client has described.
After even more back and forth, you discover that the client has Compatibility View turned on.
In the meantime, a lot of time and frustration has been expended on what may turn out to be a simple problem.
What if you could have collected all the same information from the client quickly and painlessly with a single message?
- Operating System
- Browser name
- Browser version
- Screen size
- Browser window size
- Detect Compatibility View with IE
- Flash Player version
- Protocol (Is the user visiting via HTTP or HTTPS?)
- Touch enabled
- Geolocation (in some cases)
- Online/Offline (in some browsers)
If you’re to use server side code, you could also collect the following information
- IP Address (location information)
- Referring page (when applicable)
- User Agent (same OS and browser info list above)
With a little bit of tooling (which can be reused once written), you can easily collect this information from a user who is having trouble.
By making this information easily available, you create an almost frictionless debugging experience. Meaning that it’s almost no effort for the user to provide this information to you and it’s more likely to be accurately reported to you.
There are several low friction ways to collect helpful information from your users and clients. Here are 3 suggestions
- Embedded script in the page – this can be triggered with a lesser used action, like a right-click or double-click which then shows an alert with system info that can easily be copied and pasted into an email, that way it’s unlikely to be used except when you provide instructions to the user. In which case, it’s quite easy to use.
- Comment or contact form – If you have a comment (issue tracking) database, you could connect it to your page and let users submit issues from the page. System info from the user could then be sent with the comment into the database.
Alternatively, you can collect similar info from generic contact form. Lynda.com does this with support issues. The user’s OS and other info is automatically appended to the message. This helps the support team narrow down video playback issues in specific browsers and operating systems.
- Specialized URL – You could add a query string to your regular URL, e.g.
When the site detects the query string, it could display extra info right on the page. When a user has a problem, you can send them the special URL.
Quick tip: Getting the Exact Version of IE
Referring back to the problem at the beginning of this lesson, how do you create collectable info that automatically detects Compatibility View and the exact version of IE?
Most pertinent browser can be collected from the userAgent property.
The userAgent string for IE10 might look something like this
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Typically the part after the browser name (MSIE) would be the correct version.
Unfortunately, when Compatibility View is on, IE actually alters the version listed. So the userAgent string could appear like this
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/6.0)
So how do you get the real version of IE?
Note that between the 2 examples, the Trident value is the same, even when Compatibility View is on. That means you can use it as a check against the listed version (the part after MSIE). The Trident value is 4 below the actual browser version.
A Trident of 5.0 means it’s IE9. A Trident of 5.0 and an MSIE value of 8.0 means the browser is in Compatibility View (because the difference between the values is less than 4).
A Free Course on Problem Solving
I don’t want your problem solving education to end here, so I’ve put together a free three-week course called Eureka! More Problems Solved. This article is taken from one of the lessons in the course, but the email course will walk you through seven other step-by-step solutions.
Get updates from Ajar Productions
Sign up today and get the InDesign Split Text premium extension for free!