Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

December 05 2013


Kickstarting Your Rails Education

It's been a long time since I last coded on the server-side. In fact, if you've read some of my tutorials, you may have noticed that I use ColdFusion as my application server. While ColdFusion still works great, it definitely doesn't have the panache and coolness of newer server-side technologies like Ruby on Rails. Wanting to be a bit more modern, I've decided to jump on the Ruby on Rails train. Both Ruby and the Rails framework are proven technologies that are stable and widely embraced so I think it's a great direction to head to in my server-side renaissance.

Picking it is the easy part. The hard part is actually learning how to properly use RoR and finding good resources learn from, the latter being the hardest part of it. With so many sites coming and going or not being maintained, it can be difficult to find information that's relevant and useful.

Luckily for you, I've done a lot of homework recently and started to collect a list of current. up-to-date resources that have been recommended to me and look really promising.

Let me share these with you.

The Ruby Language

You've got to walk before you can run and learning the ins-and-outs of the Ruby language will help you get a leg up. I'm a firm believer that having a good understanding of a programming language will make leveraging complementary technologies (e.g.: Rails) much easier and allow you to build maintainable code from the get-go. I know it may seem obvious but I've seen plenty of cowboys out there that learn something half-assed in a weekend and throw up production code the following Monday.

The great thing about the web is the abundance of interactive tools available for learning. The slogan for Try Ruby is:

Got 15 minutes? Give Ruby a shot right now!

And they hit the mark by providing an interactive editor that takes you step by step through the learning process. You follow some simple exercises, enter your answers in the editor and get immediate feedback.



Like Try Ruby, RubyMonk takes an interactive approach but they've also broken down the learning into skill levels. Each tutorial is listed by which level the content applies to allowing you to scale your learning appropriately. The site even offers an in-progress tutorial on using Rails.

Why's Poignant Guide to Ruby

When you first hit this site, you may actually think you've landed in the wrong place or a hipster book club. Don't be fooled. Go ahead and click on the book, then follow the pages. Initially, the imagery and cartoons may be confusing but as you get further along, you'll see it's just the author's eccentric style of writing meant to make his presentation of Ruby topics more inviting. The books is actually very good from what I've seen and a good resource to have.


As you learn Ruby, you'll see how rich the language can be. Being "rich" also means there's a lot to learn and language APIs to get comfortable with. This is where Ruby documentation project comes in. It is absolutely invaluable and you will live in this as you start to ramp up in Ruby. Seriously, bookmark it now.

Programming Ruby 1.9 & 2.0 (4th edition): The Pragmatic Programmers' Guide

Affectionately called the "pick axe" book, this is the must-have reference guide for Ruby. It's like the holy grail of the language and the one I found recommended all over the place. The key thing to keep in mind is that it's a "reference" and meant to complement your learning efforts as opposed to actually walking you through the learning process.

The Rails Framework

Once you feel you have a good grasp of the Ruby language, next it's time to jump into the Rails framework. Currently at version 4.0.x, it's become a mainstay for most startups that want a robust framework to get them up and running quickly. From what I've seen, it's very opinionated about how it does things, focusing on a lot of abstractions to make common tasks (e.g.: database access and interaction) easier.

Ruby on Rails Tutorial by Michael Hartl

In terms of learning Rails, this tutorial by Michael Hartl is one of the most complete I've seen and amazingly, he offers it up for free. He does offer some other niceties like screencasts and ebook versions for a cost but unless you want to place the book on your Kindle, reading it online should suffice.

What I love about this is that it covers every major aspect of the Rails framework and is updated with each major Rails version including v4.0.x. It's the reason that I listed it as the first Rails tutorial to check out.

Rails Guides

The tutorials in the Rails Guides will give you a solid foundation to work from. Looking through the Getting Started tutorial, it looks to cover the basics well but it does feel like Michael Hartl's stuff is a bit more comprehensive. Nonetheless, it's still a great option to learn by.

The Rails 3 Way

Obie Fernandez is a Rails guru and this book is recommended by everyone as the must-have Rails reading material. So I bowed to peer pressure and got it. Can't say yet if it's awesome but enough people I know who are good Rails developers said it's good so I'll go with that.


Online Courses

Sometimes having someone walk you step-by-step through the learning process works better. Thankfully, there are some free courses available that provide a nice walk-through of Ruby on Rails and help make piecing things together a bit easier.

Tuts+ Premium Courses

I'd be remiss if I didn't mention Tuts+ as a great place to crank up my Ruby and Rails education. I also think Jeffrey Way would totally disown me as well!

Jose Mota's course, The Fundamentals of Ruby is a great example of the high-quality courses available for aspiring Rails developers like me.


RailsCasts was created by Ryan Bates and currently lists over 400 instructional videos. Most of them are short and cover very specific topics allowing you to zero in on what you'd like to learn about.

Lots of Goodness to Learn From

Well that's my list. I think it's a pretty solid one at that. I know there are a ton of other blog posts, newsletters, sites and resources that aren't listed but that's okay. This is a list to get things kickstarted and as with any new thing, it's easy to get overwhelmed with too much information. I actually wrote about how hard it can be to stay on top of emerging technologies and finding time to learn new things in my op-ed, The Learning Conundrum.

I'm trying to keep things nice and tidy so I can focus and set realistic learning goals. I find this list to be short and sweet providing a good balance of reading material and interactive learning. But if you feel like I'm absolutely missing out on a good learning resource, mention it in the comments.

December 03 2013


What’s in a Story?

In 2006 and 2009, studies were published showing that fiction readers were more empathetic than their non-reading counterparts. In 2012, further studies showed that the areas in the brain that activate when a person tells a story are also activated in the listener. In other words, years of study led researchers to conclude something that most of us instinctively know: that the stories we (as individuals or as companies) tell our audience directly influence the thoughts and actions of those who listen.

Few people remember the year the Titanic sank, although most of us learned it in middle school history. Yet the movie Titanic immortalized every detail of the sinking ship in the minds of millions. Equally, content strategists and designers must constantly tell stories to inform the perspective of their prospective users.

Put simply: stories are more engaging than facts, and we all have the power to tell them. In this article we’ll review not only the importance of stories throughout the history of human beings, but also the ways that we, as content strategists and designers, can create stories that provide context for our target audience.

Why stories?

“People need stories more than bread itself. They tell us how to live, and why.” – Arabian Nights

Storytelling is an invaluable means of communication, dating back thousands of years. Greek and Roman mythology, for example, explained everything from the changing seasons to life and death. One Greek myth is that of Pandora’s box:

Pandora was the first human woman on Earth. There were Gods and there were Titans, but no humans. So each God gave Pandora a gift: beauty, charm, music, curiosity, and persuasion among them. Zeus, ruler of the Gods, also gave Pandora a box (or a jar, in the original Greek), and told her not to open it. Curiosity being one of Pandora’s gifts, she eventually succumbed and opened the box. Out flew disease, hatred, war—all sorts of terrible things. She managed to close the box before hopelessness could fly out.

The Greeks used this tale to explain all of the world’s evils and how humanity could hold hope in spite of them. True, the Greeks could have merely passed along “facts” from one generation to the next. They could have told their children “there is evil in the world, and yet you must continue to have hope.” Instead they used the power of story and, in so doing, created something that’s been with us for over 3,000 years.

Today, well branded companies use a similar approach. Many of us forget that sneakers are not an exciting purchase, yet Nike tells the stories of professional athletes who started out “just like us.” We buy their story and, consequently, the shoes that come with them. State Farm insurance doesn’t focus on paperwork, either. They tell a story about enjoying family time and having friends to help out in times of trouble. We purchase their insurance in hopes of buying into the camaraderie they present.

Content creators are storytellers

But information doesn’t naturally come in story form. On the contrary, many companies begin with “facts” such as “our sneakers decrease knee injuries” or “our application saves users time when they look up recipes.” This non-narrative approach may be less compelling, but what it lacks in panache it makes up for in opportunity. By adding context to facts, content strategists can provide their audience with a story rather than a table of benefits and functionality.

As a content strategist myself, I recently helped a company craft a story to provide the necessary context for their new online community. After speaking with a few of their target users—those in the “nutrition web” space—we began to establish the company’s story. We asked a second group of target users if they would like help finding healthy recipes for evenings when guests joined their family for dinner. We looked for chances to weave story into every aspect of the website: stories about family dinners, stories about children growing up, stories about busy days with only a few minutes to relax. Our target audience responded incredibly and traffic increased!

So how did we do it? In order to develop the best stories, we followed a four-step plan: We Researched our audience, Established our story, Added in details, and Distributed copies.


The first step to communication is learning about our potential audience: where they spend their time, what information they need, what vocabulary they use. We do this through listening.

Ideally our companies have a sense of who their prospective users might be. By interviewing five people (be that as vague as “iphone users” or as specific as “moms in their 40s with teenage kids, full time jobs, working in the tech industry”), we obtain a gestalt of the vocabulary our users are comfortable with (also known as a vernacular or a lexicon) and some of the stories with which they might empathize.

There is no shortcut to this part, unfortunately. Just as there’s no shortcut to learning about a blind date—all the Google searches in the world won’t tell you what you’ll learn during an actual conversation—there is no better way to learn about users than to just sit with them and listen. We do that best by way of ethnographic interviews, interviews or conversations designed to do nothing more than understand who our target audience is and how they spend their time.

The questions to ask are simple: ask users to explain what they do at work all day; ask them to describe the details; learn what acronyms they use and how much work impacts their daily life; ask them about their families; ask them how they spend their free time. Most of all, ask them what frustrates them, at work or at home. Everyone seems to warm up when they’ve been invited to complain a bit!

Establish the story

Once we understand our user’s stories, it’s time to tell our own. For many people, this is the hardest part of the job: crafting a story our company wants to tell.

Nike’s content strategy team clearly follows a trope in which a beginner athlete moves to the pros. Perhaps this is based off research in which many members of their target audience said “if I had better sneakers, I would run more. I always wanted to run a 10 mile race.” Someone who responded this way would obviously feel a connection to a commercial in which an athlete transitions from beginner to winner.

The best product stories are aspirational, providing a gateway into a world created by using the product or service. In service of that story’s creation, content strategists need to frame things with a clear beginning, a middle, and end. Consider the fairy tale of Little Red Riding Hood:

  • Little Red Riding Hood wants to visit her grandmother. (Beginning)
  • She meets the wolf, who eats her and her grandmother. (Middle)
  • The huntsman kills the wolf, and Red Riding Hood lives happily ever after with her grandmother. (End)

Companies can employ a similar structure. If Motorola’s target audience includes “parents with full time jobs,” and Motorola knows those parents have a common thread of guilt—insofar as they wish they could be in two places, the office and home, at once—the company might craft a story like:

  • Joe wants to spend more time with his family. (Beginning)
  • Joe buys the new Moto X phone, which allows him to work from anywhere. (Middle)
  • Joe leaves the office early, to take his family on a picnic. (End)

Add details

Remember, stories give us context. A story that’s devoid of personalized details fails to create context and, therefore, fails to make a connection. This is why, according to Aberdeen Group, personalized emails improve click-through rates by 14%, and conversion rates by 10%.

Many content strategists miss the mark here. We create an outline (the beginning, middle and end) based upon our understanding of our audience, but we neglect to add personalized details. No one cares about a story of a person who goes for a walk, walks into a house, and then gets kicked out when the owners return. What makes the story interesting is what it expands into. The person changes to a little girl. The strangers become bears! The bears become a family. The family enjoys a morning walk. This explains why they were out of the house. The little girl becomes Goldilocks, a very curious girl, who is always poking into other peoples’ business. And on and on and on.

If Goldilocks had a Twitter account, it would likely be filled with reports on bears, recipes to make oatmeal, and pathways through the woods. These are the personalizations that make a story compelling. Over time, the number of details woven into a social media strategy might expand as the character of Goldilocks (or the brand personality) expanded. The Twitter feed might include information on her favorite types of breakfast, or personalized emails might mention even less-obviously-related items, like a book she happened to be reading.

The story behind our companies must expand in a similar way. What makes Home Depot’s Twitter feed so interesting is not just the deals it offers; it’s the non-hardware-related articles the feed promotes that still appeal to its customers. Customers who align with the Home Depot brand enjoy DIY projects, humorous contests, and family-centric holidays.


Finally we have to distribute the story itself.

In theater, it’s commonly said that the show is not complete unless it has an audience. The same is true of a story. A story is nothing without its audience. The best part is that the same story may have multiple parts—and therefore multiple audiences—across multiple mediums.

