I recently read a couple of articles about employee compensation at Balsamiq . It is obvious that they really thought through this problem and came to what is an undoubtedly a generous package. It would be great to hear more about how they use OECD Consumer Price to calculate relative cost of living (since I fail to see how), but what really bothered me was a stated fairness of:

You are paid a little better than someone with your same job in your geographical area.

I am amazed at how often this view comes up in discussions I have about geographically distributed teams  and I still don’t find it fair. The only argument for it is the free market one. You are paid as little as company can get away with which in general is around average salary. Obviously this approach works only for those who can’t or won’t telecommute to somewhere with a higher salary or can’t find a more appealing environment with about same compensation. At least in our industry this certainly loses you a good chunk of top talent.

A fair compensation should reflect value added by the employee. Two people doing same work and providing same value deserve to be paid equally no matter where they happen to live. It is somewhat hypocritical to price your service based on value provided and fail to do so with service provided to you by your employees.

In essence it is also a judgement on what kind of living standard an employee deserves – about the same as peers around him. Probably alright if you happen to live somewhere like Stockholm and far less impressive in less developed parts of our planet, but fundamentally it is a judgement that shouldn’t be made by employers.

For those paid enough to meet existential needs compensation isn’t the most important part of a job or at least it shouldn’t be. It certainly isn’t for me and I doubt Balsamiq employees are unhappy with theirs. I also don’t have a problem working for an organization with such a policy, but I still think it is wrong.

A side note: have you noticed how every author describing their company practices says they are paying slightly above average? Either only people from above average companies write these kind of articles or some of them have to be delusional.

I was talking to my wife today about why an “Unknown Source” is becoming the most common source of visits on Flickr . My guess is that it is almost certainly because a Referer header field is missing in page requests and Flickr is only relying on presence of this piece of data to discern sources. This might have made sense when browsers ruled the web, but we don’t live then anymore.

Simply put referrer field can be added to request only when request was triggered from source which also has an URI address. Every web page has it since its address is also an URI, but most programs don’t.

That’s why referrers aren’t missing only from visitors using paranoid browsers or security software that stripped it out of requests, but also when page is visited from a link embedded in emails or instant messages.

Requests without referrers used to present a small enough subset of visits that most of us didn’t care. I first noticed this changing when Twitter clients became popular and now there are tons of apps behaving like this. With XMLHttpRequest Level 2  even web developers will get a choice of making anonymous requests which won’t include potentially private data like referrers.

That’s nice. I have certainly visited places which I wouldn’t want to share with strangers. But I suspect this is not the common case and most of the time we don’t care telling which page or application sent us there.

Nobody can precisely predict future so specifications can never be perfect. But I am always amazed when reading core web specs like HTTP’s how insightful their authors were. That most programs don’t have a URI does not mean that they couldn’t. Practically anything can and definitely more things should.

In principle it is possible for each program to have its own address which could be used as referrer when a better option doesn’t exist . I suspect this would be against the spirit of specification, but likely not against its text.

However better options often do exist. Lets take Twitter as a popular example. Every link that triggers a visit from Twitter was included in at least one tweet and every tweet is also published on web. It might not be accessible to everyone, but it does have an address. I see no reason why that address could not be used as referrer by Twitter clients.

It is originating content or its address that interest me, but really, almost anything truthful beats an unknown source. Just knowing name of the service (like Twitter) or app used (e.g. Tweetdeck) would be better than nothing. By the way there is another header field that could provide such insight: User-Agent . Sadly it is notoriously unreliable and often missing as well, but that’s another long story.

So, if I come back to Flickr. I can’t really tell how much Flickr can or could know. I suspect more than it tells, but I would be astonished if they are not mostly in the dark too. Web was largely built by people too busy (and often too lazy) not to cut corners. Meaning: learning and doing as little as possible to get something to work and sometimes we pay price for our ignorance. But it’s a small price compared to waiting for Xanadu .

After years of personal embarrassment I finally managed to update look and code of my website. This actually happened last week and I wanted to write this post sooner, but other things came in-between. There are still bugs I need to fix (iPad footer is better than it was, but not fine), but overall I’m pretty happy with how it turned out.

This was a second site I built using media queries and I learned lots. When I learn a bit more about mobile web, I might write a post about few gotchas for new developers, but this is not that post. This post is about <address> tag because it bugged me when I made that first design and I spent a remarkable amount of time on it again.

My problem with it came down to its definition. <address> can be used only to mark up contact information about content’s author. In HTML 4 this was limited to authorship of whole page. For HTML5 it was “widened” to authorship of sectioning element like <article> (so if you have more than one article on page, each can contain its own, different, address for its author). You can’t however mark any address with it and after lots of searching I found this old message from Ian Hickson which explains why (I’m not aware of any later clarifications).

I don’t agree with everything said. Mostly correct use is not necessarily a proof of well-designed element. My bet would be that <address> was a rather unknown tag exactly because of its limited use and was thus used mostly by those that dig deeper into standards, which sound also like people who care  how things are used as expected.

Still most points are valid. Loosening definition would make it less meaningful. There are microformats that you can use instead and most annoying problems (allowing only inline content) have been fixed. We also have better tools for parsing HTML so  it really doesn’t matter much if its definition feels completely right or not. It’s good enough.

At the end I still decided to mark my contact information on my homepage with <address> anyhow (augmented with hCard ), because I am after all the sole author of this website.