The CSS transform property allows a developer to perform a number of different actions on an element that changes how that element appears in the browser.  While the realm of possibilities for what you can do with one or more of the transform values is very large, here are some common uses to save time on your next project.

Centering Icons Vertically (or Horizontally)

The first example of a CSS transform value I want to look at is translate().

Let’s talk about the translate() CSS transform

What translate() allows us to do is move an element around without affecting the normal flow of the document.  If you have two elements next to each other and you apply a margin-left value to the element on the left, it will push both elements over to the left.  Margin affects the normal flow of the document.  If you would like to move one of the elements without affecting the positioning of the elements around it, that’s where you can use translate().

One thing to note first is how percentages work.  Percentages when used as your values for things like margin or width are calculated based on the parent element’s width, so if I have a container that is 400px wide and I tell a child element of that container to be 50% width or have a left margin of 50%, both of those values would be calculated as 200px.  However, when using a translate() rule, percentages are calculated based on that element’s width.  Take a look at the code below.  I’ve put two paragraph elements into a container that is 600px width, and defined them to be 50% width (300px).  I’ve set margin-left: 50%; on the first paragraph and transform: translateX(50%); on the second, which shows the first paragraph being pushed over by 300px, but the second paragraph is only push over by 150px.

See the Pen
Percentage Showcase by Zach Handing (@zachhanding)
on CodePen.

Positioning that icon!

With that in mind, let’s look at positioning any size icon to center itself vertically in its container.

Let’s say we have list of links, and we want to put an arrow icon in each link to give another visual cue that it will take the user somewhere.  In this case, that icon provides no semantic meaning to the element; it just adds to the design.  We can add that icon with CSS instead of putting it in the markup.  Now we can absolutely position the icon to be on the right, but how do we make sure it’s perfectly centered vertically?  If we know the height of the icon, we can add a top value of 50% and then subtract half the height of the icon, but what if we put in a new icon or use this component somewhere else with different values? We don’t want to hard-code the positioning values.

If we combine the top positioning of 50% (to get the top of the icon to be centered vertically), we can then combine that with a translate value to move the icon up half of its height and not have to worry about what that height value is.

a::after {
    position: absolute;
    right: 1rem;
    top: 50%;
    transform: translateY(-50%);
}

See the Pen
Transform: Translate by Zach Handing (@zachhanding)
on CodePen.

And now our icon is perfectly vertically centered in the link.

Take a look at Developer Tutorial: How to Make a Triangle with CSS to see how I made that icon using only CSS!

Expanding or Contracting Size with a CSS transform

Now let’s look at the transform value scale().  If we apply a scale transform to an element, we change its size.  Just like with translate(), scale() adjusts the size of the object relative to its own width or height.  This is useful when doing simple hover states if we want to make the element pop out a bit.  The values used for scale() can again be percentages, or a 0-1 scale (0 being 0%, 1 being 100%).  The example below shows the cards increasing to 110% their original width and height when hovering over them. It also couples with the transition property to become a seamless animation.

li:hover {
    transform: scale(1.1);
    transition: transform 144ms ease-out;
}

See the Pen
Transform: Scale by Zach Handing (@zachhanding)
on CodePen.

The best part of scale() is that since we are not adjusting the width or height value for the cards, the other cards do not get pushed around by the change in size!

Flipping an Element Around

Our next use case of a CSS transform will dive deeper into how scale() works, by adding two important bits of information:

1. You can choose to only scale specific axes by using scaleX() or scaleY()
2. You can use negative values!

When using a value of -1 inside scale(), it tells the element to scale all the way down to zero, and then come out the other side back up to its original size…but now it’s backwards!  This is incredibly useful if by allowing us to utilize one icon in multiple directions!  Take a look at the code snippet below to see how we can take a right-facing arrow (or in this case hand), and make it point to the left.

img:hover {
    transform: scaleX(-1);
}

See the Pen
Transform: Scale Flip by Zach Handing (@zachhanding)
on CodePen.

Rotating an Element

The last example I want to go over is probably the most used. This takes flipping an element around to the next level.  Instead of mirroring an element, you can use the rotate() CSS transform to spin it at any angle you’d like.  Here we are looking at an accordion with arrow icon on the right side like our other example.  When the accordion item is opened, we rotate the icon 90 degrees.  Since this is in combination with our translate example, you can see how combining multiple transforms is also possible.