Nike’s brand story, for example, is told through their commercials, their website, on their Facebook page, and on their Twitter feed. Nike tells different parts of that story in every communication with every user. They’re not trying to sell; that’s just a byproduct. They’re engaging their audience by offering articles, videos, cartoons, and other news that’s custom-tailored to a given interaction.

But that’s Nike. Not every audience can be found on TV, Facebook or Twitter. Some companies find their users on LinkedIn, or Quora, or Instagram. The key isn’t to go to a specific place. The key is that, through user research (remember step one?), we can learn where any audience member spends their time, online and off. Then we work to join the conversations whenever and wherever they take place.

Tell your story

For each individual brand, we can follow these steps to improve the overall user experience and better engage the user. Every story embodies a personality, which we can personalize for the target audience to make our product or company friendly and focused. Storytelling is in our genes, and it’s a tool everyone on the UX team can—and should—use!

This article’s lead image is copyright Mike Shaheen.

The post What’s in a Story? appeared first on UX Booth.

December 02 2013


Recently in Web Development Nov 2013

We used to have an awesome series called "Recently in Web Development" which listed out cool happenings around the web development industry. It touched on interesting frameworks, tools, articles and tutorials, helping to organize information in a quick and easy-to-read format.

Based on feedback, we've decided to bring it back and hope that it helps you, our faithful readers, stay on top of the news and announcements of this fast-changing industry.

So without further ado…

News and Releases

Let's get caught up with relevant news and releases from around the web development community.

Rails 4.0.1 Is Out

The Rails framework continues chugging away with its newest update to version four. The big update in this version is a change to the way Active Record handles order calls and the subsequent prepending of an SQL ORDER BY clause. It was primarily done for backward compatibility but worth checking out to ensure your apps behave as expected.

Read more

Google Octane v2.0

Google updated their Octane JavaScript benchmark to include some new tests to simulate complex data structures and memory-intensive applications by measuring (interestingly enough) how fast Microsoft's TypeScript compiler can compile itself. There are also a number of fixes to existing tests to help improve the reliability of measurements. If you're a JS developer, it's definitely worth checking this out.

Read more

AWS SDK for JavaScript

Looks like Amazon wants to get into the "no backend" world for client-side developers. We've seen services like Firebase offer managed back-end services like this making it easier for client-side developers with no backend experience to get up and running quickly. Seems Amazon likes this too since they launched a developer preview AWS SDK for JavaScript.

Read more

Missed the Chrome Developer Summit?

If you missed the Chrome Developer Summit, be sure to at least grab the speaker decks which are chock full of great information on performance, Chrome packaged apps, and the Chrome Developer Tools.

Get the decks

And While You're At It…

Check out Addy Osmani's deck, "Rendering Performance Case Studies", which he used for a talk at VelocityConf. It should go nicely with the decks from the Chrome Summit.

Addy's slides

The Node.js Knockout Contest Announces Its Winners

Node Knockout is a yearly event which always produces some impressive results. This year's winners are no-less impressive with everything from multi-player games to embeddable JavaScript to mine bitcoins.

Read more

Firefox 29 Alpha

This is the nightly version of Firefox which will have the new Australis UI, the first big interface update to Firefox in years.

Read more

New and Notable

Here's a glance at some new resources that might pique your interest. We'll run the gamut from frameworks to books trying to call out new things that look pretty cool and might make your development easier.


RedditKit.rb is a reddit API wrapper, written in Ruby. RedditKit.rb is structured closely to the wonderful Octokit.rb and Twitter gems. If you're familiar with either of those, you'll feel right at home here.

Read more


This component will auto-complete or auto-suggest completed search queries for you as you type. There is very basic keyboard navigation using the up and down keys to scroll up and down the results and enter adds the selection, while hitting escape hides the autocomplete menu.
This is a work in progress.

Read more

Book: Node.js In Action

Node.js in Action is an example-driven tutorial that starts at square one and guides you through all the features, techniques, and concepts you'll need to build production-quality Node applications.

Read more

INIT Front-End Framework

INIT aims to provide you with a decent workflow and structure within your sophisticated web project. INIT is based upon HTML5 Boilerplate and adds more structure for SCSS files, JavaScripts, includes build tasks and a whole lot more.

Read more


grunt-ec2 abstracts away aws-cli allowing you to easily launch, terminate, and deploy to AWS EC2 instances.

Read more

jQuery Evergreen

jQuery Evergreen works with modern browsers. It has the same familiar API as jQuery, and is lean and mean with the following, optional modules: selector, class, DOM, event, attr and html.

Read more

Suggested Reading and Off-Topic

Tutorials are cool but sometimes we just want to read the esoteric and unique. That's what this section is for. Somewhat technical but not necessarily tutorial-based content.

Converting Print Books Into eBooks Using Radically Smart Templates

If you've ever been curious about the technical process of bringing books to a readable form on the web, then this post by Brad Neuberg of Inkling is a must-read.

Read more

4 Golden Rules for Asking Questions on Forums

It may seem obvious to many but knowing how to post for help properly will go a long way to getting you the answer you need.

Read more

How Ready Are the 5 Top US Online Retailers for Black Friday?

The team at Zoompf tested out Amazon, Walmart, Target, eBay and Best Buy to see if they're ready for Black Friday. Check out what they found in their survey.

Read more

Civic Information API: Now Connecting US Users With Their Representatives

Google released their new Civic Information API "that lets developers connect constituents to their federal, state, county and municipal elected officials—right down to the city council district".

Read more

EtchMark Under the Hood: Building a Website That Handles Touch, Mouse, and Pen – and Device Shakes

If you haven't yet seen Microsoft's EtchMark Etch-A-Sketch drawing toy demo, go check it out because it's pretty cool. Then read up on how they built it.

Read more

So Much More…

There's so much going on in the industry and hopefully this will be enough to satisfy your information appetite for now. We'll continue to search out cool, interesting and unique tidbits and bubble them up to you. We'll be back soon with more great information to share.

Tags: Articles News

November 29 2013


Interview With Jonathan Snook

I've met many web developers over the years and the common theme is that they tend to specialize in a specific aspect of web development. They're either designers, JavaScript coders, server-side experts or perhaps a tiny bit of all of them. Rarely do I meet someone who is incredibly well-versed in the full-stack having an amazing design acumen and being able to take a vision and bring it to life, front to back.

Jonathan Snook is one of those rare breeds and also an influencer in the web development world. His skills have made him a sought after speaker and writer and afforded great opportunities at companies like Yahoo! and Shopify. He's now venturing into product management and we catch up with him to see how that's going and his advice for anyone looking to jump into that role.

Q Let's start with the usual. Could you give us a quick intro about yourself?

Sure thing. My name is Jonathan Snook and I'm a web developer based in Ottawa, Canada. I've been developing on the web since before Netscape hit 1.0. I've had the pleasure of working on hundreds of projects both professionally and personally. I also speak at conferences and put on workshops and have authored or co-authored three books to date, the most recent of which is Scalable and Modular Architecture for CSS (or SMACSS for short). These days, I'm a product manager at Shopify based here in Ottawa.

Q You've transitioned to a product management role recently. What prompted the switch?

Opportunity and misunderstanding! Until earlier this year, Shopify never had a product team. I was working on the design team focused on our core product. As a company, we have traditionally had a very egalitarian approach that allowed anybody to work on an idea. Shopify was growing quickly and really needed product ownership to keep the team and product focused. A product team was being assembled. If you're picturing it being like the Justice League, it's just like that.

The role, as it was described to me, sounded much like the work I was doing as a designer. Talk to customers, the support team, and other stakeholders to evaluate which problems we should be solving and testing our work to ensure that we were solving our problems well. This sounded fantastic and I jumped at the opportunity. I misunderstood just how much work it really was to define a solid product direction and be able to communicate that effectively both within the company and out. As a result, I've not done nearly as much hands-on development as I expected I'd be able to continue to do.

Q How has the new role affected your skillset? Are you still coding or are you losing your edge?

Shifting into product management has meant learning new skills. I've been doing a lot of reading. I've been researching what makes a good product manager. I've been researching what needs to happen for a team (or multiple teams, really) to build a good product. It's been a great opportunity for me to grow and has been very exciting.

I'm still coding when I can but not nearly as much as I used to. However, I still read the blogs and twitter posts. I try to stay on top of the industry, and I still get to speak and attend great conferences where I can expand my knowledge. I still participate on pull requests and technical discussions. I still feel like I've "got it", at least from a technical conceptual level. Actually spending a day writing code, on the other hand, might prove a little harder. Just don't tell anybody that!

Q Has the new role changed the way you work with your development team now that you're on the other side of the equation? If so, what are the good and bad parts of the interactions?

I've been fortunate to have a well-rounded career having done design, front-end development, and back-end development. One of the advantages to having this breadth of skills is the ability to deeply understand the requirements at all levels. I'd be lost without the ability to understand the design and technical hurdles. I wouldn't be able to engage my co-workers on the same level. They're very smart people that can code circles around me but at least I can understand what they're doing and why they're doing it the way they are. I think this is very helpful.

On the bad side, it's not anything you don't see come out of any team. People have different ideas of what we should be focusing on. Sometimes I don't communicate the vision and direction well enough and that can create confusion and conflict. Those are skills I'm working to improve upon.

Q How do you balance out the desire of developers to implement the new shiny features or technologies versus managing the realistic goals the product?

At Shopify, we're dealing with a 7 year old codebase. The team often wants to work on refactoring things instead of the shiny new features. I'm the one who wants to implement the new shiny features.

Of course, with all things, balance is key. One of the things that I liked when I worked on the design team at Yahoo! was the regular maintenance cycle that was built into their process. Clean up files, fix naming, get rid of cruft. As Shopify grows, we know we need to continue to keep this balance. I think we're on the right track, even if sometimes we disagree when we should be doing feature development or should be doing refactoring and maintenance.

Q I know a lot of devs that would eventually like to shift to product management. Could you tell us about your transition and the things you feel would help others transition successfully?

Even though we had product managers at Yahoo!, I rarely interacted with them. The role was largely foreign to me until I decided to jump in head first.

