Prototyping and Design Patterns for the web

Screenshot 2013-12-07 11.54.43

I recently stumbled across Brad Frost’s thorough and thoughtful analysis of the TechCrunch redesign process. I don’t intend to rehash all of its points, but rather look at a tool used in the process, Pattern Lab. I honestly haven’t been this excited about the potential of a set of tools in a long time. It’s because I feel that Pattern Lab and other tools like it represent the future of of user experience design on the web.

Why is this? A significant number of User Experience Designers use wireframes to communicate their ideas to clients, stakeholders, and developers. The difficulty with wireframes is that although a picture is word a thousand words an experience (read prototype) is able to be understood with little to no words because actually doing a task transcends a picture of a task. The faster the time to take an idea and turn it into something that’s usable results in faster feedback and more rapid iteration. Problems aren’t solved after delivery, but instead can be dealt with early in the process before their potential damage is amplified.

How does Pattern Lab make this possible? Three ways:

1. By Supplying Standard Patterns as well as offering designers ample opportunity to add their own solves a common issue in the UI/UX community. Pattern libraries seem to have a half-life of about one year. I’m amazed at how quickly pattern libraries are assembled and then slowly decay. I empathize with the maintainers of the libraries because I know that with limited resources and the constant rate of change it’s tough to keep them constantly updated.

2. Easy to edit code – The HTML/CSS/JS in Pattern-Lab starts you off with an excellent kit to begin learning. This is all insisted by the use of Mustache as a templating engine which helps take the heavy lifting out of HTML prototyping by providing a simple structure so that you can stay DRY.

3. Using JSON – Thinking about data early in the process provides yet another opportunity to discover problems early on. Additionally, it provides an avenue for frontend developers to meet their backend counterparts somewhere halfway.

You can find Pattern-Lab at What do you think? Do you think that tools like Pattern-Lab are the future of UI/UX Design?

My Fitbit Flex Review

I’ve been recording running workouts for over four years with a Garmin watch tracking heart rate, distance, speed, pace, elevation gain, et cetera. However, I couldn’t track indoor workouts because of the GPS and I wanted something that would also track those activities in between i.e. walking to the farmer’s market or around the neighborhood. So I started researching wearable tech wrist bands a few months ago and finally settled on the Fitbit Flex. I really wanted something that could track sleep as well as workouts so the Fitbit Flex seemed like the perfect choice.

How it Works

The Flex is very easy to use. Charge up the Flex, throw it in the wristband and get going. To download those results either use the Fitbit dongle for your computer or the iPhone app. During the day if you’d like to see how you’re doing you simply have to tap the Flex twice and your progress towards your step goal will display. From a User Experience perspective the lights that blink when you tap on the Flex provides immediate fulfillment and is very addictive. Throughout the day I find myself tapping on the Flex to see how I’m doing on steps. When you hit your step goal the bracelet does a little celebration dance by lighting up and buzzing. At first this was kind of fulfilling, but it cracks me up when I’m waving goodbye to someone and the Fitbit declares victory. Battery life is pretty good, but if you get into the habit of wearing the Fitbit every day it can be easy to forget to charge it up. Luckily it recharges very quickly.

The Good, The Bad, and The Ugly

The Flex has served as a reminder on days that I’m not as active as I should be and has helped me become more active on those days. Looking at the data for my time owning the Flex there’s a definite trend of being more active, but I can’t say that the Fitbit Flex suddenly motivated me to become an active person. When I bought the Flex I was already ramping up training for a half marathon and had a 75 mile backpacking trip scheduled. I’ll have to see what happens after I finish my half marathon and if my workout trend continues. I really like the alarm clock feature of the Fitbit Flex and it’s been a huge help in helping me wake up even earlier. My body has now adjusted to the Fitbit alarm automatically and I start to wake up before it goes off.

I only have a couple of gripes with the Fitbit Flex and nothing too major. According to FitBit, I really don’t sleep. I’ve always been someone who moves around a lot at night, but those time periods are taken as me being awake and active. I’m averaging four hours a night of sleep according to FitBit. Turning Sleep Mode Off/On can be a huge pain. Sometimes it turns right on after 5-6 quick taps. Other times it just doesn’t happen without a lot of frustration. I’ve also gotten so frustrated with sleep mode that I’m avoiding it more often than not.

Although the Fitbit Flex is waterproof I would recommend taking it off when showering. The Flex band will fill up with water and stay like that most of the day. It’s not a non-starter, but it was annoying enough to make me take it off when I shower. Tracking non-running workouts is still interesting and not very accurate. I do a lot of running so the Fitbit works out perfectly for me but I can say that doing fast reps while lifting makes the Fitbit think I’m an Olympic sprinter.


