These days being a developer isn’t an easy task. Among all the tasks and challenges you already have to deal with, you need to deal with bugs. And here’s the rub, most of the time bugs, specifically client-side bugs, are submitted by end-users. We see 3 key problems with this:
1: Most Users Are Not Tech Savvy
It’s true and whilst we not say it to them directly, we know it. The user knows something’s wrong, because the website is not working for them, but they don’t know why, how to fix it or how to report it.
Try asking your Grandmother what JavaScript is for example. I’m sure it’d be a short conversation. And some users don’t know what the browser is. So how can they properly describe the problem?
[otw_is sidebar=otw-sidebar-1]
2: “It Works For Me”
Thanks to different browsers, standards and developers a website that one user sees can be completely different for another user. When was the last time you made even a simple site that worked, easily, across Chrome, Firefox and IE?
So you can imagine the questions a developer needs to ask the user in order to reproduce a bug:
- Which page were you on?
- What were you doing exactly?
- Did you select the wrong thing?
- Did you add the street address as requested?
- Were you even logged in?
I’m sure you can think of others. But even if the user reported the situation correctly, how often has the developer, or a QA, responded with:
It works on my machine
It’s said so often you can buy the t-shirt on Amazon. To the end user though, what they hear is:
You’ve done something wrong. It’s not the website, it’s you!
Let’s be honest, it happens.
3: The End User Isn’t Experienced With Bug Trackers
The majority of the people who find bugs don’t know how to report them. Despite most companies and projects having copious documentation, explaining how to do so, the results are still questionable.
But let’s say we removed the client from the equation; what super powers would a developer need in order to get the required information to fix a bug, without asking anyone?
- How would they be able to get an overview about the client’s session, including:
- The browser resolution and version
- The operating system and version installed
- The installed browser plugins
- The steps which actually produced the bug
- How could they see through the user’s eyes, so they can understand what’s wrong and where
[otw_is sidebar=otw-sidebar-2]
What Can We Do?
Let’s be honest, the worst thing about most errors users’ report is that they happen on the client-side, in front-end javascript. And this is a cruel, cruel, place, far away from the developer trying to fix them.
It’d be awesome if, somehow, a developer could have the superpower to repeat them, without asking the client to do anything.
Here’s the solution – The Usersnap Console Recorder.
You can read more about the recorder’s marketing jibber jabber, but here’s a quick summary:
- The Usersnap Console Recorder saves every kind of JavaScript error. You can browse the web developer console in the Usersnap dashboard as if you were using your user’s browser
- Every error log contains an NTP synced timestamp, a full stack including JavaScript source files, line numbers and formatting like the developer console you already know & love in Google Chrome and Mozilla Firefox
- Every debug log issued by console.log, console.info, console.warn or console.error is fully formatted, including recursive object/array formatting and browsing
You’ll never see [Object object] hell during debugging!
Now let’s look at some typical scenarios.
Accessing Properties of Undefined or Null Objects
Something which happens quite often in the wild is that a fixed element should be aligned by another element, using the “top” property during scrolling.
But due to a markup rework, the element #inexistent no longer exists. This leads to offset() returning null and the property top can no longer be accessed:
function clicky() {
console.info("Accessing a property of an undefined object");
console.log("calculating scroll top %d", $('#inexistent').offset().top);
};
Calling Methods of Undefined Objects
Here’s another one; you try to call a method on an undefined object.
function clicky2() {
console.info("Calling a method of an undefined object");
adjust.ScrollBottom();
};
Plain Exceptions
Sometimes you even know during development that something can break. Wouldn’t it be great to know when?
function clicky3() {
console.info("Throwing an exception");
throw "Version Mismatch!";
};
XHR Errors
Sometimes XHRs deliver errors, such as 404 (Not Found) or 500 (Internal Server Error). Most of the time these errors lead to bugs which are very hard to reproduce.
function clicky4() {
console.info("404 on XHR");
$.ajax({
"url": "non_existing.php"
});
};
Cross-Origin XHRs are also troublesome. Image someone changes the CORS header and your cross origin XHR no longer work any more.
function clicky5() {
console.info("Cross-Origin on XHR");
$.ajax({
"url": "http://facebook.com/cross-origin"
});
};
[otw_is sidebar=otw-sidebar-3]
XHR and Time Tracking
Recording the Steps During a Checkout
Conversion rates are key in most businesses. Any user obstacle can lower rates. For example, it takes too long to load a page or you have an error during checkout.
This short example shows a standard click handler which calls getcheckout.php via XHR. Unfortunately, the second XHR to confirm.php fails and throws a JavaScript exception.
That’s nice, but: the user doesn’t get any feedback; the page just stalls.
function checkout() {
console.log("check out clicked!");
$.ajax({
url: "getcheckout.php",
dataType: "json"
}).done(function(data) {
console.log("Checked out: %o", data);
confirm();
});
};
function confirm() {
confirmService.checkConfirm();
$.ajax({
url: "confirm.php"
}).error(function() {
throw "internal server error on confirm!";
});
};
Additionally, you get a full synced time frame of your user’s action (regardless if the time on the user’s browser is correct or not!).
The full formatting support for objects (console.log(“Checked out: %o”, data);) is super convenient for debugging.
How To Get Started?
Sign Up for an Usersnap account, if you haven’t already. (Risk-free trial included. Go ahead)
Then create a project, or use an existing one, and click on the gear icon, visible in the screenshot below.
Then click the button Change Widget Look and Feel on the right side of the screen, which you can see in the screenshot below.
You’ll then see a configuration screen like this one. Set Enable Console Recorder to ON and close the window. Now you can paste the widget code on any page you want.
Your clients need only press a button to show you where the error is. Usersnap does the rest. Try it out today!
We know you’ll be impressed.
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.
[otw_is sidebar=otw-sidebar-4]
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.
