BlogmyQuery – BMQ

Endless layers in Photoshop. Overstuffed image folders. That jQuery plug-in that has 12 files associated with it. Hundreds or thousands of individual pieces go into making a website. No wonder we go off the deep end when we can’t find a closing div — er, section tag. We work with a ridiculously large number of things, and how we organize them (or choose not to) is often left to personal preference. But our messy habits result in confusion for the designer or developer who inherits your work.

Does it really need to be this way?

Us Vs. Them?

The great divide between designers and developers is well documented. Designers complain when developers would rather backgrounds not have any images. Developers gripe when given a Photoshop document with missing fonts. If those were the only problems we face, we’d be thrilled.

Unfortunately, not every studio is a breeding ground for pixel-crafting harmony. Sometimes designers work on one floor, developers on another. If you asked a good number of them, they’d say they were content with that arrangement. No wonder communication breakdowns are so frequent. The only brains we have to pick are those of our fellow designers or fellow developers, with little crossover it seems. Proximity doesn’t always improve proficiency, but don’t tell that to bees.

The essence of teamwork. You’ve heard of designer bees and developer bees, right?

Web designers have the unique ability to communicate through layout, shape, typography and, ultimately, simplicity. That same discipline must be exercised internally when sharing their artwork with colleagues — using, coincidentally, those same tools. As challenging as it may be, we can bring sophistication to our interfaces in Photoshop, so that our artwork achieves clarity through order. Just as our client has a target audience, we should also be considerate of the internal audience that uses our work.

We’re nibbling at the edges of websites that deliver a happy marriage between remarkable aesthetic and solid function. Seeing some websites already achieving that is exciting. But to fill the Web with more of it, designers and developers will need to combine their skills in even more proficient and efficient ways.

A Call to Arms

Let’s start a revolution that has less to do with being nice and more to do with holding one another to higher standards. Let’s get caught up not in the sexy pixels of tomorrow, but rather in attention to detail in our workflow. What if we made it easier for others to actually use and edit our work? Yes, my friends: let’s start an etiquette revolution.

Make better websites, not war. Fist bumps, man hugs and peace signs, people.

More Than Just Chivalry

Why etiquette? I agree: at first it does sound stuffy and time-consuming, especially if what we’ve done has always worked. The client won’t see the etiquette, we’ll still get paid, and all is well. But let’s reason here: whether you’re in a group or creating websites all by yourself, the level of detail in your craft reflects how much you value your profession and should be apparent in the finished product.

Even so, internally, inheriting messy artwork can be a point of contention for developers. A design could be the most beautiful and useful thing in the world, but if it’s not practically built, it will waste precious time and money. All of the investigative work of the developer in posing questions to the designer about what’s confusing in their PSD should not have been necessary; the work should have been clear from the beginning, and the designer as organized as ever.

Can both the individual and group benefit from some good ol’ fashioned etiquette?

Personal Gain

Here’s a plain illustration of my point. Think of the designer or developer whose work inspires you most. Imagine you had the opportunity to work with them on a project. They got the ball rolling with a PSD or a directory of coded files, and handed it off to you for editing. How surprised would you be if the layers were unnamed? Or the code wasn’t indented, all smushed together? You likely wouldn’t see that, right? Every layer, every line of code reflects on who they are.

Even if you’re a one-person shop, holding yourself to high standard of organization has always been good practice. By doing so, you make less work for yourself when you need to go back to edit something. More importantly, if you were ever to pass off a PSD to a developer or client, you’d want it to speak to your attention to detail and professionalism.

(Aside to Fireworks users: I’m about to make a ton of references to PSDs, so feel free to substitute “Fireworks PNGs.�)

Collective Gain

Have you ever inherited a PSD from a designer and, on seeing the missing fonts, unnamed layers and myriad of masks, knew you were in for about four hours of work just to get started? No? Must be just me, then.

Indulge me, then. Those hours, even if few, are time spent by someone less familiar with the file than the designer and, thus, unnecessary. Our job as Web designers is to run a tight PSD ship. In theory, I should be able to organize my PSD in a fraction of the time that someone else could, just because of my familiarity as the designer. The result? An easier process for the inheritor and less time billed for the company.

Equally important, how much less disgruntled would developers be if designers handed over their work without so many blunders? How many projects would come in under budget? How about world peace? Too far?

Let’s apply the same clarity that we bring to the canvas to the “Layers� panel, too. Now we’re on our way to higher standards.

Let’s look at some recurring issues and see how to resolve them.

Common Mistakes

Didn’t Put the File on the Server

Just your luck. A deadline is fast approaching, and you’ve set aside a good amount of your day to plough through editing a PSD that a fellow designer has just finished working on. Problem is, you can’t get to it because it’s sitting on their desktop instead of the server. How convenient. And doesn’t this always happen when they’re on vacation?

If you’re like me, your short-term memory could use a reminder at 5:00 pm daily.

The remedy
Depending on the hardware, designers should work directly off a networked server, and use their computers only for local back-ups. Alternatively, you could set an alert (in iCal or your app of choice) at the end of each day to remind you to commit your files to a shared spot.

Unnamed or Unused Layers

