http://stackoverflow.com/questions/9107384/server-scalability-html-5-websockets-vs-comet

Wednesday, February 15, 2012, 6:30 PM

Caplin will be hosting an “Agile UX Safari” in a couple of weeks. It will be a little different to the last one at MindCandy (we don’t have a tree house in our boardroom!) but we share their passion for design and development and mixing the perfect Agile/UX cocktail.

Check out the event –  We look forward to hosting a healthy discussion on all things design, UX and agile.

Inspiring feelings of awe

I remember the buzz created around Google Wave back in 2008/2009, of all the innovative interactions and GUI elements introduced, their scrollbars were the one GUI element that really caught my attention:

I was really surprised to find out that Wave’s scrollbars were actually first designed for Sun Mycrosystems and AT&T’s Open Look GUI. Yet Google took the credit for innovative interaction, the posts below are an evidence of that:

Google Wave’s Clever Way Of Saving Scrollbar Space
Google Wave’s Scrollbars
Google Wave Scrollbars jQuery plugin

More recently Apple (in regards to their application Siri) and Simple have shown how powerful natural language interactions can be.

Deborah Mayhew in her 1991 book “Principles and Guidelines in Software User Interface Design” describes in great detail the use of Natural Language on interfaces.

Why is it that 20 years later that’s something that still strikes us as highly innovative, even revolutionary?

A First Look at BankSimple (skip to 2:45 min for an example of a natural language search)

Know your history, know thyself

Turns out the examples above have just recently reached the public and become mainstream thanks to companies like Apple and Google rescuing them from the chest of interaction design history. The fact that these are companies familiar to the general public only helps reinforce the “oh wow, they’ve done it again” feeling. Yet the foundation of these interactions have been developed/implemented a long time ago.

For some of the earliest examples of interaction design take a look at Ivan Shuterland’s 1962 Sketchpad demo or Douglas Engelbart’s 1968 “Mother of All Demos”, shown below.

Mind blowing stuff if you realize that was half a century ago!

(r)Evolution?

Companies recognized by great interaction design have certain common traits: a deep understanding of interaction design history, of the technical and/or market constraints that might have hindered the use of certain patterns and their eyes open for opportunities to rescue and reapply those ideas.

Check back soon for more historical interaction design awesomeness!

Further Reading

If you’re interested on the history and evolution of GUIs I recommend you check out the books below. Most of them are available on Amazon for very reasonable prices.

Designing the User Interface: Strategies for Effective Human-computer Interaction (1986) — Ben Shneiderman, Catherine Plaisant

The Art of Human/Computer Interface Design (1990) — Brenda Laurel

Graphic Design for Electronic Documents and User Interfaces (1991) — Aaron Marcus

Principles and Guidelines in Software User Interface Design (1991) — Deborah J. Mayhew

The Cross-GUI Handbook for Multiplatform User Interface Design (1994) — Aaron Marcus, et al

Human Computer Interaction (1994) — Jenny Preece, et al

The Guidebook Gallery is also a great resource for screenshots, magazine articles and ads of historical GUIs.

var a = "cat";
(function() {
    var a = "dog";
    delete a;
    a = "fish";
    console.log(a);
})();
console.log(a);

The intention is to remove the local version of a from scope so that we can reassign the global version of a to “fish”. Will it work? What will be printed out?

1. a) fish, fish (success)
2. b) fish, cat (failure)
3. c) a different combination
4. d) depends on the browser (always a good option if you’re guessing)
5. e) depends on the execution context

The answer in this specific case is b, the answer to more general questions about this sort of thing is e (we’ll come back to that later). It doesn’t work! The value of the global version of a is unchanged. This demonstrates a fundamental point about the delete operator:

You cannot delete anything declared with var.

This applies even to variables that you declare within functions; once you declare them they exist forever. Bear this in mind if you want to remove something from scope using the delete operator, because it won’t work. We can fix the code by explicitly reassigning the global version of a rather than using delete:

var a = "cat";
(function() {
    var a = "dog";
    this.a = "fish";
    console.log(a);     // prints "dog"
})();
console.log(a);         // prints "fish"

So, what is going on with the delete operator?

First things first

The delete operator returns a boolean value. We can use this to get a better understanding of how it works (and doesn’t work). However there is one gotcha with the return value – whether it is true or false depends on whether the object exists afterwards, not whether the delete was successful.

