console.blog()

Matching UI Behavior with User Behavior

Craig — Mon, 07 Nov 2011 12:36:00 +0000

The viewport is a direct window into what the user sees, and a lot can be learned by watching it. In my previous post I introduced Within Viewport and I want to discuss how, particularly through my Twitter app signal:noise, I’ve found it useful in making interfaces respond sensibly to user behavior.

Dynamic content loading

A common solution for developers looking to increase their site’s performance is to load data on demand, for example using Infinite Scroll. But sometimes the scroll position isn’t enough — you need to know about the content on screen.

In signal:noise I want to control how heavier content is loaded. Since a tweet is a paltry 140 characters, and dynamically adding more of them to the top of a page causes it to scroll, it’s reasonable to start out by loading fifty or so at the initial page load. But when you factor in images and video previews linked within those tweets (which signal:noise presents inline) the page can take longer to load. I use Within Viewport to make sure I’m only loading media for tweets that are on screen or just about to be shown.

Responding to user behavior

The obvious thing to do when a user reaches the boundary of their timeline is to load more tweets. But it takes time to call the Twitter API (possibly more than once), process that response, and send the new content back to the client. By comparing the number of tweets in the user’s field of view to the number that are out of sight, and tracking the speed with which those tweets move in and out view, the app can get a sense of the user’s momentum. With this knowledge the app can avoid calling the API too late (not having tweets ready to go) or too soon (unnecessarily hitting the API rate limit).

Making appropriate measurements

The app also tracks each user’s reading position so the can resume reading at the same place in future sessions. When determining which tweets have been read, it only makes sense to consider ones that are fully in view. The app has a fixed header that shrinks the viewport by about 60 pixels, so I need to make sure a tweet is not covered by that.

Larger version

Live updates

My app also allows keyboard navigation from tweet to tweet, similar to Google Reader. When the user jumps to a tweet that is not completely visible, the app needs to know so it can scroll the page.

Tracking usage

While not directly applicable to a Twitter app, you may want to find out what areas of your site a visitor actually sees. By firing events when sections move into and out of the viewport, you can use Google Analytics’ Event Tracking to find out how often users actually see parts of your page. Wondering why a particular widget doesn’t result in many click throughs? Perhaps the answer is as simple as not many people even get to see it.

And more?

All that from just a viewport? I initially wrote Within Viewport to solve only one of the problems above, but I soon found many other uses for it. It wasn’t until I began using it that I realized, as obvious as this may seem, how pertinent the viewport is as an insight to the user’s experience.

If you have any other ideas, or suggested additions to the script, I’d love to hear it in the comments.

Within Viewport: JavaScript and jQuery Plugin

Craig — Mon, 07 Nov 2011 12:29:07 +0000

Within Viewport indicates whether an element is entirely within the viewport. It also allows you to specify your site’s effective viewport (eg, to account for fixed header and navigation bars) and provides a few handy shortcut notations.

It’s quite simply to use:

var elem = document.getElementById("myElem");

// Returns true if it's completely visible
withinViewport(elem);

// Same as above, but using the jQuery plugin
$(elem).is(":within-viewport");

// Run some function on all visible divs
$("div").withinViewport().myFunction();

There are a few “in view” scripts out there — namely, Mika Tuupola’s Viewport Selectors for jQuery provides some convenient selectors that can be tested against elements, and Remy Sharp’s Element ‘in view’ Event Plugin fires events when elements pass in and out of the viewport.

While useful, these utilities only detect whether elements are partially in view. The aim of Within Viewport is to determine what content the user can see and interact with.

Use Cases

A lot can be learned from monitoring the viewport, especially on a site with content that spans well outside of the user’s view. I will discuss how I use Within Viewport in much more detail in my next post. But here’s a quick overview of what you can do.

Dynamic content loading

A site’s performance can be increased effectively by loading data on demand, for example when the user scrolls near the bottom of the page. But perhaps the content on screen is more pertinent than the scroll position. For example, you may want to load the entire structure of your site during the initial page load, but then populate that structure with heavier media as it nears the user’s field of view.
Responding to user behavior

You may also want to tailor when that content is loaded based on how rapidly the user moves about the page. If you are relying on a third party API for content, you may want to start the process sooner than you would begin requested content from your own server.

For example, the script below would find and load items with local content that is merely just beyond the viewport, but also load third-party content that appears much further down the page.
```
// Image placeholders at most 100px below the fold
$('img:not([data-src^="http://"]')
    .withinViewport({bottom:-100})
        .loadTheseImages();

// Image placeholders as far as 500px below the fold
$('img[data-src^="http://"]')
    .withinViewport({bottom:-500})
        .loadTheseImages();
```
Making appropriate measurements

If you want to know what your user has seen, for example to remember their reading position in a feed, you can only consider ones that are fully in view. You also need to take into account the actual viewport, avoiding things like fixed header bars that cover parts of the page.

Larger version
Live updates

If you implement keyboard navigation between items, similar to Google Reader, you need to make sure a newly-selected item is actually visible.
Tracking how your app is used

You can tap into Google Analytics’ Event Tracking to find out how often items enter your visitor’s field of view.

I built Within Viewport to accomodate those needs, but I made it generic enough that any site or web app could benefit from it. There are configurable defaults and several shorthand notations described with examples in the documentation.

No jQuery? No problem

I wanted to write a tool that was independent of jQuery so it could be dropped into any project. Of course jQuery does offer some useful mechanisms such as filtering and custom selectors, so I added an optional plugin to provide that functionality.