If you want to be a good product manager for a technology company then I think a well-rounded background is good to have. Then again, I think that for nearly any role you might take. (And I believe that working for a web agency is a great way to gain that experience. Although, I'm probably biased since that is the path I took.) A good product manager needs to be able to communicate well. A good product manager needs to have empathy. At Shopify, for example, I run a store. In fact, I sell my book, SMACSS, on Shopify. This helps me understand some of the problems that our customers face every day. I don't think I could manage a product I didn't believe in.

For those looking to transition from development to product management, having that passion for the product is going to be key. For me, it was an opportunity to have a bigger picture of the entire ecosystem and to have more sway on the direction across the entire system. I wanted this because I want Shopify to be amazing. I want it to be something that people enjoy using every day.

If you want to become a product manager, don't let the word "manager" scare you. Don't worry about losing your skills. The industry changes fast but not that fast. It just feels like it does. If I decide that I want to leave product management and get back into coding full-time, I feel confident that it would be a reasonable easy transition back in. (Then again, it's only been 6 months. We'll see if I think the same thing in 2 years.)

Q SMACSS is your baby. What is it trying to solve that CSS frameworks don't already do?

Frameworks don't code your entire site. Take any framework and you still have to add your code on top of it. This was the problem I was trying to solve. What problems are the frameworks trying to solve and how is the code you're writing going to fit in with everything else.

That's why SMACSS is written the way it is: it's not a framework. It's meant to describe a process. It describes a way of architecting a site. It's a documentation of the learning process I went through in building large projects with large teams.

Q In terms of real-world development, how does SMACSS adopt to the dynamic needs of UI & UX development?

SMACSS came out of real-world development. It's not pie-in-the-sky thinking and it's not a lone wolf approach. It's an amalgamation of many ideas that were already floating around.

As an industry, we've been seeing more and more designers and developers approach site design as a modular system instead of as a series of brochure-style pages that don't change. The modular approach means that parts can be moved around. The more autonomous the parts, the easier it is to move them and add new ones or remove others.

SMACSS, being a scalable and modular architecture for CSS, is catered to the dynamic needs of UI and UX development.

Q Since SMACSS outlines a guideline for structuring your CSS, how viable is it for projects that are already in progress? At what point in the development process is SMACSS viable?

Of course, it's always easier to be able to write everything from scratch but that doesn't always happen. I had that privilege at Yahoo!. But coming into Shopify, I was contributing to an existing project that had already been under development for some time. "If it ain't broke, don't fix it" is a familiar mantra but refactoring should be something that projects make time for. Refactoring removes the technical debt that has built up allowing for faster development for new features. As they say, "there's no time like the present" to begin implementing a modular approach to a project. Just do it one piece at a time. That's the approach we took at Shopify and one we continue to take.

Q Other CSS frameworks tend to specify their own way of doing things. Is SMACSS workable in a scenario where existing frameworks are dictating process?

It depends on the process! When I wrote SMACSS, I wanted to present a number of concepts that could be taken in part or as a whole since that's the way I am when it comes to development. I'm unlikely to take someone else's project wholesale. I'm going to take the pieces that work for me and leave the rest.

Q Last question, what the heck happened to the Snitter Twitter Client?!?

Have you seen the Twitter client ecosystem?! Yeah, I think I'm okay having let it die. I'm happy with the small success it had (which wasn't really that much to begin with) and enjoyed the process of building the app. Alas, my time was better focused on other projects.

Thank You Jonathan

Jonathan, thank you for taking the time to chat with us and for your great advice on transitioning to product management. If you'd like to learn more about Jonathan be sure to visit his blog and follow him on Twitter. You can also find out more about SMACSS at the project site.

November 25 2013


November 19 2013


Fail Fast, Fail Often: An Interview with Victor Lombardi

Retrospectives are common. You’ve likely conducted one before. But how many companies are actually good at them? How many companies actually have the courage to be open and honest about their own shortcomings? My experience tells me that very few are. And that’s why Victor Lombardi’s recently released book, is so necessary: unlike the ones designers are used to seeing, Lombardi’s stories are full of objective, thoughtful, and insightful commentary.

An award-winning product designer, Victor Lombardi’s had a hand in over 40 different software and internet projects throughout the course of his career. And during that time he’s clearly paid attention to one thing: namely, all of the different ways in which a project can unfold. His new book, Why We Fail, tells over a dozen stories of projects gone awry.

So why do design projects fail? Many reasons. Lombardi attempts to answer the question from a number of angles: product ideation, design, development, and marketing. After reading his book, we brought additional questions to the discussion: How does bias factor in? Or branding? And, on a different level, what can we learn from

Our full interview appears, below. Additionally (as is always the case when we interview an author published by Rosenfeld Media) the publisher has graciously offered to give away a few books to readers. More information on that follows the interview!

Hey, Victor! Thanks for taking the time to chat. Throughout the book, you note a wide variety of places in which cognitive biases might affect an organization (“survivorship bias,” for example, is a perspective that exclusively favors success). Were you aware of bias and its effects from the outset or did you simply start to see bias the further you delved into your research?
I wasn’t expecting to hear about bias when I interviewed people for the book. Maybe that’s because I didn’t think people would open up this way. But they did.

I think it’s good therapy for us to talk through not only what we did during a project but also what we thought and felt. From there I brushed up on my psychology—Max Bazerman’s “Blind Spots” was particularly helpful—to explain the cognitive science behind the issues that led to failures.

Many companies find it (understandably) difficult to financially justify a culture that “embraces” failure. What advice do you have for them?
If senior management rules by ego, believing that the people at the top have the best ideas, then I’ve got nothing to say. They won’t hear my message.

For others, I think the overt message of “fail fast” is actually better framed as “experiment fast.” The most effective innovators succeed through experimentation. They’ve updated the traditional R&D department by stepping out of the lab and interacting directly with customers, running thoughtful experiments, and executing them quickly to learn quickly what works and what doesn’t.

Anyone doing user-centered design is already 80% of the way there. It makes a huge difference just to shift your process towards the scientific method, phrasing research questions as hypotheses and iteratively testing towards them. A key difference is in the results: instead of a lot of usability data to analyze and interpret, you get a true or false result. This makes it much easier to decide what to do next.

I recommend reading up on methods like customer development, lean startup, or by starting with the final chapter of my book.

In chapter four you recount the story of Wesabe and Mint, two startups who approached the financial space from slightly different perspectives. Wesabe suggested that users manually upload their financial data (in the name of privacy and security) whereas automated this task (at the risk of perceived security). Both were minimum viable products, but one failed while the other succeeded. Can you speak a little as to what startups can learn, generally, from Wesabe and’s subtle differentiation?
Wesabe was a useful service with a smart Web 2.0 strategy. Given more time and investment it would still be around. But certain classes of startups are dependent on attracting large numbers of customers in order to attract more investment. chose features and designed them in a way that excelled at attracting customers. They won the competition even though Wesabe was superior in many ways.

But this isn’t true in every case. In the book I cover a broad spectrum of products: startups and mature products; mobile, web, and desktop software; hardware; and services. Different situations resulted in different lessons. I summarize the lessons at the end of each case study.

One of my favorite case studies in the book is Google Wave, in which you suggest that the first sign of trouble was that everyone had a different definition of what a “wave” actually was. Personally, I think this speaks to the strong connection between user experience, semantics and branding. How do we fail in this regard and how might we do better?
The UX field generally is not good at the conceptual design stage of creating new products compared to, say, industrial design or architecture. We fall in love with our first idea, and we can quickly and cheaply move from idea to working prototype—it isn’t natural to stay in the idea stage for a while to explore alternate solutions.

It’s unfortunate that Google Wave failed because the problem still exists. The solution was close. …maybe “Concept Design” should be my next book ;-)

Chapter 7, titled “Do the right thing,” tells the story of Plaxo and, two companies who each decided to employ dark patterns to “better” their business. What other kinds of stories/examples did you consider including in this chapter that exhibited bad behavior?
In cases like I had no doubt the behavior was unethical. Others were less clear cut. Some of the things Plaxo did [ed: such as mass emailing its members’ contacts] that annoyed us back then are now accepted practice. So it’s relative. I decided against including others because there was no smoking gun, so I’ll refrain from mentioning them here as well. If you really want to know, you’ll have to buy me a drink sometime.
Last question! I know it’s a bit premature, but what, if anything, do you think designers might learn from the (highly publicized) failure of
Let’s say we solved for the myriad of political and vendor integration problems that plagued the project. What’s left are some intriguing customer experience issues. One seems to be that a long registration process is required before the customer can view prices of health plans, because the plans and prices are determined by your registration information. I don’t know how they ended up with that design, but the decision to design it this way sounds like a policy decision made around a conference table rather than through a design process that included running experiments.

What you can do if you find yourself in this situation is to acknowledge, out loud, that the goal of not showing prices prematurely is a good one, but the solution of making the customer do a lot of work up front is risky because more people will abandon the process before receiving any value from the site (see Wesabe vs. Mint). To mitigate this risk, you can generate alternate designs, mock them up, and test them out with customers.

Offhand, I can think of a few options:

  • Let visitors browse plans upon arrival and show the range of prices next to each plan to give people a general idea of cost. Then show them the actual prices after registration.
  • Show some realistic content so visitors know what factors will influence the price, like “Sally, a single mother of two in New York will pay $100/month for Plan X which includes benefits A, B, and C.”
  • If just a bit of data is needed to determine price, like state and income, just ask for that data, and require registration later when people are ready to buy a plan.

Thanks, again, for taking the time, Victor! Your book was a pleasure to read.

If you’re as jazzed about learning from failure as we are, I’d strongly suggest entering for a chance to win a copy of your own, courtesy of our friends over at Rosenfeld Media. To enter, simply follow UX Booth on twitter and leave a comment on this post answering the question: What’s your favorite story of design failure (one you’ve witnessed firsthand or otherwise) and what lessons to you think it provides? Rather than pick the winners at random, as we usually do, we’ll work with Victor to pick the three best stories of failure. Their authors will receive copies of the book. Entries must be made by Midnight, PST of November 21st. Good luck!

The post Fail Fast, Fail Often: An Interview with Victor Lombardi appeared first on UX Booth.

November 18 2013


November 14 2013


Interview With Eric Bowman of

While most of us have built really cool websites, realistically speaking, few developers have had to worry about the complexities of managing and scaling incredibly large websites. One thing is putting up a site for a small company to ensure they have a great presence and another is trying to figure out how to scale your site so it won't buckle under the load of thousands of users.

I was fortunate enough to chat with the folks a flash-sale site which has received quite a bit of press over the years and seen tremendous growth. It's opportunities like these that allow us to probe the team that manages these sites and learn how they handle their day-to-day business and technology.

In this interview, Eric Bowman, Chief Architect and VP of Platform Engineering at Gilt Groupe takes us through some of the background behind the site and the technology decisions behind keeping the service running smoothly.

Q Could you give us a quick intro about yourself?

I’m incredibly proud of what the team has accomplished.

I’ve been with Gilt since August 2011, and became VP/head of architecture and platform engineering in December 2011. During my time here, we’ve transitioned from Java to Scala, adopted Gerrit for code review, implemented a continuous delivery system we call Ion Cannon, introduced a typesafe client and microservice architecture, rolled out Play 2 for our frontend, created a public API, and rolled out platform engineering as an organizational architecture. I’m incredibly proud of what the team has accomplished. Before Gilt I was an architect at TomTom in Amsterdam and was responsible for their online map, search and traffic APIs, and products. Prior to that I was an architect working on service delivery for 3′s global 3G launch offering, and a long time ago my first “real” job was building The Sims 1.0.

Q Could you set an expectation for our readers of the scale/size of so they get a better feel for the breadth of effort needed to build a large-scale site?

The flash sales model presents a unique technical challenge because so much of the traffic comes in these incredible pulses as new sales go live. Over the course of a few seconds, our traffic can increase by as much as 100x, which really puts stress on every part of the system, all at once. Essentially, we need to have the eCommerce infrastructure almost at Amazon scale for at least 15 minutes every day. Most days this happens exactly at noon EST, and until a couple of years ago, noon was a stressful time every day. Nowadays it’s usually a non-event–in part because our software is great, and in other part due to better visibility into system performance and behavior.

In order to accommodate the pulse, we tend to over-provision on the hardware side. Our customer-facing production environment at the moment consists of about 40 physical servers running a couple hundred micro-services and a few dozen user-facing applications. On top of that we have about another 100 servers for development, testing, data warehousing, analytics and development infrastructure.

Q When it comes to large web properties, most developers are curious about the technology that runs under the hood. Could you share what you’re using and what prompted some of the technology choices you’ve made?

On the database side, we depend heavily on PostgreSQL, MongoDB and Voldemort.

Gilt was originally a Ruby on Rails application with a PostgreSQL backend. We had serious problems scaling Rails to handle the noon pulse, and the core customer-facing systems were ported very quickly to Java and a coarse-grained, services-oriented architecture starting in 2009. We kept the Java extremely low-tech: JDBC, hashmaps and JSP.

The performance and scalability of low-tech tools on the JVM is astonishing. As we grew the tech organization in Gilt, though, it became increasingly hard for teams to contribute code. A downside of the low-tech approach was that the contracts between systems were not well defined, and the most critical code bases grew monolithic over time. We gradually transitioned away from a pure servlet-based service implementation towards JAX-RS, and in parallel increasingly toward Scala. Our service stack is similar to Dropwizard, which came a few years after we built our internal platform, built on Jersey and Jackson 2. We like Dropwizard, but found that the way apps are configured–at runtime, in particular–wasn’t very compatible with our infrastructure, which uses ZooKeeper for discovery and per-environment configuration.

We’ve also moved from Ant to sbt over the last year. At TomTom I grew fond of Maven, and spent some time trying to introduce it at Gilt. At the point everything was falling into place, I had a change of heart and did some experiments with sbt. We found that sbt provides a fantastic developer experience and has an incredibly powerful extension model. Switching to sbt has enabled a degree of tooling customization that previously seemed impossible, and a lot of great features have fallen out of the sbt adoption, such as deep integration with our continuous delivery system and automatic dependency upgrading–things we couldn’t even imagine with tools like Ant or Maven. It was an interesting case where the limitations of the tools limited our imagination, and an important lesson for me personally in how to recognize and avoid that antipattern.

On the database side, we depend heavily on PostgreSQL, MongoDB and Voldemort. PostgreSQL has been part of the Gilt stack from the beginning, and has been amazing. We were one of the sponsors supporting the development of hot standby, a key feature in PostgreSQL 9.0 that enables true replication. We run it on Fusion-io cards, and the performance has been phenomenal. Our CTO, Michael Bryzek (also a Gilt cofounder), recently released a really nice open source schema upgrade mechanism for PostgreSQL. In general we’ve been moving away from a monolithic database application towards individual private databases per service. PostgreSQL is really nice for this, and its stable, predictable performance makes it straightforward to predict system behavior and to provision smartly.

Both MongoDB and Voldemort have become increasingly important in the last year or so. Voldemort has been part of Gilt’s stack for some time, though usage of Voldemort didn’t grow at all until this year. Despite less momentum than some other NoSQL solutions, we find Voldemort to be incredibly reliable and straightforward to reason about, and gradually we’ve introduced it in a few more places. We’ve wrapped it and incorporated it into our core platform, which makes it straightforward to use in new services; it’s easily embeddable, leading to almost no additional infrastructure needed to run a reliable Dynamo-style key-value store. We’ve also looked at a number of other solutions in the space, including Riak, and we’re pretty excited by all the activity in the field–particularly around multi master databases with strong semantics on conflict resolution.

MongoDB has also become increasingly important at Gilt over the past couple years. Today we run our core user and authentication services on MongoDB–absolutely critical data with very high throughput and low latency requirements–and it has been running now for a long time and very smoothly. MongoDB gets a hard time in the community sometimes, but we’ve found it to be astonishingly fast when run on high-spec hardware, and we’ve been reluctant to consider other options because of its raw performance in our use case.

Q Focusing on scalability specifically, what were your expectations when Gilt was launched and how did you prepare for launch traffic and post-launch growth?

Gilt grew faster than anyone could have imagined, and everyone was caught off guard by how difficult it was to scale the Rails stack. Like any successful startup, Gilt was assembled just-in-time, and the bulk of the effort was spent trying to react to what the market fed back in the face of so much public interest in what Gilt was trying to do. Startups in this situation have to maneuver a knife-edge of “just enough” architecture. If you overthink or over-engineer too much or too soon, it’s impossible to move fast enough to capture the market you are going after. But if you don’t architect enough, you can’t actually adapt once you’ve got something running. Gilt’s core tech stack has always embraced simplicity as a key feature, and maintaining that over time has been a worthy challenge.

Q Post-launch and obviously using hindsight, which decisions do you feel were spot on and which do you wish you could have a do-over on?

The decision to use PostgreSQL was spot-on. Despite the scaling issues with Rails, it’s an amazing framework for moving fast–until you need to scale. So that wasn’t necessarily a wrong decision, and a lot of Gilt’s internal systems today are written in Rails. If we were starting over today, we’d probably build on top of Play 2.

Q Of the technologies you’ve leveraged, which specifically helped in terms of scalability?

In terms of technology, we’ve found the JVM to be very scalable. Over time a number of tools have come into play to make scaling easier. Scala, ZooKeeper, RabbitMQ, Apache Camel and Kafka come to mind as important for scalability.

However, scalability at Gilt has had less to do with specific technologies, and more to do with architecture and approach. We’ve never been afraid to rethink things almost from the ground up, and scaling is a multidimensional problem that covers technology, infrastructure, architecture, and organizational structure. We’ve iterated along all four of those axes.

Q Being a commerce-oriented company, safeguarding customer data I’m sure is priority #1. From a security perspective, how have you had to adapt your infrastructure to adjust to the constantly changing security landscape?

We take security and our customers’ privacy very seriously, obviously. I don’t want to go into too much detail here, but a few things stand out. We take PCI compliance extremely seriously, and everyone participates on some level in the PCI review process. We’ve architected our systems using a bulkhead approach to PCI compliance, which physically limits what needs to be PCI-compliant, and also reduces risk in the event of a number of possible breach scenarios we model. We’ve found a micro-services architecture, and continuous delivery make it relatively inexpensive for us to stay cutting-edge in terms of security-related best practices, and so we try hard to do so.

Q Along those lines, what has been the most challenging aspect of security to manage?

The biggest challenge by far is coming up with a realistic model of what the risks really are, and then making the right decisions to mitigate those risks. Despite lip service about how security is everyone’s problem, in practice it’s hard for developers to keep security in mind all the time. We’ve focused more on an architecture that is forgiving and partitioned so that we don’t compromise security, and we reduce the scope of any particular potential mistake.

Q How has open-source software played a role at Gilt, both from a technology and financial perspective?

From a financial perspective, open source has helped us keep our costs down, and also helped us move faster.

Gilt is built almost entirely using open-source software. We actively encourage our engineering teams to use and contribute back to open source, and we have really low-friction guidelines for how to contribute back to open source. We have a number of open source projects we host on our GitHub repo, and we constantly feed pull requests upstream to some of the most important open source projects we use. We also actively support open source efforts, from funding feature development in PostgreSQL, to sponsoring Scala conferences like Scala Days.

From a financial perspective, open source has helped us keep our costs down, and also helped us move faster. Besides the obvious benefit of not paying licensing costs, open source provides a more subtle advantage, in that when you run into an issue, whether a trivial one or a catastrophic one, you can both look at the source code and potentially fix the problem. I started developing in a closed-source environment, and I do not miss those days where everything was a black box, and licenses were enormously restrictive in terms of what you could do with–or, in some cases, even say about–commercial software.

Q When you looked at a specific OSS-based technology, what was your decision-making process for determining it’s viability, applicability to your needs and the longer-term management of the technology?

We try to actively follow the latest developments across a number of open source projects, and read blogs, and generally we all love technology and tend to get excited. So sometimes it’s hard to avoid the irrational exuberance that can follow if you read too many blog posts and believe all the hype. We have an internal peer-review system that encourages a lightweight planning and architecture discipline, which works pretty well. We also use things like the ThoughtWorks Tech Radar to help temper over-exuberance, and also to gain insight via another lens of what’s working well across the industry.

Our approach also depends on how critical the software is. At Gilt we talk a lot about “Voluntary Adoption,” which actively encourages our developers to adopt the best tools for the job. In practice this means that individual teams have a lot of leeway in terms of leveraging whatever open source libraries they want, and when this goes well, it helps to keep things simple–and also helps us move faster. Usually the benefits of these libraries are clear; we tend to leave it up to individual teams to do the right level of analysis around the tradeoffs and costs of a particular solution. It is a struggle to avoid too much fragmentation across the organization, and we actively work to understand when teams have needed to use fairly exotic libraries, and incorporate them into the core platform in a way that tries to minimize upgrade pain and “dependency hell.”

For more critical shared components and systems we tend to use a combination of consensus, peer review, and stress testing to make decisions. Sometimes we look at a system and it’s so obviously superior to the other options that consensus is easy and we move quickly to adopt. ZooKeeper is an example of this. In other cases when the choice is less clear, we tend to just spin up the various alternatives and run them until they break, and try to understand why they failed, if they failed. For example, when evaluating messaging systems, we found that pumping a billion messages as fast as possible through several contenders was a pretty good way to eliminate poor choices via a “last man standing” criterion.

For now our approach is fairly lightweight and agile, and we hope to keep it that way. Microservices and a unique approach to deployment make it straightforward for us to try things out in production to see how they work, without much risk. Ultimately how a system works in production is the most important criterion, and not one you can divine through documents and meetings. We try stuff and use what works.

Q OSS relies heavily on community contributions. How does Gilt give back to the OSS community?

On the JavaScript and Ruby side of things, we’ve open sourced a number of libraries.

On the Java and Scala side, we’ve not contributed as much or as quickly as we’d like, due to some specifics of how our build works that makes it hard to build some of our most core software outside Gilt’s infrastructure. We are actively working on improving this, and we have a backlog of Java and Scala software we look forward to open sourcing in the next half year or so.

On the JavaScript and Ruby side of things, we’ve open sourced a number of libraries, most of which are visible on our GitHub page.

We’ve also funded specific features in PostgreSQL, for example, and we regularly sponsor conferences around open source topics–primarily Scala in the recent past. We also are large supporters of the technology groups where we have our main engineering centers (New York and Dublin)–opening up our offices to host local meetups, gatherings of technology groups, and even free all-day free courses.

We also include open source in our hiring process, in that we tend to prefer developers who are or have been involved in open source. In general we see it as a great sign that a developer is used to code that gets read, and also has priorities aligned with how we try to develop at Gilt.

In Closing

Eric, I'd like to thank you for taking the time to talk with us about Gilt. We appreciate the transparency and comfort you having in sharing many of the architectural underpinnings of such a highly-trafficked property. The complexity and diversity of the technologies you use shows that scaling a site requires more than just choosing a stack and running with it. It also demonstrates that it's important to objectively look at all of the options available and choose (sometimes adapt) to other products that can help your business be successful.

November 11 2013


November 06 2013


Interview With Jeffrey Way

If you’ve been reading this site for awhile, then you know who Jeffrey Way is. He’s the man, the myth and the legend behind the stellar growth of Nettuts+ and an influential voice in the web development community. And now he’s tackling online education full steam via Tuts+.

We wanted to catchup with Jeffrey to see how his next great adventure is going. Let’s check it out.

Q Readers want to know, “Where in the world is Jeffrey Way?”

In the last year, much of my energy has been put into the Tuts+ Premium program, and I’m really proud of what we’ve achieved.

I’m still around! I simply decided to adjust my priorities a bit. After building up and maintaining Nettuts+ for five years, I realized that I’d reached the limits of what I was capable of learning in that job. Staying anywhere too long is rarely a good thing, so I chose to step down as editor, and instead focus my attention on other projects.

In the last year, much of my energy has been put into the Tuts+ Premium program, and I’m really proud of what we’ve achieved. Though it’s been tough, we’re now at a point where we’re publishing well over 25 new courses every single month. We’ve released courses on everything from modern WordPress development, to Yeoman, to Ember, to Laravel testing. As I sometimes tease: if you enjoy Dreamweaver, then is a great choice. Otherwise, to instead learn the technologies that working pros use every day, Tuts+ Premium is a really fantastic resource. :)

