In addition to the basic development environment everyone at thoughtbot works with, there are a number of other apps most of the designers here use to keep our work flows efficient and our skills top notch. When I came to thoughtbot as an apprentice a little over three months ago, I was exposed to a variety of new apps that greatly improved my work-flow, so I thought I would share with you some of the apps I open up every morning and a bit on how I use them.
These apps are not necessarily design-specific apps but they are so essential in our day to day work-flows that I couldn’t leave them out.
If you work on the web I am sure you are already familiar with the typical Adobe software that web designers use, so Im not going to get into the details of our Adobe setups here. Most of us prefer to do hand sketches/whiteboarding and move into wire framing with HTML and CSS as soon as possible any way. Static mock-ups tend to have a host of draw backs when working in an agile development process. That said, photoshop, illustrator and fireworks are still our workhorses when it comes to specific graphic design needs.
A handy screen capturing tool that allows you to very easily draw and add notes on top of your screen shots, without having to open up photoshop or some other image editing tool.
Collaboration and iteration are key ingredients in doing great work and I have found this app to be an effective way of sharing screen shots with team members, clients and other designers so I can get that valuable feedback on the development of my work. When you take screen shot Cloud app automatically uploads your image to web servers and in a drop-down from the Cloud app icon in the OSX menu bar, provides you with a sharable link to that image.
Good for general note taking and the keeping of VIM and Git cheat-sheets. Especially if you are new to VIM or Git keeping track of commands and remembering how to get certain things done right can be quite challenging, so we all suggest building up robust cheat-sheets with this little app.
Great typography is a fundamental element of great design. Managing your fonts effectively will help you find that perfect type-face faster and reduce the time it takes to get started with a solid visual design direction. Taking the time to organise your typefaces in a way that is meaningful to you can also be a good way of curating your collection and more intimately familiarizing your self with the fonts in it.
Both are awesome tools for building a personally curated library of design inspiration. Saving images and examples of the things that inspire you is a great way to refine and hone your own personal style and also a great way to help kick off the visual direction for a new project. If you are not using tools like these already, start. It will be hugely beneficial to the quality of work you do.
A great little app for grabbing colors from anywhere on your screen. It provides rgb, hsl, and hex values for any color you select which makes pulling color pallets from photos and images you have stashed in your Gimme Bar or Little Snapper quite nice.
Bourbon is not an app, it’s a library of SASS mixins and functions that greatly speed up front-end development time. It is just as awesome for new comers to .css/.scss as it is for the most seasoned pros. It’s also one of the main reasons the sketch-to-html&css-wire frames process has proven to be so effective and efficient for us. We have extensively written about bourbon before.
So that’s it for a light-weight overview of the apps I find my self opening on a daily basis. Hopefully I have introduced you to some new and useful tools. I’d also love to hear about some of the tools your using, so feel free to add your comments below!
Today is the end of my fourth week as a Design Apprentice here at thoughtbot and it’s been pretty crazy so far. Before I got started I was excited to start filling in all the minor gaps in my knowledge. My first week was spent looking at documentation and demos for new tools and languages and running through tutorials. It was exciting stuff, and all seemed pretty straightforward. All I had to do was jump onto a project and I’d be contributing in no time. I was confident that I could go from Photoshop jockey to front-end guru in a matter of days.
Then I started writing code that was actually intended for release to a client’s product. The panic set in pretty quickly. The “minor gaps” were quickly revealed to be “huge gaping chasms of inexperience.” I had worked with HTML and CSS plenty of times before, but the pace was leisurely, the deadlines few and far between, the complexity very low. Now I would go from discussing a new feature in the morning to the expectation of having it complete by lunch.
This was a pretty big wake up call for me. At my previous job I was considered the design team’s authoritative source of development knowledge. Questions came to me first and my answers were accepted as absolute truth. On the rare occasion that the designers were expected to write code (the horror!) the task would be assigned to me. I was pretty comfortable on the top of my mountain, so to be body-slammed off of it so effortlessly was a serious bruise to my ego.
It’s been two more weeks since then. Things have gotten better. I’m not blazing fast, and I don’t always do things perfectly the first time, but my confidence is back (tempered with a good dose of humility). I’ve learned a few important things about tools and process during this time. If you’re an apprentice, or a designer that’s new to the expectation of delivering front-end code, hopefully this will be of some benefit to you.
Vim will look clunky to you if you come from a background similar to mine. A few years of Dreamweaver, the eventual move to a better piece of software like Coda or Espresso, and then this? You want me to work in a text-based interface with a complete lack of familiar keyboard commands? It will seem insane, but there are some huge benefits and you should stick it out. Once you start to become familiar with it, the potential for amazing speed will become apparent. The hard part is making your hands learn all the new movements and commands. Once your muscle memory starts to kick in things will become faster. I wouldn’t say I’m great with Vim yet, but I’m at least as fast as I was in Espresso, and working hard to improve.
It’s important to note that I work in an office of Vim users. It makes sense for me to use it and I have a great support and learning network. If everyone in your office uses TextMate, or Espresso, or something else, you should probably use that too so that everyone’s on the same page.
Sass is amazing. If you know anything about CSS, just reading their documentation ought to get your blood rushing. My favorite part is the ability to nest selectors, which makes it incredibly easy to target elements correctly. Add in variables and mixins and you’ve got a very powerful extension to CSS.
If you want a set of great mixins, allow me to humbly suggest thoughtbot’s Bourbon.
This was the hardest part for me to adapt to. I’m used to working on static sites, so finding where everything was located in the Rails framework was intimidating at first. Luckily, I get to attend workshops (for free, it’s a great perk) at thoughtbot and our Intro to Ruby on Rails workshop was incredibly helpful in teaching me to navigate an application.
Have someone else look at your work. A lot. More experienced people will be able to point out what you’re doing wrong and what you could be doing better. It’s important to correct these behaviors before they become habits. Don’t be timid about offering your own feedback either. Design is often a collaborative process, and talking about your ideas usually results in better work.
But what if you’re the only designer at your job, or a freelancer? Start by posting your work on Twitter or Facebook and asking other designers for some feedback. I’ve found that many people are willing to take the time to send you a short review. Dribbble can be another great place to get input.
You can almost always find answers to your problems by searching for them online. The odds of encountering an issue that somebody else hasn’t run into and solved before are incredibly low. And in our industry we’re lucky to have a lot of knowledgeable peers who enjoy writing about their solutions.
Most importantly, try to stay positive. You’ll have ups and downs, successes and failures, but as long as you’re moving forward you’ll be ok. I’m lucky to have people at thoughtbot who are committed to making me a better designer and a better front-end developer. Try to find people like that for yourself, either in your workplace or online. We’ve got a great community full of intelligent, helpful people. Take advantage of it.
Unobtrusive Ruby is any Ruby code that stays out of your way. It does not make you write lots of boilerplate, or stub methods, or open classes. It is decoupled. Its tests run quickly, its classes fit on one screen, its methods are tiny, and it is quickly refactorable.
Unobtrusive Ruby is a state of mind. Unobtrusive Ruby is what you want your friends to write.
Since you love your friends, here are some guidelines while you design your next gem or framework:
All your arguments should be instantiated objects, where the caller has invoked the .new method herself. Leave the constructor up to the class author. Never force a calling convention on a constructor, or in any way force someone to look up how to instantiate her own class.
Object inheritance is one way to force the user—your friend—to do odd things with the constructor. When to call super, what the arguments are, and so on. This goes for mixins, too; they add complexity to the class’s namespace, increasing the cognitive overhead. All inheritance adds brittleness.
The contents of a class should mention no other classes by name. Pass in all objects that it must use. Not only will you thank yourself for the flexibility later, you’ll notice that your tests are better at the beginning.
A unit test on a small class should be fast, and classes should be small. Mock objects, a lack of inheritance, and dependency injection will see to it. The tests for your friend’s code should not have the same dependencies as the tests for your own code. The ideal dependencies are nothing more than the test framework and the class under test.
Classes should care about composing instead of being composed.The best class will consume instead of being consumed. It makes its own rules. Maybe you can’t get there—something has to be consumed at some point—but it’s a useful goal. If it’s not possible, the required interface must be simple. One method, maybe two.
Data is easy to test: pass some values into a method, receive a value from the method, then verify that it’s the right value. Never force your friend to do anything more than this. Never force them to do database lookups, system calls, random number generation, and so on; do that for them.
The overall idea here is that your friend should always be able to just write code. You never want to stand in her way; never force documentation or change her classes or invent bizarre loopholes. You, as the gem author and framework designer, want your friends to build their system without noticing the system you’ve built.
Unobtrusive Ruby does what you expect.
While redesigning the thoughtbot site, I gave myself a challenge: create an easily editable and maintainable baseline grid. I figured that there had to be an easier way to do this with Sass than with plain old CSS.
I started off going to the wonderful modulargrid.org to create my grid. I grabbed the png and threw it into the background so I could be certain everything is aligning perfectly. Then I created 3 variables based on the grid; one for the column unit width, the gutter width and line-height. This made things conceptually easier for me instead of trying to balance numbers.
$line-height: 20px; /*line-height for the site*/
$unit: 60px; /*column size*/
$gutter: 25px; /*gutter size*/
Almost as soon as I had started, Sass 3.1 came out touting functions and in the change log examples I found this gem:
@function grid-width($n) {
@return $n * $unit + ($n - 1) * $gutter;
}
This function calculates that width of the column by giving it the number of units you want it to span. Now all I needed to do is drop in grid-width() for any width and it will conform to the column sizes in my grid. For example, I wanted the grid to be 12 units wide, so on the wrapper for the site I put:
width: grid-width(12);
Of course this isn’t always perfect, the box model adds padding and the border to the width of the box and it breaks the grid. Bah. But Sass is wonderful and can do simple math and can apply that even to functions. So on a box that spans 4 columns but has 20px of padding on both sides I can subtract the padding to get the correct width of the column.
padding: 20px;
width: grid-width(4)-(20px*2);
The background image that I had for the grid also gave me guidelines for where the baseline should fall. Then all vertical spacing for the design uses the line-height variable. Everything from padding to the margin to the height of the images can all be declared with the line-height variable and some multiplication.
height: $line-height*6;line-height
margin-top: $*3;line-height
padding: $;
Again, I ran into scenarios with the box model where I didn’t want to use the whole line-height. These changes and exceptions were easy to accommodate with a little math just like the grid-width().
padding: ($line-height*2)-(1) 0; /*Account for 1px border*/
Throughout all the Sass I’ve successfully avoided doing any real calculations and feed Sass a bunch of math problems. Updating and maintaining the layout is easy, anyone who goes into the Sass won’t have to figure out what the width of a 3 columns would be. It also has the ability to be easily adaptable to having a fluid layout.
The grid-width function has also been incorporated into Bourbon, our default set of mix-ins and functions. Use variables $gw-column and $gw-gutter and then you are all set. No need to set up the function.
If you’d like to get some more Sass and advanced HTML & CSS tricks come to my workshop on Sept. 26th & 27th.
Over the last few months we have been looking for another designer to join our team. We’ve seen a bunch of portfolios ranging in experience and style. I’ve found it intriguing to see how other designers present themselves and their work through their portfolio.
When it comes down to it you want your portfolio to show your work in the best light possible. You want to make the person hiring to be looking for more and eager to talk to you. Here are a few things that I am always looking for in portfolios.
I can’t put enough emphasis on design basics in both your portfolio and the work that you decide to put into it. There are in particular two things that I am really looking for: a proper grid and outstanding typography. You should have a solid understanding of both and be able to show it in your portfolio.
A grid is something no design should be without and there is no excuse not to use one for your portfolio. Its benefits are well documented and accepted; it adds form structure and flow. If you think you need help in this area pick up Grid Systems: Principles of Organizing Type by Kimberly Elam.
Choose a solid typeface and set it perfectly. Pay close attention to line-height, letter-spacing and the hierarchy in your type. I feel like every designer should have a copy of Robert Bringhurst’s Elements of Typographic Style, and have read it at least twice.
Don’t show anything less than your very best work. If that means that you can only have one portfolio piece then you only have one. Don’t just put in a bunch of work that doesn’t show your full capabilities. The work in your portfolio site should be shown well. It seems obvious but don’t have lots of distractions and useless ornaments around it unless it serves to better show your work.
Client work proves that you’ve done it before. It indicates that you can handle clients, handle project timelines and everything that comes with being a designer on a team.
If you don’t have this kind of work look for projects that you have done that might fill that gap. They can range from a goofy tumblr account, to contributing to open source, to maintaining a blog. They show that you have a passion for this thing you want to do, that you are eager to learn and that you eat, drink and breathe this stuff. Even if you have a bunch of great client work it’s still great to see projects that you have started or contributed to showing your passion for your work.
All in all, you want to play to your strengths. If you are right out of school you won’t have much client/in-house experience so play up those projects you take on in your free time. If you have a bunch of solid work select the few you consider the very best and switch out pieces depending on the job you are looking to get. Make sure that who you are and your core design principles are reflected in the design of your portfolio and the pieces that you have chosen for the portfolio.
I’d like to start giving portfolio reviews if there is an interest in it. It’s something that I wish I had the opportunity to have when I built my first portfolio (it was pretty bad). So if you are in the Boston area, come to the next Design with Boston. Just ask me and we can sit down and go over it sometime during the night.
