While the HIG has a lot of good information, it doesn’t go into the details of implementation, so I’m going to go through the process of how I would design a toolbar icon. I’ve chosen the iWork style because I really like how crisp and clear they are, and I think they are a good model to work towards.

So let’s take a look at the Pages toolbar.

Let’s take a note from Gmail and add a “Labs” button. This imaginary feature would take the user to experimental or even user-made plugins and macros.

Step 1: Pick your metaphor

First we have to think about what kind of metaphor would best represent this feature. The HIG offers the following guideline:

“As a general rule, a toolbar icon that depicts an identifiable, real-world object or recognizable user-interface element gives first-time users a clue to its function and helps experienced users remember it.”

So what makes me think of experiments? A beaker seems like the obvious choice. Anyone with high-school chemistry would know that symbol. But before I draw anything I should do some research. I fire up Google Image Search and Flickr with a search for “beaker.” It looks like I have a couple of choices for the shape of the object.

This is actually the kind I was thinking of, but I think these kind of beakers are generally only used in stock photography. I’ve never seen or used one like it in an actual lab. I got a lot more results for this type:

This is also what I remember from science class. The other beaker style is perhaps a bit more recognizable, but in the interest of realism (and not looking too Weird Science) I decided to go with this one.

Step 2: Figure out your sizes

So you’ll notice that Pages’ icons are very crisp, with 1 pixel outlines at both the large and small sizes. This indicates that the designers created two sets of icons, one for the large size and one for the “use small icons” size. If they had only used one and resized it, the line would not be 1 pixel exactly on both. Whichever one that was resized would have fuzzy lines. If you have the time to do this, it’s a nice way to ensure that your icons will look good no matter what your user chooses (you can also selectively reduce detail/complexity at the smaller size to ease recognition).

I’m going to design my icon for the larger size (32×32) and then size it down as needed for the smaller size. Figure out what the “large” and “small” sizes for your app are and keep these in mind. For a pixel-crisp style like this you’ll want to design at the size the icon will appear.

Step 3: Vector outlines

Open up your drawing program of choice. I prefer Fireworks for this kind of icon because it allows me to work with vectors while zoomed in to look at where the pixels actually fall. Go ahead and trace or draw the basic shape. Keep perspective and lighting (which should be top-down) in mind. The HIG says: “The perspective of a toolbar icon is straight-on, as if it is sitting on a shelf in front of you.”

At this point it’s a good idea to look at the fingerprint of your icon. That’s what I call the silhouette of the shape. Icons with different functions should generally have distinct fingerprints. Check to make sure the shape is recognizable and not too similar to anything it’s going to be adjacent to.

Step 4: Color, detail and shading

Now it’s time to fill in the colors and details. I like to zoom in pretty close for this step, but I keep an eye on the actual-size icon as I work. (In Fireworks you can do this easily by selecting Window > Duplicate Window.)

Be brutal about cutting unnecessary shading and details. Show only what you need to in order for the user to get what the icon represents. In the case of the beaker, I added two embellishments; the bubbles, which indicate that the green goop is “active” (and hopefully expresses something experimental and/or volatile) and the volume markers, which help make the beaker more recognizable.

Don’t be afraid to use bright colors here. As the HIG says, “Making each toolbar icon distinct helps the user associate it with its purpose and locate it quickly. Variations in shape, color, and image all help to differentiate one toolbar icon from another.” Also make sure the colors that should be consistent between the icons are - highlights, shadows and outlines fall into this category.

One more thing that’s actually quite important. Watch your alpha! Make sure that things that should be transparent actually are (like shadows, or in the case of the beaker the glass). I like to work with a couple of different-color backgrounds to switch between as I draw, including one that’s the standard Leopard window color to see what it will look like in production. You have no idea what this icon might end up on top of in the future! (Er, avoiding the obvious dirty joke there.)

Step five: Flatten and pixel-tweak

Save your file so you have the originals handy if you need to resize the icon, then go ahead and flatten your vector layers.

Time to break out the pencil tool! Start looking for places you can simplify your lines. Be especially ruthless around anti-aliased corners, which will have a mess of pixels you probably don’t need and will make your lines look fuzzy.

This is also where I add in line shading and other small details. You may not see much difference in the big, zoomed in picture, but at actual size the tweaked bitmap (right) looks much cleaner. Especially note the simplification of the spout shape.

So after fiddling with the pixels to my satisfaction, I’ll go ahead and plug it into the toolbar to see how it matches the other icons.

