The questions are divided into five topics covering different aspects of the language: arrays, objects and context, functions, asynchronous behavior and Backbone views. If, like me, you have a decent grasp of JavaScript, but wouldn’t feel confident writing “JavaScript programmer” on your curriculum vitae, then I think you’ll find the tests an enjoyable challenge. None of the questions are super difficult, though I confess to needing help from MDN to arrive at a few of the solutions. I definitely learned a thing or two about JavaScript along the way.

Because Rebecca’s application is built in Node, you’ll need to have Node and NPM installed before you can run it. That’s a shortcoming I think, since it throws up a fairly large barrier-to-entry, but if you’re serious about JavaScript then you really ought to delve into Node anyway. I won’t bore you with instructions for installing Node – you can do it using Homebrew or download an installer from the official Node website. After that, just follow the steps on the js-assessment github and you’ll be up and running.

Rebecca seems undecided about whether to publish solutions to the tests, but in the name of sharing the knowledge (and at the risk of exposing my own shortcomings as a programmer), you’ll find my answers below. My solutions won’t make much sense taken out of context like this, but once your start working your way through js-assessment things will become a lot clearer.

Although my solutions pass Rebecca’s tests I’m sure some of them could be improved, so if you have suggestions for optimizing my code please leave a comment below.

Arrays

1. You should be able to determine the location of an item in an array

fn = function (arr, targ) {
  for (var pos=0; pos < arr.length; pos++){
    if (arr[pos] == targ){
      return pos;
    }
  }
};

2. You should be able to add the values of an array

fn = function (arr) {
  var total = 0;
  for (var pos=0; pos < arr.length; pos++) {
    total += arr[pos];
  }
  return total;
};

3. You should be able to remove an item from an array

fn = function (arr, itemToRemove) {
  for (var pos=0; pos < arr.length; pos++){
    if (arr[pos] == itemToRemove){
      var removedItem = arr.splice(pos,1);
    }
  }
  return arr;
};

4. You should be able to add an item to the end of an array

fn = function (arr, itemToAdd) {
  arr.push(itemToAdd);
  return arr;
};

5. You should be able to create an array from two arrays

fn = function (arr1, arr2) {
  var arr = arr1.concat(arr2);
  return arr;
};

6. You should be able to add an item anywhere in an array

fn = function (arr, itemToAdd, pos) {
  arr.splice(pos, 0, itemToAdd);
  return arr;
};

Objects and context

1. You should be able to alter the context in which a method runs

fn = function () {
  // Call the sayIt() function and pass it the
  // 'b' object as its context.
  return a.sayIt.call(b);
};

2. You should be able to alter multiple objects at once

fn = function (greeting) {
  C.prototype.greeting = greeting;
};

3. You should be able to iterate over an object’s ‘own’ properties

fn = function (obj) {
  var ownProperties = [];
  for (var prop in obj) {
    // hasOwnProperty returns true if the property
    // belongs to the object, not its prototype chain.
    if (obj.hasOwnProperty(prop)) {
      ownProperties.push(prop + ': ' + obj[prop]);
    }
  }
  return ownProperties;
};

Functions

1. You should be able to use an array as arguments when calling a function

fn = function (opts) {
  // Call the sayIt() function in the context of 'this'
  // and pass it the 'opts' array.
  return sayIt.apply(this, opts);
};

2. You should be able to change the context in which a function is called

fn = function (opts){
  // Call the speak() function in the context of 'obj'.
  return speak.call(obj);
};

3. You should be able to return a function from a function

fn = function (prefix) {
  var concatFn = function(suffix) {
    return prefix + ', ' + suffix;
  };
  return concatFn;
};

4. You should be able to create a ‘partial’ function

fn = function (func, greeting, name) {
  var partialFn = function(punctuation) {
    return func(greeting, name, punctuation);
  };
  return partialFn;
};

Async behavior

1. You should understand how to uses ‘promises’

As far as I know promises are not part of the JavaScript language, and need to be implemented using a third party library. In my solution I used jQuery’s deferred object to return a promise.

fn = function () {
  // This is a contrived example to demonstrate that the promise
  // is returned asynchronously after a 1sec timeout.
  var dfd = $.Deferred();
  var timeoutID = window.setTimeout(function(){
    dfd.resolve(true);
  }, 1000);
  return dfd.promise();
};

