Recent Posts

Designers should know just enough code

A List Apart recently linked to an article by Joshua Seiden titled, “Designers shouldn’t code” is the wrong answer to the right question. Joshua’s article is actually a response to Wayne Greenwood’s article, Unicorn, Shmunicorn—Be a Pegasus.

Both authors discuss important topics like different methods of approaching problems, which details to focus on & job security, so I urge you to read them. But to be completely honest (and hopefully not belittling), I think we’re over thinking this.

Designers should know just enough code so that they understand the technical constraints of a project and are able to reduce any potential issues during the execution phase.

What is meant by “code”

Joshua does a great job covering this in his article mentioned above:

Second, “code” is such a broad term as to be essentially meaningless. What do we mean when we say this? Do we mean back-end programmers writing APIs in C#? Do we mean full-stack developers writing web applications in Rails? Do we mean front-end developers working in HTML+CSS+Javascript?

In this case we’re definitely talking about front-end code, as Joshua goes on to say. I can’t think of any valid reason a designer should have to worry things about frameworks, database adapters, frameworks, etc.

Be a t-shaped designer

What does it mean to be a t-shaped person? Basically, it’s someone who excels in one area, while still being generally knowledgeable in other related areas.

Some things you should know as a t-shaped designer:

  • Basic HTML & CSS (Box model, floats, positioning, page flow)
  • Interaction (What happens when this is clicked? How will this adapt to a phone or tablet?)
  • Performance (How will 4 web fonts affect page load time? Will this require any 3rd party scripts?)
  • Accessibility (Is there enough contrast? Is this typeface legible at this size?)

Having a general understanding in the areas listed above doesn’t mean you need to become an expert in them. I can also guarantee you that you won’t have to design in the browser, understand Sass mixins or know the difference between a rebase or merge in Git. Heck, most of the time you probably won’t even have to write code.

(But if you do end up writing code, it doesn’t need to be great either. It should hold the same value as a sketch on a whiteboard or piece of paper does.)

Going forward

Developers don’t want designers to start writing production-ready code, the same way designers don’t want developers to create interfaces. There will always be a need for a dedicated designer and no one is trying to diminish your role on the team.

Things move quickly in the web industry and that means constantly learning new things and stepping up our game. Don’t look at these extra responsibilities as burdens, instead see them as a new challenge.

Setting up a Ruby on Rails environment

Ruby on Rails is a great framework with lots to offer, but to those unfamiliar with either Ruby or Rails, it can be a bit intimidating to get a development environment set up.

Note: I’ll only be covering installation for Mac OS X (specifically Lion) because that’s what I’m using. Windows users should have a look at RailsInstaller and Linux users probably don’t need help anyways.

Custom FTW

There are lots of ways to set up a Rails environment, but I’m only going to cover my preferred configuration, which is using rbenv and ruby-build.

A few reasons why we’re not going to bother with the default Mac OS X version of Ruby:

  • it’s already out of date
  • it doesn’t support multiple versions
  • it can easily break after OS upgrades

We’re also not going to bother with RVM, but I won’t go into the reasons why. If you’re curious, just read the rbenv/rvm comparison on the rbenv Github page. (Nothing against RVM, I just prefer rbenv/ruby-build)

rbenv: Simple Ruby version management

That title doesn’t lie - installing rbenv is pretty simple, but you will need to have Git on your system. If you don’t have it yet, you can download and install the Mac package from the official website.

First things first, open up and type the following commands (without the dollar sign - that’s used to represent your shell prompt):

$ cd
$ git clone git:// .rbenv

If you’re unfamiliar with shell commands, all we did was change into our home directory (/Users/yourusername) and cloned a Git repository into a new directory called .rbenv (in OS X any files/folders that begin with a period are hidden by default).

Now in Terminal, type the following:

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ exec $SHELL

The commands above should have added a few lines of code to your bash profile (a hidden file located in your home directory). These commands pretty much tell your shell what to do when you type an rbenv command. The last command will restart your shell and let you start using the rbenv command. (If the last command doesn’t work, try relaunching Terminal and that should do it.)