The developer didn’t expect to need a machete to use your file. Thicker than the Amazon rainforest, your PSD has layers-a-plenty, some even with such distinguished names as “Layer 0 copy.�

The remedy
Name layers and make folders as you go in Photoshop. Yes, it takes discipline, but it’s easier than having to go back to rename and delete after the fact. Use folders, too: they’re there for a reason.

Distinguishing “Layer 0� from “Layer 1� is hard. Let’s use our words.

Unpurchased Stock Photos

Hello there, Mr. iStockphoto watermark. Curious to see you in the final PSD. If we could have only mustered the $3 for credits, I could have gotten rid of you myself.

The remedy
For everything, proofread, proofread, proofread. Your text and your images.

Ouch! See what happens when we forget to buy the stock?

Inaccurate File Names

You look confused, developer. Clearly, you should be using website_LATEST-v3_FINAL.psd instead of website_USE_THIS_ONE_ULTIMATE.psd.

The remedy
One file, named accurately. Archive the rest if you think you might need to go back to the third of your nine iterations for some reason.

No amount of highlights and descriptions is as good as maintaining a single file and archiving the rest.

Missing Fonts

Does this sound familiar?

The following fonts are missing for text layer “myFont, notYours�:

Guilty Culprit Extra Condensed

Font substitution will occur. Continue?

Ain’t that something? Confirming wouldn’t be a good solution in this case, because then the developer would be doing some guesswork to match the font that the designer presumably has more knowledge of. This usually happens when a font needs to be used as image text, so a straight substitution might not be an option.

The remedy
Ideally, the designer would be considerate enough to include the (licensed) font somewhere within arm’s reach of the PSD. Alternatively, the studio could install common fonts on all production computers. Apps like Fontcase, Suitcase Fusion and Linotype FontExplorer X will manage your fonts for you.

Inconsistent or Inaccurate Content

If I’ve learned anything from working with developers, it’s that they don’t like to do things twice. Rightfully so. Whether it’s unpurchased stock photos, inconsistent type sizes or inconsistent colors, when they’re not caught the first time around, images need to be reproduced and code needs to be altered. And sadness overcomes all those involved.

The remedy
Develop a brand guide if one doesn’t exist, and have someone check your work before you hand it off. Think of it as quality control.

Tips And Tools

Name Files For Function

Be descriptive but practical when naming PSDs, JPEGs, etc. Something like header_bg.jpg is a little more indicative than blue_box.jpg, isn’t it?

Conserve File Size

I may sound like an old curmudgeon, but file size is still pertinent today. When exporting images, remember that a background at 80 quality will still look close to one at 100 quality but will likely be at least 33% smaller in size. Everyone still likes pages that load quickly, even if our Internet connection speeds have increased over the years.

Snap to Pixels

When I’m cutting up a PSD, one of the most common things I have to negotiate are those 1-pixel semi-transparent lines on the outer edges of shapes. The best way to remove them is pretty well cloaked in the vastness of Photoshop’s settings. When choosing a shape to draw, such as a rectangle, look towards the top of the screen at a row of those same shapes, with an arrow at the end of the row. Click that arrow, and you’ll see more options. Check the box “Snap to Pixels,� and you’ll see that the shape you draw will have much more precise edges.

Use Version Control

A fantastic way to cut down on the chaos of sharing files is to use a version-control system such as Git or Subversion. You designers, don’t feel that only developers can geek out about this. Using some type of revision control for our PSDs and other artwork files is equally important, because those files tend to get revised and transferred quite a bit. Version control is crucial when multiple people are working on front-end and back-end development, because overwriting someone’s work when uploading your own is all too easy.

Communicate

The saying “Communication goes both ways� never meant so much as it does here. Designers should freely communicate their decisions to developers, who themselves should express their concerns about programming said decisions. Nothing new, but it just doesn’t happen as openly as it should. If you consult with each other frequently, you’re bound to have more etiquette.

Be Teachable

Part of practicing good Web design manners is having the humility to know you’re not the best at what you do (except for one of you out there, Mr. Best Web Designer). Be open to being educated by other designers, developers and fantastic websites such as Think Vitamin Membership and Method & Craft. You’ll gain the respect of your co-workers for taking the initiative to improve your skill set.

Websites like Method & Craft are invaluable resources in your quest to become a Web design hero.

Implement Standards

The best way to force your Web team to adhere to standards is to come up with a list of best practices, on that holds each person accountable for their PSDs, HTML, CSS and beyond.

Isobar has done some of the work for you with its Code Standards and Best Practices.

The Photoshop Etiquette Manifesto for Web designers was created to give both beginner and seasoned designers a crash course in keeping PSDs organized and understandable for others. With helpful visual comparisons of “Do this� and “Not this,� the website serves as both an educational resource and a checklist. With the crown of “Layer Mayor� at stake, why not take more pride as the resident PSD pro in your office?

Setting some guidelines in your workplace is key to accountability and consistency.

Moving Forward

Having said all this, it’s encouraging to see more designers learning and understanding the process of developers, and vice versa. Some have done it out of necessity, such as freelancers who are hybrid designers/developers. Others have done it in order to understand their co-workers better, in the hope of a better product.