2. You should be able to receive data from the server and manipulate it

var get = $.ajax({
  url: url
});

// Since jQuery's $.ajax returns a promise, we can use
// .done and .fail callbacks.
get.done(function(response){
  peopleArray = [];
    for (var person in response.people){
      peopleArray.push(response.people[person].name);
    }
    peopleArray.sort(); // Not required in this case.
    tests();
});

get.fail(function(){
  console.log('Load failed');
});

Backbone views

This section of the test relies on knowledge of the Backbone framework. Personally that doesn’t bother me since I have used Backbone before, but I’m not sure that Backbone knowledge should be considered mandatory for a JavaScript professional.

1. You should be able to render a view using a template

var MyView = Backbone.View.extend({
  template : tpl,
  render : function() {
    // This could be written on a single line, but I've
    // split across 3 lines for readability:
    var compiledTemplate = _.template(this.template);
    var viewHTML = compiledTemplate(this.model.toJSON());
    $('body').append(viewHTML);
  }
});

2. You should be able to update the view when the model changes

var MyView = Backbone.View.extend({
  initialize : function() {
    this.model.bind('change:greeting', this.render, this);
    this.model.set({greeting: 'Goodbye, world'});
  },
  template : tpl,
  render : function() {
    $('#my-view').html(this.model.get('greeting'));
  }
});

Robert Hoekman, Jr is a user experience designer and consultant who is best known for his books about interface design, Designing the Obvious and Designing the Moment. His self-published book Big Deal: On Being Famous to Almost No One tackles a far more personal subject. In Big Deal Hoekman, Jr recounts his rise to the top of the web design field, and describes how his craving for professional notoriety eventually devastated his personal friendships, marriage, and sense of self worth.

The form of celebrity Hoekman Jr discusses in Big Deal has been dubbed “micro-fame”:

My name is Robert Hoekman, Jr, and in certain rooms, under certain circumstances, at certain moments, surrounded by certain people, and when all these very certain things come together, I am a big fucking deal.

In other words, Hoekman, Jr might be unknown to the general public, but within the web design industry he is a bona fide rock star.

From the unique perspective that this notoriety affords, he takes the reader on a whirlwind tour of the conference rooms, hotel bars, book signings, photo opportunities and corporate retreats that consumed his attention as he rose the ranks of his profession. Along the way we rub shoulders with a veritable who’s who of the web industry: Matt Mullenweg, Jeff Veen, Jeffrey Zeldman, Caterina Fake, Luke Wroblewski, to name but a few.

Ultimately Hoekman, Jr’s craving for recognition and approval forces a crisis in his professional and personal life, and he has to face up to the root causes of his obsession with fame, and deal with the fallout.

This makes for fascinating reading, especially for a web design nerd such as myself, but I was left with the nagging feeling that Hoekman, Jr has – perhaps unwittingly – used his book about the pitfalls of fame as a platform to reinforce his cool kid credentials.

The nonstop cataloging of his professional achievements came across at times like bragging, and I wish he had dialed the self promotion back a notch. Even in the book’s later chapters, where he describes a dawning awareness that his obsession with fame is destroying his marriage, the laundry list of book signings and speaking engagements barely slows down. It is as if he wants to remind the reader that even though he no longer cares about being famous, he still is famous.

It is said that that pride comes before a fall, and in Big Deal Hoekman, Jr talks candidly about the flipside of his micro-fame: spiraling self doubt, professional rejection by Apple and Yahoo, isolation from friends, and the collapse of his marriage. It takes guts for a writer to expose their weaknesses so openly, but it feels a little like sitting in on someone else’s therapy session (in a psychotherapy cliché he lays much of the blame for his low self esteem at the feet of his mother). I imagine the process of writing Big Deal was extremely cathartic, but I question whether the experience of reading the book is equally enlightening.

The problem is that Big Deal is all about Hoekman, Jr, and frankly I’m not sure that his personal experiences provide enough material to do the book’s topic justice. If more of Big Deal had been devoted to examining the impact of micro-fame in a broader context – the cult of celebrity engendered by social networking services like Twitter, say – the book might be better rounded, and have a broader appeal.