Next, enter the following command into Terminal and you should see a help screen with the version of rbenv and all the possible commands.

$ rbenv

If you don’t get an error that means you’ve done everything correctly - congrats! Now we have rbenv set up, but we still need to install a few more things.

Enter ruby-build

If you thought installing rbenv was easy, then you’ll love ruby-build, which by the way, are both of which are made by the super awesome Sam Stephenson of 37signals.

We’re going to be installing ruby-build as a plugin for rbenv, so you’ll need to run the following commands into your Terminal:

$ mkdir -p ~/.rbenv/plugins
$ cd ~/.rbenv/plugins
$ git clone git://

The above commands created a subdirectory called plugins in /Users/yourusername/.rbenv, changed into that newly created directory and cloned the Git repo containing ruby-build. You can check ~/.rbenv/plugins to check and see if there’s a ruby-build directory there. If there is, it’s successfully installed.

Now that we have both rbenv and ruby-build set up and properly working, all we have to do is install the latest stable version of Ruby and set it as the default version.

In order for this step to work, you’ll need to have Xcode installed on your system. You can grab it for free from the Mac App Store if you need to. Once it’s installed, run the following commands. (The first command may take a while because it needs to download and compile the Ruby source code.)

$ rbenv install 1.9.3-p194
$ rbenv rehash
$ rbenv global 1.9.3-p194

We’re almost done - just a few more steps and you can start using Rails.

Multiple versions of Ruby

It’s worth noting that the above commands will also allow you to install any other versions of Ruby (old or new), simply by changing the build number.

For example, if you needed to support an older Rails app that requires Ruby 1.8, you would type:

$ rbenv install 1.8.7-p358
$ rbenv rehash
$ cd ~/legacy-rails-app/
$ rbenv local 1.8.7-p358

Then you could have the latest Ruby version set as your system default, but override it on a per project basis using the rbenv local command.

RubyGems and Rails

Since we’ll be installing Rails from the RubyGems library, we want to make sure that we have the latest version. RubyGems should already be installed by default, so all we’ll have to do is make sure it’s up to date.

$ gem update --system

Once that’s finished updating, we’ll need to install the Rails gem.

$ gem install rails

Rails and RubyGems are now installed and up-to-date.

Finishing up

Our shiny new Ruby on Rails development environment should now be set up, properly configured and ready to start using.

By choosing the rbenv/ruby-build configuration, we’ve made it pretty easy for ourselves to stay up-to-date with the latest version of Ruby. We also now have the ability to support legacy Rails apps that may require older versions of Ruby (like 1.8).

If you’re wondering what to do next, you may want to read my previous article on Getting started with Ruby on Rails.

Also, if you’ve run into any into problems during the installation process, I’ll try my best to answer any questions you may have on Twitter.

Getting started with Ruby on Rails

Over the past few months I’ve been teaching myself Ruby on Rails. I’m very happy with the progress I’ve made and thought it would be helpful if I shared a bit of my learning process with others.

My background

I’m a front-end designer, so most of my time is spent writing HTML, CSS and JavaScript. As much as I love doing that, I also wanted to explore the other side of things.

I can write some PHP and understand even more, but it’s never really felt natural to me. It always seems that what I’m trying to express in my head makes more sense than the code I write. This left me looking for a different programming language, one that more closely matched how I solved problems in my head.

(Note: I’m not trying to bash PHP here, just stating that it’s not for me. Use whatever tools make you happy.)

So, why Ruby on Rails?

There are many things to love about both Ruby and Rails, but the one thing that stood out to me was the Ruby language itself - it’s absolutely beautiful.

Ruby doesn’t heavily rely on things like curly braces and semicolons, instead line breaks and indentation are used. As a result you end up with groups of code that look like statements written in plain English. Ruby is quite often compared to poetry because of this.

And since formatting is so important, Ruby code will look virtually the same, even if it’s written by different people. This makes it much easier to read if you’re working with a team of developers or contributing to open source projects.

Language and syntax aside, there are many other reasons why Ruby on Rails seemed like a good fit for me. Here are just a few:

