Archive for the ‘Web Design’ Category

The Golden Rule of Web Design Implementation, Part 2

Wednesday, January 26th, 2011

This is part two of The Golden Rule of Web Design Implementation. In part one, we learned that pages aren’t views, and that thinking in terms of views is much more beneficial. Today we’ll wrap up our analysis by looking into development.

As you may recall from Monday’s post, the Golden Rule is:

The time it takes to implement a web design will always average out to one view per day.

Our first corollary was related to views. The second is about development. Or more specifically, developers.

There’s a reason I put that always in there. It’s to remind myself (and you) that this rule can stand up to a lot of variables. As I’ve mentioned already, the technologies being used and the platforms being targeted are irrelevant. Plenty of other things are too. But what I found most interesting was this:

The developer’s skill level doesn’t matter.

This is counter-intuitive. If a weak developer needs an average of one day to implement each view, then shouldn’t a more experienced developer be able to get those same views done faster? The answer is no. In fact, it will take a strong front-end developer and a weak front-end developer about the same amount of time to implement any given design. We’ll get to why in a moment, but first let’s clear up some definitions:

  • By weak front-end developer, I mean someone that knows the basics of front-end development in the technologies being used. That statement above is obviously false for someone with zero experience.
  • By strong front-end developer, I mean a real ace. Someone that can put “HTML/CSS Expert” or “Adobe Certified Flex Expert” on their resumé without exaggerating.

All set? So how is it that a below-average developer and a bonafide expert will require the same amount of time to implement the same design? It all comes down to the perceived level of what constitutes a correct implementation. In other words:

Better developers don’t code faster, they code better.

Picture a standard HTML/CSS implementation. The design is there, and you hand it off to your weak developer and your strong developer, and tell them each to get to work. After X days (where X is the number of views, of course), you get both implementations back. Here’s what you can expect:

The weak developer will have done exactly what you asked. The pages will look just like the mock-ups, pixel for pixel, and work as intended. There will be nothing wrong with the design from a typical user’s point of view.

The strong developer will deliver an implementation that looks about the same. Surprised? Don’t be. That’s all these two implementations will have in common. Let’s look at some things the guru probably did that our weak developer didn’t even consider:

  • The HTML and CSS both validate, with no errors.
  • Each page has a proper doctype.
  • There is a clear separation of structure and presentation.
  • Accessibility has been accounted for wherever possible.
  • The HTML is semantically clear, and would be easy to restyle.
  • The CSS is beautifully minimal, and optimized for maintainability.
  • There are <noscript> blocks for users that don’t have javascript enabled.

Do you see the difference here? On the surface, it’s barely noticeable. But just beneath that surface is a trove of quality that goes far and beyond what was asked. To the guru, this isn’t even extra work. This is just how HTML and CSS are used.

Don’t blame the developer.

You may be thinking: “The guru shouldn’t waste time doing what wasn’t asked of him; he should be able to translate that extra time into finishing the implementation faster.”

Please don’t ever ask this of your developers.

Would you ask a master carpenter to build a simple chair as quickly as possible, and not “waste” time without worrying about quality, durability, ethics, or craftsmanship? Of course you wouldn’t. That’s simply not how experts work.

The solution to this problem is simple: choose the best developer for the job. If you don’t care about the internals of a deliverable, assign a developer that has lots of room to learn. If the project requires some baseline level of quality, consider a developer that is better versed in the fine art of building interfaces. Only call in the guru when the project requires an unmatched level of care.

And remember that no matter how hard you push, and no matter which developer you choose, you’ll never beat one view per day.

The Golden Rule of Web Design Implementation, Part 1

Monday, January 24th, 2011

Hi folks! Today’s post was so full of awesome that I had to split it in two. This is part one, about views. Part two is about development.

Estimating is hard, and I hate doing it. But I have a trick.

Specifically, I’m going to talk about how to estimate the implementation of a web front-end project. Maybe it’s a UI refresh for an existing web site, maybe it’s a new take on e-commerce, maybe it’s one of those new-fangled web-apps… it doesn’t matter. As long as you’re implementing a relatively well-spec’d-out design, this rule will work every time.