Step six: Generate other sizes as needed

So I have the large-size icon but I’ll also need a smaller one. The first thing I do is size the icon down and clean up the lines. Then I’ll go over the details and make sure that nothing is lost at the smaller size. I noticed that if the spout was made any smaller, it became difficult to distinguish the shape, so I actually made the top of the beaker identical in both sizes. I also redrew the volume markers to fit better on the smaller icon.

So there you go! It seems like a tedious process, and in some ways it is (depending on your style, you may be able to skip pixel-tweaking), but once you get into the right mindset it’s not so bad. You just want to make sure you’re thinking small and keeping an eye on consistency.

It’s easy to forget that the things you write on the internet are available for everyone to see. I often take it for granted that no one but my immediate circle is interested in what I have to say, and sometimes I say things that aren’t really appropriate for a public setting. I take pride in my professionalism, and in future articles I’ll be taking greater care with my writing when it comes to people and companies.

It’s easy to think I work in an an exciting, dramatic field that’s always pushing the boundaries of what’s possible, and continually reinventing itself in new and better ways. Users love the web, right? We’ve done a great job, haven’t we?

The thing is, somewhere around 2006, the web stopped growing. Web designers in general started to become increasingly more complacent and frankly bored with their jobs. Making a web app? Okay, plug in the templating framework of your choice, set it to CRUD mode, code up an HTML form and stick a JavaScript library on top of it. Content? Who needs it! Just hook it all up to Twitter, FaceBook, Flickr, Google Maps and hell, maybe some RSS feeds too. The design has to be catchy enough to get users interested, but don’t worry too much about making it usable. People will just be plugging in to it through their phones, desktop clients, or RSS readers.

Hello, web professionals. Welcome to the future. No wonder the conferences have degenerated to a stream of excuses as to why a full quarter of the world is still using IE6. And there’s an uncomfortable amount of silence regarding anything new. There is nothing new - and there hasn’t been for three years now. The big voices have fallen silent, and no one is rising up to take their place.

The problem isn’t the web. The problem goes much deeper than that. Our interface metaphors are flawed, our input devices are outdated, and the essentialization of most human-computer interfaces, on the web or in your OS, boils down to this:

No, no, no. People, we can do better than this. AJAX doesn’t make this right. It might make it feel more responsive, but at the end of the day it’s still just data entry.

The next time you design an interface, pretend your user doesn’t have a keyboard. What if all they had was a confirm button and a cancel button? This is basically what most game interfaces are. What about the iPhone? It has a keyboard, but only nominally. iPhone developers can’t rely users being willing to deal with the keyboard, and they have to be more creative with their input methods.

The restriction of having no keyboard has driven a lot of innovation on both game consoles and mobile devices. Where is that innovation on the web? Why are we still treating this thing like a terminal running Lynx? (And don’t you dare blame the browsers. You can do better and you know it.)

Here’s a thought experiment for you. Design an IM client that does not take input from a keyboard. (And I’m not talking about voice recognition here either. That’s not allowed.) After about five minutes of thinking about how awful and tedious that would be, you might be surprised with what you come up with. Maybe it could work like a conversation tree in a video game. Or maybe you could select a mood and a topic and it would automatically generate speech for you. Or you could go the abstract route and come up with an entirely different conversation model than what we do in person, leaving written language completely out of the equation. The sky, as they say, is the limit.

Give it a half hour of thought and you might actually get excited about it. Why? Because you’re tired of this nonsense too. We all are.

We all know where this is going.

Try your best to avoid being stuck in:

• A turbolift.
• A transporter pattern.
• A static warp bubble.
• The holodeck.
• An infinite loop.
• The 19th century.

Never be any of the following people:

• The good friend of a bridge officer, who no one has ever seen before, and who appears at the beginning of the episode.
• The love interest of: James T. Kirk, Julian Bashir, William T. Riker, or Lwaxana Troi.
• A spunky young ensign who is trying to prove him/herself.
• Any member of the crew of the original Enterprise appearing on a series other than their own.
• A member of any opposing force with redeeming characteristics or sympathetic qualities who opens up to a Starfleet officer.
• An enemy defector with heartfelt emotional allegiance to his/her race or government.
• Any android other than Data.
• The only member of the away team who is not a bridge officer.
• Tasha Yar.

1. Your designer can’t read your mind.