Jump in

I honestly don’t think it matters where you start. A lot of people will tell you how to learn, when really, only you will know best. The important thing is that you just get started and stick with it.

I use a lot of different resources, both free and paid, but I had my “A-ha!” moment when I did the Rails for Zombies course.

Rails for Zombies

A free online course put out by Code School where you write code directly in the browser. This lets you learn Rails without having to set up a development environment on your machine.

Basically, you watch a video walkthrough and then write code in your browser to reach the next level. Also, be sure to check out Rails For Zombies 2 and also Rails Testing For Zombies.

Rails Tutorial

A tutorial (recently updated for Rails 3.2) that will walk you through the creation of a simple Twitter-like app.

You’ll learn about Rails MVC, testing with RSpec, user authentication, the Asset pipeline and even deploying to Heroku. You can currently read it for free online, or buy the PDF & screencasts.


A great site with new screencasts each week (one free, one pro and one revised). All sorts of topics are covered such as customizing/optimizing Rails, working with Gems and refactoring your code.

Also, if you buy a subscription then you get access to all the pro and revised screencasts.

Agile Web Development with Rails

This is probably the best Rails book out there. It covers tons of useful stuff like testing, AJAX, authentication, sending mail and deploying apps. It’s also written by very talented people, including David Heinemeier Hansson, the guy who created Rails.


This will be your best friend when you’re first getting started and can’t remember how to do something. I can’t tell you how many times I refer to this when I’m working with Rails.

The path of least resistance

If you take anything away from this article, make sure it’s this section. These may seem obvious to some of you, but a list like this would’ve made my life a lot easier when I was starting out.

Embrace the command line

It can seem daunting at first, but it’s very powerful and faster than browsing your filesystem. I put this off and did things the hard way for a while. It’s totally possible, but can be tedious.

Love thy editor

I prefer something like Textmate (or Sublime Text 2) because it lets me see the entire directory structure which can be helpful when you’re starting out. A lot of developers swear by Vim because they’re in the command line anyways and it’s one less app to switch between. Either way, make sure you love it because you’ll be spending 90% of your time using it.

Have MVC experience

You’ll be way ahead of the game if you’ve worked with other MVC frameworks in the past. If you write procedural code, start with learning the basics of MVC. Simply knowing where all the code lives can be helpful when things go wrong and you need to debug.

Know some Ruby!

Rails isn’t a language, it’s a framework built with Ruby. That means you’re going to be writing Ruby, so learn it sooner rather than later. It will also give you a better understanding of how Rails works.

Next steps

One thing I didn’t cover here was setting up a Ruby on Rails environment of your own. This looks and sounds harder than it actually is, but it can be intimidating to tackle on your own. I should be publishing an article on that in the next few weeks, so stay tuned and start hacking.

Post-Google follow up

About a month ago, I said I was going to stop using Google products because of what they do with my personal data. If you haven’t read my previous article Breaking up with Google yet, I recommend that you do so before continuing.

Progress so far

I’ve managed to close quite a few accounts, including some of the bigger ones like Google+ and YouTube. There were also a number of accounts that I had forgotten about and some I didn’t even know that I had, like Picasa.

Any others that somehow managed to survive the cut (Reader, Webmaster Tools, Profile and Gmail), have been stripped of any optional personal data. In most cases, all that remains is my name and gender.


Yep, I’m still tied to Gmail, but it’s on its way out the door. I knew that this would be a slow and painful process because of all the data accrued over all the years of use, but I feel like I’ve made a pretty good dent so far.

In case you were wondering, here’s my process for (slowly) moving away from Gmail:

  1. Is this a legitimate email? Do I know this person or did I sign up for this newsletter?
  2. Am I still interested? Do I still keep in touch with this person or do I stil want to receive this newsletter?
  3. Update my email, but only if I’ve answered yes to the first two questions.

Overall it’s a pretty short process and running through it a few times a week isn’t hard at all.

Pro-tip: This also a great way of getting rid of unwanted newsletters and notifications from social networks.