Oh, and the technology doesn’t matter either. It can be HTML/CSS, with or without JavaScript. It can be Flex, it can be JSP or ASP or anything else. As long as you’re not doing any significant back-end work, this truth still holds.

This is really important so I’m going to write it in a really big font:

The time it takes to implement a web design will always average out to one view per day.

So if the design has 16 views, the implementation will take 16 days.

There are two interesting facets to this rule. Today we’re going to talk about the first one, the significance of the term “view”.

Views != Pages

This is an important distinction: it’s not about pages anymore. We’re past that. We have bigger monitors, and that means we can have more elaborate pages. In fact, we often put several views on the same page, just because we can.

Imagine you have a page in a standard two-column layout. The main content is one view, that’s obvious. What about the sidebar? These days, if it’s anything other than nav, it’s probably also an independent view. Even the main content can be more than one view, if it separates logically and especially if part of it will be re-used on another page.

Of course, not all views are created equal. Maybe the sidebar view in our example is a lot less work than the main content view. That’s bound to happen, and it’s fine. The rule states that this will average out, and believe me, it will. For every super-easy “only took an hour and a half” view you find, you’ll get stuck with one that takes nearly twice as long as it should because you hit some silly browser compatibility issue.

Get used to thinking in terms of views.

There’s another reason for looking at the design in terms of views: That’s how implementation works. You start with the overall page architecture, build out a grid or column structure, and then tackle each distinct view one at a time. The developer’s standard divide-and-conquer approach.

Doesn’t it make sense to estimate the same way? By considering the design in terms of views at scheduling time, you’re estimating the same chunks you’ll be implementing. This will lead to more accurate estimates.

It will also make your estimates easier to defend if they seem too high. Write out a list of all the views in the design, and say “this is a breakdown of the implementation in one-day chunks”. If there are 12 chunks, that’s 12 days. You don’t even have to use the term “view”.

By throwing away the pages metaphor and instead thinking in terms of views, you’ll get better estimates that are more accurate and easier to track, and easier to explain to others.

There’s still more to learn!

We’ve only looked at the first interesting corollary from the Golden Rule. In part two, we dig even further to reveal the secrets of development.

How to Give Useful Advice

Monday, November 1st, 2010

The internet is a fantastic resource for the budding web developer. With plenty of blogs dedicated to improving the web, new tips and best practices are spread easily and often. But is this advice always useful? The veteran web developers of the world have a responsibility to their community to provide advice that is not only correct, but also well thought-out and properly explained. And sometimes, even the pros miss the mark.

Last week, I stumbled across a post from Six Revisions entitled 10 Random CSS Tricks You Might Want to Know About. Thinking that one can never know too many CSS tricks, I figured I’d give it a read and hopefully come away with something I didn’t know before. Instead I came upon a mess of poorly-chosen and poorly-explained advice that some hapless beginner may now completely misuse! Needless to say I was startled.

At first, I thought about leaving a comment denoting my dissatisfaction with the quality of the post, but I soon decided that that wouldn’t have been particularly productive. Better to point out not only the flaws, but also what is done well and maybe add a few improvements, right? So that’s what I did. Open the original article for reference, and follow along with my notes!

1: Set body font-size to 62.5% for Easier em Conversion

This is a neat math hack, but poor advice for the novice web developer. The whole point of using em is that it is a relative unit of measure. Suggesting that you set your body font in such a way that it will be easier to convert em to px implies that you’re not using em as a relative unit at all — you’re just using it in place of px. At that point you’re better off just using px and saving yourself the overhead of converting it at all.

A better tip would be to explain how em really works and to demonstrate how powerful relative measure really is. A timely example would be for a mobile-optimized design: With so many devices out there covering a wide variety of screen resolutions, proper use of em can help ensure that everyone gets a properly-scaled view.

2: Remove Outline for Webkit Browsers

This could alternately have been called “Break Accessibility for Webkit Browsers”. It’s a horrible tip, especially for an impressionable designer just getting into web development. Forms are focused for a reason — so that the user can see where she is in the page. When this is removed, it weakens keyboard accessibility and annoys power-users that navigate through forms sans mouse. There is no good reason to do this. Ever.

