SXSW 2012: JavaScript Performance MythBusters (via JSPerf)

Chris Joel
CloudFlare, Developer

John David Dalton
Uxebu, JavaScript Developer

Kyle Simpson
Getify Solutions, Owner

Lindsey Simon
Twist, Developer

Presentation Description

JavaScript is everywhere from mobile phones and tablets to e-readers and TVs. With such a wide range of supported environments developers are often looking for an easy way to compare the performance between
snippets, browsers, and devices., a site for community driven JavaScript benchmarks, was created to help devs do just that.

Join Mathias Bynens and John-David Dalton from, Chris Joel from and Lindsey Simon from Google/Browserscope in this panel discussion on some of the best dev-created benchmarks and most interesting practices debunked by real-world tests.

Presentation Notes

Browserscope and jsPerf

Open-source, community-driven project for profiling browsers. Really good at helping inform developers by providing number crunching and actual data. The whole idea is that anyone can reproduce results with any type of hardware (crowdsourcing).

Explicit Goals:

  • Foster innovation by tracking functionality
  • Push browser innovation, uncover regressions
  • Historical resource for web developers


  1. Your for loops suck: rewrite all your code and use: while –i BUSTED
  2. Double your localStorage read performances in Chrome by getting by index. TRUE
  3. The arguments object should be avoided. BUSTED (but isn’t as good in Opera)
  4. Frameworks (like jQuery) are always better at managing performance than you are, so just use what they provide. BUSTED
  5. Converting a NodeList to an array is expensive, so you shouldn’t do it. For instance document.getElementsByTagName() returns a NodeList, not an array, and then iterating over it compared to an array after taking the performance hit of converting it. BUSTED (also see: Static node list, which is closer to a performance with an array)
  6. Script concatenation and/or <script defer> is all you need to load JS performantly (aka “Issue 28“). POSSIBLY. The average website has over 300K of JavaScript. The best thing to do with your JavaScript is to concatenate all your files, but then split them into about 100K sizes. This highly increases the speed at which your browser can download if you’re downloading these in parallel. Also, chunking up your code into pieces where you separate never-changing javascript with frequent you will help with browser caching. Lazy loading (pulling in the important file first and them the others).
  7. Eval is evil, it’s too slow and quirky to be considered useful. BUSTED The performance is pretty much equal with all benchmarks.
  8. Regular expressions are slow and should be replaced with simple string method calls using indexOf(). BUSTED Engines are getting faster now with RegEx.
  9. OO API abstraction means you never have to worry about the details (including the performance). BUSTED Your API design matters more than it just being OO.
  10. Type torsion (===) takes more processing power than a regular comparison (==). BUSTED There is a difference, but it’s so tiny you shouldn’t be concerned.
  11. Caching “nested property lookup” or “prototype chain lookup” helps (or hurts) performance BUSTED In most cases the browser engine already makes the cache, and this wont matter at all
  12. Operations which require an implicit primitive-to-object cast/conversion will be slower BUSTED For instance, when converting a number to a toString() or toNumber() it doesn’t affect performance
  13. Scope chain lookups are expensive BUSTED
  14. Use switch statements instead of if/else if for better performance. POSSIBLY. In most cases this is true, except in Safari and Mobile Safari. The panel recommended to just use what you need.
  15. Use native methods for better performance. BUSTED

SXSW 2012: DIY Mobile Usability Testing

Belen Barros Pena
Open Source Technology Center (Intel), Interaction Designer

Bernard Tyers
Nokia Siemens Networks, Packet Core Engineer

Presentation Description

Usability testing is an interaction designer’s bread and butter, but applying it to the study of mobile applications and websites brings considerable challenges. Which device should we use for testing? Can we use an emulator? How do we prototype for mobile? Can we just recycle the tasks we use for desktop software tests? Do we test in the lab or in the wild? How do we record screen, fingers and facial expressions?

We don’t intend to answer all those questions in just one session: that would be madness! We’ll focus instead on the last one.
Follow us in our quest to set up a mobile usability testing environment on a tight budget. We’ll show you how others do it. We’ll roam around electronics and professional video stores searching for brackets and webcams. We’ll put our DIY skills to the test and waste a lot of silicon trying to build our mobile recording device. We’ll scour the Internet for free software, and we’ll finish off building the lab and running a usability test in front of your eyes.

If we can do it, so can you! You’ll come out of this session knowing exactly what you need to do to run and record usability tests with mobile devices.

Presentation Notes


Record mobile interaction for both a memory aid, but it’s also a powerful communication tool to prove to the clients/owners of the software that people do visually struggle using their product. Intel records both the actions of what they are intending and actually do, and as well as the reaction of the person.

Usability tests are pretty much the same on mobile devices as they are on desktop computers, except… Before you run usability tests on mobile devices you need to ask the following to produce the goals of your test:

  • Which Phone?
  • Which Context?
  • Which Connection?

