How to Give Useful Advice

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.

Tags: ,

One Response to “How to Give Useful Advice”

  1. Francis Says:

    This is a really good analysis. Goes to show that getting tricks from the internet doesn’t mean that you shouldn’t spend the time to understand the advice you are getting.

    I particularly like the comment you make about #1 and #2. Reducing accessibility just because you want it to look a specific way or because you want it to be convenient for yourself (as the designer) is not helping your user.

Leave a Reply