Q You have one of the biggest fan bases, built on your stellar work on Nettuts+. What prompted the change to Tuts+?

Like I said above, mostly it came down to a personal decision. Life is too short to not experiment with new ideas and roles. So, having managed the site for over five years, the time was right to move on. You have to be careful about falling into a rut, sometimes.

Also, with you and Andrew at the helm, I felt that the site was in perfect hands to reach the next level.

Q The focus of Tuts+ is squarely online courses. How do you see online education complementing and/or disrupting the traditional mediums for education?

The best education on the planet in this sphere is not exclusive to a cold brick building.

What’s particularly nice about online education is that it can be anything you want it to be. While traditional schooling has a tendency to force lesson plans (which I’ve never been a fan of, considering the price tag), when it comes to the online world, you’re in charge. You choose the path.

Do platforms like Tuts+ disrupt the traditional medium? I’d say the answer is a big fat yes. As I tweeted not too long ago, at this point, I can’t imagine an environment where I’d find myself recommending to my future child that he or she should attend university. Perhaps there are merits to the social aspect of college (questionable, though), but, beyond that, I see it as little more than an excellent way to start your life with masses of debt.

If your goal, specifically, is to develop for the web, then the answer is even more obvious. The best education on the planet in this sphere is not exclusive to a cold brick building. It’s widely accessible for free around the web. We’re very fortunate that our community (web development) is so incredibly open about documenting their trials and experiments.

Q I’ve read viewpoints where people, on many occasions, recommend forgoing formal education altogether and encouraging developers to leverage the Internet as their educational resource. Is online education at a point where bypassing a degree in, say, Computer Science is actually viable?

I think we passed that point long ago. Outside of the incredible price tag, the problem with university is the same problem with all forms of traditional schooling: it mandates a “one size fits all” approach to learning. Maybe every eighteen year old doesn’t learn best by waking up at eight in the morning, sitting in a 200+ auditorium for ninety minutes, and then taking multiple choice tests. Gasp – maybe there are ways to learn that don’t fit some college’s rigid curriculum. You are not a bad person if you don’t fit this mold.

Really, though, it all comes down to what type of person you are. I was not a fan of my university experience; however, my personality type virtually guaranteed the experience I had. You might be different. If that’s the case, and you can afford the price tag of admission, then certainly nothing bad could come from it! In those cases, have at it, and use platforms like Tuts+ as a supplement.

Q There’s been some criticism about online education (some valid, some FUD). How do you ensure that the courses you’re providing offer real-world knowledge and value to people who take the courses?

Honestly, it can sometimes be a struggle. The key for me has been to leverage the community that I’ve personally submerged myself in. Twitter is amazing for this. By reaching for the leaders in the community, I can rest assured that they’ll bring their experience to the courses and material that I might not personally be as well-versed in.

In terms of choosing which courses to publish and what constitutes “real-world knowledge,” well that simply comes down to experience, I think. Generally speaking, I can often refer to the technologies that I, myself, am interested in learning more about. This includes everything from Ember to AngularJS (yes, both), to architecture, and everything in between. At that point, it simply translates to a process of choosing which developer is most qualified to teach those subjects.

Q I recently wrote on the challenges of staying up-to-date with technology. What are your thoughts on how developers can manage the fast and constant changes for the evolving web development space?