Overall I would say buy one if you want to do a better job of tracking your fitness. I just ordered a Fitbit for my wife and am even buying different colored wristbands for accessorizing. I do think that wearable tech is the future of health and fitness and the fact that I’m matching my wearable’s tech style to my own is pretty fascinating.

The TLDR; I really like the device.

Building Better Select Boxes

Last week I found myself looking for a select box that provided a search option. I was trying to find a way to make it easy for a user to find and select an item quickly and autofill/autosuggest was out as an option because of other issues. Sometimes as a UX Designer building wireframes it can be difficult to explain exactly how functionality will work without an example. I decided to find a few good examples of this functionality and also write a demo to try it out myself. The best options that I found were:

Select2 – Demo & Source

Chosen – Demo & Source 

I then put together a little example here –

Thoughts on How to Learn JavaScript properly.

I’ve tried following JavaScript tutorials before, but I usually found them too focused on lectures or too heavy on practical exercises with little information on the why’s and how’s. I could never seem to find a good balance in any tutorial I worked with. But about a month and a half ago I stumbled onto a post on entitled “How to Learn JavaScript Properly”. I decided to do as suggested in the tutorial and follow the steps exactly as they’re outlined. It was only about a week and a half ago that I purchased the second book, but my impression so far has been really positive. I’ve learned more in the past two weeks about JavaScript then I have in the previous two years combined. It’s coming down to 3 main points: following directions, taking the time, and having persistence.

Follow the Directions

The tutorial suggests, correctly, that you shouldn’t be taking bits and pieces from various courses to try to learn JavaScript. I think the worst thing that I’ve done in the past is to try and learn through different tutorials each with their own way of teaching JS. The outcome of learning through various sources means you’ll probably be spinning your wheels for awhile. I think the use of Codecademy for exercises is also a big help because if you get stuck there are plenty of people to help get you back on track.

The Reading is Dense

The tutorial recommends two books to use to augment the exercises you’ll be working through on Codecademy. The books are sometimes more difficult to work through than the JS lessons themselves. Working through Nicholas Zakas’ “Professional JavaScript for Web Developers” is intense and I often find myself reading and rereading sections to make sure I’m getting it. David Flanagan’s “JavaScript: The Definitive Guide is a lot more accessible, but if you’re not used to reading technical books you’ll just have to take it a little slower. I’ve also found it really helpful to learn the background of JavaScript as a language as it helps put things in perspective. What really makes lessons stick, however, is actually using the recommended Codecademy exercises to drive the points home. For some of the reading I wish there was a way to have some more specific exercises , but so far so good.

Set aside the time and do it 

The tutorial recommends to be finished with the readings and lessons within 6 weeks, but no more than 8. In my past experiences trying to learn I’ve found myself taking breaks and then coming back which forces me to relearn a lot of information. Relearning what you lost feels like a huge waste of time and after several times of doing that it feels like I’m getting good at the basics, but not at anything that’s actually functional or useful. I’m diving in head first this time and it’s working out really well. By dedicating a few hours every night and on the weekends I find myself further along with learning JS than I’ve ever been. My goal over the next two weeks is to finish the Weeks 3 & 4 section and move into Weeks 5 & 6. I’d also like to try my hand at building a basic Backbone.js app as well a simple Node.js app.

A couple notes –

1. I ran into some problems initially and couldn’t figure out why the reading was so different than the exercises. Down in the comments I found out that I had started out on the wrong track at Codecademy initially. You should be following the original Codecademy Javascript track.
2. Work through the exercises on your own. I make sure that I don’t jump right into the forum to find the code that will pass. I spend a considerable amount of time trying to debug the code myself before taking a look at the forum. It’s easy to copy and paste the answer, but you won’t learn anything.


Learning to Code and Learning an Instrument

Hands on Piano

When I was little I learned how to play the piano. I had reading music, proper hand positioning, and playing Minuets drilled into my little skull. My piano teacher was a former funeral home director and a jazz musician. He had all the seriousness of a man who dealt with the bereaved, but the musical chops of Little Richard. My piano lessons were an exercise in perfection and rigidity and there was no room for individual thought. Sometimes I would decide that Beethoven, Mozart, or Grieg had it wrong and would exercise my freedom of expression to make it sound “better”; my piano teacher hated that. I was more interested in writing my own songs than I was in playing Beethoven’s or Bach’s. Eventually I stopped taking piano lessons and switched to drums and finally guitar. Lately I’ve been thinking a lot about the similarities between learning to play piano (or any instrument) and learning to code. I think both involve similar approaches in regards to lessons, techniques, and skills.

Here’s why:

1. An entirely new vocabulary and way of thinking is introduced.
2. Muscle memory.
3. Combining simple elements to create complexity.
4. Persistence

New Vocabulary

