RMU Round 2: Process, Tools, & Techniques
Note: This is the second of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:
Part 1: About the course & what it was like
Part 2: A first-timer’s process of styling a site
Part 3: What I learned from the course
This post is more about the process and technical challenges I faced in creating a full layout for the first time. In my final post on the topic, I’ll share more of the general lessons from this session.
For me, the process went as follows:
Mockups
Backtrack & fix (set the stage)
Create assets
Implement styling on page-by-page basis
This, with a lot of reading and learning about tools & technologies I needed to get the job done.
The mockup stage: Balsamiq, etc.
I cannot tell you how critical this is. The mockup stage is the part where you think through all the user’s paths through a site, what they’ll expect, and what context they’ll need to get what they want. You get a sense for visual priority and information design. All before writing one line of code.
The visual context simply cannot be guessed at or thrown in during implementation. My opinion is that if you’re not doing a thorough mockup before coding, you’re probably going to screw something up pretty badly.
I’ve used a lot of different mockup tools, including sharpie/paper, Mockingbird, HotGloo, Keynote UI templates, and iMockups for iPad. Balsamiq is my personal choice. You can learn it in 20 minutes, and cloning your mockup and then exporting a bunch of tabs to .png will save you lots and lots of time. My 2nd choice would be sharpie/paper.
Once it came time to actually style the pages, designing to a mockup didn’t tie my hands at all. It actually liberated me to work within the framework to offer the best presentation possible, without worrying about fundamental questions like whether to choose a 1, 2, or 3-column layout.
It took a few hours to think through properly, but I got those hours and more back when it came time to turn those mockups into styled pages.
The “Fix the broken pieces” stage
So far in my work at the office and in RMU, one consistent theme is that the thinking you put into the mockup stage will reveal flaws in the existing plan or implementation.
In this case, there were unfinished pieces of the app; features that were clearly intended but not built out, like an Announcements feature and a Puzzle Details page. The lesson here (intended or not) was that in order to move forward, you’ve often got to move back and clean up a little bit.
Once this was done, the stage was set for some actual design.
The “create assets” stage
This one seems optional, and Photoshop skills are not necessarily required, but I was sure glad I had them. I didn’t do any high-fidelity mockups or anything, but I did create my logo & background images, and tweak icons.
I also used a nifty little site called Stripe Generator to create repeating stripes, which is usually a laborious process involving Illustrator and/or Photoshop.
Last stage: Styling
OK, enough playtime. Now it was time to jump in and get my hands dirty. And then–
Haml, WTF?
I jumped into the project and immediately came to a screeching halt. Instead of my more-familiar ERB syntax, the views were in Haml.
Immediately, I was faced with 1) converting all the views to ERB, or 2) Learning enough Haml to get by. I figured that converting the Haml to ERB would require nearly as much research as just keeping it, so I decided to stick with Haml.
This was itself a crash course, and I came away both impressed and frustrated with aspects of Haml.
What makes Haml so great?
There are no closing tags. It has a Ruby-esque syntax, and it’s much easier to drop in native Ruby than in ERB. It uses CSS-style selectors. It’s terse, clean, and easy to read, once you’ve got the hang of it.
There apparently used to be serious performance issues, but they’ve since been ironed out, and Haml is about on par with ERB for speed in compiling to HTML.
What makes Haml frustrating?
There are no closing tags. That means that you’re in the realm of “significant whitespace” in your views. Personally, I don’t like having my views fall apart and spit an error at me because of my indentation.
Haml is optimized for cleanliness, not flexibility. Perhaps the most damning thing about Haml is that you can be almost certain that you’ll need to fall back to ERB (or have Haml interpret HTML via plain text, ugh) eventually for some edge case. If it works in HTML, it works in ERB. Not so with Haml. You’ll either wind up twisting something straightforward into knots to fit into Haml’s syntax, or fall back to ERB.
Would I use Haml again?
Basically, Haml is a lot more fun to work with than ERB, right up until it’s much, much worse. One surprising thing is that you don’t have to choose; you can use Haml most of the time and use ERB for your edge cases.
Yes, Haml did add a significant amount of time to my project. But depending on the project, it’s likely I’ll use it again in the future.
Once I got the hang of the markup, it was time to start styling my project. I wasn’t sure where to start, having never styled a page from scratch before.
But after my first go-round with CSS, I started getting really frustrated.
**Does CSS Suck?**
That’s a total troll question, so I’ll rephrase:
How did people do layout before Compass & Sass?
We had a pretty heated debate in the #rmu IRC room about whether CSS sucks. The sticking point was that an educational context basically isn’t a place to say that any given tool sucks.
But it’s a good question: Does CSS suck? Greg Brown has created a layout framework for PDFs in Prawn, which taught him that creating a flexible layout is a hard problem, and CSS has spent 10 years doing a pretty good job of solving that problem.
But Ruby developers used to having a universe of capability and spoiled on the “principle of least surprise” get a rude awakening. CSS is a crappy programming language, if that’s what you’re expecting.
With CSS, I kept having the experience of “tweak, tweak, tweak, KABOOM”. A small change may mean nothing, or that your layout collapses entirely, or your signup form is wrecked because of a seemingly unrelated change for another page.
That said, there are some frameworks that turn CSS into much more of the programming language that developers expect.
In fact, when it’s all working together well, I’d say that Haml/Sass/Compass/Blueprint combo is a pretty friendly way for developers to do design. Here are the pieces, broken down:
Sass: CSS, but like, for programmers. It adds some powerful features to CSS:
Variables (e.g. $light-gray: #f7f7f7)
Mixins (e.g. @include bordered-table)
Nesting & Inheritance (I didn’t use these much)
SCSS: It’s Sass but with CSS syntax. Basically, Sass is for people who really hate braces and semicolons, and SCSS is for people who want CSS compatibility. SCSS seems to have become the de facto standard for new Sass projects.
A very minor gripe is that because of the syntax change, a lot of the tutorials you’ll see will be hard to understand in SCSS, as Sass was the preferred syntax at the time they were written.
Compass: Compass doesn’t do a good job of delineating its role from that of Sass. The fact is, the majority of the benefits they claim come from Sass, but the additions Compass brings make it absolutely indispensable to me now:
The ability to define and mix in partials
Auto-compiling for Rails projects
A whole bunch of pre-defined (and easily configurable) mixins.
Compass gives you a nice framework to start from, and a project folder that is relatively easy to keep clean and organized (though I did manage to mess that up later).
For an example of the benefits of Compass/Sass, if I wanted a drop-shadow and border-radius on a div, first I’d import the partial:
@import "compass/css3";
Then I’d include the predefined mixins in the style for that div:
@include box-shadow;<br /> @include border-radius(10px);
Combined with the ability to define your own mixins, this is a huge time and sanity saver.
Auto-compiling stylesheets is also awesome, because it means every time you save a change, you get real-time feedback, as if you were editing the CSS directly. It also recompiles each time the server is restarted, so every time you push an update to Heroku or it spins up your instance, it throws an error while the stylesheets compile. I’m not sure how to get around this, but it’d be irrelevant if you had a dedicated box that didn’t spin up/spin down like Heroku.
Blueprint: Blueprint exists independent from Compass, but it almost seems like they were destined to be together. It includes some decent defaults for a Grid system, forms, and typography.
960gs vs. Blueprint Grid
Basically, a grid system is a way for you to define the horizontal layout of your pages so they don’t look crappy. They pick a default column count of 24, so you can cleanly split a page into 2, 3, 4, (or 6, or 8 ) columns. It’s configurable, but the default seems like something I wouldn’t be likely to change.
Brian Hogan (PragProg author of “Web Design for Developers”) recommended I choose 960gs over Blueprint’s grid due to 960’s better documentation. However, I hadn’t realized that Compass includes mixins for Blueprint’s grid system.
So I chose Blueprint grid.
To demonstrate how awesome Compass is, I’ll go back to Compass mixins:
Let’s say I want to create a simple 2-column layout with a header, footer, main area, and sidebar. This is a pretty basic request, but handling this in CSS requires a lot of careful pixel calculation and repetitive typing.
Here’s all you’d need to do it with Compass/Blueprint:
.two-col {#container {@include container; }#header, #footer {@include column(24); }#sidebar {@include column(8); }#content {@include column(16, true); }}
What amazed me is that I was able to get the project completed despite the initial uphill battle of learning these tools. I’ve only scratched the surface of all the amazing things you can do with Sass, Compass, Blueprint, and their associated mixins, but I look forward to using them more in the future.
Seriously, how cool is it to be able to take something from a thought to full visual execution?
That’s not to say the road was perfect. In my next post, I’ll talk about the rest of what I learned, including my EPIC FAILS.