Hopefully, it’s become apparent that being on the same page, especially in Web development, is crucial to success. What are you doing to emphasize a high standard and clarity in your own craft and to make your team’s job easier?

(al)

---

© Dan Rose for Smashing Magazine, 2011.

I think a lot of us CSS authors are doing it wrong. We are selfish by nature; we get into our little bubbles, writing CSS (as amazing as it may be) with only ourselves in mind. How many times have you inherited a CSS file that’s made you say “WTF� at least a dozen times?

(Image: Toca Boca)

HTML has a standard format and syntax that everyone understands. For years, programmers have widely agreed on standards for their respective languages. CSS doesn’t seem to be there yet: everyone has their own favorite format, their own preference between single-line and multi-line, their own ideas on organization, and so on.

A New Way of Thinking

Recently, I have begun to think that CSS authors could take a leaf from the programmers’ book. We need to write CSS that others can understand and use with ease. Programmers have been writing sharable code since day one, and it’s high time that CSS be written with as much organization and openness.

In writing inuit.css and working on a huge front-end framework at my job, it has become more apparent to me that writing code that can be easily picked up by others is extremely important. I wouldn’t say that I’ve nailed everything yet, but I’ll share with you some things that I think are vital when writing code, specifically CSS, that will be used by others.

First, the reasoning: my number one tip for developers is to always code like you’re working on a team, even if you’re not. You may be the only developer on your project right now, but it might not stay that way:

• Your project could be taken to another developer, agency or team. Even though this is not the best situation to find yourself in, handing over your work smoothly and professionally to the others is ideal.
• If you’re doing enough work to warrant employing someone else or expanding the team at all, then your code ceases to be yours and becomes the team’s.
• You could leave the company, take a vacation or be off sick, at which point someone else will inherit your code, even if only temporarily.
• Someone will inevitably poke through your source code, and if they’ve never met you, this could be the only basis on which they judge your work. First impressions count!

Comments Are King!

One thing I’ve learned from building a massive front-end framework at work and from producing inuit.css is that comments are vital. Comments, comments, comments. Write one line of code, then write about it.

It might seem like overkill at first, but write about everything you do. The code might look simple to you, but there’s bound to be someone out there who has no idea what it does. Write it down. I had already gotten into this habit when I realized that this was the same technique that a good friend and incredibly talented developer, Nick Payne, told me about. That technique is called “rubber-duck debugging�:

… an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line by line, to the duck.

Write comments like you’re talking to a rubber duck!

Good comments take care of 99% of what you hand over and — more importantly —  take care of your documentation. Your code should be the documentation.

Comments are also an excellent way to show off. Ever wanted to tell someone how awesome a bit of your code is but never found the chance? This is that chance! Explain how clever it is, and just wait for people to read it.

Egos aside, though, comments do force you to write nicer code. I’ve found that writing extensive comments has made me a better developer. I write cleaner code, because writing comments reminds me that I’m intending for others to read the code.

Multi-Line CSS

This issue really divides developers: single-line versus multi-line CSS. I’ve always written multi-line CSS. I love it and despise single-line notation. But others think the opposite — and they’re no more right or wrong than I am. Taste is taste, and consistency is what matters.

Having said that, when working on a team, I firmly believe that multi-line CSS is the way to go. Multi-line ensures that each CSS declaration is accounted for. One line represents one piece of functionality (and can often be attributed to one person).

As a result, each line will show up individually on a diff between two versions. If you change, say, only one hex value in a color declaration, then that is all that needs to be flagged. A diff on a single-line document would flag an entire rule set as having been changed, even when it hasn’t.

Take the following example:

Above, we just changed a color value in a rule set, but because it was a single-line CSS file, the entire rule set appears to have changed. This is very misleading, and also not very readable or obvious. At first glance, it appears that a whole rule set has been altered. But look closely and you’ll see that only #333 has been changed to #666. We can make this distinction far more obvious by using multi-line CSS, like so:

Having said all this, I am by no means a version-control expert. I’ve only just started using GitHub for inuit.css, so I’m very new to it all. Instead, I’ll leave you with Jason Cale’s excellent article on the subject.

Furthermore, single-line CSS makes commenting harder. Either you end up with one comment per rule set (which means your comments might be less specific than had they been done per line), or you get a messy single line of comment, then code, then comment again, as shown here:

With multi-line CSS, you have a much neater comment structure:

Ordering CSS Properties

Likewise, the order in which people write their CSS properties is very personal.

Many people opt for alphabetized CSS, but this is counter-intuitive. I commented briefly on the subject on GitHub; my reasoning is that ordering something by a meaningless metric makes no sense; the initial letter of a declaration has no bearing on the declaration itself. Ordering CSS alphabetically makes as much sense as ordering CDs by how bright their covers are.

A more sensible approach is to order by type and relevance. That is, group your color declarations together, your box-model declarations together, your font declarations together and so on. Moreover, order each grouping according to its relevance to the selector. If you are styling an h1, then put font-related declarations first, followed by the others. For example:

#header {
   /* Box model */
   width: 100%;
   padding: 20px 0;
   /* Color */
   color: #fff;
   background: #333;
}