Ahh, yes, I’ve written about these challenges myself many times, as well. There’s no denying that ours is an incredibly difficult industry. I’ve often noted that, if I knew how deep the rabbit hole went at the beginning of my development career, I’m not sure that I would do it again. I guess, from that perspective, my naivety was absolutely working in my favor back then!

I certainly don’t want to dissuade the newcomers in the audience. Instead, I’d simply recommend that they be prepared for the long-haul. Development isn’t something that you knuckle down and learn in six months (despite what some infomercials may say). It’s a non-stop battle, not too dissimilar from an RPG. Little by little, your skills level-up. But it’s a slow process. The key is to love it, and to never stop…even when you’re overwhelmed with frustration and confusion.

Q You’ve become one of the biggest advocates for Laravel. What makes Laravel so special to invoke such a passionate dedication to the framework?

If you want to talk about sheer joy of development, I’ll happily put Laravel up against any framework.

Because Laravel makes PHP development fun! There was a period of time, not too long ago, when PHP and its community were, for lack of better words, hated. Seemingly, the headline joke of every day was one that related to how terrible PHP was. Let’s see, what new PHP-slamming blog article will be posted today? While some of these complaints are certainly valid, the truth of the matter is that much of what people hate about PHP has little effect on your average developer’s day-to-day workflow. In fact, most of that vitriol is rooted in the days of PHP 4. The language and community have come so far since then. It’s unfair to continue painting it with that brush.

If you want to talk about sheer joy of development, I’ll happily put Laravel up against any framework. Rails, Django, Express, you name it. Laravel has it all, too. Migrations, Active-Record implementation, clean syntax, testing facilities, elegant routing, etc. Every Laravel developer knows that feeling of realizing that a seemingly difficult task has been reduced to a single method call.

Need to cache a database query to improve performance? You can do that in one line of code. Want to work with queues, without the hassle of a background daemon? Laravel hooks up flawlessly with’s push queues. No framework in existence makes it easier. What about things like writing a console command to deploy your application? Yep, with Laravel, we can arrange that in seconds, using custom Artisan commands and the remote component.

The reason why I’m such a cheerleader of Laravel is because I’m continually impressed by its capabilities. It never fails.

Q It seems like Laravel and Symfony have taken the PHP world by storm. How does this impact existing applications based on other frameworks like CodeIgniter? Will we be seeing a developer knowledge gap soon?

I suppose one argument is that it doesn’t affect those applications at all. Projects built upon CodeIgniter may freely stay that way. There’s no mandate that all applications must be upgraded to their nearest modern framework base! But, naturally, we’ll continue to see the decline of CodeIgniter. This is a certainty, and is specifically why I’ve stopped commissioning new CI courses for Tuts+ Premium. We’re interested in modern development; not technologies of 2008. While CodeIgniter was fantastic in its own right, the simple truth is that its time has come to an end.

Symfony and Laravel are the PHP frameworks of the new generation.

Q Along those same lines, how does PHP fit into the picture when so many web developers are preaching the virtues of Node.js, Ruby on Rails and Python with Django? Is PHP adapting to modern needs?

Pick one that feels right to you, and start building things. That’s all that matters.

Perhaps the question could instead be phrased, like so: “Despite the fact that many developers champion newer languages and frameworks, why does PHP continue to dominate, to the point of 80% market share?” Certainly, something must have been done right, yes?

What this all boils down to is that PHP has been around for a long time. It’s not “the new hotness.” It’s not overly sexy. But we get stuff done. I’ve never been more excited for what’s in store for the community and language than today.

But, sure, those other technologies are excellent, too. Pick one that feels right to you, and start building things. That’s all that matters. People focus too much on “us vs. them.”

Q Last question. What would you like to tell your many fans that miss your presence on Nettuts+?

I’m still here! Let’s stay in touch on Twitter. My username is @jeffrey_way.

In Conclusion

Thank you very much Jeffrey, for taking time to do this interview.

November 04 2013


October 29 2013


Five Tips for Conducting Scientific Research in the UX World

Despite the fact that research plays such a pivotal role in the practice of user-centered design, much has been written about how to approach it in a “quick and dirty” manner. Why the rush? I believe that the application of a more rigorous, scientific methodology could lend some much-needed credibility to our approach.

My love story with research began almost a decade ago. One day, while working as a novice prototyper, I was instructed to get feedback from customers. So — awkwardly — I introduced my ideas to potential users. Some told me what they liked; others gently glossed over what they would improve. I came away feeling accomplished.

Little did I know. My subsequent training as a scientific researcher helped me see the error of my ways. I realized that, in that moment, I used biased responses to inform my design. I heard what I wanted and not necessarily what I needed.

A rigorous approach to research provides a much clearer path to unbiased findings, findings that go a long way towards informing our design. This article covers five perspectives to that end. Starting with research plans, we’ll cover details of testing methodologies and even the role of the researcher herself. Finally, we’ll discuss the ways these tips apply to our research in practice.

Go back to where it all began

All scientific research projects begin with a research plan, a document that outlines:

  • The problem (or the research questions) to be explored,
  • A summary of existing literature,
  • The hypothesis(es) or an extrapolation of any patterns evident in the existing literature,
  • The research participants who will take part (more on this, below),
  • The data collection methodology(ies) to be employed,
  • The planned analysis methods, and
  • Any expected results.

The goal in writing a research plan is to be absolutely certain that the entire team understands not only the purpose of the study but also the fact that each aspect of the study has been given due consideration.

Developing a sound research plan requires that we begin with an extensive review of existing theories, models, and other research studies. This ensures that we aren’ t reinventing the wheel. For instance, if the study is based around the System Usability Scale, the best thing to do is to read the original paper to truly understand the scale. Finding original research is more valuable than pretty diagrams or the popularity of the source. Valuable academic citation sites include Google scholar and Microsoft Academic Search. While there’ s always the risk of playing a game of “telephone”, these documents often go through extensive committee review which minimizes the chance that they will contain incorrect information.

Determine the number of participants beforehand

Sample size has been a hot topic for a while now. Some researchers assert that five participants will suffice2; others calculate their sample size based on the power that they want to achieve3; still others believe that a higher number has a lower percentage of risk associated with it4. My take is that the sample size depends on the methodology of the study.

For example, a qualitative, exploratory study on mobile phone usage behavior needs descriptive, insightful data, so the number of participants depends on the richness of the information received. But, a quantitative study, such as looking at the effects of mobile phone usage on behavior depends on confidence limits and intervals as well as analysis methods. The more analytical you want to be, the bigger your sample size needs to be.

Either way, the key is to determine the number of participants before conducting our research and to continue researching until we’ ve hit that number. This ensures that we aren’ t swayed by early trends that might ultimately cause us to miss subtle issues. The Three Mile High tragedy is a painful reminder of the severity of subtle issues.

Don’t let your interests conflict

Scientific research focuses on objectivity. For that reason, it always begins with getting approval from an Institutional Review Board (IRB), an academic organization that approves and monitors any research involving humans. The IRB requires that all researchers state they do not have a conflict of interest in the research project at hand.

So, what does this imply for UX designers? Simple: designers shouldn’t research their own designs.

Designers inevitably design things that make sense to themselves. This is beneficial in some ways, but it also paves the way for hundreds of biases to affect decision making. In order to gather unbiased research to inform designs, a trained, unbiased researcher needs to have the final say on the questions, and decipher the answers. This helps avoid experimenter biases like interpretive bias and observer bias.

Test the test

Pilot tests are tests of a research plan. For scientific researchers, pilot tests are necessary in order to ensure the validity of the research plan and help identify possible problems with it5. Ideally, pilot tests are conducted with a group of users that are representative of the target audience.

The pilot test works exactly like the proposed one, but instead of looking for data, it allows us to catch errors in our test itself. For example, if we are pilot-testing a survey and users don’ t understand the word ldquo; cumbersome” , we might remove that from our final survey. With a survey, we’ ll also time how long users take to complete it, make sure that every question is understood correctly and ask the participants for candid feedback.

If we’ re doing a usability test, we’ ll provide the instructions and watch them complete the tasks that we plan to assign to users, to ensure that our instructions are clear; we’ ll remind users to think aloud and to be frank with their opinions, as they would in an actual test; and, most important, we’ ll take notes every time they ask that a question be repeated or for more clarity.

Make sure to stick to the planned script and behave as though this was a regular research study. Ask for honest feedback on how users would improve the overall study and let your expertise as a researcher apply their answers accordingly.

Typically, results of a pilot test are only used to modify the actual test. Results like answers to surveys, time taken to complete tasks, etc. should not be incorporated into the final results of the research to ensure consistency.

De-bias, de-stress, de-tect

Scientific research often requires extensive vetting of researchers — the people conducting the research — prior to their participation in a project. The latest trend in the UX world is to get everyone involved with the research. As a researcher, nothing excites me more than this but that being said, it is extremely important to acknowledge that the inexperience of a researcher and its number of open (versus hidden) observers can be inversely proportionate to its overall ldquo; success.”

For instance, usability testing (arguably, the most common type of research method in the UX world), can be extremely stressful for participants6. Aside from being asked to ‘perform’ , users are sometimes put in unnatural conditions which can be very nerve wracking. This, in turn, could hinder performance and risk invalidating our findings.

Another thing that affects performance is the fact that participants change their behaviour when they know they’ re being observed, something otherwise known as the Hawthorne effect. Worse still, this effect is only exacerbated as the number of observers increases. So while it’ s definitely good to get more people involved and invested in research, there are a few precautions we should take in order to minimize their potential negative effects.

  1. First, whenever we’ ve got a group of people involved in the research process, we should always ensure the facilitator of a research session has some experience and training so that they’ re not unknowingly influencing participants. Keep an eye out for leading questions and analyze the results accordingly.
  2. Second, either keep the observers hidden or to a minimum. A researcher’ s main job is to keep the data as pure as possible (objectivity, remember?), and a stressed participant does not provide reliable data.
  3. Third, let’ s remind the users that we had nothing to do with the design, so that users aren’ t hesitant to give too much negative feedback.
  4. Fourth, always remind the user that we’ re testing the product and not them. This is (hopefully) old news, but users need to be reminded of this constantly.
  5. Fifth, and finally, always keep an eye out (or a ear, if the session is remote) for any sign of stress. If the participant starts to appear stressed, immediately change the topic or consider ending the session. The key here is to note the difference between a stressful or frustrating design interaction and a stressful research session. The former provides valuable insight while the latter can provide unreliable data.

Repurposing the scientific method

In summary, I suggest taking a leaf out of the scientific researchers ’ book:

  1. Plan your study out and read the sources to get accurate information.
  2. Choose a number of participants before testing, and stick to it regardless of the first trends that appear.
  3. Be alert! Watch out for bias when conducting research.
  4. Test our tests.
  5. Avoid biases, stress, and leading questions.

Most importantly, don’t shy away from rigor in the research process; it’ s the only thing that can lead to truly dependable results!


  1. Fin, P. (2006). Bias and Blinding: Self-Fulfilling Prophecies and Intentional Ignorance
  2. Nielsen, J. (1993). Usability Engineering. Boston :AP Professional.
  3. Kraemer, C. & Thiemann, S. (1987). How many subjects? Statistical power analysis in research. Oaks, CA, US: Sage Publications, Inc. (1987). 119 pp.
  4. Faulkner, L. (2003). Beyond the five-user assumption: Benefits of increase sample sizes in usability testing. Behavior Research Methods, Instruments, & Computers, 2003, 35(3), 379-383.
  5. van Teijlingen, E. & Hundley, V. (2001). The importance of pilot studies. Social Research Update. Issue 35.
  6. Schrier, J. (1992). Reducing Stress Associated with Participating in a Usability Test. Proceedings of the Human Factors and Ergonomics Society Annual Meeting 1992 36: 1210. DOI: 10.1177/154193129203601606.

The post Five Tips for Conducting Scientific Research in the UX World appeared first on UX Booth.

October 28 2013


Interview With Brian Leroux of Adobe’s PhoneGap Team

Mobile web development is tough especially when you're trying to offer native-like experiences to users. Several years ago, a small company called Nitobi took on the effort of simplifying building native mobile apps using traditional web development skills. Ambitious and sometimes controversial, the effort known as PhoneGap grew out of this need and one converts left and right.

One of the main masterminds behind the framework is Brian Leroux who apart from being well-respected for his development skills and incredibly likeable personality is also one of the savviest mobile developers around. Considering the number of mobile devices PhoneGap targets, you have to be pretty well-versed in a variety of devices and OSs.