In the nick of time

Shortly after I published my article, Google announced its new privacy policy. My understanding is that a bunch of individual privacy policies will be going away and Google will be merging whatever personal data it can. So basically, any personal information you have in Google+ could essentialy end up in your YouTube account, or vice-versa.

And then just yesterday, The Guardian published an article on how Google was tracking Safari users, purposely bypassing Safari’s own privacy settings.

Of course, this wasn’t just limited to the desktop either, it affected iPhone users too. This is especially bad when you consider the following: the current iPhone market share, Safari being the default browser and Google being the default search engine.

Update — Feb 20, 2012 Microsoft published an article today on the MSDN IE Blog stating that Google is doing the same thing with Internet Explorer, but using an entirely different method to bypass the browser’s security settings. The article, posted by Dean Hachamovitch, Corporate Vice President, Internet Explorer says:

“We’ve found that Google bypasses the P3P Privacy Protection feature in IE. The result is similar to the recent reports of Google’s circumvention of privacy protections in Apple’s Safari Web browser, even though the actual bypass mechanism Google uses is different.”

I’d be curious to see if this is also happening with Firefox and Opera. I wouldn’t be at all surprised if the answer was yes.

Not everyone is bad

About a week ago I discovered the search engine DuckDuckGo and it’s been my default search engine since.

There’s a lot to love about DuckDuckGo: an adorable mascot, a simple-yet-beautiful UI and search suggestions that are actually helpful. But that’s not why I like it so much. On they’re homepage, DuckDuckGo clearly states that they don’t track or bubble (personalize) your search results.

Finally, a company that gets it.

So, mission accomplished?

Sort of. I still have a lot of work ahead of me with Gmail but I’m very happy with the progress I’ve made so far. It felt really good pressing that “Delete Account” button a bunch of times and in all honesty, I haven’t missed Google once since I started doing this.

Probably the best part of this is finding out that good, honest companies (like DuckDuckGo) are out there and that they’re on our side.

Breaking up with Google

I’ve been a long-time user of Google products. For the most part it’s been fine. I say fine because I’ve never been overly excited or impressed when using their products — they’ve always just done the job. This isn’t necessarily a bad thing and it’s certainly not the reason why I’m distancing myself from Google. It actually has nothing to do with the user interface or features of the products themselves.

The reason is quite simple: I’m leaving Google because I don’t trust them with my data.

Why am I doing this?

It’s hard to explain without sounding like a paranoid fool, but basically, Google has access to a lot of my personal data (which I’ve provided them with) and I don’t agree with what they’re doing with that data.

My main concern is with Gmail, which I’ve used as my primary email service since it was in private beta. It’s been ad-supported for as long as I can remember and I’m completely fine with that. Advertising is a necessary evil and it’s how Google makes most of its revenue. In fact, Google made 96% of their revenue from advertising in 2010.

The fact that someone wrote an algorithm to scrape my personal emails for keywords just rubs me the wrong way. What makes this whole situation even worse is former Google CEO Eric Schmidt and his thoughts on privacy and data.

Here are a few quotes from Eric Schmidt in an interview with The Atlantic’s James Bennet.

“We don’t need you to type at all. We know where you are. We know where you’ve been. We can more or less now what you’re thinking about.”

“Google policy is to get right up to the creepy line and not cross it”

He may not be the current CEO, but he’s still the Executive Chairman.

We’re doing it for you

In this video about Ad Preferences, Google basically says that they provide personalized ads to benefit the user and that you can also opt-out of said ads at any time.

First of all, I can’t think of anyone I know that would willingly click on any ad (especially some of those shady Google Adwords ones), so I find it hard to believe they’re doing it to benefit the user. I think it’s also safe to say that most people hate ads no matter the medium or relevancy.

And secondly, I opted out of these ads long ago, yet I still get ads that are based on private content from emails. This could very well be a bug, but if it is, they’re in no hurry to fix it.

Getting the hell out of Dodge