h1 {
   /* Font */
   font-size: 2em;
   font-weight: bold;
   /* Color */
   color: #c00;
   background: #fff;
   /* Box model */
   padding: 10px;
   margin-bottom: 1em;
}

Ordering CSS Files

Ordering CSS files is always tricky, and there is no right or wrong way. A good idea, though, is to section the code into defined groups, with headings, as well as a table of contents at the top of the file. Something like this:

/*------------------------------------*\
   CONTENTS
\*------------------------------------*/
/*
MAIN
TYPE
IMAGES
TABLES
MISC
RESPONSIVE
*/

/*------------------------------------*\
   $MAIN
\*------------------------------------*/
html {
   styles
}

body {
   styles
}

/*------------------------------------*\
   $TYPE
\*------------------------------------*/

And so on.

This way, you can easily read the contents and jump straight to a particular section by performing a quick search (Command/Control + F). Prepending each heading with a dollar sign makes it unique, so that a search will yield only headings.

The “Shared� Section

All CSS files should have a section for sharing, where you tether selectors to a single declaration, rather than write the same declaration over and over.

So, instead of writing this…

/*------------------------------------*\
   $TYPE
\*------------------------------------*/
h1 {
   font-size: 2em;
   color: #c00;
}

h2 {
   font-size: 1.5em;
   color: #c00;
}

a {
   color: #c00;
   font-weight: bold;
}

#tagline {
   font-style: italic;
   color: #c00;
}

… you would write this:

/*------------------------------------*\
   $TYPE
\*------------------------------------*/
h1 {
   font-size: 2em;
}
h2 {
   font-size: 1.5em;
}
a {
   font-weight: bold;
}
#tagline {
   font-style: italic;
}

/*------------------------------------*\
   $SHARED
\*------------------------------------*/
h1, h2, a, #tagline {
   color:#c00;
}

This way, if the brand color of #c00 ever changes, a developer would only ever need to change that value once. This is essentially using variables in CSS.

Multiple CSS Files For Sections, Or One Big File With All Sections?

A lot of people separate their sections into multiple files, and then use the @import rule to put them all back together in one meta file. For example:

@import url(main.css)
@import url(type.css)
@import url(images.css)
@import url(tables.css)
@import url(misc.css)
@import url(responsive.css)

This is fine, and it does keep everything in sections, but it does lead to a lot more HTTP requests than is necessary; and minimizing requests is one of the most important rules for a high-performance website.

Compare this…

… to this:

If you section and comment your CSS well enough, using a table of contents and so forth, then you avoid the need to split up your CSS files, thus keeping those requests down.

If you really want to break up your CSS into multiple style sheets, you can do that — just combine them into one at build time. This way, your developers can work across multiple files, but your users will download one concatenated file.

Learning From Programmers

Programmers have been doing this for ages, and doing it well. Their job is to write code that is as readable as it is functional. We front-end developers could learn a lot from how programmers deal with code.

The code of my good friend (and absolutely awesome chap) Dan Bentley really struck a chord with me. It’s beautiful. I don’t understand what it does most of the time, but it’s so clean and lovely to look at. So much white space, so neat and tidy, all commented and properly looked after. His PHP, Ruby, Python or whatever-he-decides-to-use-that-day always looks so nice. It made me want to write my CSS the same way.

White space is your friend. You can remove it before you go live if you like, but the gains in cleanliness and readability are worth the few extra bytes (which you could always cut back down on by Gzip’ing your files anyway).

Make the code readable and maintainable first and foremost, then worry about file size later. Happy developers are worth more than a few kilobytes in saved weight.

Code Should Take Care Of Itself

So far, we’ve talked about people maintaining your code, but what about actually using it?

You can do a number of things to make the life of whoever inherits your code much easier — and to make you look like a saint. I can’t think of many generic examples, but I have a few specific ones, mainly from inuit.css.

Internationalize Your Selectors

Inuit.css has a class named .centered, which is spelt in US English. CSS is written in US English anyway, so we’re used to this; but as an English developer, I always end up typing UK English at least once in a project. Here is the way I have accounted for this:

.centred, .centered {
   [style]
}

Both classes do the same thing, but the next developer doesn’t have to remember to be American!

If your selectors include words that have US and UK spelling variants, include both.

Let the Code Do the Heavy Lifting

Also in inuit.css, I devised a method to not need class="end" for the last column in a row of grids. Most frameworks require this class, or something similar, to omit the margin-right on the last item in a list and thus prevent the grid system from breaking.

Remembering to add this class isn’t a big deal, but it’s still one more thing to remember. So, I worked out a way to remove it.

In another major inuit.css update, I removed a .grid class that used to be required for every single grid element. This was a purely functional class that developers had to add to any <div> that they wanted to behave like a grid column. For example:

<div class="grid grid-4">
    …
</div>

This .grid class, in conjunction with the .grid-4 class, basically says, “I want this <div> to be a grid item and to span four columns.â€� This isn’t a huge burden on developers, but again, it’s one more thing that could be removed to make their lives easier.

The solution was to use a regex CSS attribute selector: [class^="grid-"]{}. This says, “Select any element whose class begins with .grid-,â€� and it allows the developer’s mark-up to now read as follows:

<div class="grid-4">
    …
</div>