Rule #1 is that you must be communicative about your expectations and preferences. If you hate blue shiny things, say you hate blue shiny things. Send your designer examples of art you like. If he requests more information or feedback, give it to him. If you want his opinion on something, tell him that. I know you’re thinking, “But I’m hiring a designer because I don’t know about this stuff!” And that’s true. But he is trying to help you realize your vision, and you’re both likely to be unhappy with the results if you don’t communicate your goals.

2. Don’t be afraid to say you don’t like it.

This happens to everyone. Your designer works all night on a mock-up and it just doesn’t sit right with you. Maybe he does a couple more revisions and it still isn’t working. The more he works, the harder it can be to say it’s not what you’re looking for. But remember that your designer is (probably) a seasoned professional. Believe me, he is used to criticism and negative feedback. It will not hurt his feelings or make him discouraged. When you say you don’t like it, he’ll know he’s going in the wrong direction and try something different. Unless he truly is a one-trick pony (in which case you should probably find a new designer), your honesty will help him do his job better.

3. Be as specific as possible in your feedback.

One nice thing about working in the world of digital art and media is that our work is no longer nearly as static as it used to be. Imagine a painter in 1829. If you commission a painting and you don’t like how it comes out, he has to start all over again. He can’t go back and make the sky purple or have the subject face the other direction. By contrast most contemporary designers and artists create their work on a computer in the form of large, complex multi-layered documents. Relatively speaking, these are incredibly easy to change. Elements can be added or removed non-destructively. Colors can be changed on a whim.

When you send feedback on a revision, don’t just say “I don’t care for the headers.” Instead, say what you like and don’t like about them. An example might be, “The font is good, but they don’t pop enough.” A designer will know what to do with that, and more importantly they will know what not to change.

4. Leave some room for creative space.

Unless you’re just hiring a Photoshop jockey (and I hope you aren’t), try to remember that your designer is not just creating deliverables but also coming up with ideas for you. They are thinking of creative solutions to your problems and looking at your company or product through the lens of usability, branding, or aesthetics. This process involves research, mental energy, and most importantly time. When you have a timeline, make sure your deadlines for deliverables and milestones are clearly communicated at the start of the project. And then leave them be! Don’t ping every day asking to see “how it’s coming.” If they even have something tangible to show you, they won’t want to. Give them room to come up with something great.

5. Remember they have your best interests in mind.

This one’s important for dispute resolution. It’s true that the customer is always right, so a paying client can usually win any dispute by pulling out the “who signs the checks” card. But it probably isn’t in your best interest for you to do this.

When your designer disagrees with you, it’s his professional responsibility to explain why. Even though he does creative work, it is still ruled by logic, research, and experience. If he doesn’t want to do things the way you wanted, he probably has a reason that he thinks is aligned with the goals you expressed to him in step #1. It’s your right to ask for this reason and to spend time talking it out if you need to. But insisting on something on principle, without regard for your designer’s judgment, is a waste of his talent. He’s not your enemy; always assume that he is trying to help you.

Many computer folk were IF players back in the day. But what you may not know is that there is still an active community of people writing and distributing these games. And best of all, both the games and the interpreters are free! I don’t think the quality of these “amateur” games is any lower than the Infocom games I played in my youth. If anything, I think the genre has grown in incredible ways, and you can find some truly unique stories and play experiences in the IF archive.

So, let’s dig. I’ll tell you about a few of my favorites, and you’ll go play them. All you need is an interpreter (I recommend Spatterlight for the Mac).

Christminster
1995, Gareth Rees - Download

When I was younger I spent an entire summer vacation playing Christminster on my Mac Plus. The basic story is that you visit your brother at college only to find he has gone missing. Your investigations lead you to a curious and sometimes mystical conspiracy. The game is incredibly rich, featuring memorable NPCs and some of the best descriptive writing I have seen. Bonus points for having a (likable) female lead.

Shade
2000, Andrew Plotkin - Download

A true mind-fuck, and one of the most renowned one-room games. You start out in your apartment, looking for your tickets as you get ready to leave for desert retreat. You can’t find them, but you do notice a slow trickle of sand into the room… seemingly coming from nowhere. There is not much you can do in this game but wait for the inevitable, but you’ll do it anyway, out of hope or perhaps morbid curiosity. Truly frightening and difficult to forget.

Worlds Apart
1999, Suzanne Briton - Download