.btn-link {
    &::after {
        transform: translateY(-50%);
    }
  
    &.collapsed::after {
        transform: translateY(-50%) rotate(-90deg);
    }
}

See the Pen
Transform: Rotate by Zach Handing (@zachhanding)
on CodePen.

And there we have four common uses for the transform() property in CSS.  Share in the comments if you have any other creative ways to use it!

There is a problem with the default styling of the figure caption (figcaption) element that is intrinsic to the way HTML and CSS work on their simplest level.  Elements don’t know or care about the other elements around them; they behave in their own way, no matter what content comes before or after them.  Let’s take a look at why the figcaption throws a wrench into this idea.

figure { display: table; }
figcaption {
  display: table-caption;
  caption-side: bottom;   /* optional */
}

Off to a good start

We’ll begin with a fairly unassuming article layout. It has an image floated to one side and content flowing around it.

Note: the direction of the float (left or right) is not a factor in the forthcoming issue.

See the Pen Figure with Caption #1 by Zach Handing (@zachhanding) on CodePen.

This layout as it stands works exactly as we want it to.  We haven’t set a width or height on the floated image, because we want the ability to put in an image of any size as it relates to our article.  We set margins on the side and bottom so that the content doesn’t crowd our image, and we add max-width: 100%; to ensure that if we drop in an image that is a larger resolution than our page affords, it won’t break the layout.

Running into our image caption problem

Now we want to add a caption to our image.  In the world of semantic HTML, this is a straightforward process.  All we need to do is put a figcaption directly after our image, and wrap both elements in a figure.   We can take the margin and float rules off the image directly and put them on the figure since we’ll want these rules to apply to the image and caption as a whole.
With a short caption all appears fine, but as soon as we write a caption that takes up more width than our image, our layout breaks.

See the Pen Figure with Caption #2 by Zach Handing (@zachhanding) on CodePen.

This is happening because the caption doesn’t know how wide the image is, and it doesn’t care. It knows how much space it needs, and it knows there’s enough room for it, so it takes up all the room needs.  It has no reason to know we want it to start wrapping to a new line once it reaches the width limits of the image.

Brainstorming image caption solutions

The cop-out

Now, one way to solve this issue is to let the caption know exactly how wide we want it to be.  We can set an explicit width on the figure so that the image and caption are always the same size, but that’s not what we’re going for here.  We want to put in any size image, and have the caption adapt and align to it.

Thinking outside the block

Enter display: table-caption;
HTML tables are very interesting little creatures, even though they have a pretty bad rap nowadays.  One thing tables do extremely well is automatically handling the widths of the elements inside them.  A table will figure out the size of each column for you.  That goes for the caption of a table as well.  A table will make itself as wide as its contents need, and it applies the same width to any caption inside it.  Luckily for us, this behavior has been adopted into CSS, and we can apply it to any element using the display: table; and display: table-caption; rules.  Let’s take another look at our solution.

figure { display: table; }
figcaption {
  display: table-caption;
  caption-side: bottom;   /* optional */
}

Instead of displaying the figure as a block element, we tell it to display as a table instead.  And likewise with our figcaption, we tell it to display as a table-caption.  Now our figure looks at all the content inside of it (except the figcaption) and makes itself as wide as it needs to be.  In this case, the figure simply takes on the width of the image.  It then takes that width and ensures the figcaption adheres to it as well. This then makes our caption wrap to multiple lines once it reaches the limits of the image.

See the Pen Figure with Caption Final by Zach Handing (@zachhanding) on CodePen.

One more thing…

The last piece to this particular puzzle is to put the caption back below the image where we wanted it.  By default, the table-caption style puts the caption at the top of the table.  This is reversed by declaring caption-side: bottom;.  This is of course optional, as you can keep your caption above the image if you so choose.
Image captions: now solved with CSS.
If you liked this, check out my previous post about using Sass mixins to create the Teenage Mutant Ninja Turtles.

The end of the year is here, and it’s a time to kick back and enjoy ourselves and our families; a time to have some fun. A time to build a set of minimalist Teenage Mutant Ninja Turtle characters in CSS! Outside of being a fun exercise in general, this is a great look into how you can use the concept of inheritance and a swanky Sass mixin to write easily themed and reusable front-end components.
Since this is a theming lesson using ninja turtles, there’s no better application than comparing the 1987 TV series to the 2012 series.  Let’s get started.

The Parent Turtle