I have to congratulate Google for their efforts with The Data Liberation Front. It’s sole purpose is to provide users with a hassle-free way to export all their data and move it elsewhere on the web (even if it’s a competitor). Not all apps are supported yet, but a lot of the major ones are.

Below is a list of all the Google products I use and what I’ve decided to do with them.


iCloud will be used as my primary email service because there are absolutely no ads. Also, the user interface is similar to on both Lion and iOS.


This will also be replaced by iCloud. I’m really not a fan of the “real-life” calendar interface here, but it’s a small price to pay to have email and calendar together.


This one is kind of a lateral move because it still has targeted ads, but I’ve been using Bing as my default search engine for about a week now. The desktop version is nothing special, but the mobile version has a Metro-inspired layout which I absolutely love.


I was lucky enough to get in on the Google+ beta. I actually like it and find it much easier to use than Facebook. The only problem right now is that it hasn’t been widely adopted by the general public. I still haven’t decided on what I’m going to do with this account. (I’d actually like to get rid of my Facebook account too because of targeted ads, but that’ll be another day.)


I have a YouTube account which I use pretty much for subscriptions only. I also have a Reader account which I use only because Reeder requires it. I’ll be keeping both of these accounts for now but I’ll be paring back whatever personal information I can.

Google isn’t evil

By no means is this meant to be an anti-Google post, so I truly hope it doesn’t come across that way. I don’t believe that they’re “evil” or anything like that. Eric Schmidt, however, does creep me out quite a bit. Sorry, Eric.

Google has very talented people working on some awesome products and they seem to finally understand that software design doesn’t have to be boring. The recent design refresh we’ve seen across its suite of products is a very welcomed change.

Google relies on advertising to stay in business, but in my opinion, they’ve crossed a line by using personal data for advertising and then saying it’s to benefit the user. A person’s private data and trust are not things to be taken lightly.

Hopefully this post will make you question what personal data you’ve provided companies with and what they’re doing with it.

Hitting the ground running

I’ve wanted to get this site back up and running for a few years now. It’s taken this long because I honestly wasn’t sure what the purpose of a new website would be, or if I even needed one at all.

A little history lesson

The previous version of this website first appeared around the beginning of 2007, right after I graduated from college. The whole purpose of the website was to showcase my graphic design work, try to land a few freelancing gigs and blog about graphic and web design.

The website achieved all of those things, but it was quite obvious that the blog was an afterthought. I probably wrote about a dozen articles or so, none of which were spectacular or really said anything unique. The problem, was that I had originally decided to start blogging because a lot of other web designers were at the time. What I didn’t realize then was that I wasn’t contributing anything useful to the web and was just creating noise where it wasn’t needed.

I ended up taking the site down in early 2009 when I was hired by Barking Dog Studios as a front-end designer. The blog had been neglected for quite a while and the rest of the site wouldn’t be needed anymore, so I replaced it with a “coming soon” page (which was actually still online up until a few weeks ago).

Starting over

When I first started redesigning, I was too caught up with what the rest of the web was doing. I was adding features I didn’t need, trying to go after a certain “look” and using shiny new technologies just because they were available. I went through a number of designs and even got to the coding stage a few times before completely scrapping them.

It took me a while to realize that all of that stuff didn’t matter to me. I wanted my website to be a place where I could write about the things I love and share things that interest me with like-minded people.

Once I knew what the purpose of the website would be, it wasn’t so hard coming up with an appropriate design for it. It’s far from perfect but I’m quite happy with the result so far.

So, what now?

First things first — no promises. I’m not going to tell you that I’ll write a certain number of entries per month or anything like that. I’ll write when I have something to say. It could be an idea, a review, a suggestion or even a frustration (hopefully not too often). I imagine that most of it will be web or technology-related, but don’t hold me to it.

Also, this website is very much a work in progress. I wanted to launch it as soon as possible so that I could start writing, but that also meant I had to leave some things behind (for now at least). This included a fluid grid layout and also support for media queries so that the site will be more usable. Hopefully those features will be added back in the near future.

Also, this site will never have comments, but if you ever have questions or thoughts you can reach me on Twitter @matthalliday.

Thanks for reading.