The only IF that has ever made me cry. You wake up in a strange world with no memory of yourself, and you end up on an inter- and intra-personal journey to unlock your blocked-off memories. The author has a remarkable ability to create a world both dreamlike and incredibly real, complete with specific species of plants and animals. A long game, but the ending is beautiful and satisfying. Worth playing through.

Spider and Web
1998, Andrew Plotkin - Download

This game has won a million awards and deserves all of them. On the surface, it’s a futuristic spy thriller, but the gameplay is what makes this game so unique and entertaining. The narrative is “told” entirely through flashbacks - which means it is, in a way, fatalistic. You can’t do something that didn’t actually happen, can you? It may sound strange, but play just a few puzzles and you’ll see how subtle and brilliant it is (while still being quite challenging). It also culminates in one of the most spectacular twist endings in any IF game. Probably one of the more original games you’ll find anywhere.

Lost Pig! And Place Under Ground
2007, Grunk via Admiral Jota - Download

The 2007 IF Competition winner. I wasn’t expecting to like this at all, but it won me over immediately. You play a simple orc named Grunk caught up in an underground adventure to find his lost pig. The writing and dialogue are incredibly funny, as everything is done in oafish Grunk-speak. You can also set your pants on fire. What’s not to love? Charming and amusing with memorable puzzles and an impressive array of destructive actions you can try.

…and more

So hopefully now you’re hooked and desperate for more. Don’t worry, it’s out there. Start with Baf’s guide to the IF archive (now slightly out of date), and after that try browsing through the IFDB. And there are always more great titles emerging every year for the IF Comp and the XYZZY awards. Go forth!

And yet, there is still one large (and vocal) market segment waiting for rescue from their corporate overlords. I’m talking about professional designers, photographers and artists, who continue to be slaves to Adobe and its golden goose, Photoshop.

Now, there are several independent apps out there that offer some of the functionality of Photoshop. Many of these are quite good: Acorn, Vector Designer, Pixelmator. But no graphics professional is going to use any of these apps instead of Photoshop, despite the much lower price tag. The problem is not that the apps don’t have useful features. It’s that they haven’t managed to target a segment of the population that uses Adobe software to do their job and present them an alternative with the feature set they need.

Well, I’m here to help. I’m presenting four professional user archetypes of Photoshop along with what features they would need to switch to another application. Note that they rarely overlap. Hopefully this illustrates the futility of appealing to all of these people at once. Pick one segment of users and fine-tune towards their needs.

Pierre the Painter

Pierre and others like him use Photoshop for something we call digital painting. Their typical workflow involves scanning a sketch or sketching onscreen with a tablet, then inking and painting the sketch with different kinds of brushes. They rarely if ever use vectors because they don’t have the same organic qualities as natural media, so they usually work at a very high resolution to allow for printing and exporting at a variety of sizes.

Essential features:

Brush editor: Size, shape, opacity, blending, pen pressure. The more options the better. Brushes are the crux of everything they do.

Peripheral support: Must work seamlessly with their pen tablets and scanners.

Color tools: A fully featured and prominent color palette as well as an eyedropper tool that they can easily swap to from the brush. Color proofing tools are important for artists who want to print their work.

Smudge: Aids blending, should ideally have similar options to the brush tool.

Layers: Pierre uses layers and layer blending to build up a painting from bottom to top. Changes to layers should be in the form of layer properties - in other words, you can go back later at any time and add/remove effects. (We call this non-destructive editing.)

Wish list:

Canvas texture: Natural media textures that affect brush dynamics on the “canvas.”

Line correction: Automatic line smoothing, perhaps as a brush option, would help correct a shaky hand when inking bold lines.

Where others have done it right:

Take a look at the oekaki phenomenon. Oekaki typically uses a simple web-based illustration tool and enjoys massive popularity in Japan and all over the world. Even though the feature set is relatively small, a creative artist can achieve a wide range of visual effects.

Corel Painter is also quite good, but much more complex and just as crufty as Photoshop in some ways.

Dana the Designer

Dana uses Photoshop primarily to create mock-ups and layouts, usually involving a fair amount of text. She uses vector tools to draw shapes and embellishments, typographic tools for text layout and headings, and bitmap tools to add images to her design. Assembling all the various pieces of a design into a cohesive whole means she needs to be able to work easily with many different kinds of graphic elements.

Essential features:

Robust typography tools: Design is 90% typography, so the more options here, the better. Kerning, anti-aliasing, conversion to paths - all the usual suspects.