CSS attribute selectors may be less efficient than, say, classes, but not to the point that you’d ever notice it (unless you were working on a website with massive traffic, like Google). The benefits of making the mark-up leaner and the developer’s life easier far outweigh the performance costs.

Do the hard work once and reap the benefits later. Plus, get brownie points from whoever picks up your project from you.

Be Pre-emptive, Think About Edge Cases

An example of being pre-emptive in inuit.css is the grid system. The grids are meant to be used in a series of sibling columns that are all contained in one parent, with a class of .grids. This is their intended use. But what if someone wants a standalone grid? That’s not their intended use, but let’s account for it should it happen.

Note: inuit.css has changed since this was written, but the following is true as of version 2.5.

Another and perhaps better example is the 12-column grid system in inuit.css. By default, the framework uses a 16-column grid, with classes .grid-1 through .grid-16 for each size of column.

A problem arises, though, when you attempt to switch from the 16-column system to the 12-column system. The .grid-15 class, for example, doesn’t exist in a 12-column layout; and even if it did, it would be too big.

What I did here was to make .grid-13 through .grid-16 use the exact same properties as .grid-12. So, if you switch from a 16-column layout to a 12-column one, your .grid-13 through .grid-16 would’t break it — they would all just become .grid-12s.

This means that developers can switch between them, and inuit.css will take care of everything else.

Pre-empt the developer’s next problem, and solve it for them.

That’s It

There you have it: a few humble suggestions on how CSS authors can write code that is perfect for other developers to inherit, understand, maintain, extend and enjoy.

If you have any other tips, do please add them in the comments.

(al)

---

© Harry Roberts for Smashing Magazine, 2011.

For years the web design and development communities have had an enemy amongst the ranks. A wolf in sheep’s clothing, parading through the communities as a friend of the game, when really it is more of a foe. Perhaps a well intentioned foe, as some might argue, but a foe nonetheless. That enemy goes by the name of Spec Work. We see posts popping up all over the web condemning this community damaging practice, yet still it persists. And what is worse, is that it there are still so many in the community buying into the lie this backward business model projects and perpetuates about it being good for the community.

A No!Spec poster from designer Jeff Andrews

After years of dedicated sites and services springing up around the web to facilitate this selling out of the community, it is easy to see why so many struggling designers and developers see these contests as opportunities, and not as what they truly are. Part of the reason they are struggling. So today we are going to take a hard look at the downsides and damaging impacts of Spec Work on the design and development community in hopes to open a few more eyes to how much partaking in these communal contests for work do more harm than they do good.

The Breakdown

If you are unfamiliar with how this beast operates, we will break it down for you briefly in this first section. The Spec work model is one that relies on the ‘spirit of competition’, where a prospective client comes to the community with an ‘opportunity’ to showcase their skills and potentially get paid for the work that they complete. On the surface it seems like a fairly simple, lighthearted and fun approach that works out well for all parties involved. When in reality, it doesn’t.

A No!Spec poster from designer Rob Gough

In this model we have professionals being asked to use their time, training, and developed skills for free. Time, training, and developed skills that they could be directing towards a more promising and prosperous job. And we hear examples all the time about how you wouldn’t ask this of any other business professional, but that is really not the point. Many of us know that several businesses and handfuls of those outside the field of design undervalue it. So it should come as no surprise that we would be asked to give so much of ourselves so freely. The surprise is that there are so many in the design and development community who are willing to participate.

A Labor of Love Alone

Most of us who chose design or development as a profession do so because we enjoy it. It truly is a labor of love. However, for some, this translates into the fact that the love of doing it is all we should need to work for them. And this Spec work model is simply an evolution of that mindset, as there are a number of these so-called contests that end unresolved because the person hosting found nothing that they liked ‘even after all of their encouraging notes prompting revision after revision spoke otherwise). But the dream is not to just do what we love, there is more to it than that. We seek to make a living doing what it is we love, and Spec work is making that more difficult than ever.

The Impact on the Community

If we want to see the negative impacts that this model is leaving in its wake we need only examine a few ways that it has effected the fields so far. After all, if this model is being represented as being beneficial for the design and development community, and it is through this misguided marketing that so many buy into it, then a look at the true impact could shed light on why there are so many who are avidly anti-spec work. So many that an entire movement has sprung up to rally the community against this model.

The Competitive Market

With so many qualified professionals having chosen to populate this field of business, the market is a fairly competitive one. Just like with nearly every field of business, you have each designer and developer vying for potential clients over the rest of the field. All looking for that proverbial edge that will get them favored over the others. But there is still an artistry behind it which elevates the industry and causes everyone to step up their game. Reflecting positively on the field as a whole. The Spec model amps up the competitive aspect of the market, so that it becomes overly so, without the rest of the benefits this competition usually yields rising in balance.

Lowers the Bar

Not only does this competitive imbalance tend to lead to less than perfect end products, but it also can cause the perception of the field to get driven down from those outside it. Given that these contests undercut the overall design process by hugely shortchanging the project brief and research aspects of it, the work that gets churned out for the contest holders does not measure up to our best work. And with the highly publicized nature of these competition sites and services there are many who see this as indicative of the entire field’s potential. They see these contests and set all of their expectations of the industry based on this model. And what exactly is this saying to them?