It’s a subtle difference, but it means that delete will return true if you try to delete something that never existed in the first place. You might not expect that. I didn’t.

var a = "you can't delete me!";
console.log(delete a);          // prints false
console.log(delete octopus);    // prints true!

Deleting in global scope

Everything you declare in global scope, with or without the var keyword (which creates the new variable in local scope), also becomes a property of the global object.

var a = "apples";
b = "oranges";

console.log(window.a);	// prints "apples"
console.log(window.b);	// prints "oranges"

It’s worth mentioning at this point that declaring a variable without the var keyword is illegal in ECMAScript and will throw an error if you try to do it in strict mode. This is a good thing because declaring a variable without using var often indicates that the programmer mistyped the name of an existing variable. Strict mode makes this kind of error fail fast. Unfortunately strict mode is not widely used, so for now we will have to pretend it doesn’t exist.

Going back to the example, let’s see what happens if we try to delete a and b.

var a = "apples";
b = "oranges";

console.log(delete a);	// prints false
console.log(delete b);	// prints true

console.log(window.a);	// prints "apples"
console.log(window.b);	// prints undefined

Since it was declared with var the variable a is an object in global space and can never be deleted. However variable b was declared using sneaky shorthand to create a property on the global object, and properties can be deleted. In fact this is the main purpose of the delete operator:

The delete operator is for deleting properties, not objects.

So far, so good!

Deleting in function scope

The good news is that delete in function scope works the same way as in global scope. However it does provide a good demonstration of the point above, which is that failing to use the var keyword causes things to leak into global scope.

(function() {
	var a = "apples";
	b = "oranges";

	console.log(window.a);	// prints undefined
	console.log(window.b);	// prints "oranges"

	console.log(delete a);	// prints false
	console.log(delete b);	// prints true

	console.log(window.a);	// prints undefined
	console.log(window.b);	// prints undefined

	console.log(a);			// prints "apples"
	console.log(b);			// Error: b is not defined
})();

The example shows that the local variable a which was correctly initialised with var can never be deleted, but b (which is actually window.b) can be deleted.

Deleting in eval scope

Back at the start of this article I claimed that the answer to the initial puzzle depends on the “execution context”. JavaScript has three execution contexts, and the good news is that we have already covered two of them:

1. 1. Global code
2. 2. Function code
3. 3. Eval code

The bad news is that the third case causes the delete operator to behave differently to what we have seen so far. The worse news is that it causes us to throw out what has so far been a golden rule – you can’t delete anything created with the var keyword.

eval('var a = "cat";' +
'console.log(window.a);' +	// prints "cat"
'console.log(delete a);' +	// prints true (?!)
'console.log(window.a);' +	// prints undefined
'console.log(a);');			// Error: a is not defined

In this case we declare var a and see that a has found its way on to the window object, which is familiar behaviour implying that we are in global scope. However things then take a twist when we discover that inside an eval statement it is possible to delete a.

You might be thinking “who cares, I never use eval”, but just remember that browser developer tools such as the Firefox Scratchpad work by putting whatever code you enter into an eval statement. That’s why you might not have come across some of the behaviour in this article before, and why you can’t test it using browser tools. You need to actually create an HTML page with a script if you want to see how delete really works.

A few other things you can’t delete

Some objects and properties are specifically flagged with a property indicating that they cannot be deleted, such as the length property of arrays and functions or the window object.

console.log(delete window);					// prints false
console.log(delete undefined);				// prints false
console.log(delete [].length);				// prints false
console.log(delete function() {}.length);	// prints false

These restrictions are designed to stop you from getting into a mess. This is a pleasant surprise coming from a language that allows you to redefine undefined.

The precise way that these things become undeleteable relates to a feature of JavaScript called “property attributes”, which may be the subject of a future blog in this series.

Final points

We now know that you can’t delete anything declared with var unless you are in eval execution. Given that we also know that declaring variables without var is illegal, and we also know from various blog posts that using eval is generally a bad idea, we can come to the slightly surprising conclusion:

You can never delete objects in JavaScript.

