By releasing Inside government we were testing a proposition (‘all of what government is doing and why in one place’), and two supporting products (a frontend website and a content management system).

Ross Ferguson

People usually forget this. When you don’t, your project has way more chances to succeed.

1. Put all of CSS in one file, which means less requests, but also means that the first time people land on your site, they will wait longer than needed to see the content which could mean a ruined first impression.
2. Put CSS in per-section files, which means less loading up front but more request as people drill down into different sections of the page.

When using the first option your only focus can be on how to optimize the CSS so that it loads as fast as possible and is as small as possible. As you have less files you can easily have that file minified and gzipped even if you’re not using a deployment solution that will do that for you.

Using the second variant gives you more options – you should still optimize the files, but now you have the option of deciding when to load them to make sure that the landing page does not get hit by the added request.

Even though I started with CSS preloading can be done for any resources needed on the page – fonts, scripts, images.

When to preload?

An very obvious case is a search results page. It usually has a very distinct design that requires certain resources not needed anywhere else. But that’s not enough – you need to know when the user will these resources so you don’t go preloading everything just in case. With search it’s when they focus inside a search box – they start typing the query, while you start preloading the resources in the background.

Other obvious places to preload resources:

• My account – when users click log-in or focus into the login form
• Checkout – when users add stuff to their cart

Other less obvious places are landing pages when the choice a user makes turns into many sub-options, especially when products have the same resources used on the content pages.

To the code!

If you’re already using a library it probably provides AJAX methods and event methods. If not, you can search MicroJS to find one and adapt the syntax.

A simple preloader is almost as simple as helloWorld – the only thing you need to make sure is that the type of data type is set to text so that it does not get executed.

window.preload = function (src) {
	$.get(src, null, null, 'text');
} // call with preload('somefile.css');

If you want to allow the loading of multiple files at once you can detect if the passed element is an array.

window.preload = function (data) {
	var a = $.isArray(data) ? data : [data];
	$.each(a, function (i, n) {
		$.get(n, null, null, 'text');
	});
}
// call with preload('somefile.css');
// or preload(['somefile.css', 'otherfile.js']);

If you prefer to call the function with many parameters you can just use arguments in the each function call.

window.preload = function () {
	$.each(arguments, function (i, n) {
		$.get(n, null, null, 'text');
	});
}
// call with preload('somefile.css');
// or preload('somefile.css', 'otherfile.js');

Key element is to load the resources after the window.onload has happened – this means that any resources needed for the page to function properly have been loaded. If you do stuff sooner you might have to wait for other resources like fonts, images, videos. This means you need to know if the onload event happened – if it has, preload immediately, otherwise wait for the event to fire.

(function () {
	var win = window,
		$ = window.jQuery,
		$win = $(win);
	$win.load(function () {
		$win.data('loaded', true);
	});
	win.preload = function (data) {
		var a = $.isArray(data) ? data : [data],
			fn = function (i, n) {
				$.each(a, function () {
					$.get(n, null, null, 'text');
				});
			};
		if ($win.data('loaded')) {
			fn();
		} else {
			$win.load(fn);
		}
	};
}());
// call with preload('somefile.css');
// or preload(['somefile.css', 'otherfile.js']);

As you can see I also did a few other things – wrapped the code into a function to isolate all the variables. I also assigned window.jQuery to a local $ to make it a bit more bulletproof.

Needless to say this script needs to be loaded during the load stage. If you intend to load it afterwards you need to make sure that you properly detect the onload event – if you don’t nothing will get preloaded as it will be waiting for that event to fire.

Goal

The goal of this exercise is twofold:

1. To force caching of resources that slow down the loading of your page.
2. To actually be able to use the app when offline.

Solution

It’s as simple as writing a cache manifest. It pays to name it [something].manifest, as Apache already serves the correct header with that suffix. What you do is list all the files you want cached, add stuff you allow on the network (check Appcache Facts and Dive Into HTML5 – Offline Web Applications) and it all works. Except it doesn’t.

CACHE MANIFEST
# version 1

CACHE:
resource.js

NETWORK:
*
http://*
https://*

AJAX stuff

If you’re using AJAX to get data from a server using jsonp/script, your framework of choice (jQuery in my case) will probably default to using a no-cache approach to loading it. This will mean that it will request the file + some suffix to prevent browser caching. This will mean that the resource will not be available if you’re actually online.

You can use navigator.onLine to switch cache on/off, but I suggest you first try requesting the no-cache resource and if it errors out, request the cached resource. The benefit is that even if you are online but the server is not, the users will still see the data / use the app.

$.ajax({
	dataType: 'script',
	url: 'resource.js',
	cache: false,
	success: successHandler,
	error: function () {
		$.ajax({
			dataType: 'script',
			url: 'resource.js',
			cache: true,
			success: successHandler
		});
	}
});

iPad issues

Fixing the AJAX meant that it worked properly on the desktop (test with Firefox that has offline mode) and in Safari on the iPad. The trouble started when I added the app to Home Screen – data failed to load. It was the same app as in Safari and it should have worked.

After some debugging I found out that the data actually was loaded but the eval failed (I was using $.getScript). Some weird testing showed that the problem was a newline character in the data. As I really liked the newline there I added some code to the error handling that removed the newline and evaled the data, then ran success. And it worked!

$.ajax({
	dataType: 'script',
	url: 'resource.js',
	cache: false,
	success: successHandler,
	error: function () {
		$.ajax({
			dataType: 'script',
			url: 'resource.js',
			cache: true,
			success: successHandler,
			error: function (xhr) {
				eval(xhr.textResponse.replace(/\n/g, ''));
				successHandler();
			}
		});
	}
});

Debugging

It’s somewhat hard to debug offline stuff. I suggest using a clearly visible version indicator in the file to make sure you know which version of the file you’re looking at. Also remember that the first time you load the app after changing the file & cache manifest it is served from cache. At the same time the manifest is checked and on the iPad the files are downloaded after everything else is done (app finished loading and rendering).

It works!

After these problems were solved I used the aforementioned navigator.onLine to hide stuff that normally comes from the network but is not relevant to the offline app (banners, share links, like/+1 buttons) and you can now check the La Vuelta 2011 results page.

The problem