Learning to read music teaches you how to think outside of your comfort zone. You’ve got time signatures, keys, notes, marks to denote staccato or a phrase that is largo. What’s that you say? Why the Italian? The language of music is Italian so you also have to know what it all means. The first year or two of music lessons includes learning to decipher this new language. Once you’ve figured it out, however, it opens up a new world. You can sit down with sheet music and it gives you an instruction pamphlet for how to play. Coding has its own unique language as well. A language that is filled with “a-ha” moments when something suddenly hits you for the first time. It’s just like music in that everything is descriptive in regards to what it does and why, but you still have to learn and translate the basic vocabulary.

Muscle Memory

My first piano lessons involved drilling proper hand positioning. I practiced until my hands ached and then one day, they stopped hurting. What’s most amazing to me is that two decades after I took my last piano lesson I can still sit down and my hands know exactly where to go and how to rest. The muscle memory is even there to play scales in almost every key. I don’t know how I know how to do it, but somehow I do. I’ve begun to notice something similar as I continue to learn how to code. My fingers just know what to type and where to go. It’s as if muscle memory is taking over and I’m using less brain power to process the basics.  

Combining the Simple to Create the Complex

In it’s simplest form music is just notes. Add a few notes together and you have a chord. Play a few chords together and you can create a song. It’s all about putting together the basic building blocks one note at a time. Coding is the exact same way. When I first started playing piano it was extremely frustrating because the process seemed to move so slow and I really wanted to just play a certain song. My piano teacher would hold me back while unbeknownst to me he was leading me down that path so that when he said, “ok, learn this song” I already had the skills to put it all together. I feel the same way about learning to code. I really want to build an application or do this specific thing. What I’ve learned is that if I take my time and understand the individual components behind the song or the program its help me build even better songs/programs. I’ve certainly hacked my way around building a basic Ruby on Rails app and after a few hours got it “functional”, but going through and learning the proper way to do it opens up the inner workings and makes fixing issues easier and faster.


Learning to play any instrument takes persistence. Playing guitar makes your hands just plain hurt. You have to stretch, bend, and hold down strings to try to get the right chord. After you’ve got that one chord you have to learn a bunch more and then figure out how to transition them. It’s easy to give up and I know a lot of people with guitars who have never been able to push past that first painful month (it honestly only takes one month to push past that phase). I have had a lot of banging my head against the wall with coding. I can’t even begin count the number of times an errant semi-colon, colon, “end”, bracket, et cetera stumped me and I had to sit and review lines and lines of code to track it down. It’s all worth it though when it ties together and works just as you wanted. The thing that makes the persistence pay off is that you can see actual measurable progress appear right in front of you.

In Conclusion

When I learned piano everything was broken into elements so that you learned one piece at a time. First hand positioning, then sheet music, then basic melodies, then chords. Slowly as you worked through these individual elements they could be combined to create bigger blocks. All of this crescendoed into the moment when sheet music was placed in front of you and you could play a song you had never seen and didn’t think you could play.

I keep having these moments as I push forward coding where I look at the screen and say, “how did I know how to do that?”. The answer is pretty obvious after I add up all the time spent grinding away at it, but there’s still that sense of wonder when I create something out of thin air that I hope I never lose.

Starting with HTML

I wrote this blog post last June after spending some serious time studying and teaching myself HTML.  Hopefully this information will help someone out on their journey to learn frontend development!

The hardest part of learning how to code is getting started. The second hardest part? Knowing where to start. I decided to begin by jumping into HTML which has a ton of free resources available on the web. Why HTML? Since it’s not really a programming language I thought I could begin to make myself comfortable looking at code and understanding basic web development. I found the following websites to help me beging to understand HTML.

1.W3 Schools HTML Tutorial. Nothing to download, no text editor needed just dive in and start playing around. This was my first real taste of learning HTML.

2. nettuts+ web development from scratch. This begins to get a little deeper into the world of web development. Helping you pick out a text editor.

3. Udemy – Learn HTML in 24 hours. I don’t know why, but this is where it finally clicked. Something about the presentation or the videos finally had me understanding basic HTML.

I recommend taking a look at the three courses above and try to start wrapping your brain around looking at code. I think it’s easy for people who already know how to code to offer what they think is sage advice on how or where to start. For someone who doesn’t know how to code all of it seems like some strange magical process. I imagine a gigantic monitor somewhere with a green cursor blinking waiting for a command. Developers are like sorcerers in my book.

My Remote Work Tools

I saw a post by the Active Explorer about remote office tools that help set her free and I thought I’d do the same, that is list the tools that help allow me to do my job nearly anywhere.

15′ MacBook Pro – This is my old standby. I’ve got it loaded up with 16gb of RAM to make sure that my VM’s can run with what they need. Specifically the VM that gets the most use is my Windows 7 instance with Visual Studio running. However, if need be I can make do with just an iPad and bluetooth keyboard.

