Recording

JavaScript Error- and XHR Log Recording With Every Bug Report

Let’s start with a story. A user story:

A friend of mine called me in the middle of the day with a very strange request. He told me

“Could you come over and help me to fill-in a form”.

I was surprised as filling forms is the easiest thing to do online, isn’t it? Even for not so-tech-savvy people.

So I went to my friend’s home and surprise, it wasn’t so easy! It took me 25 min to debug what was wrong with this website (a government one, in Bulgaria). The problem was missing validation (via XMLHttpRequest).

Of course, I called the agency, expecting everything to go to /dev/null/, but surprisingly they were interested in the problem, so I spent another 25 min explaining the problem and sending them all data they needed. These included:

  1. Screen Size
  2. Browser and OS version
  3. Where exactly the problem occurs
  4. Javascript errors and XHR Logs (pasted in an email)
  5. Plugins installed on my friend’s browser

etc, etc, etc … you know what I am talking about.

It was exhausting.

The perfect bug report

Let’ step aside from the story and think more like developers. What a developer will need to fix the problem quickly, WITHOUT asking the user difficult questions:

  • Screen size, plugins, installed on your browser, URL where the problem happened, OS and Browser version
  • A visual and annotated screenshot showing where exactly is the problem and how it looks like through the user’s eyes with all steps on how to reproduce the bug.

Right?

Wait, something is missing.

The worst thing about most error reports from users is that they happen on the client-side, in front-end javascript, a cruel, cruel place, far away from the developer trying to fix them.

Agreed? That’s why a perfect bug report should contain something else – a browsable JavaScript error- and XHR-logs recorder.

See

Let’s Talk Code: Recorded JavaScript Errors

The Usersnap Console Recorder saves every kind of JavaScript error. You can browse through the web developer console in the Usersnap dashboard, as if you would sit right on your user’s browser!

Every error / log contains a NTP synced timestamp, a full stack including JavaScript source files and line numbers and formatting like the developer console you already know from Firebug

Every debug log issued by console.log, console.info, console.warn or console.error gets properly formatted (including recursive object/array formatting and browsing).

Guaranteed no [object Object] hell during debugging!

Accessing Properties of Undefined/Null Objects

First example which happens quite often in the wild: a fixed element should be aligned by another element by using the top property during scrolling.

However, due to a markup rework, the element #inexistent does no longer exist. 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

Another rework case here: One tries 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 it when it actually breaks?

function clicky3() {
    console.info("Throwing an exception");
    throw "Version Mismatch!";
};

XHR Errors

Sometimes, XHRs deliver errors (like 404 Not Found or 500 Internal Server Error). Most of the time, such 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 troublesome. Image someone changes the CORS header and your cross origin XHR does no longer work from one day to another.

function clicky5() {
    console.info("Cross-Origin on XHR");
    $.ajax({
        "url": "http://facebook.com/cross-origin"
    });
};

XHR and Time Tracking

Recording the Steps During a Checkout

Conversion rates are key in most businesses. Any obstacle for the user can lower your rates – e.g. it takes too long to load a page or you even have an error during checkout.

This short example shows a standard click handler which calls getcheckout.php via XHR. Unfortunately, the second XHR (confirm.php) fails and throws a JavaScript exception. That’s nice, but: the user does not 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 will 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.

Conclusion

Now every developer can have the superpower of understanding what the problem is even on the client-side and stop worrying about “It does not work. Fix it ASAP!” type of communication.

And now every user will be able to report the issues better, because he/she needs just to press one button to report and issue, using the tools he/she knows well, and the magic will happen in the background.

Free licenses for FOSS projects

We at Usersnap support and believe in the FOSS (Free/Libre and Open Source) movement and that’s why Usersnap is free (as in free beer) for any FOSS project to use.

We utilize a number of open source components like nginx, python, rabbitmq, angular and giving back to the community + improving the quality of your projects is a way to say “Thanks”

Your project must meet all of the following criteria to be approved:

  • The project is licensed under a license approved by the Open Source Initiative.
  • The project source code is available for download.
  • Your open source project has a publicly accessible website.