Handset usability affects test results. If a user is used to an iPhone and you give them an Android, then you’re going to have a learning curve and cause issue. To get around this always make sure you run tests against users with the phone they are used to. If you cannot do this, make sure to use training and warm-up tasks which allows the participant to get used to using the device first.

Should we run tests in the field or the lab? Well, with desktop usability testing it doesn’t really matter. But with mobile devices we use phones on the toilet, well lit, and dark settings. In all seriousness, no one really knows right now which test is best to do. However, we do know that testing in the field is resource intensive and expensive. Even if you just test in the lab, it’s better to do that than nothing at all.

If you must do field testing:

  • Do it late, because your in-lab tests will get most of the usability concerns first
  • Plan and run pilot tests
  • Be prepared, such as if it rains


  • Never test over wi-fi, as you’ll loose a lot of value running over a slower network
  • Cover participants’ data costs who are doing the tests for you

So how do we record the experience?

  • Wearable equipment like hat-cameras
  • Document cameras; but those are not cheap, and have the disadvantage of requiring participants to keep within the camera’s range and this just isn’t natural feeling
  • Mountable cameras which allow for natural interaction with the phone, if they don’t get too heavy
  • Screen capture software; but no one likes you installing stuff on their phones, and no application will support all platforms
  • Remote tool such as (records visits to your website without people knowing). It supposedly also works on mobile devices. It seems as though this doesn’t fully work yet on all phones though

If it would be possible you’d want

  • Easy to put together
  • Cheap
  • Repeatable
  • Allows holding the device
  • Allows one-handed use
  • Supports all form factors
  • Runs tests with participants’ phones
  • Captures screen, face and fingers
  • Gives enough video quality

Photograph of PresentationIntel took the 5 recording methods and found that the mounted devices were the best solution. But that was too expensive, so they instead built their own using Erector Sets, cheap web cams, poster putty (BlueTag, which also helps protect the phone), and bolts. They then run this through a windows machine with both of the cameras showing up, and just simply screen capture.

SXSW 2012: The Science of Good Design: A Dangerous Idea

Ben McAllister (@benmcallister)
Frog Design, Assoc Creative Dir


Presentation Description

The business world is increasingly enamored with design. Business leaders look to designers for guidance on everything from product innovation to corporate strategy. While designers and business people may bring different perspectives to the table, they share one common language: research.

But research can be dangerous. It often provides easy answers that go unquestioned because the research feels like science. What if we’ve put too much trust in research? What about the aspects of design and product development that are important, but hard to measure? Where does research end and design judgment begin?

In this talk, frog Associate Strategy Director Ben McAllister explores these questions and takes a hard look at the role of research in design. Drawing from not only design, but also economics and the philosophy of science, Ben confronts the conventional wisdom around design research, offering a new vision of how research can inspire creativity and guide decision making.

Presentation Notes

“Strategy” is a pretentious word and idea. Ben used to have a title with the word “Strategy” in it, and it was always a challenge. The word strategy comes from the Greek word “general” and breaks down to “to lead” and “that which is spread out.” But Strategy is really just about Leadership and Uncertainty. All humans do not like uncertainty, but without uncertainty there is no need for leadership. If you know what is going to happen, and have the perfect information, then you have no need for strategy.

Research is about informing decisions, but not everyone will agree. In regards to Mad Men the following are still true: Agency life hasn’t changed, but agency work has. Advertising agencies used to be a much more creative world, and they were highly trusted for their advice. However, now this creative world has marginalized. The word “The Research” bothers Ben. It implies the research has its own voice, and cannot be interpreted any other way. It wasn’t about ambitiousness, it was about a clear represented answer. Scientism is the act of using science terms to trick people and create a level of uncertainty (such as people in lab coats smoking cigarets as an advertisement). Scientism is a con, and it is cartoon science as it misguides you on what science really is.

With science you have certainty, objectivity, and progress. The problem is that we take Science and easily lump it in with Research although not all Research is Science. On one end of the spectrum of Research we have “Hard Sciences” (Laws), in the middle is “Social Sciences” (Experiments), and on the other end “Looking at Stuff” (Design World). But even Hard Science Scientists are not absolutely sure of anything (See: Richard Feynman, who admitted this). Even with the Great Depression people are still asking why it started, and why it ended.

Confirmation Bias is when you do research to find research that match your beliefs, and then you find more and more, and then you count is as fact although there is a whole slue of other science for the other side.
Flip Flop Rhythm is when one person says something is good for you, and then someone else says it is bad for you. This happens in nutrition and medication a lot.

We need to approach everything with a level of skepticism, and don’t take it to heart. As well, always keep an open mind that anything you do could be wrong. We need to be honest about where the value of design comes from. It’s dangerous whenever a client asks us to prove why we design the way we do. Sure, science can provide us with an easy answer. The value of what research provides comes from the person doing the research or the person interpreting the data. Research should be used to inform decisions, but not make them for us.

What kind of business do you want to be in? Do you want to be in the business of leading people through uncertainty, or in the business of following directions?

SXSW 2012: The Page is Dead