Internet – This is almost a no-brainer, but I can tell you depending on what I’ve got on my plate it can be a disadvantage as well.

Tunnelblick – For various reasons I need access to our company VPN. It’s also handy when traveling and dealing with random internet restrictions.

DropBox – I use DropBox to help keep everyone on my team synced up and it works pretty darn well. I think everyone can attest to this.

Evernote or Apple’s Notes – I use both of these back and forth pretty regularly. I use Evernote for To-Do lists and random thoughts and I use Apple’s Notes for writing blog posts.

Thanks to the Active Explorer again for the inspiration. Here’s the original article as well “Remote Office Tools that Set Me Free“.

Using my iPad as my main computer

Traveling with the iPad as my main computer.

I decided to give my ipad and a keyboard a test drive for a weekend before using it full time for 2 1/2 weeks whole in Europe. The goal being to stay lightweight and not carry around the 15′ MacBook Pro through airport, train, and bus stations. I brought along my iPad and a bluetooth keyboard to conduct my tests.

Here were the initial pros and cons;

Pros –

1. The iPad forces you to monotask. This is huge. You do one thing and one thing only.
2. Lightweight, keyboard has tight integration with certain products. Works well with Skype and of course Apple products.

Cons –

1. Skype still requires a lot of touching. My team primarily uses Skype so this is a little bit of a challenge, but it’s a straight first world problem. [EDIT] It appears that this problem was fixed after my initial testing.
2.  Jumping back and forth between the bluetooth keyboard. It can be a little hard moving between a Bluetooth keyboard and the touch screen. This is remedied by using the built in keyboard instead.

I’m on Wifi, not 3G and i’m traveling internationally so it means that I’ve got to find wifi to have any hope of staying in touch with my team at all, but the no data thing has actually turned out to be a boon, however, as it’s forced me to do things like just read and relax that because I’m normally so connected I forget to do. Which admittedly, is my fault.

These were my initial impressions using an iPad as my main computer for a few days. I’ll post the results of a few weeks using only the iPad tomorrow.

Believe in yourself

I have a very simple New Year’s resolution.

Believe in myself. 

Since I started writing here I found that I am my own biggest critic. It means that I have dozens of articles ready to go that I’ve never published. When I get ready to publish I say no, it’s not good enough and I tweak it until I convince myself it’s total garbage. The problem is that I don’t believe in myself and as such I am my own worst enemy.

So why can’t I hit publish?

I’m worried about what you, the reader, will think of what I’ve written. I’m scared you’ll think it’s crap or even worse think that I’m crap. I think this is the biggest problem with creating. When you’re putting yourself out there, your opinions, your words, your writing, it’s easy to take criticisms as personal.

It’s almost comical at times that I can’t hit publish on my own blog considering I’m a Project Manager who’s obsessed with shipping early/often. I can rectify this by knowing that I have a team that I work with and I stand by my product decisions, but it’s funny that I can’t stand by my own writing decisions. When I write for work it’s easy for me because I have a deadline and I feel like an expert in the subject matter.

So how will I hit publish in the future?

Pretty simple. When I’m done with writing I’m just going to hit the button and let it go. I’m not going to obsess over finding the perfect picture, a bitly link, et cetera. But moreover, it’s important to me that believing in myself extends beyond hitting publish on a blog and allows me to take the next step whatever may come.

So why the hesitation?

There’s none. I’m hitting publish. Will you do the same this year?

Updating Ruby on OSX Mountain Lion

This past weekend I tried to pick up where I left off with the Ruby on Rails Tutorial by Michael Hartl. I had last worked on the tutorial at the end of May. When I tried to pick up where I left off I found that none of my routes would work. Literally I couldn’t route to anything with “foo_path”. Since the tutorial had ended I had updated my OS to Mountain Lion and installed the newest version of Xcode, but hadn’t done any real Ruby on Rails work. Trying to run the app immediately ran me into problems.

I had been working with Rails 3.2.3 so I had additionally updated to 3.2.8. I updated my Gemfile and did a bundle install and Nokogiri started going nuts –

WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.7.8.

Thinking that the problem might be related I tried to fix Nokogiri’s issue I tried to start by fixing that. I found that other people were having the same issue; once, twice, three times!

To fix the Nokogiri issue I downloaded and installed Xcode Command Line tools and installed them. Uninstalled and then recompiled Ruby. All of that seemed to make Nokogiri happy. My routing was still broken. So I tried updating my gems again, still no luck at all with fixing the routing, however, a new error had appeared. I was getting an error with the gem “Addressable”. I knew I was at least getting closer. After this I decided to completely restart the Sample_App tutorial and create a brand new gemset. Magically, that seemed to fix all of the dependency issues and solved my problems with routing.