A much better tip would be to promote proper use of the CSS :focus pseudoclass. Instead of removing the border, change it to something that better matches your design. Or change the background color or some other property so that it’s still clear when a form element is highlighted. Whatever you do, make sure you aren’t breaking an important accessibility feature.

3: Use CSS transform for Interesting Hover Effects

This is a good tip; there are plenty of interesting new effects coming out in CSS 3, and anyone that has worked on a website with me can tell you that I’m a huge fan of rollovers. What irks me about it is the example they chose — using the scale function to resize text. This is ridiculous for two reasons:

  1. You don’t need scale() to do this, you could just as easily change the font-size property.
  2. Artifically scaling a font makes it look uglier. You won’t get this side-effect using font-size.

The article should have either found another way to show the benefits of the scale() function (images are a classic) or chosen an effect that suits text rollovers better, such as text shadow.

4: Target IE6 and IE7 Browsers without Conditional Comments

This is my least favourite “trick” in the entire list. The whole reason we have conditional comments is because before they came along it was a pain in the ass to target browsers like IE6 and IE7. Why anyone would condone reverting to exploiting browser bugs via CSS to target specific browsers is beyond me. Conditional comments are much, much better suited for the job.

Predictably, my preference for this tip would be to explain why conditional comments are better than awful, outdated hacks. The main advantage is that they allow you to localise your browser targeting to one spot in your mark-up, rather than all over your CSS file. This makes it much easier to maintain and has the added bonus of avoiding ugly character-based hacks all over your otherwise-gorgeous styles.

5: Support Transparency/Opacity in All Major Browsers

This one is largely okay. It’s a good tip, and the example is solid, I just found the introduction a bit lacking. A possible improvement would be to mention that originally, every browser had their own transparency hack and it wasn’t until CSS 3 that opacity was officially added to the specification. This way the novice developer following along gets a touch of back-story regarding why Internet Explorer is different from its counterparts.

6: Use !important to Override Normal CSS Precedence Rules

This is a good tip (I’m willing to bet a lot of people don’t know about !important), but it only explains half the problem. What isn’t covered is when to use !important, and that’s just as, well, important. The example given is too simplistic to be useful.

The ideal tip would describe a case where using !important is necessary. Like those times when you’re dealing with some poorly-auto-generated HTML, and you need to override some inline styles.

7: Centering a Fixed-Sized Element

This example is poorly explained. It reads a lot like “do this magic CSS, and *poof* your content will be centered!”. That’s not how CSS works, nor is it a good way to learn. Why not explain how the styles work? They’re not obivous. Furthermore, why not provide a few alternatives? If the dimensions of the container are known, for example, the math gets quite a bit easier — and that will be a very common case.

This tip would be more useful if the inner workings of the sample CSS were clearly explained. Educating a reader is always better than conjuring up a magic block of code with no elaboration.

8: Easy Web Fonts with Google Font API

This is one of two tips that is already really useful. There are no glaring errors, the example is current, and the content is still likely unknown to a large number of developers. There’s even a bit of history regarding the current state of @font-face! I wouldn’t change a thing.

9: Prevent Line-Wrapping of Text Elements

This tip again fails to mention when it should be used. “Sometimes” is too vague, and even the example of link text isn’t really justified (are there advantages to no-wrapping link text? what are they? when else is this useful? etc). By answering a few more questions, this could be considerably more useful advice.

10: Vertically Align Text

This is the second already-useful tip. It explains the problem, introduces the solution, and explains some of the solution’s shortcomings. Exactly the kind of information necessary to really understand this tip.

§

There we have it; a few tweaks and these potentially-harmful tricks can flip into advice that is decidedly useful. We can draw a few conclusions from our observations above:

  1. Start with the problem. Clarifying the problem up front shows that your advice is practical.
  2. Be specific. Removing ambiguity makes advice easier to use.
  3. Explain yourself. Justifying your reasoning helps your subjects learn.
  4. Provide compelling examples. Make sure you hit both what and when.

So the next time you’re offering some advice, don’t just stop there — offer some advice that is really, truly useful. Your community will thank you.

Design Blogs I Follow

Tuesday, February 2nd, 2010