Jacob Surber
Adobe, Project Manager (HTML Design)

Presentation Description

Responsive web design is changing the definition of a “page,” as it aims to address the growing variety of device form factors and locations where content is consumed. Additionally, as the web evolves, rules and limitations must be better understood in order to create truly unique content. This session will focus on design philosophy and development techniques to create and adapt your content for maximum impact, regardless of where and how it is consumed. Topics will include: • Proper elements for the proper content • Design for context • Adapt your UI and adapt your content • Design with ratios vs. design with pixels • Know the limitations • Designing with limitations • Let the limitations set you free.

Presentation Notes

With the advancement of technology there are so many new/different devices all of which have different screen sizes. So, what are your options when creating a website?

  • Create a mobile website: But where do we stop? (Don’t do this)
  • Build a responsive site!

Get your content down first: “Content precedes design. Design in the absence of content is not design, it’s decoration.” – Jeffery Zeidman

Responsive design is more of philosophy than a technique. It is something that defines control differently, and it is a team effort. It’s about knowing your center and how people are going to approach you. You need to have a soft center and have the ability to let go and have a certain level of control.

The New York Times has a poor design as it is not responsive, however The Boston Globe is. Ethan Marcotte worked with The Boston Globe to make this possible. See: Blog post and Book. The design company who worked with The Boston Globe just recently released a blog post about this.

There are three types of grids: fixed, fluid, golden.

  • Fixed isn’t really flexible, but can be good some times. Pelicanfly does a good job with a grid system. They use the method 960 Grid System.
  • Fluid grids are calculated with math: target/context = result. The idea is to take an individual column and measure it out. For instance, if a column on a 960px screen is 60px, then we divide it and get a percentage for just that particular column. Don’t round when you do the math, even if they are crazy long. The List Apart has an example website called The Baker Street Inquirer. In chrome you can view the Developer Tools > Elements, and hover over the elements to see what CSS properties are applied at any given time.
  • Golden Grid is the concept of the Golden Rectangle. Anderson-Wise is an example of this.

Layout is an enhancement. Do all website experiences need to be the same on every single browser? No. Create an experience targeting those you want to target (such as not IE6).

When using Media Query Specs you should care mainly about: width, orientation, -webkit-device-pixel-ratio (iPhone advantage)

  • @media screen (min-width: 1024px) and (max-width: 1220px)

But wait! Break free from pixels, as that just wont scale. “We can get rid of half of the images on the web, because they’re used for styling.” – Hakon Wium Lie, Opera.

Best Practices

  • Start with low res graphics first.
  • Be resolution independent: CSS, SVG, @font-face


  • How you can convey importance
  • How you structure your DOM
  • It’s important!

The New York Time has over 11 different fonts and faces, and 7 different size column widths. As a consumer this is highly confusing and hard to look over.

As you’re laying out information that you’ve defined, it will start to logically group together in modules. At The Boston Globe they have breaking news, main titles and a body of content, These things still exist on smaller views, they’re just shifted around.

DOM Order

Spark-Box does a good job with structuring the order in which things flow with different sizes. Illy Coffee moves their DOM around based on what device they’re using, and what that device’s user is more likely to want to do.

  • Be task oriented
  • What do you hope your use to do?
  • How long will users be using it?

Flexible Images and Content

The easiest way, but least scalable: img { max-width: 100%; }

A better scalable solution:

What W3 is proposing:

Additional Resource

SXSW 2012: How to Remember Anything: A Teach Yourself Guide

Mark Channon
How to Remember Anything, Author

Presentation Description

“How to Remember Anything” shows how a radically improved memory can add real value in life and in business and can help build your career. Mark Channon, Actor, Hypnotherapist, Product Manager and author of Teach Yourself How to Remember Anything, will take you on a whirlwind tour of the memory techniques inside How to Remember Anything. Guiding you through a set of key examples on how to remember names, books, presentations and more. Mark was one of the first Grand Masters of Memory in the world and creator of BBC’s Monkhouses Memory Masters.

Presentation Notes

Relaxing makes you concentrate better, so whenever it is you’re in need to remember something make sure you are just that.
Break down words into pictures, as pictures are easier to remember.

  1. Chain Method: you can remember words by chaining them into a story with images, even if the words do not correlate with a logical story. Mark gave an example of this method to everyone, and had someone regurgitate the main points precisely.
  2. Names: This is a multi step method consisting of 4 parts:
    • Prime Yourself: What’s interesting about the person you’re going to talk to? It’s easy to look around you and figure out what is all brown, but if you are only concentrating on what’s brown it’ll be hard to then reiterate what was blue.
    • Listen to their name
    • Create an image and imagine a short story about their name
    • Repeat their name back as you think of the story
  3. Memory Networks: System to correlate items to body parts. For instance, correlate each item from your toes to your head: feet, knees, thighs, butt, stomach, chest, head. This same method can be used to correlate numbers to objects around you. A television could be #1, a speaker could be #36, etc. This same method can also be used to remember passwords.