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. jsPerf.com, a site for community driven JavaScript benchmarks, was created to help devs do just that.

Join Mathias Bynens and John-David Dalton from jsPerf.com, Chris Joel from Cloudflare.com 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

Myths

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

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

Slides: diymobileusabilitytesting.net/doku.php?id=diy-mobile-usability-testing-sxsw2012

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

Recommendations:

• 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 mouseflow.com (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

Intel 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.

#SXDangerous

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?

Presentation Description

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: m.mywebsite.com. But where do we stop? ipad.website.com? ipad.landscape.website.com? iphone.4s.website.com? (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

Hierarchy

• 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: https://github.com/filamentgroup/Responsive-Images

What W3 is proposing: http://www.w3.org/community/respimg/

Additional Resource

• The Flexible Box Model
• Object Oriented CSS
• HTML5 Boilerplate
• Skeleton Grid
• Bootstrap (Twitter)

Presentation Description

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.

Scott Lenger
Beaconfire Consulting, Functional Analyst

#SXshit

Presentation Description

Presentation Description

Presentation Notes

Slides: http://bit.ly/teamSass

The Basics

• Variables (font-colors, font-family, etc.). You can set a default variable, but then have an opportunity to change it with the “!default” operator similar to “!important”
• Nesting selectors: .nav { li { … } … }
• Parent references with the nesting selectors
• Nesting statements: background: { color: …; image: …; }
• Comments (Sass specific) that are stripped out when compiled: // instead of /* … */
• Loops: @for, @each, @while
• Mathematical operations

Desktop GUI’s

• Web Workbench (Visual Studio Plugin)
• Compass.app (Mac, Windows, Linux)
• CodeKit (Mac)
• Scout (Mac, Windows)
• LiveReload2 (Mac, Windows in early alpha)

Command Line

• Sass itself
• Sass-convert
• Vast number of static generators (Middleman, which can also minify your code)
• Compass

Debugging Tools

• Generated Line Comments
• FireSass for Firebug, allows you to see what Sass file a particular element definition is in

Good Practices for CSS

• Don’t nest more than 4 selectors deep
• Break things down as much as possible
• Work from the main area …

Put all of your partial sass files in a “lib” (library) sub directory

Output Configurations

• :line_comments
• :debug_info
• :compressed, :nested, and a couple others

CMS Plugins

• Sass WordPress Plugins
• Forge from The Theme Foundry
• Sass Drupal Modules

What is Compass?

• Gives you helper functions on top of what Sass already has. For instance, it can auto convert between hsl and rgb.
• Mixins for CSS3. Generates all of the browser implementations of new tags (-webkit-…, -moz-…, etc).
• Framework for Building Frameworks.
• Plugin Architecture for creating Mixins for buttons where you can publish for Ruby and then others can take them and re-use them.

Additional Resources

• CSS3 Helpers
• Sassy Buttons
• Sass Script Functions
• Sass Website
• The Sass Way
• Compass
• Compass Install Guide
• Compass Plugins
• The Changelog, Episode 0.0.1 – Haml Sass and Compass
• Using SASS With the 1KB Grid System

Presentation Description

Presentation Notes

Slides: http://estelle.github.com/sxsw

Duane Forrester
Bing, Sr Product Marketing Manager

Matt Cutts
Google Inc, Distinguished Engineer

Presentation Description

Presentation Description

Presentation Notes

CSS was originally created to slim down markup and remove the need for design elements.

ZenGarden is a website where users could collaborate and create beautiful CSS designs running on top of fixed HTML DOM.

There’s too much flexibility and power in CSS, and the best of things are the simplest.

“Nobody is really smart enough to program computers.” – Steve McConnell
“Nobody is really smart enough to style web pages.” – Andy Hume

Code Quality can be measured by: correctness, reliability, reusability, web 2.0 compliance, performance, extensibility, etc. But the one thing we need to optimize code the most for is: change. Having simple code, it is easier to maintain a code base. If you don’t have maintainability then you’re not in a position where you can easily make these changes. You wont be able to fix apparent bugs.

“Very few people (only professional designers, it seems) write style sheets longer than a hundred lines.” – Bert Bos, 2008

Pre processors can help out in managing complexity:
Sass – http://sass-lang.com
Less – http://lesscss.org
Stylus – http://learnboost.github.com/stylus/

But rather than making changes and additions to the language, why not use a tool that just makes what we currently have better?
OOCSS – http://oocss.org
SMACSS – http://smacss.com
CSS Lint – http://csslint.net

Layers of CSS
Base Styles: applied to element selectors such as font sizes, line heights.
Module Styles: product list, main navigation
Layout Styles: provide a grid or set up columns

One of the worse things you can do is apply a class name as “green” and then have the CSS markup: .green { color: green; } as if your design changes to “red” then your class is still labeled as “green.” Instead you should make the class name whatever it is (header, navigation, etc), and not based on the color or style it is.

A convention of applying to class names to an element, for instance “promo-box” and “promo-box-alert” is to make it “promo-box–alert” with the two “–”s.

Selector Queries – http://github.com/ahume/selector-queries

• Allows you to apply rules like, “if the width of element X is smaller than Ypx, then apply a certain class to it”
• This gets away from having to base CSS @media queries on the size of the browser, and instead the size of the element.

Base Style Sheets

There are many available, such as Bootstrap by Twitter, but you too can create one for your organization. It’s basically guidelines and standards created by your company.