Layers: The ability to move, group, lock, name and otherwise manipulate layers of all kinds is critical.

Layer effects: You should be able to add basic effects like stroke, drop shadow, transparency, etc. to any kind of layer. Same for blending effects. But keep it non-destructive! Anything you add should be removable later.

Basic vector tools: A pen tool, simple shapes and lines with the option for stroke/fill on any of them. Basic pathfinding tools (join, union, add/subtract) are a bonus.

Image masking: Designers often don’t require extensive bitmap manipulation (level correction, etc) but do need to fit these images into shapes in their design.

Wish list:

Grid tool: Rules and guides are a given, but additional tools to help you set on a grid with pleasing proportions would be great.

System anti-aliasing: For web designers. A text tool that emulates the system anti-aliasing you’d see on various kinds of computers.

Where others have done it right:

Fireworks (originally Macromedia, now Adobe) is a good example of an app with a boiled-down feature set for designers. It includes “lite” versions of many tools you can find in Photoshop or Illustrator. Despite not being as powerful, many designers prefer it for its relative simplicity.

Patrick the Photographer

Patrick uses Photoshop primarily for post-production work on his photographs. He imports an image from his camera, opens it at a high resolution and does level/color tweaks on the image. He may also use some limited drawing tools for clean-up.

Essential features:

Level/color correction: All the usual suspects for photograph enhancement. Non-destructive please! If you add a correction, you should be able to edit or remove it later.

Heal and clone: Used for cleaning up artifacts and photo manipulation.

Basic drawing tools: Airbrush-like drawing tools with blending options are helpful for enhancing a subject. Used often on pictures of models.

Quick mask: Easily isolate a subject or portion of the photograph for editing. The ability to have alpha properties on a selection further enhances this tool’s usefulness.

Wish list:

Automatic depth-of-field blur: Detect elements in the foreground and blur elements in the background. Useful for when you are working with low-quality photographs.

Photo browser: Interface seamlessly with the user’s library of photographs.

Where others have done it right:

Of the four archetypes, this one enjoys the best coverage on the Mac. Both Aperture and Pixelmator do a nice elegant job of working with photographs. Both of these are reasonable alternatives to Photoshop for professionals.

Ian the Illustrator

Illustrators and icon designers fall into the same group and generally need the same tools. They rely almost exclusively on vector tools to do their work, and the more powerful the better. They may work from initial sketches but otherwise rarely do hand-drawn work with a tablet.

Essential features:

Powerful vector tools: A well-designed pen tool, point/handle editors and pathfinding tools are all absolutely essential. Any path, once placed, should always be fully editable.

Gradients: Standard gradient fills are a must have, but many will also want mesh gradients or gradients that follow a path.

Export to standard file formats: One of the reasons illustrators work in vectors is so the final output can be resolution-independent. You should be able to export to a variety of standards like EPS, SVG and PDF. Bonus if you can export to AI as well.

Bitmap layer for tracing: Your canvas should be able to support bitmap layers so you can easily trace over photographs with the pen tool.

Wish list:

Icon preview: Automatically generate a view that lets you preview your icon at a number of different sizes on various backgrounds.

Hand-drawing tools: Tools that convert input from a pen tablet to paths are great, but even better when you can use different kinds of brushes that respond to pen pressure.

Where others have done it right:

Sadly, I can think of no professional-grade vector illustration tool. Some swear by the open-source app Inkscape, but I’ve never seen it used in professional circles and don’t have much personal experience with it myself.

Say what you will about Photoshop, it’s pretty amazing that one single app services all four of these archetypes. However, the flip side of that is that for any one of them, 75% of the app’s features are totally useless. Specialization and customer service is where independent software is strongest. If you can align yourself with your users, and if you listen to their needs, you will find yourself with a very willing audience. We all hate paying $1k+ to Adobe for a bunch of features we never use. We’d much rather pay $50 to an indie developer for exactly what we need.

Do you remember the popular kids? You know, the people who sat at the best lunch table, wore the most fashionable clothes, and went to awesome parties? Objectively, there was nothing particularly special about this clique, but everyone understood that they were “cool.” Coolness was in fact their salient characteristic.

What I find interesting about being cool is that it’s simply not a label you can give yourself. In this context, cool means that everyone else thinks you’re cool. Think about what that does to the locus of control when it comes to coolness. The popular kids didn’t make themselves cool - it was the rest of the school who did.