Apply here.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Three geeks and a microphone – recording screencasts with Telenor in Oslo, Norway

Beginning of last week I spent three days in Oslo, Norway, with Jan Jongboom (@janjongboom) and Sergi Mansilla (@sergimansilla) of Telenor Digital recording screencasts for an upcoming series on Firefox OS aimed at developers in Asia. These will be dubbed and localised, which is not only super exciting, but also very powerful.

sergi and chris

Here’s a quick recap how we managed to create ten different screencasts and six intro/outro videos in two and a half days. It was taxing, it was tiring, but it was also amazing. Many factors played a role, but probably the most important one was a Scandinavian “hands-off” attitude by the video production crew and PR and trusting in the abilities of people involved.

Preparation

Before meeting to record, we shared a Google Doc and created an outline of all the different things we want to cover in the screencast series with scripts for each section. These didn’t have to be detailed scripts as we all knew what we are doing. Just “show app xyz in the emulator, connect phone, push to it” – this sort of thing.

things go here, only things, not stuff

Heads up: I’ve recorded other screencasts that had very defined scripts like “go to the input box, enter ‘fiddlesticks’ and press the button labeled ‘submit’, explain the viewer that this sends the form to the server”. These can work and are important if the person recording is not familiar with the matter or the script needs review by 8 managers and 5 random people from the legal department. We were lucky to have a much more freedom as these screencasts were meant by developers for developers.

We agreed what to show and wrote the code, sharing it on GitHub.

This is immensely important: the code needs to work and be done. You can of course fake to write it live in the screencast using the AppleScript by William Bamberg and me or Stuart Langridge’s Sublime Text plugin. You will not have any time to re-code much (I did clean a few things up) and you will lose time with technical issues as it is (we lost an hour to an appcache problem and another with some problems with the Marketplace submission process). This is not the time to be a coder ninja – this is the time to be an educator, so make sure your stuff works, is documented and understandable before hitting the record button.

Technical set-up

All in all our setup was simple:

  1. A dedicated room that is sound-proof-ish with a large table. Adding a thick black tablecloth to it prevented both unintended “knock” sounds on the recording and made for a good background for recording the mobile device
  2. A good USB microphone that can be easily handed over from presenter to presenter (we used a Yeti).
  3. Three computers, one being the dedicated recording machine, the others for writing and editing. The main machine was a Retina MBP, as you can never have too high a resolution of your original material (downsampling is easy, blowing up video makes it blurry). It is also important to have one machine to record on as this means all the editor settings and the look of the Desktop is the same in all videos. It also means that only one of us had to clean up their machine and start a whole new, clean profile without embarassing autocompletes and history entries (we chose Sergi’s – he is by far the most grown-up and organised amongst us).
  4. An external HD (500GB, USB3) to store all the videos and transfer large files from one computer to another
  5. Screenflow to record and edit the screencasts
  6. A small HD video camera with a Gorilla Tripod to record on-device actions that needs to show hands

Recording and editing

Once all was set up, we divvied up the different screencasts amongst us and got started recording them. We spent the first two days only recording screencasts and left the “talking heads” video shoots for the last day. That way we could work without having to have the film crew around which is a good thing as they tend to be paid by the hour.

jan recording video

People have different ways of working and it is important to allow them to apply their strengths if you want to create a lot in a short amount of time. Us three, for example, learned that I am most comfortable when I speak and show what happens in the screencast at the same time (a running commentary of my own actions). I am not happy reading from a script, as I did that as a job for far too long before escaping to the web (I worked as a radio newscaster).

Both Jan and Sergi struggled with showing and explaining at the same time and thus got much more effective when recording the screencast without audio, then writing a script and re-recording a video of the screencast and narrating the script over it.

The great thing about Jan and Sergi’s MO is that it allows for asynchronous creation of content: when recording and doing the live coding any distraction in the room is tricky to work with and you need to use the one machine to record. When de-coupling the recording of the audio, the editing of the screencasts and the writing of the scripts you can silently sit in the room and edit or write while the others are recording. The thick table-cloth and the quality of the microphone made sure you couldn’t hear any typing in the background. Swearing, yes, but that could and was cut.