A No!Spec poster from designer Von Glitschka

Furthermore, these contests can also leave somewhat of an less than professional taste in the outsider’s mouths. Giving them the impression that the entire field as a whole is still in the the professional infancy stages, and not growing into a fully grown industry demanding to be taken seriously. If we allow our business to determined by these games, then what incentive do they have to treat us as professionals? It is hard enough to get those outside the field to take our profession seriously because our work is steeped in creativity. Creative’s contributions are often undervalued and underestimated as it is.

Reasonable Rates?

As those outside the field begin to let their perceptions of the industry slip, witnessing these contest results and in turn discounting our processes more so than before, the rates that the rest of the community try to charge for their time and work no longer seem reasonable to them. Suddenly it seems as though those charging what should be seen as reasonable rates are looked at as greedy overchargers. And the mindset gets pushed that if there are those willing to do the work that cheaply, then those trying to scale their prices above those more minimal contest rates are doing for no other reason than avarice. In their eyes, a large portion of the community is attempting to gouge them with the pricing model.

And if the rest of us try to explain the rates by breaking down what all goes into the processes and overall time and effort involved, then we are looked at as being dishonest. After all, they can watch the results of these contests come in and argue that our quoted lengthy and involved processes are unnecessarily so. They get to then point to these examples of Spec work as indicative of the industry and say, but it obviously does not take all of that work and planning to complete the task at hand. Because for those outside the industry, they do not see any difference between those contest entries and their potential end result.

Declining Demand

And where does that road lead us? To a bit of declining demand for those wishing to not partake in the Spec work system. Given that so many see this model as a viable solution to any design and development needs, when they find themselves with needs of their own, which direction are they likeliest to turn? They will opt to hold a contest and watch the slew of puppets dance for them with the pull of a single string. So how are the rest of us in the industry supposed to compete? As this leads to less actual paying work being available as more of the potential client base align themselves with this bastardization of the design and development system.

When Scales Tip Beyond Balance

Welcome to the design and development new world order. Look around today and you can see that the scales are already tipping out of balance. When the Spec model was introduced, it was seemingly done so as a cheap alternative for those small businesses and sole proprietors who did not have the financial prowess of their big business counterparts. And so it was initially looked upon as a path of accessibility to the industry, but that is no longer the case as the model reaches beyond these smaller businesses these days. Suddenly we have big companies and businesses who can afford to pay some of the best designers and firms out there, holding competitions to get their design work done rather than handling it the professional way.

Another No!Spec poster from designer Von Glitschka

Facebook recently ascribed to this Spec approach when they decided to host an architectural and urban development contest for their new corporate headquarters that they want to build in New York. So a company that is worth as much as Facebook sees no harm in asking hundreds of professionals to give of their time and expertise freely. And they can do so because of their status. People believe that just by being associated with Facebook in some fashion that they will be looked after and safeguarded against being taken advantage of. Or what is worse, they do not care that they are being taken advantage of because of who is doing the taking.

The Huffington Post also opted for this approach in a recent logo redesign competition. With businesses this large taking part in the devaluing of the industry, it just further demonstrates to others that this is how designers and developers work. It is a labor of love and we are expected to bite any bullet we are asked to simply because we enjoy our work. No other professionals are expected to work for free, competing for a chance to maybe get paid for their work, and we should not either.

Field of Nightmares

This makes the playing field less populated with opportunities and more populated with frustrated games of chance. We end up looking down at a field of nightmares upon which we are expected to slave away with the odds stacked against us, and the rules being written without any consultation or consideration for their impacts on us. They have built it, and we are supposed to come along and be thankful for this damaging construct that undermines the industry as a whole, and our chance to play within it. But we have the opportunity to correct this slight by simply refusing to play this game. Though for some it is not so simple.

Hunger Pains

One underlying and well known reason that Spec work has taken such a hold on the industry is not because of a streak of greed that runs through the members of the community, but because of the hunger pains that run through it. With such a large number of active players in the game, naturally the amount of work we can get for ourselves can be somewhat slim when it comes to pickings. So as we see less actual opportunities on the horizon, and more of these contests cropping up, then it is easy to understand how many of the designers and developers end up with their hats thrown into the Spec work ring.

A No!Spec poster from designer Matt Clarke

Which effectively makes the entire Spec work model that much worse when you consider that by and large it is taking advantage of those struggling to find their footing in this new field. And most of them are hungry. Considering that there is faction of these participants who are also fresh to the field, it is also easy to see how they could get caught up in this industry debacle. Especially if they are students. After all, students are conditioned through internships and work of that nature to understand that not all time and work is compensated. Forgetting that with most internships you are at least given room and board of some sort, so some of your needs are effectively being looked after. In the Spec work model, no one is meeting any of your needs or looking out for any of your interests.

In Conclusion

In the end, the sad truth is that there more than likely is a small niche that the Spec work model could effectively and beneficially serve in the design and development community. However, given the rampant greed and devaluing of the industry by the large corporate sector of the business world, reigning that model into that small a niche may never fully be possible. There will always be those who are willing to take advantage of others situations and circumstances to save themselves money. And unfortunately, there will more than likely always be those hungry enough to allow themselves to be taken advantage of for a shot at bettering their situation. No matter how long a shot it is. What are your thoughts on Spec work and its impacts on the design and development communities? Leave your thoughts in the comment section below.