Despite the reservations I have outlined above, I still found Big Deal very enjoyable. There is no doubt that Hoekman, Jr is a talented writer, and has penned a book that can accurately be described as a page turner. I finished the book in one day, and certainly wasn’t left unsatisfied. Hoekman, Jr paints a very human picture of his life as a web industry A-Lister, and in a field where technical manuals are the norm Big Deal is quite unlike any other web design book I have read.

Big Deal: On Being Famous to Almost No One will be released as an ebook through Amazon and iBooks later this year. Learn more about the book on Robert Hoekman, Jr’s website.

The book is over 200 pages in length, and covers a whole gamut of topics including web accessibility, coding HTML emails, database basics, online marketing, and going freelance.

Get the book for free from the Sitepoint store.

While I was twiddling my thumbs waiting for my last Amazon shipment to arrive I asked my studio mate if he had any design theory books I could borrow. “Aha! I’ve got just the thing”, he said (or words to that effect) and plucked a copy of Kenneth Fitzgerald’s Volume from his bookshelf. The author’s name didn’t ring any bells, but the book’s back cover promised a survey of “the discipline of graphic design in context with the parallel creative fields of contemporary music and art”. Since I love graphic design, music and art, I figured I was on to a good thing.

Kenneth Fitzgerald is an Associate Professor of Art at Old Dominion University in Norfolk, Virginia, and has previously written for Emigre, The AIGA Journal of Design, and Eye. Many of the essays collected in Volume first saw print in the pages of one of those publications, though all but one were new to me. Thankfully the vintage of the older articles has done little to dull their impact, and even the essays written in the 1990s seem topical today.

In his writing Fitzgerald explores the connections between graphic design and other cultural forms, particularly music and art, and many of Volume’s essays make the case for a more inclusive understanding of graphic design’s place in the world. I worked in art galleries for several years before becoming a graphic designer, and I found Fitzgerald’s no-nonsense critiques of the art world to be right on the money.

Fitzgerald takes a similarly unsentimental view of the design profession, and is unswayed by the star power that is frequently attached to its high achievers. In Volume he exposes the class system that operates largely unchallenged in the design sector, and the role that money, privilege and celebrity play in shaping the field. In the process several of graphic design’s sacred cows are roasted – Stefan Sagmeister and Paul Rand are both singled out – which makes for entertaining reading.

Another theme he returns to frequently is the profession’s preoccupation with formalism and suspicion of critical theory. This sometimes comes across as self-referential – design theory about design theory – but that doesn’t detract from the relevance Fitzgerald’s ideas hold for designers working “in the trenches”, and he clearly sees the need to break down the barriers that separate design critics and practitioners.

It’s not all good though. Sometimes Fitzgerald repeats himself, treading the same ground in different essays, and he seems more adept at pointing out problems with the state of design than he is at proposing solutions. But those are minor quibbles about an otherwise very enjoyable collection.

If you’re tired of reading puff pieces about celebrity graphic designers and want to sink your teeth into something that will challenge your mind rather than your eyeballs, Volume may be just what the doctor ordered.

You can read more of Kenneth Fitzgerald’s writing on his website, Ephermeral States.

Donald A. Norman’s The Design of Everyday Things frequently pops up on lists of “must read” design books, but I’ve somehow managed to avoid reading it until now. I finally included the book in my last Amazon order, and now I wish I hadn’t waited so long to get my hands on a copy, because it really is a classic that deserves all the praise that’s been heaped on it.

The Design of Everyday Things was first published in 1988 under the title The Psychology of Everyday Things, and is aimed at anyone involved in the design process, regardless of which field they work in. Norman’s background is in cognitive science, and in the book he explores the psychology of everyday objects, making a persuasive argument for the importance of a user-centered approach to design. After reading The Design of Everyday Things you will never look at a tap, light switch, stove top, or telephone the same way again (and I guarantee you’ll learn a thing or two about the layout of your computer keyboard!)