Almost all websites now have some forms on them, some of them are contact / registration forms, others use the data submitted and display it on the site itself (comment forms). But letting others submit data to your site/database opens you to all sorts of attacks. If you actually show the content of the submitted form, you’ll get a bunch of spammers posting comments with lots of links. If you only store data and not show it anywhere you’re still at risk – if you don’t notice your disk can fill up, your database may grow beyond its limits,… So what we want to do is to prevent bogus form posting.

Spammer approach

If you think about writing a spam-bot that will try to spam as many sites you possibly can you have two basic approaches.

Record / replay

This is a very simple approach – you use a person to submit the form, preferably with something that looks like real input and record the request made. Then you hand that data off to the bot, it changes some content and tries to resubmit it.

Automation based on heuristics

I wanted to say AI, but it really isn’t. What it is is a set of simple rules and randomized values that the bot thinks might trick your site into accepting the submit. Let’s say you have three fields, two are inputs with field names “name” and “email” and the third field is “comment”. A simple script can fill these with “valid” data and try to submit it.

Human entry

By far the simplest, but also most costly for spammers. Go on Amazon Turk or whatever other service, send a link to a Google Spreadsheet and have people manually enter the stuff into your forms. This is the source of “Sorry, this is my job” endings to spam comments.

Popular solutions

Turing test

Add a field to the form that the user must fill with something that humans can do easily, but machines can’t. The biggest group here are Captchas (display an image with distorted characters, possibly an audio link that reads out the same characters, and have the user somehow figure it out and write the solution), but there have been others, like a “Human?” checkbox, or “3 + 4 =” fields, “Is this a kitten?” with a pic next to it.

2-step process

Supposedly by far the easiest way to do this is by introducing a 2-step process. After the initial submit, you get back a preview of the submitted data, possibly with a checkbox that says “Is this correct?” and another submit button. Robots are usually not good at following through and thus don’t actually submit the content.

Both solutions have an impact on user experience. With Captchas it’s sometimes really hard to see what they are and even if they have a “different image” link, it just seems like the owner of the site wants to make your life hell before you can submit your data. The other challenges might be easier on the user, but also easier to figure out if you’re being targeted by bots. The 2-step process works great for comments, that usually don’t have an edit link, so it might actually be good for user experience if done right (not Wikipedia style), but are less appropriate on other types of forms.

Protect yourself differently

These are the techniques that should prevent most bogus form entries from random passing bots, except “Human entry” – no protection for that, even though Captchas try hard. There is not much you can do when you’re targeted…

Honeypot field

Use this field to trick autoguessing bots to submit something in a field you know should be empty.

• Add an input field to your form with a regular name (state, maiden-name,…) that does not appear on your form otherwise.
• Use a label that will clearly communicate that it needs to be empty.
• Hide it with CSS, preferably not by adding class=”hidden”.

If the form post includes content in this field discard it and redirect back to the form. The trick is to make sure the bots don’t figure out this is a honeypot, so use valid looking but nonsensical classes…

Date field

Use it to prevent resubmit of data too far from the creation date. Allow users a few hours to post the form.

To prevent manual modification you can use either proper encryption (symetric or asymetric) that will allow you to decode it on form post or use this date in combination with the onetime token.

Onetime token

Use this field to prevent replay of request data. If you can, save it into the database.It is a good idea to make this token in a form that it cannot be faked (say one character changed ad you have a valid one). This can be done with hashing data or encryption.

This one can be as tricky as you want. What I usually do (disclaimer: I don’t know much about encryption so this might be crap advice) is use a plain datetime field with the onetime token generated from IP address, UserAgent and the date field with HMAC. There is no need for this token to be reversible – I can recreate the same thing with the data from the form post and check if it matches.

When using these techniques make sure you take care of the user experience. If you detect a problem on what might be valid user input (“timeout” on the date field with a non used onetime token, wrong onetime token from an ip change by the service provider), you might want to display a second step from the “2-step process”. Whatever you do, don’t call your users spammers or bots – be nice, bots don’t read the text anyway.

Did I miss anything?

I know of no plugin that uses all of these techniques, but I haven’t really looked for it. What I do know is that I don’t want to ever use a Captcha, cause it often keeps me out, and the 2-step process in just too weird sometimes. Hope this helps. And again – if you find the original article (must be some 5 years old now at least if not more) or have any other solutions you use or endorse, do leave a comment.

It makes me sad to see lots of sites minifying code for performance and not releasing the full version of the code so other developers could learn from it. It’s the openness that I really like about the web.

I think there should be a “View Source Alliance” that would set rules on how to release your code in a way that visitors can benefit from the speed of minified code, while web developers can still find your full files and learn from them.

I’ll set a few simple rules here, hoping somebody with more reach picks them up:

1. If you minify the files for them, use a simple convention name.min.ext (say jquery.min.js)
2. When you deploy minified files, also deploy their full version at name.ext (say jquery.js)
3. If you for some reason can’t release the full files next to the minified ones, add this to the top of the minified file: /*viewsource*http://path.to/full.ext*/ (say /*viewsource*http://http://code.jquery.com/jquery-1.4.4.js*/)

This way you will not only help others, but sometimes even stop breaking the law. Because you might be using some open source code with a licence that says you must release your code with a same/similar licence.

Back to the beginning. There are loads of theories on motivation and most of them just cover different aspects and mostly they can all live together. One of the aspects of motivation is where it comes from. That gives us intrinsic motivation and extrinsic motivation. Obviously it’s not a boolean thing as any individual sits on a line between the extremes. And there’s also the matter of having a different source of motivation for different things. Let’s not get into that.

Intrinsic motivation

Let me quote Wikipedia on this:

Intrinsic motivation refers to motivation that is driven by an interest or enjoyment in the task itself, and exists within the individual rather than relying on any external pressure.

We are motivated by the fact that we’re getting something done and by the feeling we get ourselves when we’re done. We’re not in it so someone can tell us we did a good job. We don’t really care. A friend of mine once said: “It’s for me. If somebody else likes it – great.” We like to think that the more we get into the subject, the better we’ll be at it and the better the result. In other words no relying on luck, no shortcuts, no marketing/selling, no subpar stuff. Because of all this we don’t like when others interfere with stuff we’re responsible for.

Extrinsic motivation

Another quote from Wikipedia:

Common extrinsic motivations are rewards like money and grades, coercion and threat of punishment. Competition is in general extrinsic because it encourages the performer to win and beat others, not to enjoy the intrinsic rewards of the activity.

