Archive for April, 2009

font-weight: broken;

Tuesday, April 28th, 2009

I’ve just been doing some experiments with font-weight for my latest project that is soon to be released. It appears it’s another prime example where browser vendors have spectacularly failed to implement an incredibly vague and woolly W3c CSS spec,  causing a messy, ugly, time consuming birdsnest of behaviour.

 The behaviour specifically is regarding the keywords: “lighter”, “normal”, “bold” and “boldest” , now the trouble really stems from the fonts themselves, which have no formally recognized weighting system and use the keywords

“Regular, Roman, Book, Medium, Semi- or DemiBold, Bold, or Black”

to describe their relative darkness.

GREAT. That makes things easy then, so we’ll just rely on the W3C to give us a scale from 100 to 900 that maps these possible darkness to one of the increments of numbers (although it fails to mention why 100-900 was chosen?A random whim?), hmm, wait a minute, that means the keywords “lighter”, “bolder” and “bold” mean bugger all as they’re totally inconsistent from font to font.  Apparently normal is “synonymous” with 400 and bold is “synonymous” with 700 but “synonymous” isn’t much fr*cking use, as in the world of computers we need ACTUAL CONSTANTS to be able to do anything robustly programmatic with them.

ARGGGGGGGGG!

So to further this I decided to conduct some tests with a javascript test page to see what I got from the different browsers. You can see the test page here and the results are pasted into this file here.

To summarise, it’s a total mess, the webkit browsers seem consistent but completely at odds with the spec, saying almost everything is “normal”, firefox 2 & 3 does a weird behaviour where it makes lighter and bolder 1 (enter random boldness unit here) thing higher than the synonymous “normal”, in a kind of perverse trick, IE6, 7 and opera all seem to interpret the spec as one might expect (have I jumped into some kind of parrallel universe where Microsoft got something right - cue argument about 5.5’s box model was correct…) and have implemented it so lighter is 100, normal is 400 and bold is 700.

So  forget font-weights returning something consistant cross browser, they’re obviously another CSS property that was deemed unimportant enough to care about. Thanks browser vendors, you’ve just wasted two evenings of my time.

Posted in javascript/css | No Comments »

Productivity vs. Cognitivity.

Thursday, April 23rd, 2009

ok ok, I know cognitivty isn’t an actual word but it makes for a better sounding title, and you all get the idea, if you don’t I’m about to explain it anyway.

So having freelanced for a few years,  I’ve had the good fortune to work at a range of companies, and I’ve got a pretty good comparison basis of how hard different companies work and specifically how hard programming departments work.

I’ve seen companies where being asked to work more than half an hour was the greatest outrage, companies where if you didn’t work an 80 hour week, you were a lightweight, and companies that were somewhere in-between.

So it’s the extremes i’m interested in and who thinks what about what, an obvious example is google, who allow their employees 20% of their time to experiment with their code, which is a good start, although I feel lacking in direction, it’s one thing to give time to people to experiment, but the greatest inventions come are born of conflict and there’s nothing as compelling as a good project to analyse and build a tool to enhance. Companies like Yahoo and Google almost seem to give some of their staff tenure and operate in a similar fashion to a university. Other more production orientated consultancies, seem to care very little for growing their resources and see them more as a throw away commodity like workers in a Nike factory somewhere in the 3rd world.

But that said some of the more liberal companies can go too far, and allow their programmers to spend 99% of their project time trying to invent faster ways of doing things at the sacrifice of actually achieving anything, which is both frustrating for the business and the programmer.

So where is the happy medium between forcing your staff to produce goods 100% of their time vs. allowing them to experiment all day long.

Well, if I were a client I would expect the following: I would want half of the time spent producing the deliverable, and half of the time inventing faster ways of producing the deliverable, that way, I get my product and I know that next time I want it built it should only take half the time, and if it doesn’t I’d be demanding to know what happened to my investment?

That means that someone needs to come up with a way of accurately measuring output AND innovation and potential time/cost saved, unfortunately it seems current agile implementations are not up to the task…

Posted in Uncategorized | No Comments »

Are sitewide redesigns counter-productive?

Tuesday, April 14th, 2009

For the last ten years I’ve made a living from implementing redesigned/rearchitectured websites, but it’s started to dawn on me that perhaps this isn’t the right approach to be going forward with.

As a coder I learned pretty quickly, the best way to debug something is the scientific methodical way. 

The first step is to identify the area of code/class which the bug is in,  this can be done in many ways so I won’t delve into my particular preference.

The second step once you have said offending class/method is to start logging and commenting sections out to see what fixes it. Now this is the step I’m interested in. 

Depending on your skill level with the language on first pass you may have a ‘hunch’ as to what the problem is so you’ll go straight for the quick win, you’ll change a variable and retest to see if it fixes it. If it works ‘woo hoo’ -> moveon. If not then go to the beginning and start blindly commenting out and testing variables, you may be in for the long haul.

The key though, and if you spot someone not doing this it either means they’re exceptionally competent or exceptionally inexperienced (read:  stupid, a moron, dimwitted, a duh) is that you do one test at a time.

The reason, if you change more than one thing and then retest and it works or breaks, how do you what did what? You don’t.

So a question: when as a company you do a sitewide redesign, how do you expect to know which elements for your redesign worked and which didn’t? Answer: You don’t. You hope that the successes outweigh the failures and that your client decides to pay you regardless. It’s very similar to the problem of knowing if your advertising is successful.

What secret successes went to the grave with this building demolition?

So rather than doing sitewide redesigns just for the sake if it, It would be far more prudent to take the existing site identify key areas which have both flaws and successes and start drawing up experimental alternatives to be designed and built, which can then be a/b tested and analysed in the existing framework and then ported easily into a new design ethos. This way there would be no more of the ‘hit it and hope’ mentality plaguing web design today.

Tags: , , ,
Posted in Uncategorized | No Comments »

IndexOf is faster than regex

Saturday, April 4th, 2009

I’ve just been doing some extreme performance testing on javascript. I wanted to see that if I scaled up massively (10,000 calls each) which of these two functions is faster and it turns out that doing:

var string = "test";

var regex = /test/;

regex.test(string);

is actually slower than doing:

var string = "test";

string.indexOf("test")

by a magnitude of x3, so if your doing a bunch of tests, then using indexOf to see if the string exists is actually more perfomant, the counter argument being that less coders know what indexOf does, but most know what regex does.

Tags: , , , , ,
Posted in javascript/css | 2 Comments »