A big part of what makes The Design of Everyday Things so enjoyable are the descriptions of flawed designs that Norman peppers throughout the book. These case studies serve to illustrate both how difficult it is to design something well, and how essential good design is to our lives. Norman draws on his own (often humorous) experiences with poorly designed objects, as well as anecdotes from colleagues and friends, and paints an all-too-familiar picture of design gone awry. If you’ve ever struggled to program a VCR, pulled a door handle when you were supposed to push, or been mystified by the taps in a public restroom, then you’ll be sure to relate to these encounters with bad design. Norman uses the book’s examples of substandard design as a springboard for examining the factors that frequently derail the design process, and he proposes that matters can be improved when designers adopt a user-centered design philosophy and focus on the needs of the user.

While The Design of Everyday Things deals mostly with the design of physical objects, its principles are equally applicable to the design of websites and other interactive systems. Consider this description of the relationship between the number of visible controls a device has and how difficult it is to use, which has obvious implications for the design of web applications and navigation systems:

We found that to make something easy to use, match the number of controls to the number of functions and organize the panels according to function. To make something look like it is easy, minimize the number of controls. How can these conflicting requirements be met simultaneously? Hide the controls not being used at the moment. By using a panel on which only the relevant controls are visible, you minimize the appearance of complexity. By having a separate control for each function, you minimize complexity of use. It is possible to eat your cake and have it, too.

Norman devotes a portion of a chapter called The Design Challenge to the discussion of computers, and while the technology he describes sounds antiquated to a modern audience – he has to explain to the reader what a computer mouse is – the interface design concepts he discusses still hold true today. Interestingly he singles out the Apple Macintosh, which had only been in the market a few of years at the time of the book’s publication, as an example of outstanding computer design and usability. His only complaint: the single button mouse. Over twenty years later Apple still set the benchmark for good design in the computer industry, and still draw criticism for the design of their mice!

Given that the book was written in the 1980s, and devotes a lot of space to discussing technologies that seem antiquated today, I was surprised just how easily its principles can be applied in a contemporary context. It is a testament to the timelessness of Norman’s ideas that many of the predictions he made about technology have proven to be very accurate. In a chapter on the function of reminders and human memory he speculates about the future of computer devices:

Would you like a pocket sized device that reminded you of each appointment and daily event? I am waiting for the day when portable computers become small enough that I can keep one with me at all times [...] It has to have a full, standard typewriter keyboard and a reasonably large display [...] And it should be easy to hook up to the telephone.

Writing in 1988 Norman wasn’t able to guess that the computer and the phone would one day merge, but in other respects he was describing the modern smartphone. It’s that kind of insight that makes this book so valuable.

Whether you design consumer goods, electronics, software, websites, technical documentation – anything, really – you’re bound to look at your craft in a new light after reading The Design of Everyday Things. This is surely a book that deserves a place on every designer’s bookshelf.

Stay tuned for more reviews

At the start of the year I resolved to read more design and development related books, so I’ll be posting more book reviews here as I check each title off my reading list. If you want to see reviews and ratings for other books in my collection, check out my Goodreads profile.

I must not be the only person who enjoys these kind of real-time statistics, because Campaign Monitor have just launched a new reporting feature they call Worldview, which is designed to give instantaneous feedback about your subscribers.

Worldview plots your subscribers on a world map (driven by Google Maps, of course), dropping a new pin on the map each time someone opens your email, clicks a link in an email, or shares your campaign.

So there is no longer any need to repeatedly reload your Campaign Monitor reports to simulate real-time metrics, just sit back and watch the show…

In a little over 24 hours the project has raised almost $50,000 in pledges, well exceeding the $27,000 target. Wow.

Check out the video of Frank’s lecture of the same title, given at the Build conference.

In his presentation Frank discusses graphic design in the context of history, philosophy and anthropology, and draws interesting conclusions regarding the purpose and function of design. Apparently The Shape of Design book will expand on the themes of the lecture, so it should be a goodie.

• The original typeface for Safari and Firefox 3.5
• A WOFF font for Firefox 3.6+
• An SVG font for Opera, Chrome, and iPhone
• An EOT font for Internet Explorer
• A sample HTML page
• A sample CSS stylesheet

The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.

Sweet!

The campaign leveredges Twitter to rally the web design community around the issue, and a realtime mosaic of the tweets can be viewed at fixoutlook.org. The site is worth a visit for this feature alone!

Further reading

Microsoft to ignore web standards in Outlook 2010 – enough is enough

Version targeting in Flash