These people often need to be “managed” to give them the sense of direction and success and are in that way more demanding. They also need more information about what is going on and might see the successes of their co-workers as their own and be empowered by them.

Who to hire?

You might want to hire intrinsically motivated people when you don’t have the management layers to keep them motivated or you just don’t have time to do that. On the other hand it’s very hard to keep them motivated when all the fun work is gone and thus tend to either switch tasks/assignments or try to over-explore/discover. These two reasons are also why some people want to hire intrinsically motivated employees only to later regret it as they can’t motivate them anymore or don’t know how.

Hiring extrinsically motivated people might be better for cases where you can manage them properly as they might feel lost without guidance. They are somewhat easier to motivate as you have a lot more ways to do it – sometimes even just a public pat on the back suffices. They are surely a better choice for a company in an established market as they thrive on beating the competition. If you have an “employee of the month” you should hire extrinsically motivated people.

I think it’s very important to hire a homogenous team motivation-wise. An extrinsically motivated manager might have a problem motivating an intrinsically employee and the employee won’t get why his extrinsically motivated colleague is bummed that he wasn’t complimented on the great work last week.

The intrinsic problem

We intrinsically motivated have a problem. Even though that extrinsically motivated people can internalize motivation when it matches their values and beliefs it is much more common for somewhat extrinsically motivated people to become more and more extrinsic with time due to the Overjustification effect. As that means that their number will go up with time, most of us are used to just getting in to solve the problems and then get out. Somewhat ironic that it sounds like a mercenary.

HTML Lint is a tool that makes sure your code looks good. While XHTML was very strict with syntax HTML 5 is more lenient like previous versions of HTML, which means keeping consistent code styles will become more difficult. Validating is not good enough anymore.

HTML Lint is under constant development. If you find a bug, report it on Twitter.

It started in Seattle, at An Event Apart. Jeremy Keith said in his presentation that validation for HTML5 doesn’t make much sense anymore and that there should be a Lint tool. I started thinking about it and after lunch I asked Jeremy what options he wanted in it. I added some of my own and made the first version of it flying to Phoenix (going to IA Summit) and then fixed it flying back to Ljubljana.

We released the first version soon and updated it with a new design a few days ago. I’ve been putting the update off as I had a few other projects going on, but Jeremy mentioned it at Drupalcon and Remy pointed his htmllint.com to it and tweeted about it. So it had to be done.

HTML Lint was coded in Python by MMM, which consists of me (Marko Mrdjenovič) and Marko Samastur. The design for it was done by Sara Tušar Suhadolc. The source code should be available soon.

Related articles by Zemanta

• Book Review: A Book Apart’s HTML5 for Web Designers by Jeremy Keith (reybango.com)
• validate() || dont() (wait-till-i.com)
• The value of HTML validation (nczonline.net)
• CSS3 is not HTML5 (456bereastreet.com)

Yeah right.

CORS is supported on XMLHttpRequest object in Gecko and Webkit. You just request something on a different domain, and if the response has the right header with the right value you get the data. In IE you have to use a new object called XDomainRequest which is somewhat similar to XMLHttpRequest, but without readystate, onreadystate event handler and basically any header getters/setters.

Sounds ok and when I first tried it I was quite happy with how it worked. But unfortunately nothing is that simple in the land of browsers. When it fails, it’s a whole new game…

Gecko (Firefox)

Same domain request:

• 200 response: xhr = {status: 200, statusText: ‘OK’}
• 304 response: xhr = {status: 304, statusText: ‘Not Modified’}

Cross domain request with proper headers:

• 200 response: xhr = {status: 200, statusText: ‘OK’}
• 304 response: xhr = {status: 0, statusText: ‘Not Modified’}

Cross domain request without proper headers:

• 200 response: xhr = {status: 0, statusText: ‘OK’}
• 304 response: xhr = {status: 0, statusText: ‘Not Modified’}

Webkit (Safari, Chrome)

Same domain request:

• 200 response: xhr = {status: 200, statusText: ‘OK’}
• 304 response: xhr = {status: 304, statusText: ‘Not Modified’}

Cross domain request with proper headers:

• 200 response: xhr = {status: 200, statusText: ‘OK’}
• 304 response: xhr = {status: 304, statusText: ‘Not Modified’}

Cross domain request without proper headers:

• 200 response: xhr = {status: 0, statusText: ”}
• 304 response: xhr = {status: 0, statusText: ”}

IE

Same domain requests made with XMLHttpRequest, cross domain requests made with XDomainRequest.

Same domain request:

• 200 response: xhr = {status: 200, statusText: ‘OK’}
• 304 response: xhr = {status: 304, statusText: ‘Not Modified’}

Cross domain request with proper headers:

• 200 response: onload invoked
• 304 response: onload with cache, onerror otherwise

Cross domain request without proper headers:

• 200 response: onerror invoked
• 304 response: onerror invoked

Where’s the knot?

The problem with this is the lack of error handling. Firefox will return status 0 on all errors, but will indicate what the response was with statusText. It will also return 0 on a 304 response, which is a bit weird. Webkit on the other hand only returns status 0 on failed requests, but without telling you what’s wrong. You get the same error when a preflight request fails, a 500 error on the server or the real request fails. IE with its own separate XDomainRequest implementation simplifies this two handlers – onload and onerror. Unfortunately it raises an onerror request when a 304 is returned on empty cache.

jQuery issues

If you’re working with jQuery (and possibly other libraries) you’re in for a treat. Opera 9.5 falsely reports status = 0 when a HTTP status 304 is returned from the server. For this reason jQuery treats status === 0 as a successful request. Thus you have no way of knowing whether your request was a success or a failure.

Untying the knot

If you intend to use jQuery’s built-in methods you’ll need to do your own bookkeeping:

1. Know when a request is a CORS request
2. Wait for complete event
3. If data is empty trigger error handling

For this to work you obviously always need some data. If empty data is valid you’re screwed.

Easy way out

You might have noticed before that I made a jQuery.windowName plugin. It still has the same name, but now also supports CORS requests and does some of the CORS related bookkeeping. As the latest version is still in testing you can get it directly at http://friedcell.net/js/jQuery.windowName/jQuery.windowName.plugin.1.0.0.js (test page).