(Once in a while, someone can define a new understanding of coolness, but only if they are not trying to be cool. It is one of the great paradoxes of human interaction.)

The thing is, this phenomenon does not just apply to cool. It applies to just about any feature or characteristic you can think of to define a group of people as different from others. You can be an emo, a goth, a slut, a jock, a dork, a hipster, or whatever else, without passing some objective test that shows you have the right set of qualities to earn the label. Those are labels other people give you based on their understanding of you and the world.

This is normal and I suspect mostly understood. We all do it; it helps us formulate our big-picture worldview without spending too much processing time on individuals that aren’t immediately relevant to us. The problem is when the label starts to mean something to you as an identity.

Let’s talk about the word “nerd.” Let’s just deal with that word for a second and think about what it means. I assume that most of the people reading this article are like me and probably think of themselves as nerds. I’m also going to assume they are reasonably internet-literate and have read their share of the incredibly common treatises on what it means to be a nerd and why we’re better than everyone else (especially if you read Reddit). Perhaps the most well-known of these is Rands’ Nerd Handbook. It’s actually quite well-written, and I personally have a lot of respect for the author. But I find this particular article condescending and counterproductive. It reads like a laundry list of excuses written for people who don’t “get” nerds.

Listen. Being a nerd is just like being cool. It’s an arbitrary label originally assigned to you or people like you because you act a certain way or have certain interests. If you encounter someone who doesn’t seem to “get” you, it’s not because they need a five-page article about what you’re about. It’s because they are interested enough in you to try to get past the label and interact with you on a level that’s deeper than just “nerd” or “not nerd.” Shoving them back over the line with a huff and a mumbled “it’s a nerd thing, you wouldn’t understand” is escapist or elitist, depending on your mood that day. Take your pick — the stereotypical nerd is both.

The cool kids aren’t fundamentally different than any other clique, and neither are nerds. Yet it seems as though we keeping trying to believe that we are. It’s stupid and just as bad as telling yourself that it’s okay to act the way you do because you’re “cool.”

Embrace what you are, but don’t use a label as an excuse to stop growing. Be a good person, whatever that means to you. There are enough walls and boundaries in this world without us trying to build them higher.

I’ve been thinking a lot about this as I read Gladwell’s latest book Outliers. I won’t go into the details of what he says in the book, because it’s worth checking out on your own. But the basics of what he discovered when he studied exceptionalism can be summed up in two sentences. Experts practice a lot, and must have the opportunity to do so to become experts. And seemingly arbitrary factors such as when you were born or where you were raised can have a big impact on your success.

Suddenly the truth of the gifted program becomes clear. For some reason or another, some kids got a jump-start on their intellectual development. The top 8% were identified as efficiently as possible and accelerated. I guess that’s the best public school can do, and I’ll never fault them for that. They simply can’t help everyone. But it certainly does reveal a few things about the pattern I have observed as the lot of us age into gifted ex-children.

As you grow up, the special programs tend to disappear, and by the time you reach college it’s assumed that you are capable of finding something suitably challenging on your own. Additionally, your exceptional intellectual growth as a child has probably slowed down and the other students are catching up to you. You may even be starting to see them pass you. Just like that, the gifted label is gone. Children are gifted. Adults are ambitious, hard-working, and driven.

So what happens to you now? The understanding that you are somehow different from the people around you has already become a part of your subconscious. You might struggle to fill the void of the “gifted” label with something else. “Nerd” or “geek” maybe. You might feel pulled towards engineering and computer science, where the myth of exceptionalism still thrives. Or maybe you just let it go quietly, and mourn the death of your childhood potential. It was nice while it lasted.

But the fact is, you were never gifted. No one is. No one is deemed worthy of some special gift that makes them better than everyone else. And the myth that you were may - may - have prevented you from doing the things that you needed to do to become truly great. Like working hard. Seeking challenges. And not taking anything on faith.

I spent four years in college doing more or less nothing and wasted every good educational opportunity I had because I believed I was too good for it. Because it’s hard to hear that getting good takes work - no more, no less. I’m lucky in that I have a singular love for what I do that kept me plugging away at it, but I still struggle with the notion of hard work and practice. I get angry at myself when I don’t do something perfectly the first time. I have to coach myself to keep trying. It gets better slowly but only through extreme, sometimes painful awareness of the fact that I am not gifted. No one is.

But in a way it’s kind of nice. I always felt guilty, that I never deserved whatever “gift” I got. Now I know that it’s just a frame of mind — and that can be taught. And where there are people willing to teach, we are all gifted.