Further Reading

• Don’t design on spec by Jeffrey Zeldman
• Why CrowdSpring Owners Should Be Ashamed of Their Business by Brian Yerkes
• The No!Spec Campaign vs crowdSpring by Ross Kimbarovsky
• Why the No!Spec Movement Isn’t Working. And Why That’s So Awesome! by Nick Campbell
• To Spec or Not To Spec by Ben Tollady
• Awesome and professional form letter from Supernice Studios which wonderfully explains to any potential clients expecting you to work on spec why that is an unreasonable request.

Consider Some of Our Previous Posts As Well

• Quality-Price-Ratio in Web Design (Pricing Design Work) is a post from the Smashing vaults that looks at the difficult question of whether good design always has to have a hefty price tag.
• Why Wait For The Opportunity? Create Your Own! is a another previous post from here at Smashing that discusses taking charge of our own fates and not letting our design opportunities be controlled by others.

(rb)

Navigation is such an important part of your website. It’s how your visitors navigate to the main areas of your site and makes it easy for them to find your good content.

CSS is of course the perfect language for designing beautiful navigation menus. It can be applied to any type of website and is very flexible. Don’t be alarmed if your own CSS skills are fairly limited as there are a lot of great tutorials out there that walk you through how to add clean and professional looking CSS menus to your website. You can either copy and paste the code into your own design or modify the menu to suit your needs.

Today we would like to show you 100 of these tutorials; 75 horizontal CSS menu tutorials and 25 vertical CSS menu tutorials.

Horizontal CSS Menu Tutorials

1. Advanced CSS Menu Trick

View Tutorial | Demo

2. Elegant Drop Menu with CSS Only

View Tutorial | Demo

3. Bulletproof CSS Sliding Doors

View Tutorial & Demo

4. Tabbed Navigation Using CSS

View Tutorial | Demo

5. Create an Advanced CSS3 Menu – Version 2

View Tutorial | Demo

6. Create a Slick Menu using CSS3

View Tutorial | Demo

7. How to Make a Smooth Animated Menu with jQuery

View Tutorial | Demo

8. How to Make a CSS Sprite Powered Menu

View Tutorial

9. Simple jQuery Dropdowns

View Tutorial | Demo

10. Designing the Digg Header: How To & Download

View Tutorial | Demo

11. Dynamic Page / Replacing Content

View Tutorial | Demo

12. Create a Fun Animated Navigation Menu With Pure CSS

View Tutorial | Demo

13. How-to: DropDown CSS Menu

View Tutorial | Demo

14. Flexible CSS Menu

View Tutorial & Demo

15. Creating a glassy non div navigation bar

View Tutorial | Demo

16. CSS Sliding Door using only 1 image

View Tutorial | Demo

17. CSS UL LI – Horizontal CSS Menu

View Tutorial

18. How to Build a Kick-Butt CSS3 Mega Drop-Down Menu

View Tutorial | Demo

19. A Different Top Navigation

View Tutorial | Demo

20. Create a Cool Animated Navigation with CSS and jQuery

View Tutorial | Demo

21. Navigation Bar

View Tutorial & Demo

22. CSS: drop down menu tutorial

View Tutorial | Demo

23. RocketBar – A jQuery And CSS3 Persistent Navigation Menu

View Tutorial | Demo

24. A Great CSS Horizontal Drop-Down Menu

View Tutorial & Demo

25. Overlay Effect Menu with jQuery

View Tutorial | Demo

26. Grungy Random Rotation Menu with jQuery and CSS3

View Tutorial | Demo

27. Rocking and Rolling Rounded Menu with jQuery

View Tutorial | Demo

28. Slide Down Box Menu with jQuery and CSS3

View Tutorial | Demo

29. Advanced CSS Menu

View Tutorial | Demo

30. CSS3 Dropdown Menu

View Tutorial | Demo

31. How To Create A Simple Drop Down Menu With CSS3

View Tutorial | Demo

32. Pastel color menu with dynamic submenu using CSS

View Tutorial | Demo

33. Creating an Animated CSS3 Horizontal Menu

View Tutorial | Demo

34. Tutorial to create a Beautiful, simple, horizontal CSS menu

View Tutorial & Demo

35. CSS Sprites2 – It’s JavaScript Time

View Tutorial | Demo

36. Image Menu with Jquery

View Tutorial | Demo

37. How to Code an Overlapping Tabbed Main Menu

View Tutorial | Demo

38. Pure CSS Horizontal Menu

View Tutorial | Demo

39. Pure CSS Menu With Infinite Sub Menus Tutorial

View Tutorial | Demo

40. Animated horizontal tabs

View Tutorial & Demo

41. CSS Sprite Navigation Tutorial

View Tutorial | Demo

42. Create your own drop down menu with nested submenus using CSS and a little JavaScript

View Tutorial | Demo

43. CSS Drop Down Menu Tutorial

View Tutorial & Demo

44. Nicer Navigation with CSS Transitions