1. Writing HTML is very hard on the iPad due to extensive keyboard switching. Opening tags are hard, but closing tags are even harder (switch to extended for <, back to symbols for /, back to normal for the tag name and then to extended for >).
2. I’m missing the spell checking feature I have in my Firefox, because I usually have the iPad native checker off as I write lots of stuff in Slovenian.
3. I like adding some links automatically with Zemanta and you don’t get that in the native app.

While writing the first version of this post I also found another error – it seems that the WordPress iPad app doesn’t like &lt; or &gt; inside posts, so actually writing an HTML tag like this <a> is not possible (it crashes the app immediately).

So it seems I’ll still mostly be using the iPad for content consumption and chitchat and not content creation. And possibly scribbling down ideas.

1. POST data to a script that checks it and sets appropriate cookies
2. On success redirect to the previous (or some other) page
3. On error show that error or redirect to an error page

You do this so that users don’t get the annoying “resend data” pop-up if/when they reload the destination page. On the other hand this pattern exposes a usability issue when login data is correct but cookies are turned off.

For some reason my cookies were disabled today. That means that logging in to Twitter (that uses the previously described pattern) looked a bit weird. I’d log in, get redirected and end up on the home page again. Same thing happened on Mozilla Addons page. The very definition of recursion.

When I finally figured it out, I immediately thought of a solution. When you redirect from the post add something to the URL – that way the redirected page can check if you’re actually logged in and alert you if you’re not.

Now this has a few problems of its own:

1. It exposes that you have an account on a specific service that can be detected with history sniffing.
2. If you create a user based URL to circumvent the previous issue you might leak user information.
3. If you reload the destination page after session expired you’ll get an alert that might be wrong itself (you would have to implement some server-side logic that checks if the session has just started).

With all this in mind I still think that redirecting to a different URL is better than leaving users without any information (no matter how uncommon having disabled cookies is).

How do YOU solve this?

“This is your pilot speaking. We’ve been notified that the passenger bridge has a flat tire.” were the first few words after landing in Chicago, the third airport of the day. I left Ljubljana at 7:15 CEST towards Amsterdam, switched planes and continued towards Chicago. Fortunately the issue with the gates was small enough not to endanger my connection for the last leg – to Seattle, where I landed around 16:15 PST (around 18 hours after taking off from Ljubljana).

I came to Seattle to attend An Event Apart, a conference I wanted to attend since it was first announced. Meeting people like Jeffrey Zeldman and Eric Meyer and learning from them is just amazing. But first I needed to get to the hotel in downtown Seattle and get some sleep.

After a really long day the light rail ride from the Sea-Tac airport to downtown Seattle was really amazing. Going through the suburbs, enjoying the displays of American culture – the highways, the trucks, the architecture, the people. There were only a few of us on the train at the first stop, but at the next stop loads of people got on wearing bright green shirts, scarfs and even a few kids with their faces painted green/blue – fans of Seattle Sounders FC. I thought to myself – nah, it can’t be soccer.

As I arrived a day early I had a day to spare to see the city. I woke up late and then visited The Space Needle – amazing views even in cloudy weather. I didn’t take the old-school monorail built for the world fair in 1962 thinking I’ll do that some other day. After registering at the wonderful Bell Conference Center (thanks to Marci for resolving the issues and sorry I woke you up Gašper) I walked through town to the Pike Place Market and to the high street stores – and wandered into a huge Anime convention (Sakura-Con) and a bunch of kids (not even teenagers?) wearing totally inappropriate clothes.

The day ended with a karaoke meet-up set up by Jeff Croft. I met Mike Davidson of the Newsvine fame (thanks for the beer!) and I heard Andy Clarke and Jeremy Keith sing Ace of Spades together.

The conference started on Monday with breakfast – a really good one. And then two days of talks and an additional day of workshops. I’ll review them in different depth.

Jeffrey Zeldman – Put Your Worst Foot Forward

I wanted to see Jeffrey talk for some time now. I also got to meet him just before the conference started which made me want to see this even more as he’s a really friendly guy with years of experience to share. And the talk proved to be all that and more. Explaining his mistakes from the past and the ways he is solving them – teaching what to do with anti-patterns (to quote Jeremy Keith) was really effective and I think we were all nodding as it seems we all do the same mistakes.

The checklist

1. Know before you go.
2. Keep expectations on track and in sync.
3. Constantly course-correct.
4. Tell the TRUTH.
5. Phrase it from the client’s/boss’s point of view.
6. Report bad news before the client/boss notices it.
7. Have a recovery plan.
8. Apologize-but never denigrate yourself or your team.
9. Have an exit strategy.
10. Know when to quit.

Takeaways

Working with clients is a long distance relationship – away from sight, away from heart. You need to put more energy into syncing and you need to make sure you see things with their eyes. And as in any relationship – you need to know when to leave.

Nicole Sullivan – Object Oriented CSS

Nicole used to work for Yahoo! and recently helped Facebook optimize their stylesheets, so you might say she has some experience in building and maintaining CSS systems. But unfortunately it also means that a lot of us cannot relate to some stuff she is saying. One of the first thoughts I had was that she might be a good person to write the “CSS – The Good Parts” – she even quoted Douglas Crockford in her presentation.

Controversial

There were a few points that I couldn’t agree with when she said them and decided that I will think about them later. I’m not saying they’re bad practice, I just don’t think they’re good advice for most of us.

1. Don’t use specificity was one of the things that seem like throwing away a really powerful tool because some people can’t handle the power. I could probably agree with this in big systems, but it sounds like one of the reasons to adopt Java – it’s easy for beginners to start doing productive stuff and hard for them to screw things up.
2. Don’t use .class1.class2 as that causes all sorts of cross-browser issues. I would classify this as good stuff but it seems only IE6 is affected. So I couldn’t care less…
3. Hacks shouldn’t change specificity as you’re not using specificity at all. That means that Modernizr and all other tools that add a class to the HTML/body elements are out of the question. The solution – using _property:value; – was something I don’t feel good about – using such invalid hacks just seems wrong.
4. To define headers use h1, .h1 {} and in HTML use <h2 class=”h1″>…</h2> if necessary. That just seems wrong even though I agree that reusing styles is important.
5. Avoid specifying location when targeting elements. When you do that moving an element into a different context loses the styles.

Good stuff