Nitobi has since been acquired by Adobe and the PhoneGap codebase donated to the Apache Software Foundation to continue its development as the Apache Cordova project. Brian moved over to Adobe and continues to steward the codebase. In this interview, we'll chat with Brian about how PhoneGap came about and what the future of mobile web holds.

Q Let's start with the usual. Could you give us a quick intro about yourself?

Hello, I'm Brian. I work on Apache Cordova, PhoneGap, and a new css library called Topcoat at Adobe. In my spare time I created a code joke site called which kind of follows me around.

Q You were one of the creators of PhoneGap. How did Nitobi decide to build such an ambitious framework?

I've definitely been one of the stewards of PhoneGap but it is very important for me to say that MANY people of contributed to the creation and growth of it. No one person really decided to do anything it was a lot of forces coming together at once. PhoneGap was an outcome of the primordial soup that was the new Github model for open source, nascent mobile web browsers, and new generation smartphones. We started hacking, and did the whole thing in the open, and eventually more people subscribed to the project philosophy and utility. It grew from there.

Q Now that Adobe has acquired Nitobi, what's the future of PhoneGap?

Adobe acquired Nitobi in 2011! It is a little hard to believe that was close to two years ago already. Since our acquisition we donated the source of PhoneGap to Apache which is now known as Cordova. We are constantly improving project, adding features, polish, performance improvements, new tooling, and recently we shipped a vastly improved plugin architecture. PhoneGap has become as much about tooling and extension as it is a fancy embedded web browser for building apps.

We're also working closely with a new team at Adobe on a CSS library called Topcoat that is designed for building fast and clean apps. Of course, everything in Adobe Edge is growing mobile consciousness as a part of our focus on web technologies. Brackets is great for authoring web centric code. Reflow and Inspect are great new tools helping tame responsive design. We'll see more and deeper integrations between these tools and PhoneGap in the future.

Q There's a lot of confusion about PhoneGap and Cordova. Can you clear things up?

Adobe PhoneGap is a downstream distribution of Apache Cordova. It is the same as the relationship of Safari to WebKit. When Adobe acquired Nitobi the original source of PhoneGap was donated to Apache to continue its open development, and encourage contribution from the wider developer community. It has been really great, and the community has grown exponentially since joining Apache. It was a great move for the project and has really matured the development.

Author Note: Brian goes into more detail about this in this blog post.

Q There have been a number of other similar projects but PhoneGap's received the bulk of the attention. What can you attribute to its popularity?

I think our popularity is owed, in part, to very clearly defined principles and goals. We want the web to be a first class platform and we often state a purpose of the project is to cease to exist. It's a powerful acknowledgement of our intention to get back to web development. This resonates with the web community.

PhoneGap is also just a really good name that clearly communicates the project succinctly. We got lucky there. I'm not sure if it was Brock Whitten or Andre Charland whom coined it. Rob Ellis was there but I doubt he'd remember either. I hated it at first but after five years of working on the thing I'm sort of used to it!

The adoption of PhoneGap was probably a little bit of dumb luck too. I'd like to think we made some of that luck with a regular release cadence and a strong testing philosophy. We rarely have regressions, and we ship quality releases continuously. That healthy activity has helped to build the confidence of our developer community, and the businesses and organizations that are using PhoneGap today.

Q In terms of mobile, how easy or challenging has it been to use web technologies like HTML & JavaScript to create a platform that builds native apps for mobile devices?

Well, on one hand it is super easy to get started building a web app. On the other hand, web apps can grow complex quickly, and the devices we're talking about don't have a whole lot of horsepower to begin with. Software development is a balancing act. We're balancing all sorts of forces. Skill and code reuse. Adding more features or working on performance.

Q Did you find mobile OS vendors receptive to PhoneGap? What challenges did you have to overcome?

Most mobile operating system vendors are contributing directly to Cordova!

We have friends from Google bringing Chrome Packaged Apps to the fray. Mozilla is ramping up Firefox OS with us. Canonical has hackers working on Ubuntu Phone. Blackberry has a bunch of devs bringing us the Blackberry Webworks perspective. Intel and Samsung representing Tizen.

Early in the PhoneGap project, before all this glamorous Apache business <g>, we were temporarily blocked from the App Store by Apple. It was the best thing ever. It brought a tonne of attention the project. After much kerfuffle, Apple reviewed our code to our mutual satisfaction that we were not in violation of any of the App Store policies and PhoneGap apps have been shipping there ever since.

Q What are the practical use cases for using PhoneGap and at which point should developers consider going totally native?

Well if you have an existing investment in web content or web developers then PhoneGap is worth looking at. If you are looking for portability then web technologies are obviously useful, and this can even mean on a single platform, but able to automatically target handset and tablet form factors with a single codebase.

I used to say that web technology isn't really the best choice for games. But this depends on the type of game. Mobile games in particular tend to be more puzzles, card, or two dimensional sorting things that do not require immersive graphics. Web technology is surprisingly good for these types of games. Until we get better support for WebGL I think going native is still compelling. The W3C and browser vendors are very aware of this shortcoming and it is only a matter of time before the Game Controller, Orientation Lock, Fullscreen API, and the Audio API are fully realized. The console will move into the browser and monetization will move towards a service model as a result.

Q When should developers look at native versus going pure browser-based for mobile apps?

Well, if you have the time to invest in a particular platform (sometimes proprietary too) then going native is a fine, if costly, route to invest in.

It is easy to write a crummy native app as it is with web tech but it is even easier to debug these things using the native platform tooling. That tooling integration makes most development environments very comfortable, with great documentation, and distribution is kind of built in. (You get these advantages with PhoneGap too as that we do not hide these details.) I encourage developers to always be learning as much you can and native mobile development is super fun stuff to learn.

That said, I'm not as convinced about the business benefits of going native. You inherit a reliance on (often) proprietary tooling and distribution channels which is inherently risky. When the vendor makes a change so do you. If they chose to shut down, deprecate, or otherwise abandon infrastructure you rely on for revenue you will have no say or recourse. I personally would not build a business in that way, but I can also respect that some do, and either way you can use PhoneGap to mitigate that risk.

Q Is browser-based mobile web ready for primetime? If not, what's missing?

Offline is still messy, we have App Cache but it is really complex and creates a janky user experience. When a new version is available you have to prompt the user to reload. But I have high hopes for the Navigation Controller effort to fix it.

Push notifications are another thing the web needs to get right. Notifications are crucial for user engagement. Those standards and support are starting emerge in desktop web browsers but we need those capabilities to rise up into the mobile web browsers.

The security models for packaged apps is in need of refinement. But that is happening. As a result we will win more and better device APIs. Firefox OS and Chrome OS are going to point the way. We're going to do everything we can to help by providing a quick prototyping surface for browsers.

Developer tooling experience needs love. It is getting pretty good and there is a real healthy competition between Firefox, Chrome, Opera and to a lesser extent IE and Safari. Performance instrumentation for monitoring and especially post deployment crash reporting would be particularly nice.

Thank you Brian

I want to thank Brian for taking the time to provide us with the history of PhoneGap and his insights into mobile web. If you're interested in building mobile applications using your web development skills, be sure to check out Apache Cordova and Adobe PhoneGap.


Introduction to A/B & Multivariate Testing in Web Design

Advertise here with BSA

Anyone who is familiar with increasing website conversions has probably heard about A/B testing. It is a way for webmasters to display 2 variants of the same page out to their audience at random, and then gauge results based on user performance. A/B testing(or split testing) is very popular on sites where users are more interactive on the page. Think about projects like social networks, SaaS products, e-commerce shops, business portfolios, etc.

split testing ab dribbble shot philip clark

There is also a higher stage of this process called multivariate testing. Here you can include more than just 2 options which may range out to A/B/C/D+ testing. The concepts are all similar but you’ll need to run tests for longer in order to acquire accurate results. In this guide I want to introduce the idea of split testing and how webmasters or project directors can get started.

What to be Testing?

This is a common first question and it’s completely reasonable to ask. You want to think about areas on your webpage, newsletter, or other digital interface which could be improved for an easier user performance. Blog headlines, sidebar advertisements, main navigation links, anything which should be commonly accessed by users is fair game.

The goal is to see which of your 2 designs performs best in a general 50/50 split of your traffic. You want to determine the average percentage of users who click your headlines more frequently, or click on the quicker, or something like this. It’s all about “fixing” your website’s first impression to get users more interactive on the areas you want them to be interacting with.

Online Tools

I would recommend a list of tools, but many of them do charge money for a full account. SaaS products have become more relevant and it is often easier for webmasters to pay money to a 3rd party service and have them manage the backend.

If you want a free product then definitely try out Google Website Optimizer. Their old URL has gone down and the service is now combined into Google Analytics. But it is completely free to use and directly ties into your Analytics traffic results. This is the best way for a new tester to dive right into the process.

visual website optimizer vwo homepage layout screenshot

But when you know you want something more detailed, I would highly recommend Visual Website Optimizer. You can signup for a free plan which has some pretty relaxed limits. It does include a majority of the paid plan features – however you are limited to testing only 1,000 visitors per month. For high-traffic websites it’ll take a lot longer to obtain useful results. But on low-traffic websites this is a great way to start manipulating your interface and seeing how it affects conversion rates.

Newsletter Designs

Not every website needs to or should run a newsletter. But for larger communities it is the perfect way to keep people visiting over time. You can include new items for sale, free downloads, or recent blog posts. And it is a great way to check out the response from visitors onto your internal landing page(s).

A/B testing for newsletter designs is much more common than you might think. It is somewhat easier than testing a website, and it can be handled by many e-mail delivery services. Both Campaign Monitor and MailChimp offer split tests as a part of their system. You can build two distinct email layouts and have them divided into a rough 50/50 split out to your subscribers.

email newsletter ab testing split multivariate mailchimp diagram

Obviously your goal for testing here is the same as anywhere else. How can you redesign buttons, links, headers, and content to engage visitors into clicking through to your website? Once subscribers can flesh out your newsletter they will be more likely to actually read what it says. Maybe one of your links or headlines gets somebody curious and they go through your entire landing page.

Web copy is just as powerful as small design changes. Many case studies online talk about this minor difference which can have a tremendous impact on your conversion rates. Don’t try to assume minor updates are silly and will have no effect, because you may be surprised when you see the results!

Testing in Phases

I want to add that you can’t give up too easily on this stuff. Waiting around for 5,000 visitors may not be enough of an audience to completely gauge how you changes are working. Don’t be too steadfast to move onto your next idea without allowing enough time to pass.

The best way to manage your A/B testing is in phases of updates. Either look for small wins through single-element updates, or try updating a lot on the page and see which version of the layout works best. These two scenarios are both helpful and they can both be run using an A and B option. But what you are testing for will play a huge role in the process.

android ux ui testing mobile app screenshot dribbble

If you feel more comfortable doing minor changes between design iterations this is another solution. Just be sure that you leave time for enough visitors to check out the page and give you some helpful feedback. Writing down a full list of ideas can be a great start towards figuring out what you hope to test, and how these tests may improve the percentage of user interaction.

Related Websites

There are some really cool blogs online which discuss the ideas of A/B testing. Some include tips while others focus on case studies and real impactful results. Check out some of these links if you want to learn more.


There are plenty of similar online articles which delve into the A/B testing process. I would greatly recommend looking for case study articles in Google. These will provide context for what other webmasters have tested, and what the results were. It may actually save you time in the long run when brainstorming ideas that you should be checking out on your website. A/B split testing most likely isn’t needed for every website, but when understood properly it can provide value into any creative project.

Advertise here with BSA


October 22 2013


Using Dark Patterns for Good

It was so frustratingly difficult to find the “sign out” button on Gmail that my father finally gave up and left himself signed in forever. Independent UX consultant Harry Brignull found the iOS ad tracking so difficult to turn off that he described it as “hidden.” And just last month, author Paul Brooks called out the company Twifficiency for neglecting to tell users that they were spamming their followers just by signing up.

What do these all have in common? They’re dark patterns, an astonishing—but nonetheless surprising—way to learn more about good design.

This situation actually affected me, recently. One day I received one of those chain emails we all receive—you know the kind. This one was from Goldstar. Having realized this was a chain email, I scanned along the bottom in search of an unsubscribe link. Fortunately I found one, but after clicking the link I saw that the page it linked to asked me to sign in. “Sign in,” I thought, I never created an account in the first place! I provided my email address to buy a ticket, but I never entered a password. So I clicked “forgot my password” on the next screen and was soon informed that there was no account linked to my email address.

I was unable to unsubscribe.