Complete cross-browser console.log()

Craig — Tue, 12 Apr 2011 16:55:28 +0000

Many front-end web developers make use of the wonderful browser consoles that have matured in the past few years. While the tried-and-true console.log() often does the trick, its lack of support (particularly in IE) has led to the use of proxy functions, such as Paul Irish’s console.log wrapper and Ben Alman’s Debug() which prevent unsupportive browsers from throwing errors.

I had a need for logging data in every browser, not just ones that natively support console.log(). So I forked Paul’s function and expanded it to work with every browser I could test — IE6+, Firefox 3.6-4, Chrome 10-11, Safari 5, and Opera 11.

This will be exhaustive, so you may want to jump directly to:

Current state of the console

Like Paul’s implementation, we’re simply going to create a function called log() and pass along any arguments it receives to console.log(). But before that we need to do a little setup to ensure that, when possible, console.log() is properly defined as a function in every browser.

First, let’s review console support in today’s browsers:

Chrome, Safari, Opera: native console.log()
Firefox: native console.log() with Firebug
IE9: native console.log(), but it needs a little nudge to turn on
IE8: While console.log() exists, it’s an object rather than a function — But we can still write to the console with a clever trick.
Others: We can inject Firebug Lite which will define console.log() as a function

Note that when I talk about IE I’m referring to the native versions — “IE8″ means IE8, not IE9 switched to IE8 mode with the Developer Tools.

IE9

Before we build log() we need to tell IE9 to use its own console and to consider console.log() to be a function. Many thanks to Andy E for this piece.

if (typeof console.log == "object" && Function.prototype.bind && console) {
	["log","info","warn","error","assert","dir","clear","profile","profileEnd"]
		.forEach(function (method) {
			console[method] = this.call(console[method], console);
		}, Function.prototype.bind);
}

For this particular case we really only need to define the log method, but it can’t hurt to flip the switch on the others as well.

Modern browsers

Now we can define log(). There’s no sense in re-inventing a very round wheel, so I’m just going to fork Paul Irish’s original console.log wrapper.

if (!window.log) {
	window.log = function () {
    log.history = log.history || [];  // store logs to an array for reference
    log.history.push(arguments);
	if (typeof console.log == 'function') {
		// Modern browsers
		if ((Array.prototype.slice.call(arguments)).length == 1 && typeof Array.prototype.slice.call(arguments)[0] == 'string') {
			console.log( (Array.prototype.slice.call(arguments)).toString() );
		}
		else {
			console.log( Array.prototype.slice.call(arguments) );
		}
	}
	// to be continued...

Notice that if() condition. Paul’s use of Array.prototype.slice.call() is great because you can pass along any amount and variety of objects, strings, functions, etc directly to the console. However, there’s one unfortunate side effect: in Firebug and Chrome (and possibly others), if the argument array’s sole content is a single string greater than 50 characters, it will be truncated faster than you can say Llanfairpwllgwyngyllgoger…wllllantysiliogogogoch.

So we’ll check the array length, and if it’s 1, and that 1 thing is a string, then we’ll convert the entire argument array to a string before passing it along. You could use console.error() to avoid truncation, but then it will look like an error when it’s not.

Opera

So that takes care of the modern browsers… except Opera. Opera seems to display the arguments as a whole Array() rather than splitting them apart. So if you passed several arguments you’d just see this:

And that’s not too helpful. We can get around this with a rather boring while() loop to log each argument one by one.

var log = function () {
			// Modern browsers
			if (typeof console != 'undefined' && typeof console.log == 'function') {
				// Opera 11
				if (window.opera) {
					var i = 0;
					while (i < arguments.length) {
						console.log("Item " + (i+1) + ": " + arguments[i]);
						i++;
					}
				}
				// All other modern browsers
				else if ((Array.prototype.slice.call(arguments)).length == 1 && typeof Array.prototype.slice.call(arguments)[0] == 'string') {
					console.log( (Array.prototype.slice.call(arguments)).toString() );
				}
				else {
					console.log( Array.prototype.slice.call(arguments) );
				}
			}
			// to be continued...

Which results in:

It’s a little messy and if you use log() a lot you’ll find that your console will fill up fast, so you’ll have to decide how important Opera support is to you.

IE8

As we discussed earlier, IE8 has a console but your scripts can’t call console.log() directly, so we’re going to add a special condition for it. Andy’s aforementioned post included a similar bit of code for writing to IE8′s console, however in actual IE8 (as opposed to IE9 switched to IE8 mode) Function.prototype.bind is not defined. Instead, I’m using @kangax‘s alternative, Function.prototype.call.call().

			else if (!Function.prototype.bind && typeof console != 'undefined' && typeof console.log == 'object') {
				Function.prototype.call.call(console.log, console, Array.prototype.slice.call(arguments));
			}

One slight alteration: I changed the second part of the condition from console to typeof console != 'undefined'). It seems a little silly, but IE7 actually throws an error without the typeof check.

Older browsers

Now we’re going to inject Firebug Lite (“FBL”) for all the other browsers — namely, IE7 and older — by adding a

console.blog()

Matching UI Behavior with User Behavior

Dynamic content loading

Responding to user behavior

Making appropriate measurements

Live updates

Tracking usage

And more?

Within Viewport: JavaScript and jQuery Plugin

Use Cases

Dynamic content loading

Responding to user behavior

Making appropriate measurements

Live updates

Tracking how your app is used

No jQuery? No problem

Complete cross-browser console.log()

Current state of the console

IE9

Modern browsers

Opera

IE8

Older browsers