Version targeting in Flash works in much the same way as it will in Internet Explorer: each Flash movie contains embedded information telling the Flash Player which version of Flash it was created for, and the Flash Player itself contains multiple rendering engines to handle legacy content.

This approach to backwards compatibility has been a feature of the Flash Player since its earliest incarnations. The latest version, Flash Player 9, supports content produced for FLV (Flash video), SWF9, SWF8, SWF7, SWF6, SWF5, SWF4, SWF3, SWF2, and FutureSplash. That means that Flash content created in 1995 still renders perfectly in 2008. Flash developers can have a great deal of confidence that an application they create today will continue to work in the future without any need to revisit it*.

Why have Adobe worked so hard to ensure the Flash Player is compatible with legacy content? I think the answer lies in the commercial nature of Flash. Because Adobe relies for its livelihood on the continued patronage of website developers, they need to keep that customer base happy. Flash would never have gained traction if developers were forced to rework their legacy websites every time a new Flash Player version is released – I can’t imagine anyone paying $700 for software that generates code that breaks every eighteen months!

Does backwards compatibility hamper progress?

Let us consider my concerns about version targeting, and see if they have been borne out in Flash: Has backwards compatibility hampered progress in the Flash industry? Has it slowed adoption of the Flash Player? Has it stalled advances in Flash technology? I think the answer to these questions is “no”.

One metric we can use to gauge the rate at which advances in Flash are taking place is to look at Flash Player adoption rates. A fast adoption rate by end users is a sign that users are encountering Flash content targeting the latest Flash version, and are upgrading their player in response. Even before the introduction of an automatic update feature, adoption rates for the Flash Player were very high. From the time a new Player was released, it would achieve 55%-65% market penetration within 6 months. This is a good indication that Flash developers are quick to take advantage of new features in Flash.

Another measure of technical progress is the rate at which new features are added to the Flash Player (as opposed to the Flash authoring tool, where some changes will be merely cosmetic). During the past four releases there have been three complete overhauls of the Flash programming language, the introduction of powerful video functionality, bitmap effects (motion blur, dropshadows, etc) and filters, to name just a few new features. Because version targeting ensures there is no pressing need for Flash developers to upgrade, Adobe needs to continually improve Flash’s feature set to give its customers a compelling reason to purchase an upgrade license. Rather than stymieing progress, version targeting actually encourages technical advances in Flash.

A personal perspective

I worked as a full-time Flash developer for four years, and Flash development still accounts for about half the work I do. Until this week I hadn’t given much thought to the impact of version targeting in Flash, but on reflection I see that it has compelling benefits for end-users, seasoned developers, and Flash novices alike.

Flash has a very healthy development community keen to push the boundaries of their medium, and even though version targeting enables many developers to work at a lower level, I don’t see any evidence that this skill gap impedes advances in the field. I myself still publish content targeting Flash Player 8, and am familiarizing myself with the new ActionScript 3 programming language in the meantime. I certainly don’t feel that I am holding anyone back by learning at my own pace!

I also consider that version targeting goes a long way towards easing the Flash developer’s workload. If I build a site targeting Flash Player 8, I know without testing that it works in Flash Player 9 too, and vice versa. I know too that I will never need to “fix” that site to comply with a future Flash Player release. This forward compatibility is something that I take for granted when I develop a Flash site, and the idea of ‘fixing’ my legacy projects every couple of years seems totally absurd. Yet for some reason this “break and fix” cycle is considered perfectly normal for HTML websites.

What’s good for the goose

Of course, comparing Flash Player with a web browser is not like comparing apples with apples: Flash and Internet Explorer have very different business models; Flash has no serious competition whereas Internet Explorer is part of a busy browser ecosystem; Adobe is free to introduce new features to Flash as it sees fit whereas Microsoft is beholden to various working groups; the upgrade cycle of Flash is driven by web developers rather than software vendors. What works for Flash may not necessarily work for Internet Explorer.

Yet I believe there are enough similarities to draw a comparison. Flash shows us that under the right conditions version targeting can actually be beneficial for everyone involved in the development, delivery, and consumption of content for the web.

Footnotes

* There is only once exception I can think of: new ‘sandbox security’ restrictions introduced in Flash Player 7 caused some older Flash applications to break.