The way we recorded worked the following way:

  1. We recorded the screencast according to the script, one person recording and another making sure there are no issues with the recording (for example “learn Indian” as a To-Do List item in an app could be offensive, as there is no “one” Indian language). Make sure to leave some breaks in the screencast to allow for more detailed narration.
  2. The person who recorded then can go and look at the screencast on another computer and write the script of it.
  3. Meanwhile the other two can record the next section
  4. Each script then got another peer review to edit for flow (active vs. passive language, adding the “what is in it for me” messaging, shortening of sentences and many other tricks – if you are interested I can do an own post about that)
  5. Once the script is done, the presenter goes back to the main computer and records a screencast speaking over the old recording, taking breaks to cough and assemble thoughts as needed without endangering the quality of the recording – all you need to do is to stop the video part of it. You even don’t need to worry about the size of the video and you can resize Screenflow and have a text editor with your script side-by-side.

It is important to keep the recording going. Stopping every time you mess up and starting from scratch only increases the frustration. The same rules apply that apply on stage: you can mess up – just admit it, take a very short break and move on. You can always edit, and it is easier to cut out a single “shit!” than to have to make a very annoyed sounding start of a screencast palpable for viewers.

Editing

The final production of the videos will be done by the professional editing team, but, as they are paid by the hour and because of the way we already used Screenflow to record and separated audio and video we could do a lot of the editing ourselves, cutting the “uhms” and “errs” and heavy breathing and adding still images over longer parts of narration. Screenflow makes this super easy by hitting “t” at the place you want to split the audio or video streams and moving the chunks around.

Next steps

Currently the videos are in production and will be dubbed and we’re putting together the landing page on the Wiki where they will reside. We also clean up our outline and script to be the descriptions of the videos. Thus, nothing was wasted.

Before you go on a righteous rant about professional screencasting…

We are very much aware that professional screencasting and recording looks different and by no means we want to say that it should always be that easy. Professional learning materials need much more planning and more meticulous execution and you should pay people who do that well what they deserve – a lot.
However, for three geeks and a microphone, we’ve done quite well and this might inspire others to do the same.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

[Evangelism Reps] How to say “hi” with a quick video – recording and editing

One of the things we want participants in the The Evangelism Reps program to do is give us a quick introduction video of themselves to have a face to connect to a name. This should not be anything big, a simple, “hi, here I am” will suffice. So here is my introduction as an example.

All in all the production and publication time of this was an hour – and that included cycling a mile to find a shop that has Tofu sausages and Babybel cheese. Here’s what I used:

  • A MacBook Air (could be any laptop with a camera)
  • Photobooth (or any other tool that can record a camera – this could be on your mobile, too)
  • MPEG Streamclip

The first thing to remember when trying to do something like this is to simply for go for it. So I wrote myself a little script and just had it open next to the recording tool:

Technically, this is not good, but I wanted to do this quickly. You can see my eyes flicking to my script from time to time. I shouldn’t have to as I knew what I wanted to say but humans work that way. Give us a “Linus blanket” and we will always come back to it.

Regardless, of course this didn’t work in one go, so here is the full recording with out-takes:

This is the simplest way to record – don’t try to re-start the recording and delete it in between failed takes, just go on and cut the bits that didn’t work afterwards.

You can see that I waved my hand over the screen every time I started again. This is the sign to myself that another take started.

For cutting, I used MPEG Streamclip which couldn’t be simpler:

  1. Go to the hand movement and find the start of the next take
  2. Hit O for “out” – this highlights the video from start to where you are now
  3. Press cmd+x to cut (delete) the video up to the point where you are
  4. Find the end of the video
  5. Press I for “in” to mark the video from there to the end
  6. Press cmd+x again
  7. Save as MP4

You can see this in action on vid.ly.

All in all this is very simple to do, so I am looking forward to a lot of those cropping up in the nearer future.


View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)