From an analytics perspective, this is certainly a smart decision—Goldstar likely has a very low “unsubscribe” rate—but as a user it’s beyond frustrating. Today, Goldstar’s emails find their way to my Spam box. How could the company have leveraged the same brilliance it took to fool me to instead make me a loyal customer?

Dark patterns

To briefly recap, a dark pattern is any interaction that benefits a company at the direct expense of the user experience. UX designers and researchers Harry Brignull and Mark Miquel have even founded a Dark Patterns website, where they highlight companies doing things they shouldn’t be doing (or, at least, things their users would prefer they didn’t do). The site’s about page states, “[our] aim is to spread awareness about Dark Patterns, and to name and shame sites that use them.”

The dark patterns listed on Harry’s site range in severity. Some are mildly annoying, such as the MBNA credit card that confusingly asks users to confirm both that “Please DON’T contact me” and “Please DO contact me,” while others are downright unacceptable, such as Pixmania, which actually adds products to customer’s shopping carts without asking! refers to the interaction of pre-checking an item as a version of “Sneak Into Basket.” For example, on Pixelmania, an expensive extended warranty is pre-selected, which benefits the profiting company, but not the user, who likely didn’t intend to spend an additional £21,47.

A good history… corrupted

But as a content strategist, I try to keep in mind that words—or patterns, as the case may be—are neither good nor bad. Rather, they’re powerful or weak. Shouting “Fire!” is powerful, for example. When someone shouts “Fire!” in a crowded theatre, they might save lives or they might cause unnecessary panic. The power that comes from exclaiming the word “fire” can be used for good or evil.

Similarly, the concepts behind most dark patterns are powerful: most can be found in negative as well as positive user experiences. Microsoft Word offers a positive user experience, for example, by not only asking if the user wants to save changes, but also by highlighting “Save.” This is an interaction design pattern known as a smart default: for a busy user who hits the Enter key before reading the pop up, Microsoft’s thoughtfulness is the only thing stopping them from losing hours of work.

And Amazon uses the same interaction to allow users to enter a “default” credit card. When the user enters new credit card information, a popup appears asking “would you like to make this the default credit card?” “Yes” is highlighted. It doesn’t hurt the user if he accidentally makes this his default card …but it doesn’t necessarily help either. This means the same interaction that yielded a “positive” user experience in Microsoft Word creates a “neutral” user experience on Amazon.

Finally, the same interaction design pattern has its equivalent dark pattern. For example, most companies suggesting users to sign up for a newsletter are not doing it to help the user. In the newsletter sign up for a Boston-based rock gym, below, “Yes” is highlighted—as it was in Microsoft Word—but this streamlines the business’s goal, not the user’s.

What’s to be done?

As with most areas of life, the first step to “fixing” a problem is acknowledging you actually have one.

The Dark Patterns website has successfully shamed at least a few culprits into cleaning up their act. In December of 2010, after being “named and shamed” on, updated their unsubscribe process. also responded positively, updating copy to make their “share” option less likely to result in spam.

From a designer standpoint, however, the consensus is out. UX Strategist Gary Bunker, for example, sees all persuasion as a road to evil. He proposes a code of conduct that would stop all UX professionals from working on sites that used UX techniques to create dark patterns. Paul Brooks expressed similar sentiments last month, reminding companies that happy users become loyal customers, and that dark patterns aren’t the only way to be successful. On the flip side, Chris Nodder, author of the book Evil by Design, believes that morality depends on the designer’s intention. He says that “it’s ok to deceive people if it’s in their best interests,” and considers persuasive design a kind of “white lie,” as opposed to the evil intent of dark patterns.

Using our powers for good

I recently reviewed the copy for a client’s website that employed the “bait and switch” dark pattern. Where they advertised “free cars!” users found themselves facing fees. What was so powerful, though, was the word choice: By considering what they could actually offer for free, such as “free car advice!” I was able to maintain the power of offering something free without, importantly, lying to users.

In her UXPA 2013 presentation, Ahava Leibtag explained how content strategy is concerned with two issues: aligning our content with our business goals and helping users accomplish their own. Content Strategy and UX Design have this in common, and that’s the crux of the issue with dark patterns: dark patterns align content/interactions with business goals, without helping users accomplish their own. Therefore, the key to learning good UX from dark patterns is implementing them to advance the user’s goal. (Prerequisite: identify the user’s goal.)

My advice to interactions designers, then, is to consider employing a dark pattern in your next wireframe. Later, replace it with its equally powerful, positive counterpart. For example:

Ask twice

There are two reasons the “trick question” dark pattern works. As the MBNA credit card discovered, asking the same question twice means that users have to answer it twice, and leaving the answer preselected means users are more likely to leave one of the answers checked in the direction the company wants.

Make it user-centered: Asking the same question twice makes it twice as likely that users will do the “right” thing, whether that is saving their work, staying on the site, or creating a secure password. Use this tool wisely — there’s no reason to ask users twice if they want to change a text color, for example, but when it seems important to ask a question twice, make sure the question is phrased the same way both times (requesting the same response both times), and the preselected response is the one that benefits the user.

Hide unimportant information

Hidden costs is a frequently used dark pattern on airlines and cell phones. People pay $25 extra for insurance they didn’t realize they had selected, because they only pay attention to items highlighted in the user interface.

Make it user-centered: While cost is important, there is plenty of information on a site that is not, and only serves to distract. Take a page out of the dark patterns book and only highlight useful information.

Add to the shopping cart, helpfully

The “Sneak into Basket” dark pattern is reminiscent of a three-year-old on a shopping trip who helpfully adds candy bars, cereals and anything-else-within-reach to Mommy’s shopping cart. If Mommy doesn’t pay attention at the register, she’ll end up with far more than she planned on buying. But the three-year-old is legitimately trying to help.

Make it user-centered: Amazon already does a user-centered version of this. Instead of adding items to the cart, they advertise related items immediately after something has been added to the cart. Alternatively, if you are absolutely certain that every iPad purchased needs an iPad cover, make it obvious. Let users know how the auto-additions are helping them out, and give them the option to stop “helping” in the future. Most won’t opt out; the possibility of auto-additions adding something the shopper might have forgotten is too delectable to pass up.

Spamming, or sharing?

Friend spam is a highly controversial dark pattern, due to the feeling of invasiveness caused by an application messaging family and friends. What’s worse, friend spam acts like a virus, emailing, tweeting, or Facebook-status-updating without permission. The benefit for the company comes from the promotional (“viral”) value, but the icky feeling it causes users outweighs the benefits.

Make it user-centered: The problem with friend spam is that the application doesn’t ask for permission. The easy fix is one, preselected question: “Would you like to tell your friends and family about us?” Other options include the ability to customize a message to friends and family, or the ability to select which contacts should be added to the auto-email. Anything that provides choice is helpful in this situation.

Light the way

Dark patterns are successful precisely because they’re founded on good interaction design patterns. The best way to learn from them, then is to start with a dark pattern… and remove its darkness.

The post Using Dark Patterns for Good appeared first on UX Booth.

October 21 2013


October 18 2013


Interview With Bruce Lawson of Opera

There’s a perception that being in developer relations for a browser maker is all glamor and glitz involving lots of jet setting and rockstar-like experiences. So far I haven’t personally found that to be the case but in looking at the life of Opera evangelist Bruce Lawson, I think he may be fitting that description.

Helping fight the good fight for standards, Bruce is constantly on the move either updating his awesome book Introducing HTML5 (which is regarded as one of the best HTML5 books out) or attending developer conferences to read the pulse of the community.

With Opera’s recent shift to the Blink rendering engine, I managed to snag some of Bruce’s time to ask him how the shift will change the Opera browser.

Q Let’s start with the usual. Could you give us a quick intro about yourself?

I co-authored the first book on HTML5, "Introducing HTML5" (New Riders). I’m one of the founders of, and was a member of W3C's Mobile Web Best Practices Working Group. I evangelise open web standards for Opera, the oldest browser manufacturer whose mobile, desktop, TV and embedded browsers are used by 300 million people across the world.

Q In spite of traditionally having excellent standards and feature support, the Opera browser has struggled with desktop marketshare and ensuring developers properly test for it on their sites. Why should developers consider the Opera browser and what do you think will be the impetus for them to do so?

Developers should find that Opera behaves as Chrome does.

