A collection of stuff

So, how good are you at seeing things?

The video is for a campaign to pay attention to cyclists on the road, but it’s derived from an experiment made by the University of Illinois’ Visual Cognition Lab and it’s something to keep in mind not only when we are driving or playing basketball, but also when engaged in interaction design: people won’t see what they aren’t looking for. Even if there’s a big colourful sign it’ll tend to be missed if there aren’t other clues about what the visitor to a website should be looking for, of if they are not expecting it.

Here is another one, let’s see how long it takes you to notice what changes in this picture.

Saw it? If you haven’t the answer’s at the bottom. Anyway, that image was also part in another experiment that tried to determine how good are humans are recognizing visual change, and it seems we are not very good at all. Unless something is considered important, it’ll go unnoticed. The flash between both images acts as a kind of “brain reset” for what we are seeing. It’s something to keep in mind in interaction design, whether we want the user to notice a change or make them look the other way so they won’t see us putting the rabbit in the hat before pulling it out again.

This lack of awareness for some stuff could be a survival mechanism that made us pay more attention to things that are close to us that could kill us and less to things far away. Because even if things far away could kill us, who cares? they’re far away. And if it’s a volcano or a flood it’s not like you can run away from it very successfully.

We can take advantage of this limitation of the human mind to manipulate gently encourage users to perform the actions that are more important for the objectives of our site and to create a less confusing and more useful interface.

What do you think? Should we use these techniques or should we just be blunt?

Oh, yes! The answer to what changes in the image above.

After the stir and controversy not caused by my post yesterday I feel it’s completely unnecessary to clarify my position on whether form should follow function in web design or the other way around. I’m going to do it anyway just because I’ve got nothing better to do.

Whoever thinks there is a debate or a question about whether it’s necessary to choose between form or function in a website should stop labeling him or herself as a web professional and go back to web school. Function without form and beauty is a pain, while something that’s beautiful but gets nothing done is equally a failure. I’m sure we’ve all come across people like that: either too focused in results but no joy to be around, or complete airheads, fun for a moment but ultimately boring and annoying.

Same thing with web sites. The problem is that some people who can do beautiful things look down on people who can do good function as uncreative, insensitive, blind brutes; while some people who can do good function see those who can create beauty as empty, shallow bubbleheads.

The truth is somewhere in between. You may have noticed that I have not used “web designers” or “web developers,” simply because design involves making something that people will find a joy to use, while development involves being able to create such a thing in a practical and efficient manner. A “web designer” who doesn’t consider function in his or her designs cannot be a good designer; while a developer who doesn’t consider the ultimate user and the fulfillment of their goal cannot be considered a good developer.

A good web designer is that who, instead of obsessing about their site looking perfect in every environment focuses on creating designs (plural) that allow every kind of user to get through to the functionality of the site. A good designer is not one that says “oh, I want it to look exactly like when I drew it in Photoshop” but one that goes “oh, I had not seen it before in a screen like this, it works!”

Same with a developer. A good developer is one that even before applying any visual layers you know what the site is supposed to do and you know what to do with it. Not one who can explain his or her code, but one whose code can explain itself.

So, there, I hope that made it much clearer for all the unexisting crowds who were waiting for me to explain further.

The IE6 debate continues. Should web designers support it? Should we at least test on it? Or should we ask IE6 users to go lay an egg in a variety of ways from terse and subtle to completely blocking the site or even being kind of deceitful?

Actually, there’s no such debate. It has no basis. A good web developer will support all browsers to the degree that browsers are able to display different elements in a site. Old browsers will be shown the things they can interpret while newer browsers will be let loose to work their magic. There’s no yes, if, or buts. It’s a simple question of accessibility and being a good web designer. A store owner wouldn’t refuse service to someone just because they arrived in a ‘92 Lada or a beat up pick up truck. Well, maybe some would but they would be jerks. Do you want to be a jerk? If you don’t then don’t behave as one.

Anyway, back to the point of this post. Catering for IE6 is really no more complicated than catering for old browsers. The real trick is in defining what we mean by “support” and letting our clients know that IE6 users will see the bare-bones but fully usable version while newer browsers will see more bells and whistles. If they ask why tell them that IE6 simply is not up to the task of the modern bell and whistles, but for a charge you can add some of those if required because that represents extra work.

However, just serving a basic style sheet to IE6 doesn’t represent any extra work because you need to create one for older browsers anyway. Of course you know how to deliver a complementary style sheet to IE6 using conditional comments, but remember that you can also hide things with those comments. So, what we are going to do is this:

<!-- Basic styles for older or simpler browsers -->
<link href="basic.css" rel="stylesheet" type="text/css" />
<!-- Let's use conditional comments to keep IE6 out. Take that, IE6! -->
<!--[if gte IE 7]><!-->
<style type="text/css">
  @import url("advanced.css");
</style>
<!--<![endif]-->

First we link a basic style sheet that most browsers will understand. Here we can set up our basic fonts stacks, fixed widths, some floats, use safe gifs and jpgs, etc. Then the conditional comments keep IE6 and lesser away from importing the advanced css style sheet, while allowing IE7 and over, as well as other browsers, to read that line. Older browsers won’t know what to do with the @import, so they’ll leave it alone, while newer browsers will read and enjoy the sweet, sweet fixed and absolute positioning, transparent pngs, flexible layouts and other crazy, creative stuff we put there.