I think the problem many people experience when trying to learn CSS is that they jump straight into the hard stuff (layouts, box model, browser compatibility) without learning the basic structure and behavior of the language. Here I’m just going to present you with a simple document and show you how to style the text on the page using CSS. You’ll learn about the different kinds of selectors and how inheritance behavior works, and it will hopefully provide you with a framework for learning the more advanced stuff.

It’s easier than you think. So leave your mental blocks at the door and come on in.

Style: It isn’t just for the design kids

So you have a document. Let’s call it boring.html. Go ahead and copy this into a text editor of your choice:

<html>
<head>
<title>Boring-ass document.</title>
</head>
<body>
  <h1>Don't mock my pain!</h1>
  <h2>by a webpage</h2>
  <p>I know I'm a boring ol' document.</p>
  <p>But surely you have room in your life for <a href="#">someone like me?</a></p>
  <p>I'm just <em>so</em> lonely...</p>
  <p>Will you go out with me?</p>
</body>
</html>

Pretty straightforward, huh? If you don’t know what you’re looking at, start here. Come back when you’ve mastered the art of marking up a bunch of emo rambling with HTML. (LiveJournal is a good place to practice this.)

Now then. Open the page up in a browser and you’ll see why it’s so down in the dumps. Looks pretty crappy, doesn’t it? A little bit Class of ‘96. I’m not hating on Times New Roman, but a new font would go a long way towards getting this guy a date to the prom.

If I said you had a great <body>, would you hold it against me?

Go ahead and stick a style tag in the head of your document. That’s where we’ll house our CSS. (You can also link to an external CSS file, which is great for keeping the same styles across many documents. But we’re going to keep it simple for now.)

So we want to change the font across our document. We want this change to be global, right? Don’t want to see Times New Roman creeping in where it’s not wanted. It’s a good thing we’re using CSS for this, because this grand, sweeping vision can be accomplished with one line in your style tag.

<style>
body {
  font-family: Arial, sans-serif;
}
</style>

Save. Refresh. Ta-da! You should see that all of the body text has changed to Arial. Now then, what exactly did we do?

As you probably already know, an HTML document is essentially a tree of nested nodes. p tags are nested in the body tag which is nested in html. The default stylesheet applied by browsers is pretty intelligent about when to inherit CSS styles from parent nodes. An attribute like font-family or font-size will be inherited down through the tree, so if you apply font styles to the body tag you will see those styles applied to the entire document. Neat, huh? You will usually set your base font styles on the body tag for this reason.

This is called a type selector.  You can do this with any HTML tag: body, p, em, span, td, div. The sky’s the limit!

…You’re just not my type

So let’s go back to our body styling. The font size is a bit big for my tastes, so let’s bring that down a little. (Now, I should note that there are a great multitude of ways to size text, including a few that are more elegant than what I’m showing you here. For the sake of your understanding and your sanity, I’m going to sidestep the issue for now and simply use pixel values. If you really want to know the gritty details, thar be dragons beyond ye hyperlinke.)

<style>
body {
  font-family: Arial, sans-serif;
  font-size: 13px;
}
</style>

Hey, look at that. Much better. “But Anne,” you whimper. “Why didn’t the h1 and h2 inherit the font-size property and become 13px as well?” Worry not, youngling. I said the default stylesheet employed by the browser was pretty smart (just like you). It inherits the base font size, then sizes the headers with relative values. h1 is 180% of the base size, h2 is 160%, and so forth. This way the visual hierarchy of the headers is preserved, even when you change the base font size. And all without you having to individually define each one. Nifty, eh?

Play around with this a bit. Try different tags and attributes and see what happens. Be amazed at how pretty you can make this page without ever having to touch a class selector. (We’ll get to those if you haven’t heard of them. But chances are you have, and they annoy you.)

Here’s what I came up with:

<style>
body {
  font-family:Arial, sans-serif;
  font-size:13px;
  padding:30px;
}
h1 {
  border-bottom:1px dashed #ccc;
}
h2 {
  font-style:italic;
  font-size:14px;
}
a {
  color:#CC6699;
}
</style>

Hey, this isn’t so hard!

The one time in your life class will actually be useful

“But Anne,” you whine. “This is all well and good, but what if I don’t want to change every p tag on the page to style one block of text?” You astute observer you. It’s very true that sometimes you need to apply a style to a specific object or element. Why don’t we give that a try and see how it’s done? For this we’ll bring out the power of the class selector.