This list is what I think can mostly be used today for most of the people writing CSS. It is not a set of rules to abide in every case, but it should be your main modus operandi.

1. Reuse code as much as possible. If you’re copy pasting, you’re doing it wrong. One of the ways to do this is by following the second rule.
2. Don’t use ids, inline styles and !important to write easily applicable code. You should not write location specific code. Don’t use .sidebar ul, but rather add a class (eg. sidenav) to that ul and use .sidenav for the rule. Smaller CSS yes, but it will also get you bigger HTML (and classitis?).
3. Think in modules and provide styles that are easily reusable by just using a class name in HTML. Only elements that are strictly bound to modules should have location specific selectors (but with .class, not #id).
4. Put defaults into .class and use elm.class to apply specifics. Many elements can have .error – and all errors should have a similar look, whether they’re divs, lists or paragraphs.

Wish-list

1. Variables are something a lot of people want. What I want is for them to be simple enough that people can’t abuse them to make CSS a programming language. The proposed syntax:
   • To set the variable: @variables hex {myblue:#006;}
   • To access the variable a {color:hex.myblue;}
2. Prototypes are a really good way of providing defaults to a lot of elements at once and gets rid of rules that have many comma-delimited selectors. The proposed syntax:
   • Set a prototype with allowed child nodes: @prototype .box {margin:10px;children:b,.inner;}
   • Add styles to child nodes: .box .inner {position:relative;}
   • Use a prototype: .weatherBox {extends:.box;}
   • Under the hood this translates to: @prototype .box, .weatherBox {…} .box .inner, .weatherBox .inner {…} .weatherBox {…}
   • Also allows checking code: .leftCol .inner {color:red;} is invalid as .inner is part of .box prototype and .leftCol does not extend it
3. Mix-ins were skipped in the presentation as she was running out of time. You can think of them as small pieces of repeatable code that is only set in one place and used in others. Syntax:
   • Set a mixin: @mixin .clearfix {zoom:1}
   • Any selector that matches the mixin selector modifies it: .clearfix:after {content:”.”;display:block;height:0;clear:both;visibility:hidden;}
   • Include a mixin: .line {include:.clearfix;}
4. Prototype sub-nodes were also skipped. They seem to allow calculations based on values defined in different sub-nodes of prototypes – they’re not meant to access computed style:
   • Use calculations: .box .bottom {height:5px;} .box .bl {height:10px;margin-top:.bl.height-.bottom.height;}

Some of these changes will require us to write code for new and old browsers independently or to write a “compiler” that will compile code for older browsers. Is there one already written?

Takeaways

Building a CSS system means thinking about the selectors (and not the properties) and Nicole probably knows more than anyone else on that subject (to make you feel more comfortable, Jeremy Keith of Clearleft said they arrived to the same conclusion independently). Another, probably even more important takeaway is that you should think about flexible modules – sometimes stuff is more similar that it might seem at first. If you write CSS for a module that supports variations you’ll write less code that will apply faster and your visitors will be happy. If you want to look into an Object oriented CSS framework – check Nicole’s project OOCSS project at GitHub.

Dan Cederholm – The CSS3 Experience

Dan told us that we can and should use CSS3 now in non-critical areas such as experience, visual rewards, feedback and movement for users with the latest & greatest browsers. Not so much progressive enhancement as progressive enrichment.

Some ideas for use of CSS3:

• Hover on items with RGBa background, a text-shadow and a border-radius with a transition (Sam Brown style).
• Hover with opacity change. Create a single image, make it transparent normally and less transparent on hover. With a transition of course.
• Multiple backgrounds to achieve a Silverback parallax effect.
• Enriching form elements with a background gradient and border radius.
• Making form buttons prettier with text-shadow, border-radius, box-shadow and a background gradient. Animate the focus styles.
• Use scale transform with box-shadow and a transition for hover on images in gallery.
• Rotation on hover for a single degree with a transition.

Takeaways

You can use CSS3 today, but know what others are missing so they don’t miss critical visual cues. Be subtle with these things or we’ll end back at using transitions to make stuff blink.

Luke Wroblewski – Mobile First!

Web products should be designed for mobile first. (Even if no mobile version is planned.)

Mobile is a big opportunity for growth, but you need to think about different things than when you’re doing web development like:

• Multiple screen sizes and densities
• Performance optimization
• Touch targets, gestures, and actions
• Location systems
• Device capabilities

Designing for a smaller screen size will make you focus on core actions. To do that you’ll need to know your users. You should focus on iPhone, not (only) because of its popularity but also because it sets the design expectations very high. It also doesn’t allow any hidden features that hide in menus pressed by buttons – everything needs to be on the interface. When designing you should define device groups, create a default reference design and define rules for content and design adaptation – opt for web standards and a flexible layout. Technically you need to take care that you reduce requests and file size. You should take advantage of HTML5 that allows you to cache things locally and gives you the canvas tag that might sometimes be smarter than loading images. Think outside your web box – less cross browser issues means some new tricks come into play (like data URLs).

The context of using mobile applications is different. It’s not a long time sitting in front of a computer but rather quick bursts of attention everywhere, using mostly just one hand.

Mobile is innovating fast and you should think about the new capabilities to innovate yourself. Touch interfaces mean no hovers, thinking about bigger touch targets and a bunch of gestures that differ from platform to platform. Location information (from GPS, WiFi, cell towers or IP) is almost ubiquitous and can be used for positioning and filtering, but you should not forget other innovations that are less obvious like orientation information, audio & video input and output, compass, push notifications, Bluetooth connections, proximity sensors, ambient light detectors,…

Takeaways

You need to think about mobile because it’s an opportunity for growth, the constraints will give you the focus you need to make a great product and the capabilities will drive innovation in your product. But don’t forget that the design considerations are different.

Aarron Walter – Learning To Love Humans—Emotional Interface Design

There’s a lot of talk about usability of web pages, but is this enough? Usable is just edible. Would you say you go to the restaurant because their food is edible? We have a few options on how to trigger an emotional response to our designs – one of them is giving our sites personality. It’s a platform for emotional response as we like to empathize and personality invites empathy.

People will forgive shortcomings, follow your lead and sing your praises if you reward them with positive emotion.

You can use treats to give users something more. Let users discover new things. It’s the little positive surprises that make us happy.

Takeaways

Usability is not enough, we need to think about designing pleasurable experiences. We need to create an emotional response from our users and make them want to come back.

Jared Spool – Anatomy of a Design Decision

How do we make design decisions and what kind of designs exist? There are a few decision styles:

1. Unintentional design – when users will put up with whatever we give them and we don’t care about support costs and frustration (think airlines & hotels).
2. Self design – works great when users are like us and we are our own users (think 37signals).
3. Genius design – when we have domain knowledge that informs our decisions and we’re solving same design problems repeatedly.
4. Activity focused design – when we can identify users and record their activities to go beyond our previous experiences.
5. Experience focused design – when we want to improve our users’ complete experiences, in between specific activities.

There are ways of moving up the chain:

• “Eat your own dog food” to get from unintentional to self design.
• Do usability testing to get from self design to genius design.
• Field studies get you from genius design to activity focused design.
• Personas & patterns help you get to experience focused design.

There are two fundamentally opposite ways we can make decisions:

1. Rule-based decisions are based on design books, brand identities and other rules. They don’t allow exceptions and ignore the knowledge of the person deciding.
2. Informed decisions are based on design patterns and put the person deciding behind the wheel. They are good for handling exceptions.

With this in mind we can look into what is needed to do one or the other:

1. Dogma
2. Methodologies
3. Process
4. Techniques
5. Tricks

The first two are typical for rule-based decision making as they rely on a set of rules and don’t require a lot of knowledge from the person deciding. Techniques and tricks on the other hand come with experience and a lot of domain knowledge.

Takeaways

You need to know which decision style you’re using and encourage informed decisions, avoiding rule-based decision making. Techniques and tricks are more effective than methodologies and dogma even though/because they’re harder to come by.

Pete LePage – Help Us Kill IE6

A sponsored talk that didn’t really turn out as bad as some I’ve seen at other conferences (eg. FOWD). Pete presented the history and some IE9 features. He also suggested that we let IE6 users know that they might want to upgrade their browser as Facebook does.

MediaTemple Party

The party was nice – being fashionably late meant that it wasn’t too crowded and that most of the snacks had already gone. I had a brief chat about designing Drupal 7 with Mark Boulton, met Aarron Walter and Petra Gregorová formerly from Slovakia and a police man from Denmark that does web development in spare time. And I grabbed a (mt) beer and a coaster as a souvenir.

A lot has been said about why Keynote on the iPad is bad. I agree that most of the issues mentioned are a problem, but there are just a few I really care about:

1. No presenter notes. I like my numbers in notes and not on slides. In case anybody asks I’d like to be able to check the screen and tell them. How about a drawer similar to the slide index that comes from the bottom of the screen? Oh, and not removing notes on import…
2. Can’t see which slide I’m on. I have the problem of checking the projection as it is, I don’t need the software to make me do it even more. This is also problematic when using “the laser pointer” – you have no idea what you’re pointing at unless you check the projection. I could do with a faded slide in the background.

Most of the others would be nice to have, but these are just a big pain. Until they’re fixed the iPad to VGA connector was just a waste of money…

I’ve been trying to write something for some time now. As I obviously suck at blogging I decided to just post this short list of stuff that happened in between.

1. I now work part time at Zemanta. I’ve also downgraded to Head of Frontend as knowing everything as VP Engineering would be kind of hard. This gives me more time to work on my own projects.
2. I’ve been to Seattle for An Event Apart and I have proof. It was a great conference and I’m writing a review post. It’s taking more time than I expected. I should have known better.
3. I’ve been to Phoenix for IASummit. Another great conference and a great community. The closing plenary by Whitney Hess made me want to go again next year and help out. I promised to write a rookie review, but haven’t yet. I also hope to make it a review post.
4. I have an iPad. I love it. I should write a post about it but I probably won’t. First observations? I tweet more. I attribute that I’m chattier on Twitter to that and to the conferences. I need to upgrade my blog so I can blog from it. Maybe then I’ll blog more.
5. At An Event Apart Jeremy Keith said that it would be lovely if somebody made a tool that would check HTML5 for more than the validator does. I did the first version on the plane (SEA-PHX and PHX-ZUR). Marko Samastur wrote most of the Django app and it’s now online at http://lint.brihten.com. It has an API and will be opensourced soon. It is the first MMM project.
6. I started thinking of doing something very cool next year due to Andy Budd‘s convincing at the IASummit karaoke, hosted by the very cool Kevin M. Hoffman. I shall disclose the details at a later date, but it will be also a MMM thing.
7. EuroIA call for papers is open and it will only be open until Sunday, May 16 24:00 CET. The conference will be in Paris in September and I think you should check it out.

Enough about me, how about you? Who am I kidding, there’s no one out there…

Do not use jQuery 1.4 or 1.4.1 with user generated content!

jQuery 1.4 branch added some great stuff, but let a really ugly bug through. Something that you could call jQuery injection.

replaceWith: function( value ) {
	if ( this[0] && this[0].parentNode ) {
		// Make sure that the elements are removed from the DOM before they are inserted
		// this can help fix replacing a parent with child elements
		if ( !jQuery.isFunction( value ) ) {
			value = jQuery( value ).detach();
		}
...

With previous versions you could easily do $('#myElement').replaceWith('some text'); to replace the selected node with a text node. In jQuery 1.4 and 1.4.1 you can’t – but just failing does not constitute a huge bug.

If you take a good look at the code above you can easily find that if value passed is a string that looks like a selector, it will detach nodes from the document. Consider calling $('#myElement').replaceWith('html'); – the screen goes blank and everything the user has been working on is gone.

Fortunately…

jQuery 1.4.2 fixed this issue by properly using detach only when value is not a string. If you are using jQuery 1.4 or 1.4.1 and for some reason cannot upgrade to 1.4.2 (or just don’t want to), you can still just copy the whole replaceWith method from jQuery 1.4.2 to your version.

Related articles by Zemanta

• 101 on jQuery Selector Performance (java.sys-con.com)
• It’s Easy to Fall in Love with jQuery (sitepoint.com)
• jQuery: Novice to Ninja (oreilly.com)

var elm = document.getElementById('myElement');
elm.innerHTML = 'Test';
alert(elm.innerHTML);
// alerts '<div xmlns="http://www.w3.org/1999/xhtml">Test</div>'

I just figured out the problem is that one of myElement ancestors is attached to a table as a non-table element. In my case there was a div attached to a tr. Changing that div to td fixed the problem.

And they say web development isn’t full of surprises…

The traffic graph is the number of visitors per day while the conversion rate is the percentage of the visitors converted. When you go mainstream your traffic will spike and plateau at a lower level a few days later. This will screw up your conversion rate. Don’t worry though – figure out who the visitors are and fix your landing pages to target them as good as you can.

This graph obviously focuses on start-ups that have a huge conversion rate at the beginning as most of the conversion happens on tech-news sites and only already “converted” people get to your page – conversion rates of 80% are common in such cases. It should also be valid for later stage companies, but you need to adjust the conversion rate numbers. Another fact of conversion rates is that as your number of visitors grows your conversion rate will drop due to the fact that more users will be “just browsing” (think about a store in a mall).

If you don’t belive me think about the what the Twitter homepage looked like in time. The first one I saw had the public stream on it – geeky as hell. They changed that into a still somewhat geeky homepage that explained what Twitter is and helped you register. The latest one is almost non-geeky and focuses on real-time search and has a prominent sign up button.

Related articles by Zemanta

• Conversion Rate Optimization Lessons Learned in 2009 (seomoz.org)
• Breaking A Goal Into Metrics (altitudebranding.com)

I was approached some time ago by a designer who was working on a fluid design but was having problems with a HTML/CSS only solution for a fluid searchbox. The idea to create a searchbox that grows when the window grows is simple, but becomes a tad more difficult when you add stuff to the left and right of it, some being fixed width (width in px or em) and some fluid width (width in %).

As I like challenges I took it on and produced a sample that worked on most modern browsers in a single evening. They didn’t like it because it didn’t work in IE7 (cause I never checked it) even though the fix for IE (it was only IE7 that didn’t work) was trivial. After a while I went back and checked it out again, changed the code a bit and I think it’s much better now.

The simple form

Creating a fluid search box when you only have a single element next to it is trivial. What you do is wrap the input in an element and use padding to create space for the fixed element, then position the fixed element absolutely (or relatively) in the space created by the padding.

HTML:

<fieldset>
	<div>
		<input type="text" name="q" value="" />
	</div>
	<input class="s" type="submit" value="Search" />
</fieldset>

CSS:

fieldset {position:relative;padding:0;}
div {padding-right:6em;}
div input {width:100%;}
input.s {width:5em;font-size:1em;position:absolute;right:0;top:0;}

Sample

You could target the input with input[type=submit] but that wouldn’t work in older browsers.

A complex form

The complex form from the intro includes a title, a search type drop-down (select element), the input box and a submit button. This gives us four elements, two of which are fixed and two fluid – and more stuff to hack around.

HTML

<fieldset>
	<div class="l">
		<span>Find</span>
		<select name="type">
			<option>in Books</option>
			<option>in DVDs</option>
		</select>
	</div>
	<div class="c">
		<input type="text" value="" name="q" />
	</div>
	<div class="r">
		<input type="submit" value="Search" />
	</div>
</fieldset>

CSS

fieldset {margin:0;padding:0;position:relative;border:0;}
fieldset .l {height:0;}
fieldset .l span {width:3em;display:inline-block;}
fieldset .l select {width:10%;}
fieldset .c {margin:0 60px 0 4em;padding:0 .7em 0 10%;}
fieldset .c input {width:100%;}
fieldset .r {position:absolute;right:0;top:0;}
fieldset .r input {width:60px;}
* html fieldset .l {float:left;width:100%;margin-right:-100%;}

The basics

I created three elements that help me align elements. I’m using classes l for left, c for center and r for right. The left element includes the title and the type, the central element includes the search box and the right element includes the submit button.

fieldset .l {height:0;}
fieldset .r {position:absolute;right:0;top:0;}

The left element has its height set to 0 so it seemingly doesn’t take any space. The central element includes the input and needs no special positioning, while the right element is positioned similar to the simple solution – absolute and set to right.

The surrounding elements

You can set the width of these elements in any unit you like. I set the width for the span element in em, type drop-down in % to make it fluid and submit button in px.

fieldset .l span {width:3em;display:inline-block;}
fieldset .l select {width:10%;}
fieldset .r input {width:60px;}

The only thing you need to do in CSS is set the width to these elements. You need to set the display property on the span element to work around the fact that inline elements don’t allow setting of width.

The fluid input

fieldset .c {margin:0 60px 0 4em;padding:0 .7em 0 10%;}
fieldset .c input {width:100%;}

The input needs its width set to 100% so it will stretch the whole available width of the parent. That happens due to the fact that block-level elements will grow to 100% automatically and the margin and padding will “shrink” its contents. This allows setting the spacing in two different units – one for margin and one for padding. If you look at the CSS rule, you’ll see that the widths are similar to those set for the surrounding elements – of course with some spacing added.

• Right: 60px margin (width of the submit button), .7em padding (spacing)
• Left: 4em margin (3em for the title + spacing), 10% padding (type select width)

The browsers

You can check out a sample page with the complex form. Working on Windows I’ve tested it in these browsers:

• Firefox: 2.0, 3.0, 3.5
• Opera: 10
• Safari: 4
• Google Chrome: 3
• Internet Explorer: 8 (with its rendering of IE7 Standards and Quirks)

As always at least one browser had to fail – IE6 did. The problem was height:0; as IE6 will render elements as high as their content. We can work around this by changing the way we make it zero width/height so it doesn’t affect the central element.

* html fieldset .l {float:left;width:100%;margin-right:-100%;}

I’m using the IE6 CSS filter to target IE6, you can use conditional comments or whatever you like best. The rule floats the element left, making it 100% wide, but resets the position by setting the right margin to -100%.

As I’m using display:inline-block; this will work a bit different on browsers that don’t support inline-block. In Firefox 2.0 you can use display:-moz-inline-box; in the rule for the span, but make sure you put it before the inline-block.

fieldset .l span {width:3em;display:-moz-inline-box;display:inline-block;}

Last words

You might want to fix some stuff in some browsers so everything aligns nice. The techinque used is derived from the multi-unit any-order column layout by Eric Meyer as it opens your mind on how to use multiple units in a single layout without fuss. I’ve tried all the browsers I have on my dev machine and I’m not saying it works everywhere. If you find a browser where it doesn’t post a comment; if you find a better way of doing things also post a comment.

You always expect some people to send you a job application request that will not conform to what you’re requesting and that’s ok – you can easily ignore these applications. You will also always get some people who don’t fit the requirements by a mile but are trying to get “on the shortlist” for possible openings in the future – that’s ok too. And you’ll also get a lot of people that will value their own knowledge far more that they should – these are the ones I wanna talk about here.

You’ve probably met a bunch of “airheads”, “egomaniacs” or whatever you call the people that are full of themselves and describe their knowledge as expert but turn silent when you pop a simple advance question. I call them “king of the hill” types.

Assessing your own knowledge is hard

It’s in our nature to compare. My “house” is bigger than your “house” is part of our minds, even more so in Slovenia, a small market where basically everybody knows everybody. So it’s only natural that we assess our knowledge based on comparison. There’s an obvious problem with that – I will have no idea who you’re comparing yourself with and therefore your score will make no sense to me. In that sense it’s similar to confidence levels in search.

You might think setting a comparison chart would make the scores better, but it really doesn’t. If you tell a developer that he should assess his knowledge of a language based on a scale where 1 is “can read it” and 10 is “i invented it” you’ll get a lot of 8s. Which would mean they’re basically the best developer for that language in the country. When you do, you can easily think that the guy saying it is a moron and discard him as a viable candidate. And you’d be wrong doing that, at least sometimes.

Are you King of the Hill?

When people overestimate their knowledge it’s because of two basic reasons:

1. They are genuine asswipes that think they know more than the guy that invented the language, but know showing they’re an egomaniac on the interview is not smart. So they’ll lower the score to an 8 to make you feel good. These guys are usually easy to recognize as they’ll be defensive and dismiss any questions they don’t know with something like “that sucks”, “i never need that”, …
2. They really have no idea what else is out there. I was sure that in the age of internet such people don’t exist anymore, but even in computer related industries you can easily find people that got stuck in a particular part of the web of amateur forums and people of the previous variety. This means they do actually know everything, but don’t realize that everything is a lot bigger than they know.

But this is only a part of the story.

Who to hire then?

I’ve drawn a simple graph to help explain this:

Don’t hire the King of the Hill!

The beginners

As you start learning about something you’ll know that you know next to nothing. You’ll also see a lot you can learn and might even see where you want to get – as near to the “i inveted it” as possible. At that time your think you know less than you really do – these are the people you should hire only if you are willing to wait until they learn more and if you believe they can. As you learn and overcome the problems you thought were the “the big problems” you’ll go over the equilibrium and become a smart-ass.

The kings

This is where it gets interesting. Some people like to be king of the hill so they will ignore everything beyond that point. They will also make sure that people lower on the actual knowledge axis will not see over that point. They’ll have all sorts of reasons why everything beyond this point is crap. These are the people that make the most damage to development communities, as they’re usually the vocal ones. You should not hire them.

The enlightened

But as I said before they might really just have no idea what’s beyond that point. That’s easily solvable even during the interview – you can show them some code, throw around some ideas and arguments on why that’s good and some people will say “Wow, I didn’t even know all that is possible!” (yep, I actually got a response like that). You should hire this people immediately – seriously, don’t let them leave the interview without signing a contract. Tell them they’re the last interview before the decision and that you decided already and don’t need to wait. And because they’re now sure they know less than they really do, you’ll be able to get great value for money.

You must however be really careful with developers in this stage. They will climb the curve fast and soon they’ll start whining about lack of challenging work. They’ll also start to want more money. They might even want to say they want to be a team leader. When they do, they’re really just saying they want more money. Don’t confuse expert developer knowledge for managerial skills!

The experts

The best you can do at this stage is making them architect or senior developer. And with that done you need to start sending them to topnotch conferences and encourage them to write papers trying to get a gig at one of them. They’ll meet with the inventors, see that they’re actually normal people with a unique set of knowledge that is much wider than they expected. The new “lack of focus” will keep them busy and inspire them. They might become a better developer or stay at the same level, but they’ll be happy. They’ll be the kid with a new toy. With the ability to find a new toy when this one gets boring. That’s what supporting extracurricular activities and flexibility is good for.

Related articles by Zemanta

• Introducing Balloons: Free multimedia overlays for bloggers (zemanta.com)
• New Zemanta Release (avc.com)
• Making The Web Smarter (myventurepad.com)

Are you the frontend developer we are looking for?

Zemanta is developing a platform for contextually enhancing content and your job would be to help us develop tools that make this easy and fun for writers and readers alike.

If you have an exceptional understanding of Javascript and the internals of browsers, thrive on challenges and love learning new skills, then we would love to talk to you. Knowing Python and Django framework is a plus, but not a prerequisite.

“I have nothing to offer but blood, toil, tears and sweat.”

(Winston Churchill on life at a startup)

Well, not quite. Working in a startup means working in an ever-changing environment. We expect you to be flexible, do what needs to be done when needed, but offer flexibility in return. We care about good work and meeting deadlines. We don’t care where or when you do it, as long as you keep true to mutual agreements which include occasional meetings and we promise not to overburden you with work. A self-reliant member of a team is how you see yourself.

Schools you might have attended are none of our concern. We care only about how good of a developer and person you are. We expect you to send us examples of your work or explain persuasively why we should hire you. Zemanta is an international company, so your application, as much of our communication, will have to be in English.

Please send your application saved as an HTML or TXT document to jobs@zemanta.com.

Closing date for applications: 31.7.2009

In a time when practically all pages include some sort of JavaScript I am surprised that we don’t have more JavaScript developers popping up – this now surely is a full time job even in Slovenia. So you are one challenge yourself and send your job application and if you know one, send him our way…

Related articles by Zemanta

• WTF is Python (slideshare.net)

That’s why I’m supporting had in trying to become the best result for retorik and retorika on Google and save 590 EUR that people would otherwise pay to get to learn how to become the first result on search engines.

Related articles by Zemanta

• How SEO Myths can mess you up (Free Report) (web-workathome.com)
• Make Your Blog Easy To Find Thru Web Directories (raketscience.com)
• Track Your Seo Performance (franklinbishop.net)
• Luring local traffic to your Web site (money.cnn.com)
• Utilizing Google Local For Your Business (unionstreetmedia.com)