Sure, IE7 and IE8 won’t be able to render some of that but at least they won’t throw a fit over it. In fact IE8 is pretty good and you can always use another conditional comment to serve a complementary style sheet to IE7 in those rare instances when it’s really necessary.

Now, some designers will get their knickers in a bunch at the thought of their beautiful work of art being displayed differently in another browser, their carefully positioned elements and lovely crafted transparent backgrounds just done away with in the name of letting a gang of louts not even good enough to update their browsers to be able to come and have their filthy ways with their pristine layouts.

Well, to those designers all I have to say is… maybe you’re just not cut out to be a web designer. It’s another medium, buddy, one where the user has a lot of say in the way the message is used and displayed. If you don’t like it or are not prepared to accept it, maybe you should move back to print or something where you feel safer. Because, as you see, catering to all is not really that difficult and there is no extra work that can be used as an excuse.

Brothercake wrote an article about 10 cool things we supposedly will be able to do only once IE6 is dead. Those things are pretty cool and certainly provide visitors with an enhanced experience. The “problem” is that they rely on things like css3 selectors, modern javascript implementations and other stuff that IE6 won’t do and since currently about one fifth of all internet users are on IE6 there is a perceived need to “pander” to them.

But, here is the big secret, you don’t have to wait for IE6 to go away to provide that same experience to users on more advanced broswers. Look, programming a website is more than just providing a “great experience”, it’s about making content accessible and engaging users. You can both provide a “great experience” to users with modern browsers while, at the same time letting users of older or more limited browsers, like IE6, enjoy a good experience. If you are a web creator worth your salt you will *always* pander to all users, no matter how old or limited their browser is, or how small their screen size or how less acute than average their vision is or whether the reach of their fingers is short or long or none at all.

Honestly, I don’t think “great experience” should be defined by the frills, whiz-bang, and technical wizardry of the site, but by allowing the user to achieve their goal clearly and quickly. A well structured and clearly defined site should be able to accomplish this before the layers of plaster and paint have been applied.

Users with an old browser should enjoy a “good” experience. This doesn’t mean the same experience as users of modern browsers, or that you have to throttle back your design for all users. It’s okay for users with modern web browsers to enjoy a better experience than users of old browser. Do you expect the same joyful ride from a 1988 Lada than from a just-out-of-the-assembly-line Mercedes? Of course you don’t. But at least you expect to be taken from A to B without too much hassle and in a reasonable time. Ok, so you won’t get the heated seats and satellite radio, but you’ll still get there, in fact, if either car fails then the car is a useless, no matter how plush the interior or how much music you get on the satellite radio.

Use those 10 things that brothercake mentions. But don’t depend on them to provide the user experience, and don’t fall in the trap of wanting to provide the same to everybody. Educate your client and satisfy your users.

Well, no, not really. Sitepoint ran an article written by Craig Buckler titled 5 Reasons to Avoid CSS Hacks and Conditional Stylesheets which caused a bit of a commotion since those methods are very popular to work around certain limitations in Internet Explorer. I mean, let’s be honest, the only reason we talk about these things is that damn buggy Internet Explorer 6. Those affect the way sites look.

The reasons:

1. CSS validation may not be possible
2. Your CSS becomes more complex
3. Your CSS may not be future-proofed
4. It is browser detection
5. There is rarely a need for them

In general I agree with the reasons although I have a bit of a problem with number 3, I mean… what is ever future-proofed? And number 1 is a problem for hacks, not conditional stylesheets, but this doesn’t mean that you should say never ever jamais to the use of conditional stylesheets or even hacks. Just as there are good reasons not to use them, there are good reasons to use them and there will be times when you just have to do it. No matter how well planned and thought out the layout is, something strange can slither out of IE that is just best handled through a conditional stylesheet. Hacks not so much. I would leave those as an absolute last resort.

However, the truth is that over reliance on these tricks of the trade is not a good thing. It’s much better to plan your layout before hand, work the css out in strict mode and try alternatives instead of jumping right on to the conditional stylesheets at the first sign of trouble. Of course, practice makes perfect and it will be only through experimentation that you will learn the pitfalls of IE and css coding and the techniques to avoid them. Working with a javascript framework and some kind of css reset can also help to pave over the holes.

My personal experience has been that a site can be built with minimal code in the conditional stylesheets, sometimes just a couple of lines, and in some special cases with none. And most of the time hacks are not needed at all. A lot of the problems can be avoided if we manage client expectations by warning them that trying to make the site behave exactly the same in IE6 as it would in Firefox, Safari or IE7 may mean bending over backwards or cutting back on features for high-end browsers. This doesn’t mean we shouldn’t build a good experience in IE6.

So, do I agree with the Sitepoint article? Yes. Those there are valid reasons to keep in mind. It doesn’t say there that you should never do it, it all comes down to analyze the layout, evaluate the options and decide on the better solution instead of taking what looks like the easy way out every time.