We’ll begin by defining all of the common styles that will make up a ninja turtle, regardless of who that turtle is or from what series they hail. The element itself should have a .turtle class, and we’ll give it two children, .mask and .shell. We’ll eventually want four of these things on the page, so let’s make it a list item inside of an unordered list.

See the Pen Half Shell Zero by Zach Handing (@zachhanding) on CodePen.

Add the styling for the legs in ::before and ::after pseudo-elements, then move on to the mask and shell. No mask color yet, since this is just our base class for the turtles. Little guy’s starting to look pretty cute!

Let’s Start Mixin It Up

Now to make each individual (and quite unique) turtle brother, we will inherit those styles we just wrote and add on features as needed, chiefly their mask and skin color.  All of these styles will be inherited because we’re using the same HTML markup for each series turtle as we did for our parent turtle.  Since we’re using the same markup, the same styles get applied to every turtle; making them unique is simply a matter of apply additional styling where needed.  Codepen does a great job of this by allowing any pen to link to a separate pen, which is what I’ve done with the next two examples.

Note: the 1987 turtles all have the same color skin (do turtles have skin?), but we’re writing this component to future proof it in case we come across a scenario where the turtles need to have different skin tones (e.g. the 2012 turtles).

Something like the following is what we’re after, complete with named parameters and default values:

$leo-green: #4c9c23;
$leo-blue: #09b6e1;
@mixin theme-turtle($skin: green, $mask: transparent) {
  background: $skin;
  .mask {
    background: $mask;
  }
}
.turtle.leo {
  @include theme-turtle($skin: $leo-green, $mask: $leo-blue);
}

Of course we have to add a bit more flair to make these guys resemble their television counterparts, which is done by adding some more optional parameters in our mixin. Be sure to check out the full SCSS source for each series, and let me know which you prefer!

1987 TMNT

Defined by their very uniform look, with the only discernible differences being their mask and knee-pad colors, and their adorable monogrammed belts.

See the Pen Half Shell Heroes (1987) by Zach Handing (@zachhanding) on CodePen.

2012 TMNT

A grungier look for a generation less amused by bright colors, these turtles add in leg wraps and shoulder straps.  They also give us the opportunity to write a Sass function for calculating their heights!

See the Pen Half Shell Heroes (2012) by Zach Handing (@zachhanding) on CodePen.

Here’s the collection of pens for this post.
 

A colleague recently asked me to give him a high-level overview on how to get started using these fancy front-end build tools everyone’s talking about. Since I’m a team player, I thought it would be best to share my advice with all of you as well!
First, what the heck am I talking about? What are “front-end build tools”? Simply put, there is a community of people and a whole bunch of services out there who just want to make it easier for front-end developers to build projects. Their motivation? Why go through the hubbub of setting up your working directory structure, downloading the plugins and libraries you need, writing scripts for minification, etc., when all of that can be automated?  Enter the realm of build tools.
Now that you know what they do, how do you use them? I fully support the idea of learning by doing, so my job here is to introduce you to your new friends, and let you guys get to know each other on your own time. Have fun!

Node.js – https://nodejs.org/

First things first is Node.js. Node is the foundation for any front-end build tooling you want to do.  Many, many blog posts could be written on what Node can do, but for our purposes, it’s a means to use NPM (Node Package Manager) which you’ll use to install all the other things.

Grunt – http://gruntjs.com/getting-started

Grunt is a task runner that lets you automate a lot of your development process (minifying scripts, compiling SASS, watching for changes to files and reloading your page for you, etc). There is an alternate tool called Gulp that is gaining traction, but I still find that Grunt’s community is larger and better supported.

Bower – http://bower.io/

Another package manager that will download any assets you want / need for your particular project.  Most build tool generators will use Bower to get you set up.

Yeoman – http://yeoman.io/