Well, it would be nice if it went without saying that web developers should develop for the web and not individual browsers, and these days all browsers have great standards support. However, one of the problems that we had is that developers didn't test on Opera properly – because many devs are in the USA, and our desktop browser has a high market share in countries outside the US. So we've recently changed the rendering engine inside Opera Desktop and Opera Mobile to the Blink rendering engine that Google Chrome uses (we're the first to ship Blink-based browsers). Developers should find that Opera behaves as Chrome does. Because of greater compatibility with mass-market sites, and a more visually appealing UI, and some unique features, we're aiming to grow the user base more in the USA and Western Europe.

Q With Opera’s move to base its browser off of Chromium, how will it distinguish itself in a fairly busy and crowded browser market?

We have some unique features in both desktop and Android. One is off-road mode, which saves bandwidth and makes sites render faster. Another is Discover, which is visually appealing, curated content which can be customised to show certain languages and categories. Then, on Desktop, there's Stash – a place where you can save web pages for viewing later with a visual snapshot of the site and its text saved in the browser for later full-text searching.

We've long been known for innovating in browser UI (tabbed browsing, Speed Dial etc) and by using Chromium, we're able to get our developers making new, innovative interfaces rather than solely focussing on making our own rendering engine

Q When Opera was based on the Presto rendering engine, it was considered as part of the W3C’s “two interoperable implementations” requirement for a spec to be considered for candidate recommendation status. Now that it’s based off of Chromium, how has that affected this?

When Opera Mobile and Desktop were based on Presto, there were four rendering engines on the market: Presto, WebKit, Gecko and Trident. Now there are four: WebKit, Gecko, Trident and Blink – and the same engineers who developed Presto are actively enhancing web standards support in Blink – enhancements that can be used by anyone.

Q Opera has traditionally been very strong in mobile. How does the move to Chromium improve Opera’s browser position on smartphones and what’s the impact on the non-smartphone market where Opera is the clear leader?

Moving to Chromium gives Opera Mobile greater compatibility with sites that were coded with only Android and iPhone in mind, so serves our customers better – but working with the Chromium team helps break the incorrect perception that "only WebKit matters".

Our Opera Mini product has traditionally been the market leader on feature phones, as it does the heavy lifting on our servers, so it allows people with very low-powered phones to use the Web. It's used on over 3000 different devices world-wide – many of which we've never heard of – and is often the only way that people can join the Web in some emerging economies. But it's not just a featurephone product: compression and speeding up rendering is just as important on smartphones. We've seen the share of Opera Mini smartphone users in Asia Pacific countries increase from 9% to 32% (see for monthly insight into worldwide mobile web use).

Q A lot of debate has been happening about HTML5 vs. Native apps. Is it practical to believe that HTML5-based web apps will match the UX of native apps, especially on mobile devices?

It's harder for developers to get paid when there isn't an installable product.

I think we need to understand why the web is great. Noone complained that a website didn't match the UI of the Linux box it was being viewed on, or the browser that displayed it. In fact, designers have always been adamant that they should be able to style native UI element such as form fields away from browser defaults. As JavaScript gets closer to native performance, and more and more integrated with device capabilities (File API, WebRTC, Pointer Events, etc) we'll see fewer and fewer reasons for developers to make native apps. The reasons to still make them aren't technological, it's social (apps are curated by App Stores) and economic. It's harder for developers to get paid when there isn't an installable product. I'm confident that we'll plug those gaps, but it will take time; there are many business interests here.

Also, browsers can help make HTML5 sites feel more app-like. Watch Opera for an interesting product that does just this.

Q You’re a leader in the HTML5 world publishing, along with Remy Sharp, one of the best HTML5 references out. Tell us what you think about the current state of HTML5 and related features.

I think the web stack is in pretty good shape these days. There’s work to be done making sure that sites can work offline (Appcache-done-right, in whatever guise it comes back) and with web payments. The lack of any useful way for developers to deal with responsive images is a problem, 18 months after it was flagged up.

My biggest worry isn’t the pace of standards development so much as lack of browser choice. Paradoxically, we have the most powerful and interoperable browsers that we’ve ever had, yet many platforms don’t allow the users to choose their browser.

Q I think there’s a lot of confusion about the role of the WHATWG and how it pertains to HTML5 and the W3C. Where do you see the intersection between the work that the WHATWG does versus what the W3C manages and provides?

Confusion is the word, indeed. I like the fact that the WHATWG keeps a living standard, that’s always up-to-date. But it means that lots of the stuff in there is really experimental, and not implemented anywhere (or even ready to be implemented, in some cases). It’s also really useful to have just one spec containing all the things.

However, it’s a shame that there are discrepancies between W3C and WHATWG specs. For example, the main element is really well specified in W3C spec, but badly specced in WHATWG. I’d advise developers looking to see what they can use now to look at the W3C version.

Q Last question. What’s up with the naughty bunny at the bottom of your blog?

It’s a mash-up of memes from 2003, when I first (and last) redesigned my blog. It’s a combo of oolong the rabbit that balanced things on its head ( and goatse, which isn’t a goat. Look it up. Or rather, don’t.

In Conclusion

We’d like to give a big thank you to Bruce for taking part in this interview.

Editor’s Note: Bruce mentioned during the interview that a new, interesting product would be released by Opera. Between the time the interview was conducted and published, Opera released Coast by Opera for iPad, that make HTML5 sites feel more app-like. Be sure to check it out.

October 16 2013


The Learning Conundrum

When I started working in information technology professionally in 1989, things were pretty easy in terms of choosing a direction to head into. At least in my area (South Florida), you went into one of the following areas:

  • Network and systems management
  • Database administration
  • Software development
  • Project management-related tasks (including QA work)

ColdFusion was my technology of choice and it too lasted me nearly ten years.

I took the software development route and for a very long time, it was easy to choose a programming language that you could base your career on. In my case, I started with Clipper (a dBase-based compiler) and eventually branched into client-server development using PowerBuilder, the latter being my goto tool for almost five years.

And even when I got into web development, tools and technologies were still easy to choose, primarily because the web was still so young and simple post-back, server-side page refresh style development. ColdFusion was my technology of choice and it too lasted me nearly ten years. And most recently, jQuery and JavaScript have been my focus since 2008.

There's a reason I'm telling you all of this.

The Hamster Wheel

I've been very fortunate to have chosen technologies that have had great longevity but of recent, I've noticed a dramatic change in the industry. The maturation of web development has led to an explosion of new tools that aim to help manage the complex process of building today's sophisticated websites and apps. This is actually a very good thing since for a long time, web development was like the wild west. The formalization of patterns, processes and best practices is certainly a positive thing and will invariably help to build substantially more stable systems.

And a lot of this explosion has been driven by the ease of access to sophisticated programming languages and tools, many offered for free via the open source community. This has enabled developers to rethink the way things should be built and empowered them to build amazing tooling.

This empowerment, though, can be a double-edged sword for the developer community as it feels like we're on a hamster wheel with no brakes that allow us to stop and take things in. It's a bit of a perpetual learning cycle where in many cases, not staying on top of the latest development trends can put you incredibly behind in terms of current development practices. I know I've felt it more than once and in talking with my peers, it seems to be a pervasive feeling.

The Evolution of Learning

I think it's fair to say that software developers have one of the most complex jobs in the world.

You'll hear constantly from others that our field is one of constant learning and that is so true. Developers are rockstars nowadays and it's because we work on cutting edge stuff that makes a tangible impact on large communities of people. And those communities are demanding more information via easier user experiences across multiple form factors. I think it's fair to say that software developers have one of the most complex jobs in the world. So constantly learning isn't a choice anymore; it's a requirement.

Which is why I was mentioning my career path to-date. I think it mimics that of a lot of my peers, where we could comfortably depend on knowing some "thing" for "x" number of years before we had to begin to retrain ourselves. If you're in the web development world, that's no longer the case and in my opinion, a career limiting move. I'm not saying that you need to go off and learn every new library that comes out. Honestly, I think many of the libs and tools being pushed out:

  • Are meant to scratch a very specific itch
  • Replicate an existing tool and offers little additional value
  • Are meant to satisfy someone's ego in a "look at what I built" type of thing

But there is a clear rationale for staying on top of emerging technologies especially when you see your peers chatting about them. And to be clear, I don't define peers narrowly as those I work with. I look closely at people on Twitter, Facebook, Google+, blogs and forums to gauge where their thinking is at. If you're not doing the same, you're doing yourself and your career a disservice.

As you get older (yes I'm touching on age), for most, "time" becomes the biggest limiting factor to staying current. I can attest to this as at age 45 with a ton of family commitments, I have to be extremely regimented in order to dedicate the necessary learning "time" while ensuring I dedicate "time" to my family (which is my number one priority). And I'm confident I'm not alone in this conundrum. I think back to when I was in my 20s and used to write for print magazines (you guys remember those right?) and my colleagues would ask, "How do you have time to do that?". Well, it has come full circle and I find myself asking my 20-something developer friends the same thing.

The thing I've learned is that I can't compare myself to a 20-something because our priorities in most cases are different. A young buck will invariably have more time to focus on the newest stuff allowing him or her to tinker away and even build that next great tool. And that is awesome and I remember those days myself!

As you progress in your career though, it's important not to be lulled into complacency and develop a plan that will allow you to stay up-to-date by being selective of not only the technologies you choose but also the goals you plan on achieving.

Choices, Choices, Choices

As you look at the technologies that are currently available, it's easy to become overwhelmed at where to start, much less what to choose. I empathize with you and you are certainly not alone. Part of the problem is that as developers, we're naturally curious about new technology. I like to call it the "moth to a flame" syndrome:

  • Oh look, there's a new lib to mimic web components! (flutter, flutter, flutter)
  • This influencer just released this new preprocessor! (flutter, flutter, flutter)
  • Oh my god, here's the 4th SaaS that offers real-time backend services! (flutter, flutter, flutter)

The list could go on and on. What I'm trying to get at is that at times, we suffer from attention deficit and try to rationalize it by thinking it will immediately solve a non-existent or future problem for us. In essence, we're technology hoarders doing a "just in case". In reality, it's important to sit back and determine what you're trying to accomplish and how the current suite of tools solve your problems based on where you want to head to.

Part of the problem is that as developers, we’re naturally curious about new technology.

For example, I've heard so many developers say that they want to learn iOS only to find that they have no real plans for building an iOS app. If you have the time to do that for fun, more power to you but if you don't, that's time that should be spent learning things that are actually important.

For example, if you're a front-end web developer and that's what you plan on being for some time, I'm of the thinking that ensuring you're up-to-speed on things such as AMD, ES6, Sass and Yeoman is far more important than diving into IPTables, ActiveRecord, WebView or Amazon EC2. Before everyone loses their minds because of what I just said, let's be clear, if you can manage to learn all of these things (for example, a full-stack developer), more power to you because it will make you more valuable.

What I'm trying to convey is that instead of allowing yourself to become overwhelmed with the thought of learning "the full stack", narrow down the scope into easier to manage goals. Determine where your career focus is, pinpoint a handful of key technologies you should be up-to-speed on, and focus on those in order for you to stay relevant within your career focus.

The front-end developer tract, for example, is involved enough and staying current will keep you busy for a long time. Lou Lazaris wrote a post back in 2011 titled "Skills for Front-end Developers" and in many cases he's spot on. If you look at his list, he's specifically targeted front-end technologies that are important to that role. It reinforces my thinking that it's better to narrow down the scope of what you're learning into manageable chunks within the role you're in. But it's also important to filter down lists like these even further. Do I think that CoffeeScript is critical to my success as a front-end dev? Absolutely not, which is why I've purposely not dedicated time to it.

Again, I'm not advocating not learning as much as you can. Despite me clearly being on the front-end side of things, I'm currently working on learning Ruby and Rails because I'd like to learn a new server-side stack to round out my skills. For me, it means sacrificing learning how to use something like Yeoman but I've taken the time to determine the value proposition of going down this route and I think it's worthwhile for me.

Learn Something

Learning comes in different styles. I learn best by:

  • Reading a book (a real one with actual paper pages)
  • Typing in code examples and seeing results
  • Having a mentor I can ask questions from

Others prefer to simply dive into something and learn by the school of hard knocks. Whichever way you learn, having good resources available is a critical part of the equation.

More and more, I've been leaning towards online courses because they've matured to a point where in many cases they're comparable in quality to their onsite brethren. They also afford the flexibility of allowing you to do things on your own schedule (almost always) and to focus on the technologies that are important to you.

In my case, I recently signed up for One Month Rails which offered me the following:

  • Flexibility: I participate on my schedule without the pressure of having to sacrifice enormous amounts of my personal time
  • Affordability: It's $49 $99 and seems to be well-structured for the price.
  • Mentorship: I can contact the course creator directly and have the support of their community

Regardless of what learning options are available, if you don't set aside some dedicated learning time, it's all irrelevant.

I see this as a jumpstart opportunity that will be complemented by sites like Nettuts+ and Tuts+ Premium as well as books and my community contacts. But ultimately, the flexibility and pace of the course is what I feel will allow me to learn something new in a timely manner. Cost is certainly a factor which you need to weigh versus the anticipated learning benefit and resulting updated skill.

The fact that there are so many online learning options available (many of them free) makes it substantially easier to keep your skill-set current, especially if you're methodical about what you want to learn (for example, don't be a moth).

But you need to carve out the time to learn. Regardless of what learning options are available, if you don't set aside some dedicated learning time, it's all irrelevant. I've personally found that spending one to two hours, two to three times a week immediately after work seems to work well because my mind is still in developer mode. I recently chatted with a friend who finds it better to wake up very early (6am) and focus on learning during the first few hours of the morning before starting work. That way, he's fresh and focused, free of distractions or concerns about his job.

My good friend and badass developer Joe McCann offered this great feedback:

The one bit of knowledge I'll add is that the number one thing I learned studying philosophy in college was not what I was learning, but how I in fact learn things. Truly understanding how one learns, understands, etc. is key to learning a new skill or enhancing current ones.

If someone learns by reading a book or writing down notecards or hearing it via lectures, all of these are available to use now online. It's a matter of understanding how you learn and then going and seeking the proper medium to do so.

Well said.

Learning Resources

It goes without saying that I think Nettuts+ and the various Envato properties offer some of the best online learning options around. In addition, here are a couple of learning sites I've used and recommend:

  • Codeacademy: Learn JS, Ruby, Python and more via their interactive site
  • Ember 101: Ryan Florence did a bangup job creating screencasts that walk you through the process of learning Ember
  • Why's Poignant Guide to Ruby: The style takes some getting used to but it’s definitely a great resource for learning Ruby
  • Focused almost exclusively on AngularJS and recommended by a lot of community members
  • The Ruby on Rails Tutorial: This is the goto tutorial for anyone just starting off with Rails development

If you want something a little more structured and hardcore, a new trend are onsite bootcamps where you will invest a considerable amount of time learning how to use the newest technologies. Just note that many of these require you to move to where the bootcamp is being held and commit full-time to it for a number of weeks. Also, these courses are pricey running into the thousands of dollars in exchange for the more personal learning experience. I've personally participated in the bootcamp but didn't require moving. While I wasn't able to finish it due to time constraints, I would recommend it. Here are some of the bootcamps that have received a lot of positive press:

  • Well structured course that will run you through up-to-date technolgies and provide you with online mentorship via email, chat or voice. Doesn't require you to move.
  • Hacker School: Based in New York, it's a three month onsite bootcamp where you'll work full-time learning programming skills in Ruby and Python
  • The Starter League: Onsite in Chicago, IL and partnered with 37signals (makers of Basecamp) to enhance their learning experience.

The site BootCamper has been aggregating a list of the various bootcamps that are available and providing information about them in a searchable fashion.

Get Unstuck

The main thing is to keep learning and do it at a manageable pace and in a thoughtful manner.

I've been wanting to write something like this for awhile. It's a bit self-serving since it helped me jot down feelings I've had about being overwhelmed with the hamster wheel of learning. Over time, I've been looking at ways to ensure I'm staying on top of things while not burning myself out and I've come to realize that it's impossible to stay on top of everything, even in my own niche. There's just too many devs building too many cools things and not enough "time".

So I've resolved to focus on things that are timely and relevant but may not be bleeding edge and the newest cool toy. I find this to be a much more manageable way of learning for me. And I also think it's important to revisit the tried and true stuff that may not be the latest model car but may have some great surprises for you under the hood. I look back to Jeff Atwood's great post "Why Ruby?" where he discusses his choice for using Ruby to build Discourse and specifically touches on Ruby's maturity and lack of coolness.

The main thing is to keep learning and to do it at a manageable pace and in a thoughtful manner. Really give thought to where you're heading in your career, outline the key things you should be good at within that scope and work towards developing a plan to tackle staying current. There are plenty of flames out there and you don't need to flap your wings to every one of them.

I'd love to learn more from you guys how you stay up-to-date so please be sure to offer your suggestions in the comments.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
Get rid of the ads (sfw)

Don't be the product, buy the product!