If that sounds like a memory leak waiting to happen then don’t worry, it shouldn’t be the case. Objects declared in functions will be eligible for garbage collection when they go out of scope, and you should avoid polluting the global namespace with objects in the first place. This also doesn’t really mean that delete is useless – it’s designed for deleting properties rather than objects, and that’s what you should use it for.

This is part three of a series of posts about JavaScript quirks. For part two, click here.

Here at Caplin we use and are constantly evaluating Agile practices and techniques that make software development and maintenance as efficient as possible. In particular to the practice of BDD, which ‘utilises stories as it’s basic unit of functionality’ according to Dan North (http://dannorth.net/whats-in-a-story/). Even if there is an existing body of requirements assets available at the inception of a customer engagement the first challenge is to ‘storify’ those assets. That is to assess each of the assets and ensure that it meets both Dan North’s assessment of what makes a good story, and also so that it passes our own 4 criteria for a good story:

1. Testable
2. Valuable
3. Estimable
4. Tradeable

Passing on all of these criteria ensures that stories are suitably sized and that there is enough information to add the stories to an initial backlog for categorisation. This categorisation process will then provide the basis for dividing the stories up into groups as iterations and releases.

About 5 years ago two of our number who regularly manage customer engagements were at a conference where Jeff Patton was speaking. He was describing Story Maps (http://www.agileproductdesign.com/writing/how_you_slice_it.pdf) and the thoughts that the talk elicited were that this was a ‘brilliant’ idea, and something that would really help with the process of categorising and prioritising the initial story backlog produced at the inception stage of a project.

Since that time we have regularly used Story Maps as part of the Inception phase to facilitate categorising the initial stories and producing the iteration and release plans. Stories can be arranged into functional areas, and then ranked by criticality. This allows a ‘walking skeleton’ (http://alistair.cockburn.us/Walking+skeleton) to be built, providing a ‘steel thread’ or ‘barebones’ implementation to be built in the earliest iteration. Then the ribs can be fleshed out and slowly the application will be built around this skeleton.

In part 2 we’ll look at some issues we have had with using Story Maps.

While I might not be able to persuade you that all of the things he complains about make sense, I hope I’ll be able to show you some of the reasons that javascript behaves as it does.

The + symbol

The + symbol in javascript can mean one of three things.

• It can be an infix addition operator where it operates on two numbers.
• It can be an infix string concatenation operator where it operates on two strings.
• It can be a prefix ‘this number is positive’ operator where it operates on a single number.

What makes all of this slightly more complicated is that javascript has automatic type coercion, so if you use something that isn’t a number or a string before or after your + symbol, then javascript is going to automatically convert whatever you did use to be either a string or a number.

• boolean, null, undefined coerce to a number (true = 1, false = 0, null = 0, undefined = NaN)
• object, array, function all coerce to a string.

So when you see

[] + []

You know that javascript is going to coerce both of those empty arrays to a string and do a string concatenation on them.

When an array is coerced to a string, you get a comma separated list of its contents, so the result will be an empty string.

[] + {}

In this case, the empty object on the right hand side is again going to be coerced to a string.  Since it doesn’t implement a toString method, it’ll pick up the toString method of the default Object by inheritance which returns the string [object Object] for objects, so we’re concatenating the empty string with the string "[object Object]".

Empty Code Blocks

Now we come to a parsing weirdness in javascript.  You might have spotted that we use curly braces for two distinct things in javascript.  One of them is to indicate code blocks (like after an if statement or as part of a function definition), and the other is to write object literals (JSON as it’s often called).  In some languages code blocks can appear in most places within the code and indicate a new scope.  Javascript doesn’t use block scoping (yet), but it still allows code blocks to appear inside normal code.  Which means that sometimes when you write {} the javascript parser understands that as an empty code block and sometimes when you write {} it understands that as an empty object literal.  Generally speaking, if the { appears at the beginning of a statement it’s going to be interpreted as a code block. You can force the object literal understanding by wrapping the literal in normal brackets.

{} + []

In this case the empty curly braces are interpreted as an empty code block, which means that the + appears at the beginning of the next statement, meaning that here the + is a prefix operator that indicates a number is positive.  The + prefix operator can only accept a single number argument, so it will always coerce its argument to a number.

In an extra wrinkle, the way javascript coerces an object, a function or an array to a number is via first coercing it to a string. An empty string coerces to 0.  So for example:

+ [] === 0 // because the empty array becomes an empty string which becomes 0
+ [1] === 1 // because the array with 1 in it becomes a string with 1 in it which becomes 1
isNaN(+[1, 2] ) // because the array with 1, 2 in it becomes a string "1,2" which is not a number.
+({toString: function() {return "3"}}) === 3

So an empty object coerces to a string [object Object] which then coerces to NaNwhen it has to become a number for the prefix + operator in the following statement:

{} + {}

The – Symbol

isNaN("wat" - 1)

Why does this matter?

There are a few aspects of this that can and do come up in ‘real life’.  Back in the bad old days when people used ‘eval’ to parse JSON, they used to have to wrap their JSON in brackets to ensure that the parser didn’t treat it as a code block.  It’s often important to bear type in mind and turn your strings into numbers, because otherwise people will be confused when 3 + 1 = 31.  Knowing how coercion happens can make a lot of the rules around what == false much less confusing.  And perhaps most importantly of course it’ll let you sit in the audience of a ‘javascript is crazy’ talk (of which there seem to be a few) and act as if it all makes perfect sense to you.

Context switching can lead to both frustration and lost time. So what can make this context switching easier?

This is the question that Priyank Vyas, Yasser Fadl, and myself (aka Team Hack’N'Slash) set out to answer for our Caplin mobile hackday project. Our use case was of a trader who uses his phone/tablet to view some data for a set of financial instruments while traveling, and then wants to view a more detailed analysis when he logs into his desktop at the office.

Caplin Thrower

Team Hack’N'Slash dubbed our project “Caplin Thrower”. Caplin Thrower is not an application in itself, but a mechanism to transfer context data between applications. This meant we had to make two web applications; one that was intended to run on a mobile device and one for a desktop computer.

For the desktop application we used the reference implementation of Caplin Trader. This allowed us to focus purely on how we injected context data into the application without having to write a fully fledged trading application from scratch. For the mobile application we created a very simple page that displayed a set of trade tiles.

Keep it simple

The reason context switching is a problem is that it pulls the user out of their current workflow in order to facilitate the context switch. If your solution requires the user to stop thinking about what they are doing to think about the context switch, then I would argue that it is not a good solution.

Taking this into account, we opted for a simple “flick” gesture to initiate the context switch. We chose this gesture as it felt like the user was literally flicking the tile from one device to the other! This action felt very natural, and gave an intuitive experience to the user.

Don’t re-invent the wheel

The next question we had to answer was “how do we get the context data from one device to the other?”. For us, there was only one answer to this question: Caplin Xaqua. If you have a world leading streaming server at your disposal, why look elsewhere?

We used SL4B to send small snippets of context data from the mobile application to our Xaqua server. We then listened for this data in our modified Caplin Trader.

Remember, your contexts are different!

The last part of the puzzle was to determine how to inject the context into our desktop application. As one of the key features of Caplin Trader is its content management, this turned out to be very easy from a technical standpoint. However, there was still the question of what should be displayed to the user after the context switch.

It is important to keep in mind that your two contexts will be different. If they are not, why would your user make the context switch in the first place? The key is finding how the two contexts differ, and why the user wants to put in the effort required to move from one to the other.

In our case the biggest difference was screen size. A mobile device cannot be expected to display the same amount of data as a desktop computer. This suggests that the primary reason a user would switch from their mobile to their desktop is to see more data.

To take advantage of the extra screen size we decided that instead of just transferring the tile, we would launch an entire new page with multiple components relating to the context of the flicked tile (ie, its currency pair).

The power of simplicity

When we demonstrated Caplin Thrower, it received a large round of applause. I believe this was due to how it made the context switch seem completely effortless. What seemed like a complex problem was disposed of with a simple flick of the finger.

Team Hack’N'Slash was a runner-up in the Caplin mobile hackday (you can read about the Caplin mobile hackday here, and the winning team’s project here).

In JavaScript, is it possible to call a function before it has been declared?

It’s easy enough to demonstrate that it is indeed possible, as this self-executing function proves:

(function() {
    console.log(typeof greet);    // prints "function"
    greet();                      // alerts "hello"

    function greet() {
        alert("hello!");
    }
})();

Unfortunately for the hypothetical interview candidate it’s just as easy to demonstrate that it’s not possible:

(function() {
    console.log(typeof greet);    // prints "undefined"
    greet();                      // Error: greet is not a function

    var greet = function() {
        alert("hello!");
    }
})();

In the first case we declared a named function and in the second case we declared a variable and assigned an anonymous function as the value. Although they seem very similar, the first case allows us to call the function before it is declared and the second case does not. This doesn’t seem very intuitive unless you understand the mechanism at work behind the scenes.

Hoisting

Javascript interpreters employ a slightly mysterious process called declaration hoisting, in which all function and variable declarations are moved to the top of their containing scope. If a variable is declared and assigned in one statement then the statement is split into two, with only the declaration getting hoisted. For example, here is a block of code as written by a developer:

(function() {
    console.log(a);     // prints "undefined"
    b();                // prints "b"
    console.log(c);     // prints "undefined"
    d();                // Error: d is not a function
    e();                // Error: e is not a function

    var a = "myValue";
    function b() { console.log("b"); };
    var c;
    var d = function namedFunc() { console.log("d"); };
    var e = function() { console.log("e"); }
})();

And here is how that block of code would be interpreted after the hoisting process has taken place:

(function() {
    // hoisted section
    var a;
    function b() { console.log("b"); };
    var c;
    var d;
    function namedFunc() { console.log("d"); };
    var e;
    function __anon() { console.log("e"); }

    // user code
    console.log(a);     // prints "undefined"
    b();                // prints "b"
    console.log(c);     // prints "undefined"
    d();                // Error: d is not a function
    e();                // Error: e is not a function

    a = "myValue";
    d = namedFunc;
    e = __anon;
})();

Suddenly it makes more sense. Notice that variables and their assignments are split up with only the declaration getting hoisted, while functions declarations are hoisted along with their bodies. That’s why we’re able to call b().

Now that we know how hoisting works we can see why it wasn’t possible to call greet() before it was declared in the second code example. The variable greet would have been hoisted, but the assignment of that variable to the function does not happen until after greet() is called.

Why should we care?

Besides the fact that you can impress friends at parties with your esoteric JavaScript knowledge, you should be aware of hoisting because not knowing about it can lead to nasty bugs, and before you know it you will be hoist by your own petard, whatever that means.

A petard: some kind of medieval bomb apparently

Take this slightly contrived example adapted from Ben Cherry’s blog about hoisting:

var a = "old value";
function changeTheValueOfA() {
	a = "new value";
	return;

	function a() {}
}
changeTheValueOfA();
console.log(a);

If you execute this code you will find that it prints “old value”, indicating that the changeTheValueOfA function doesn’t work. To someone unacquainted with hoisting this may seem bizarre.

The reason it doesn’t work is that the local function a() will be hoisted to the top of changeTheValueOfA, and since declarations are function-scoped the assignment of “new value” will apply to the local a rather than the a outside the function.

This shows another facet of hoisting – all declarations are hoisted whether they are relevant or not, even declarations that are in unreachable code blocks.

Here’s another one:

(function() {
    var a = "initial";
    if(a) {
        function f() { console.log("1"); };
    } else {
        function f() { console.log("2"); };
    }
    f();
})();

Since we are now wise to the tricks of hoisting we know that function f will be hoisted. But in this case there are two functions with the same name. You might expect the first instance of f to be hoisted because a is defined, so the declaration in the if block will execute rather than the else block.

Unfortunately the hoisting process does not care in the slightest about which branch executes, and even more unfortunately there is no defined behaviour regarding which function declaration “wins” by overwriting the other.

If you run this code in Firefox it will print 1. If you run it in Internet Explorer it prints 2. Ouch – try tracking that one down if it was buried in a large code base!

What should we do about all this?

It’s worth pointing out that the last example is actually illegal in ECMAScript, although no browser will complain about it (unless you use the ECMAScript 5 strict mode). Hoisting generally won’t trip you up unless you are already doing something a little bit dubious, such as declaring a variable twice.

The static analysis tool JS Lint will recommend that all variable and function declarations should be placed at the top of their containing scope, in other words write your code as it would be interpreted after hoisting has taken place. In most cases I think this is overkill, just take a bit of care with your declarations and you’ll be fine.

Next time: some esoterica about deleting objects.

This is part two of a series of posts about JavaScript quirks. For part one, click here. For part three, click here.