Yeoman let’s you skip learning all the intricacies of building a Node / Grunt project from scratch and just use a build tool someone else already wrote.  Install Yo, then head over to the generators page (http://yeoman.io/generators/) to find one tailored to what your project needs are.

The appeal of build tools is that they should make your development process easier.  Yeoman and Bower make setting up your project at the start quicker, and Grunt makes your dev process easier throughout the life of your project.  You’ll excel if you really dive into Grunt and learn all that it can help you do. No task is too trivial!

And that about wraps it up. Get out there and start automating!

Looks like the folks over at Wired launched a redesign of their site yesterday.  I was just reading through an article about it written by their engineering director.

http://www.wired.com/2015/03/wired-dot-com-from-the-devs/

I’ll let you creative types comment on the actual design of it, but there are some interesting things they are doing developmentally that strike my…interest.

First, they appear to be using Flexbox, which is an awesome layout tool, but won’t really help you if you need to support older versions of IE.  I’m glad to see a large company taking the plunge and using modern practices to take the web into the future and not being held back by older browsers. I wonder what their browser usage stats are; speaking with Perficient XD’s Manny Muriel, he made a good point:

That is interesting that they are using Flexbox. I just tried their site out on IE8, and it is completely broken. Maybe the amount of hits from old IE are too few for them to care anymore.

It’s a bold move, but it’s what we front-end developers like to see. If you don’t need to support out-dated browsers, don’t do it!

They also claim to have done some extensive tweaks in regards to performance and cut their page load time by half.  I’d like to take a more in depth look at what exactly they’ve done, and how similar tactics could be applied to our client projects. XD is pushing performance this year, and this seems like a good case study.

The way they handle link underlining is intriguing as well.  Not just your standard text-decoration: underline, and it makes for a neat experience.  There’s a write-up about how they did it on Hyungtak Jun’s blog.

Thoughts? Leave a comment with what you think of Wired’s site redesign.

In the technology industry, we often take for granted things in our work routine that we do so often we don’t even realize we’re doing them: keyboard shortcuts, program macros or any other “muscle memory” tasks that are second nature to us.  Many a time I have found myself working with a partner or helping a coworker with a bit of code and they stop me with a, “Whoa now, what the heck did you just do?”  For those people I’ve bullheadedly helped without helping, here is a short list of things you might not have known you could do with Chrome DevTools.

Android Debug Bridge

For starters, a few years ago I wrote a two-part article on how to use the Chrome DevTools to inspect and debug webpages from an Android device.  Pretty cool stuff, and useful when developing a responsive web design.

Force Element State

Another helpful feature is the ability to force states on any particular element in the DOM.  Do you need to debug the :hover styles of your main navigation, but can’t just leave your mouse hovering over it?  Pull up the DevTools, right click the element in question, then go to Force Element State.  You can have the browser mimic :active, :focus, :hover and :visited styles on any element.  This simple feature saves many a page reload.

Forcing an state on any element is just a right click away

Color Picker

The DevTools also have a color picker built into every CSS attribute that accepts a color value (color, background, border, etc).  In the Styles pane, right next to your color value it will show a small box that is filled with the color value you’ve specified.  That in itself is a handy feature to show you exactly what you’re specifying, but if you click that box it will launch a color picker that will let you extract any color from the entire page.  It’s your standard magnifying glass picker, so you can get right down to the pixel level with the color you’re choosing.  Great if you’re trying to match styles from one part of your page to another.

There is also a slider that lets you set the alpha level.

Console API

The last thing I want to share isn’t really a helpful feature as much as it is a “hey that’s pretty cool” feature.  In your JavaScript code, whenever you write out a console.log, you can style the text anyway you want by using the %c format specifier, and then passing it a string of CSS styles.  I guess if you wanted to show a certain error as GIANT RED TEXT then this would be useful, but other than that it’s just a fun way to make debugging less boring.

You can see more info about the Console API and all of the other neat things you can do with Chrome DevTools by checking out the documentation on their website.

Ref: the random CodePen I used in my screenshots

When designing and developing a website for mobile devices, there are many things one needs to consider. Are you using a responsive or adaptive approach? What devices / browsers should be supported? What are the major breakpoints? When trying to answer these questions, we as designers and developers tend to focus on mobile device resolutions as a deciding factor, but one thing that is often overlooked when considering the size of a mobile device is the CSS pixel ratio.
Put plainly, CSS pixel ratio (also referred to as device pixel ratio) is the relation between a device’s physical pixels and logical pixels. Especially with the advent of retina screens, the pixel resolution of modern mobile devices is growing at a fast rate. Consider that the iPhone 3g had a resolution of 320×480 px, the iPhone 4s’ resolution was 640×960 px, and now some phones like the LG Nexus 5 boast a resolution of 1080×1920 px. How is one supposed to design a website for all mobile devices when their screen sizes are so vastly different? That is precisely why the device-pixel-ratio was created.
Jumping back to the idea of physical pixels and logical pixels, we can see how device pixel ratio helps keep things in order. Physical pixels are the actual number of pixels in a device’s screen. Using the Nexus 5 as an example again, its screen resolution is 1080×1920 px, meaning its physical screen is 1080px wide and 1920px tall. Now if a browser were to use every single one of those pixels when it tried to render and display a website on a phone with a 5 inch screen, things would be far too small to see. Enter logical pixels. Logical pixels are defined as the number of physical pixels in a device’s screen divided by the CSS pixel ratio, and logical pixels are what you see when you look at your device (and more importantly, what your browser sees). For the Nexus 5, its pixel ratio is 3/1, so for every 3 physical pixels there is 1 outputted logical pixel (this is often referred to in units of dppx, or dots per pixel). That takes a physical resolution of 1080×1920 px down to a logical resolution of 360×640 px, and a much more manageable view for your eyes.
The table below outlines some more devices and their pixel ratios.

Want to see how this translates to your own device?  Pull out your phone or tablet and check out the demo I’ve created to show you what your own device’s CSS pixel ratio is.
The important thing to take from this is that a device’s screen resolution when viewed in a browser is not always what it says on the back of the box.

In the past few weeks, I’ve seen no less than five different companies publish an article documenting their internal CSS frameworks; it’s a fascinating pattern.  Getting an inside look at how other people (or companies) are organizing code and what tools they are using is a pretty fantastic way to become a better developer yourself.  Take a look quick look.

1. GitHub’s CSS
2. CSS at Lonely Planet
3. CodePen’s CSS
4. CSS at Groupon
5. CSS at Plataformatec

The benefits of having a defined development process are plenty: streamlining your workflow, code reusability, greatly decreasing the amount of time it takes to ramp-up new developers; the list goes on.
What are some of the things you or your company does to organize the structure of your code?

Microsoft published an article on their Internet Explorer blog yesterday that discussed their plans for supporting older versions of IE, and the web development community has been blowing up ever since.  I have seen many eager Interneters making loud claims to the tune of, “IE8 is dead!  We no longer have to support older versions of IE!”  However, it’s very easy to get caught up in the pandemonium or start bandwagon-ing and miss the actual facts of what is and will be happening according to Microsoft.  I want to clarify some things and set the record straight before we all hang up our Windows XP virtual machines.
Let’s look at the main quote from Microsoft’s article that sparked all this excitement:

After January 12, 2016, only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates.

There are two big parts to that statement.  The first is that Microsoft is only stating that they plan to stop providing technical support and security updates for all versions of IE except the most current available for each of their operating systems.  The table below shows exactly which versions they mean.

 
“But IE8 isn’t in that list anywhere!”  Correct, but that doesn’t mean IE8 is going away.  All this means is that Microsoft is not going to provide updates or support for IE8 anymore; it does not mean that people are going to magically stop using it.  The article also mentions that “Microsoft recommends enabling automatic updates to ensure an up-to-date computing experience”, but recommending that it happens does not mean that everyone will do it.  Yes, this is a big leap towards a day when developers do not need to worry about IE8 specific styles, but that day is not here yet.
Which brings me to the second big part of their statement: “After January 12, 2016”.  That’s a year and a half from now.  Microsoft is still going to provide support and updates for Internet Explorer 8 for another year and a half, and after that (as I mentioned previously), the browser will still be around.  All of those people that are using it now because it’s what they’ve always used, or because it will cost too much money for companies to update their employees’ computers…those people will still be using Internet Explorer 8.
I hope this helps to calm everyone who is hyping up the idea that we no longer need to support older versions of IE.  Don’t get too used to the idea just yet, because we’re still a long way off from that reality.

The CSS Flexible Box Layout Module Level 1 (or Flexbox) is a box model specification in which the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent.  In other words, it’s a neat way for front-end developers to layout content in a way that isn’t just “left to right, top to bottom”.
But I’m not here to tell you what Flexbox is, nor am I here to tell you how to use it.  At the end of this post are a few links that can cover that for you well enough.  No, what I’m here to tell you is that right now you in fact can use Flexbox.  Go ahead!  Use it!  Before vender prefixes were added, browser support for Flexbox had been sporadic and not very well adopted.  It was possible to use Flexbox on any project you wanted, but the problem was it wouldn’t work on a majority of browsers and mediums.  Now (looking at this Can I Use chart), adoption is so widespread it’s almost universal.
The only problem is (say it isn’t so!) Internet Explorer.  Trying to use the flex box model on anything earlier than IE10 just isn’t going to work.  This is the main issue, and unfortunately it’s a pretty dang big issue.
The solution? Go ahead and use Flexbox, just be sure to contain it to mobile devices (or progressive enhancements).  Most uses that I’ve had for needing to adjust the box model layout in a way that required Flexbox were design changes from desktop to mobile devices. Say you’ve got a two column layout with your main content and a right-hand sidebar.  If you wanted that sidebar information to float to the top of your page on a mobile device above the main content, you were going to have a difficult time. With Flexbox however, it’s pretty simple. And if used in conjuncture with media queries or Modernizr, keeping any usages of Flexbox limited to mobile device should be simple as well.
At the time of this posting, I’m not aware of any shims or polyfills to make Flexbox work on IE9 and earlier, so it’s not looking like widespread adoption of Flexbox in Internet Explorer will be happening anytime soon, but never say never!  And regardless of that, it is now finally a good time to start use Flexbox on mobile devices!

If you’d like to learn more about using and implementing Flexbox, here are two links from Chris Coyier of CSS-Tricks:

• Using Flexbox: Mixing Old and New for the Best Browser Support
• A Complete Guide to Flexbox

Back again with another recap of the STLUX conference sessions!  My previous post in this series covered Practical Interaction Design for Developers, a session by David Ortinau.  Where that session discussed how developers can educate themselves about user actions and expectations in regards to the design, this session covers another aspect of a user’s expectations for your site: its performance.  Given by Duncan Jimbo, here are my notes from Getting Started with Website Performance.

What is website performance?

Website performance is the delay perceived by a user between an action and a response.  Your website’s performance is your business, because poor performance costs you money.
Nearly 60% of users expect a site to load in 3 seconds or less, and 71% of mobile users expect the same results or faster than its desktop counterpart.

How can I improve my site’s performance?

To start, make performance a goal during the Discovery phase of your project. It’s best to begin thinking about your website’s performance before you begin development.
Consider setting a performance budget (that you can measure in seconds, kB, etc).  This enforces you to discuss HOW to display your content, not WHAT content to display.
It’s important to know that a user’s machine can only download four pieces of your site (resources) at a time, and 80% of the response time occurs on the front-end.  Some ways to cut down on front-end load times are as follows:

• Cut down the number of resources downloaded by concatenating (and minifying) CSS and Javascript files
• Optimize images (ImageOptim) and use image sprites
• Load CSS before Javascript
• Consider the effect of any third party plugins you are using
• “Lazy load” non-critical content
• Conditionally load content for responsive web design
• Use sub domains to serve CSS and Javascript (this is a handy way to download more than four resources at once)
• Use a CDN to delivery files or content

There is an app called Slowy that will allow you to simulate different connection speeds and test your site for how it responds to slower connections, and testing is crucial to fixing any problem.
But above all, the most important thing you can do for improving your website’s performance is to try to create a culture of performance thinking in your company.

St. Louis had a user experience conference last month (yes, I am very timely) called STLUX, and I’m starting a series of blog posts to recap some of the sessions I attended.  Instead of the typical essay type of blog post, these will be a more in depth breakdown of my notes, which come in a bulleted format.  Enjoy!
This is the first in the series, covering the session by David Ortinau called “Practical Interaction Design for Developers.”

• Interaction design is defined as the structure, behavior and the meaningful relationships between people and products.
• In interaction design, people are the focus, not the code.
• EVERYONE (on the team) needs to be informed about what the design is trying to do.  Designers and developers need to work together.
• Developers don’t know everything, and should constantly be questioning themselves and their solutions.
• “How did I come up with this answer?” Question yourself. Your brain can often trick you with your first answer.
• It is the duty of the machines and developers to understand people and how they think. We can absorb the pain, so our users have a better experience.
• Bill Verplank’s Three Questions (for interaction designers to answer in regards to their users)
  • How do you do?
    • Push that button
  • How do you feel?
    • I messed up
  • How do you know?
    • Way finding
• Don’t make your user figure out and understand how your product’s system works.  Your system should understand how your user thinks and expects the system to work, and your system should work accordingly.
• Slow is a bug
• Cognitive dissonance is a bug 
• Cognitive dissonance is when the user expects one thing to happen, and something else happens instead.

All in all it was a great presentation.  I always enjoy listening to David speak, because he has a fantastic presence and passion for the topics he presents.
Stay tuned for my next session summary on fixing your website’s performance!