Back in January I wrote a post about how I’m going to try to update every Monday for the entire year, and keep track of how many weeks work and how many weeks don’t. For the first time all year, I missed a week.

I’d like to say it’s because I’ve been busy (I have) or because the computer I normally use for blogging won’t boot (it won’t) but the truth is I had a really good post I wanted to write that I didn’t get done, and that’s lame. I’ll have it up in a couple of days, but until then I’ve prepared a list of pretty things for you to look at while you wait.

Last week, a friend of mine asked me what design blogs I currently follow, and here’s what I sent back:

Smashing Magazine — Easily the most popular name on the list. I find they do post a fair bit of noise, but they have some really good stuff every now and then that’s certainly worth following for.

For a Beautiful Web — Probably the best design blog I follow. Lots of interesting stuff, highly recommend.

I Love Typography — This is the only strictly-typography blog that I follow. Gives a very good summary of new and interesting type-related things once/week and a few other misc posts here and there (which are usually pretty interesting).

100 Redesigns — This guy is doing something really cool: every week he picks some ugly looking major website and posts a redesign for it. They’re good designs, and I find them inspiring because redesigning web sites is a valuable skill.

Dustin Curtis — This guy makes a completely new design for every post on his blog, and he’s a totally ace designer. Oh, and his posts are great too.

Jason Santa Maria — This guy has some remarkable credentials and his blog is a great source for interesting design-related ideas (though posts are often few and far between).

Stop Design — Another guy with an awesome design blog that doesn’t update often. He’s a graphic designer that used to work for Google but now works for Twitter, and his website is literally the best-designed website I’ve ever seen. Every time I visit I find something new about it that I totally love.

Colour Lovers — This isn’t really a design blog, but it’s good inspiration for colour palettes, and every once in a while they post a gem of an article about colour theory or how colours are interpreted on a biological level.

The Oatmeal — Ok, so this is clearly a web comic of sorts, but the design of the comics is always top-notch and I learn more from one of these comics than I do from ten self-proclaimed ‘awesome CSS galleries’.

Who do you Follow?

If you follow any great design blogs, I’d love to hear about them; leave your own list in the comments.

What is a Font Stack?

Saturday, October 24th, 2009

Font Stack (n) : A list of several fonts provided from a website to a browser via CSS from which the browser will chose a font with which to render the associated text. eg. font-family: Helvetica, Arial, sans-serif;

This is a pretty simple concept to understand. To show text on screen, the browser needs to use a font, and the way web developers tell the browser which font to use is by making a font stack like the one shown above. The browser will go through the list from left to right, and when it finds a font that it can use, it renders the text using that font. So you put the ideal font first, then the next-best-thing that looks pretty similar, then maybe another back-up or two, then a default like serif or sans serif, which essentially tells the browser to use whatever default font it has of that type.

I was sifting through WordPress themes the other day when I stumbled upon:

font-family: Georgia, sans-serif, Verdana;

Let’s take a moment to go over the various atrocities committed by this abomination:

  1. Georgia is a serif font, while Verdana (and obviously sans-serif) are sans-serif fonts. It’s purely nonsensical to include serif and sans-serif fonts in the same stack — you either want serifs or you don’t.
  2. Browsers choose fonts from left to right, remember? And sans-serif is one of those default fonts we talked about, so it’s guaranteed to always be supported by all browsers. This means that the Verdana in that stack will never be used, ever. There is absolutely no reason to include another font after a default.
  3. One of the notable characteristics of Verdana is that it’s very wide. The wider the font, the less characters will appear on a single line. It’s a terrible idea to include a wide font, such as Verdana, in the same stack as a comparatively thin font, such as Georgia (or Arial, which is a more common mistake) because now the width of your lines, the length of your page, and the general look and feel of your text vary greatly depending on which font is used.

Horrible! But all is not lost; here are a few simple guidelines to make sure you don’t create anything similar:

  1. Never mix serif and sans-serif fonts in the same stack.
  2. Always include a default font, but always put it at the very end.
  3. Always test each font first to make sure your lines break in about the same places and that your text still has the same general shape.
  4. Never guess — the internet is a wonderful place with plenty of resources for the aspiring typophile, use them!