View Tutorial | Demo

45. CSS Navigation Menus

View Tutorial

46. Pure CSS Fish Eye Menu

View Tutorial | Demo

47. How to Create a CSS3 Tabbed Navigation

View Tutorial | Demo

48. Create an apple style menu and improve it via jQuery

View Tutorial | Demo

49. Create a multilevel Dropdown menu with CSS and improve it via jQuery

View Tutorial | Demo

50. Sweet tabbed navigation using CSS3

View Tutorial | Demo

51. Create an Advanced CSS Menu Using the Hover and Position Properties

View Tutorial | Demo

52. Sexy Drop Down Menu w/ jQuery & CSS

View Tutorial | Demo

53. How to Create a Horizontal Dropdown Menu with HTML, CSS and jQuery

View Tutorial | Demo

54. CSS Express Drop-Down Menus

View Tutorial | Demo

55. Professional Dark CSS Menu

View Tutorial | Demo

56. Creating a Simple yet Stylish CSS Jquery Menu

View Tutorial | Demo

57. jQuery Drop Line Tabs

View Tutorial & Demo

58. Animated Menus Using jQuery

View Tutorial | Demo

59. Make a Mega Drop-Down Menu with jQuery

View Tutorial | Demo

60. Animated Navigation with CSS & jQuery

View Tutorial | Demo

61. Horizontal Subnav with CSS

View Tutorial | Demo

62. Mega Drop Down Menus w/ CSS & jQuery

View Tutorial | Demo

63. CSS dropdown menu without javascripting or hacks

View Tutorial & Demo

64. CSS Drop Down Navigation Tutorial

View Tutorial

65. Sleek Pointer Menu 2

View Tutorial & Demo

66. CSS Overlapping Tabs Menu

View Tutorial | Demo

67. Horizontal CSS Menu With Icons

View Tutorial | Demo

68. Creating a Multi-Level Dropdown Menu using CSS and jQuery

View Tutorial | Demo

69. Create The Fanciest Dropdown Menu You Ever Saw

View Tutorial | Demo

70. Create A Speaking Block Navigation Menu Using Pure CSS

View Tutorial | Demo

71. Horizontal CSS List Menu

View Tutorial | Demo

72. CSS3 dropdown menu

View Tutorial | Demo

73. Making a CSS3 Animated Menu

View Tutorial | Demo

74. How To Create A Clean CSS3 Navigation Bar

View Tutorial | Demo

75. How to Create a Modern Ribbon Banner Navigation Bar with Pure HTML/CSS3

View Tutorial | Demo

Vertical CSS Menu Tutorials

76. CSS Pop-Out Menu Tutorial

Tutorial | Demo

77. CSS graphic menu with rollovers

Tutorial | Demo

78. Vertical CSS Menu With a ‘Behavior’ File

Tutorial | Demo

79. Super Fantastic CSS Navigation Image Rollovers

Tutorial | Demo

80. Vertical Menu with Hover Effect using CSS

Tutorial | Demo

81. How To Create A ‘Mootools Homepage’ Inspired Navigation Effect Using jQuery

Tutorial | Demo

82. Simple CSS Vertical Menus

View Tutorial | Demo

83. Create a Social Media Sharing Menu Using CSS and jQuery

Tutorial | Demo

84. CSS3 Minimalistic Navigation Menu

Tutorial | Demo

85. Beautiful Slide Out Navigation: A CSS and jQuery Tutorial

Tutorial | Demo

86. Awesome Cufonized Fly-out Menu with jQuery and CSS3

Tutorial | Demo

87. Two CSS vertical menu with show/hide effects

Tutorial | Demo

88. Animated Drop Down Menu with jQuery

Tutorial | Demo

89. Clean and Attractive jQuery Vertical Menu Tutorial

Tutorial | Demo

90. Nested Side Bar Menu

Tutorial & Demo

91. CSS menus

Tutorial | Demo

92. Simple Vertical CSS Menu

Tutorial

93. Sliding Jquery Menu

Tutorial | Demo

94. Reinventing a Drop Down with CSS and jQuery

Tutorial | Demo

95. Drop-Down Menus, Horizontal Style

Tutorial | Demo

96. CSS Vertical Navigation with Teaser

Tutorial | Demo

97. jQuery style menu with CSS3

Tutorial | Demo

98. Green Vertical Navigation Menu

Tutorial | Demo

99. CSS: Sexy Vertical Popup Menu with CSS

Tutorial | Demo

100. Uberlink CSS List Menus

Tutorial | Demo

Overview

We hope you have enjoyed this list of CSS navigation menus and found something useful for your site (We made a point of including a mix of different menu styles: basic menus, flashy menus, menus which use jquery, menus that use pure CSS etc). If you know of any other great CSS menu tutorials, please feel free to share them in the comment area. :)

So the other day I was trying to get text input fields to have the same height across browsers. I figured I could use the line-height property for this, but no such luck. Well, it does work in WebKit browsers, but not in Firefox.

When looking closer at why I discovered that Firefox specifies line-height for form controls in its user agent stylesheet using the !important keyword. Since you can’t override that, a workaround is necessary.

Read full post

Posted in Browsers, CSS.

Copyright © Roger Johansson