Our emo web page is looking pretty good, but it needs more drama. Let’s take that last paragraph and dress it up a little. If we want to isolate a section of text or a specific tag (instead of all tags of that type), we have to assign a class to it in the HTML. Let’s go back to our markup and fix it up:

<html>
<body>
  ...
  <p class="proposition">Will you go out with me?</p>
</body>
</html>

You can name your class whatever you want, but remember what you called it when you return to your CSS declarations. Go ahead and add the class selector the same way you’d add a type selector, only this time preface the name with a period to indicate its classiness.

.proposition { }

The styles you define for .proposition will apply to all elements you add the class=”proposition” attribute to. In this case, it’s just one paragraph, but it could be any number of objects on the page. Classes are pretty laid back that way.

So now that we have this in place, we can style that paragraph independently from the other p tags on the page. Give it a shot.

.proposition {
  color:#3399FF;
  font-size:18px;
  font-weight:bold;
}

Pretty radical. There’s no way this guy’s going home alone now.

I don’t care how big your mustache is, I’m gonna have to see some ID

There is one other kind of selector you can use to style a specific element (or group of elements, if you remember inheritance), the ID selector. In this case the CSS looks for the attribute id on the HTML tag. On the surface level it looks and behaves a lot like a class. The difference is that an ID must be unique to the document — There Can Only Be One. Therefore, IDs are usually reserved for high-level elements that only appear once on any given page. Most commonly these are layout elements like header, footer, navigation, etc. Since our emo page doesn’t have much of a layout, we don’t really have a need to use IDs here, but for demonstration’s sake let’s change the “proposition” paragraph from a class to an ID selector.

<html>
<body>
  ...
  <p id="proposition">Will you go out with me?</p>
</body>
</html>

In the CSS you’ll have to change the style declaration from .proposition (which denotes a class) to #proposition (which denotes an ID).

#proposition {
  color:#3399FF;
  font-size:18px;
  font-weight:bold;
}

Everything should look exactly the same. When to use IDs and when to use classes is a tricky question that is best learned with experience. The more complex your documents get, the more you’ll have to think ahead and plan the structure of your data. The goal is to make your life as easy as possible (CSS is a lazy designer’s best friend). In general, you will use classes for most of your actual styling. IDs really shine when you assign them to div tags that hold your content in neat little buckets. Then you can make good use of descendant selectors - a bonus, super-secret ninja technique that allows you style types and classes differently within the different buckets. For example, these two rules will make the a tags in the header black, while the a tags in the footer are white.

#header a {
  color:#000000;
}
#footer a {
  color:#FFFFFF;
}

And these could both be different from the global a color, which could be anything. It could even be puce.

A note about good design

One of the trickiest things to learn about CSS is how to manipulate selectors, the cascade, inheritance, and specificity to isolate portions of your HTML document while keeping the document itself as bare-bones as possible. It’s true that this kind of thing works:

<p class=”main”>Marco de Polo was a most amazing fellow. He wrote many books, including
<em><span class=”gray”>Summer Fun, or How To Ensure Every Child Ever Knows Your Name For The Rest Of Time</span></em>.</p>
<p class=”footerline”>Copyright 2008, Not True Magazine<p>

You can simply define all those specific classes in your styles and be done with it. But both your HTML and your CSS will bloat, it will be difficult to maintain, and you will too often find yourself wondering what the .littleblue class was for.

If you’re smart about things, you can reduce your HTML to this:

And you can achieve exactly the same amount of control over the different elements in the document with CSS. p tags within the #content block have a certain style. em tags are colored gray. The #footer block has smaller text and a border on top. Easy to do, easy to read, easy to change.

Go ye forth unto the world of the web!

I’ve really just scratched the surface here, but you should now have at least a fundamental idea of what you’re working with when you use CSS. If you want to learn more complex techniques, like using CSS for layout or positioning, there is a wealth of excellent tutorials out there. Here are just a few:

Starting with HTML + CSS (W3C tutorial)
CSS-Discuss (Wiki with many tips and tricks)
Quirksmode (Compatibility charts and reference for advanced CSS)

And the next time some hotshot web 2.0 designer is bragging about the CSS on his blog, you can nod sagely and say “CSS? Yes, I know a little.” And then you can splash your drink on his trendy glasses. Do it for me?