Terminally Incoherent

I wasn’t going to comment on Joel Spolsky’s Martian Headsets ramble for two reasons: it was an obvious troll-bait, and people much smarter than me already pounded it into the ground. But alas, the Spolsky FUD seems to have infected one of the less known blogs that I really enjoy. I don’t blame Shamus though - he is a good man. It’s just that well written FUD is contagious like brain rot. And Spolsky went all out - he even has pretty pictures all over that article. So I kinda feel that I must counter measure this until it spreads any further.

Joel is essentially trying to tell us that W3C standards are bad because there is no 100% compliant implementation in existence. Therefore he advocates completely ignoring them, and and claims that the efforts make IE8 default to standards mode are ill conceived.

Only he is missing the forest of the trees here. If there is no standards, how can we even strive for interoperability between browsers? Joel doesn’t care because he only uses IE and he is convinced that 98% of the universe does the same (which is gross exaggeration). In the real world however, the standards give us an ideal towards which we can strive for. Different platforms will implement things in different ways, and by comparing implementations we can slowly improve and creep toward that ideal. Sooner or later everyone will be roughly on the same page, and the differences in implementations will be small enough to be negligible. Stefano Mazzocchi does a much better job of describing this process, so take a look on his post on the topic.

In a way this has already happened. Most of the major browsers out there including Firefox, Opera and Safari are perfectly happy displaying the same pages in very similar ways. The standards problem only becomes apparent when IE enters the equation - it has always been a problem. If we bring IE8 into the manifold, then this inter operation and compability issue will slowly phase itself out of existence. I think Sam Ruby hit he nail on the head when he said:

Web pages like Google Maps work on other browsers. Not because of a mythical, platonic “standard” in scare quotes. But because of standards that are actually implemented compatibly. And because in standards mode, these other browsers don’t implement the non-standard IE only Javascript objects that Google Maps checks for.

After reading Joel’s long winded rant, one might come to the conclusion that these “standards” are some truly arcane mysterious texts. But they are not. Granted, they are not simple and straightforward, but it’s not like there is no existing body of knowledge, and interpretations out there. Volumes of text have been written on the nuances of these standards, and there are groups and communities out there completely devoted to pouring over these documents and interpreting them. There are people who specialize in this stuff and will actually hire them to consult you on any and all standards related questions and concerns. But Joel conveniently ignores this fact. He goes on to say:

The precise problem here is that you’re pretending that there’s one standard, but since nobody has a way to test against the standard, it’s not a real standard.

Mark Pilgrim, whose post on this topic is hilarious, eloquently sums with one short sentence:

I have never heard of test suites.

There are test suites, applications and comparison tables you can use. And if anything else fails, you can go straight to the source and hit up the W3C mailing lists. But Joel is not done, he goes on this weird tangent - just bear with me while I quote it in it’s entirety:

If you’ve ever visited the ultra-orthodox Jewish communities of Jerusalem, all of whom agree in complete and utter adherence to every iota of Jewish law, you will discover that despite general agreement on what constitutes kosher food, that you will not find a rabbi from one ultra-orthodox community who is willing to eat at the home of a rabbi from a different ultra-orthodox community. And the web designers are discovering what the Jews of Mea Shearim have known for decades: just because you all agree to follow one book doesn’t ensure compatibility, because the laws are so complex and complicated and convoluted that it’s almost impossible to understand them all well enough to avoid traps and landmines, and you’re safer just asking for the fruit plate.

WTF in hell? I actually laughed as I was reading this. I hope you find this funny too, because this whole big paragraph shows exactly where Joel is coming from, and how far he is of the mark. They are nothing like religious orthodoxy. The interpretation of religious scriptures accepted by the Mea Shearim Jews is pretty much set in stone. In 50 years they will probably be using the same interpretation - perhaps slightly adjusted to account for advances in technology and changing lifestyles. Implementations of web standards are not meant to be religious orthodoxies. If MS doesn’t make IE default to standards mode now, then they will be in the exact same situation in a year or two when they are ready to release IE9. If we keep defaulting to quirks mode, and continue rendering web pages in the same half assed IE6-7 mode, then why even bother implementing the standards? Why even make any changes to the rendering engine? Let’s freeze the code at IE7 stage and only improve the browser by adding UI features from now on. That seems to be what Joel is implicitly suggesting.

Gordon Weakilem makes a very good point when he says:

I mean, really, after Joel harping on about “smart, gets things done”, would Joel accept “Those documents are super confusing” as an excuse in an interview, or for why a developer doesn’t understand something like operator precedence? Really, is there an excuse for ignorant or lazy?

Indeed my friends. Joel’s whole rant is about how difficult, confusing and impossible to implement the standards are. I guess we ought to give up then, right? A mark of a good software developer is that he simply abandons a project at the first sign of trouble.

But the best part is that even Joels summary near the end of his lengthy triad contains a hidden contradiction:

98% of the world will install IE8 and say, “It has bugs and I can’t see my sites.” They don’t give a flicking flick about your stupid religious enthusiasm for making web browsers which conform to some mythical, platonic “standard” that is not actually implemented anywhere. They don’t want to hear your stories about messy hacks. They want web browsers that work with actual web sites.

Let’s for a minute assume that 98% of the world does use Windows, and that they will all install IE. If my website doesn’t work in IE8 on the release date, guess who is going to get publicly flogged and then castrated by the upper management? If you guessed it was me, you are right. My boss is not going to give a flying fuck that the IE changed the way it is rendering pages. The people who will notice this change the most will be web developers who will have to fix hundreds of web pages, not the customers. No major company will allow their page to remain broken once IE8 release is imminent.

Here is what I secretly think will happen - IE8 will get released, and end users will blog at length about all the new features in the browser. Most of them won’t even notice the standards thing. Few legacy applications, and poorly maintained pages will break, but Google, Yahoo, Myspace, Facebook and all the other big and popular sites will work like they always did, or better.

Sure, few people here and there will blame IE8. Are they going to install Firefox? Yeah, right. The people who know about Firefox either don’t like it, or are already using it. IE8 breaking won’t push people towards alternative browsers. And surely it won’t make them abandon windows altogether. That would be the day! Worst that will happen is that they will downgrade back to IE7 - if they can figure out how to do it. Most of the clueless users from Joel’s example will simply shrug it off and learn to live with it.

You don’t even want to know hoe many times I heard my users complain about “the new Microsoft” (IE7 in luser speak) that got installed on their computers. When I offered to downgrade them back to IE6 almost all responded with a surprised “you can actually do that?”. Users will survive - they are already used to Microsoft breaking their shit.

So there. This is my Spolsky headsets rant. Regrettably, that’s another link to Joels page, and probably few dozen page views (considering my click through rates) and few extra dollars in his adsense account. Maybe I should take cue from Mr. Spolski and post some horribly inflamatory, nonsense every once in a while and then just sit back and rake in the cash. Unfortunately, while I’m shameless and blunt at times I have that thing… I think they call it integrity or something like that. Oh well… Now that it’s over with, let’s get back to usual craziness.

Few days ago I did that whole 3-value checkbox thing basing it on some script I found online. I went back and I re-implemented it using some JQuery magic. I’m not going to reiterate the whole setup here. I recommend that you check the linked post for details. You can find the JQuery-fied code below:

$(document).ready(function() 
{
   checked = '/path/to/checked.jpg';
   unchecked = '/path/to/unchecked.jpg';
   na = '/path/to/na.jpg';
   i = 0;
 
   // replace the checkboxes with images    
   $("form.funky_form > fieldset.funky_set :checkbox.funky_box").hide().each(function() {
 
      img = document.createElement('img');
      img.className = "funky_image";
 
      switch($(this).val())
      {
         case "0":
            img.src = unchecked;
            $(this).attr("checked", "false");
            break;
         case "1":
            img.src = checked;
            $(this).attr("checked", "true");
            break;
         case "2":
            img.src = na;
            $(this).attr("checked", "true");
      }
 
      // these will let us identify which image was clicked
      // and which checkbox does it belong to
      $(this).attr("id", "input" + i + "image" + i);
      $(img).attr("id", "" + i + "image" + i);
 
      i++;
 
      $(this).before(img);
   });
 
   // add onClick functionality to the new images
   $(".funky_image").click(function() {
 
      // select the checkbox corresponding to the clicked img
      t = $("#input" + $(this).attr("id"));
 
      switch(t.val())
      {
         case "0":
            $(this).attr("src", na);
            t.val(2).attr("checked", "true");
            break;
         case "1":
            $(this).attr("src", unchecked);
            t.val(0).removeAttr("checked");
            break;
         case "2":
            $(this).attr("src", checked);
            t.val(1).removeAttr("chekced");
      }             
   });
});

The major difference from the other version is that I’m much more discerning in which checkboxes get converted. The code will select only a box that is of the class funky_box and is inside a fieldset with a class of funky_set and inside a form with a class of funky_form. I’m mostly doing that to show power of JQuery - this is all specified in that very first select statement. I was trying to do something similar in the old code, but I was getting hung up on the silly DOM gotchas. JQuery makes this easy.

Also note the chaining functions. The first line after I declere i both hides all the selected check-boxes and begins the each block. Similarly, check out the second switch statement. In several places I set the value of t and change the checked attribute on the same time. It’s very expressive, and lends itself toward very compact and concise code.

Here is the HTML for the form to go with the code above (note the inclusion of the fieldset tag):

<form name="funky_form" method="POST">
      <fieldset class='funky_set'>
         <label for="c1">
            <input type="checkbox" name="c1" value="1" class="funky_box" checked>
            Some Important Task
         </label><br>
 
         <label for="c2">
            <input type="checkbox" name="c2" value="1" class="funky_box" checked>
            Some Important Task #2
         </label>
      </fieldset>
 
      <label for="c3">
         <input type="checkbox" name="c3" value="1" class="funky_box" checked>
         This is a checkbox with the funky_box class outside the funky_set
      </label><br><br>
 
   <input type="submit" value="Submit">
</form>

How readable is this version? To me it is actually better because it’s smaller, and more compact. To someone who never worked with JQuery it might be a bit confusing at first but I think you get used to the weirdness pretty quickly. I find the selection statements much more elegant than nested loops for example, even if they might The more code I can see on my screen the better. I’m not golfing though - all the methods and most variables have meaningful names (well, except stuff like t and i but you know how it goes).

Which version do you like better?

Here are two interesting quirks in the way JQuery works. Let’s say you want to check all the check-boxes on the page - how do you do it? It’s trivial:

$(":checkbox").attr("checked", "true");

Now quickly, how do you un-check all the check boxes on the page? If you said:

$(":checkbox").attr("checked", "false");

You are wrong. Despite the fact that if you use a more standard notation and say for example:

document.myform.mycheckbox.checked = false;

it will give you the desired result. The JQuery call however does not work. In fact, it does the exact opposite - it will set all the check-boxes on the page to their checked state. Apparently for the few funky attributes like “checked” and “selected” the second argument of the attr() method call can be any non-empty string. It makes sense because you actually don’t have to give these attributes an explicit value in your HTML code for them to work. So how do you un-check a box in JQuery? There are two ways. First one, and the more sure-fire one is to remove the checked attribute altogether:

$(":checkbox").removeAttr("checked");

Second one which has worked for me for some reason was to set the attribute to the empty string:

$(":checkbox").attr("checked", "");

Same goes for select attributes in combo boxes and list boxes. You need to remove them or set them to an empty string, or they won’t go away.

Quirk number two: axjax weirdness. Look at the code below:

$("a").hover(function() {// do something});
$("#sometrigger").click(function() { 
   $("#container").load("/some/page.html #links"); });

What am I doing here? I’m adding some hover functionality to all the links on the page. Then I add an on-click even to #sometrigger element. When it is clicked I want to load the contents of #links from /some/page.html into #container asynchronously. Where is the quirk? The hover functionality will not apply to the dynamically loaded links. It’s weird, but that’s just how it works. So if you want this functionality on all your links you will need to reapply them:

$("a").hover(function() {// do something});
$("#sometrigger").click(function() { 
   $("#container").load("/some/page.html #links", 
      $("#container > a").hover(function() {// do something});
         });
   );

It’s a little bit silly, but it kinda makes sense. You may not always want to apply the same events and formating to newly loaded html. But if you don’t expect it, it may throw you off. One you know about it however you learn to compensate for it. I’m being told that folks coming from the Prototype community are hitting this little quirk like a brick wall because their framework behaves in the opposite way (ie. the effects and behaviors are applied to the ajax loaded html).

I’m doing more and more work with JQuery lately, and as I mentioned several times before I’m totally loving Javascript again. It is really a very concise and terse framework so it doesn’t really take long until you start feeling like you know it inside out. But it is very powerful and learning to use it properly, and efficiently will probably take me a while. Last time when I was raving about it I did it without any neat code samples to show you how cool it is, so this post will have a few.

One nice thing about this framework is that it is all about closures. Most of the JQuery functions take a pointer to a callback function as an argument, and the selectors automatically loop through DOM instances they match forcing you to write very different code. For example, if I wanted to add an onClick event to all links on my page with regular javascript I would probably do something like this:

function addOnlclickToLinks()
{
    myLinks = document.links;
    for(var i=0;i < myLinks.length;i++) 
    {
       myLinks[i].onclick = return onClickFunction();
    }
}
 
function onClickFunction()
{
    // the on click code goes here
}
 
 window.onload = addOnClickToLinks

It’s readable, and understandable code, but it looks messy. JQuery saves you tons of typing and really makes the code more ellegant:

$(document).ready(function() {
    $("a").click(function() {
        // on click code goes here
    });
});

This is a totally new way to code, and it forces you to think in a much different way. After doing this for a while, you come to rely on this new way of coding to the point where it trips you up. For example, the other day I wanted to do something like this:

$("input.someclass").after(function() {
    if($(this).val() == foo)
    {
        // do somethign complex
    }
    else
    {
        // do something else
    }
 
    return something;
}());

What I want to do here is to generate element called something based on the value of the selected input - and the process may actually be quite complex, requiring several lines, or multiple function calls. The sample above doesn’t work because I’m using the $(this) selector in the wrong context. To the best of my knowledge, the way to achieve this sort of thing would be by doing:

$("input.someclass").each(function() {
    if($(this).val() == foo)
    {
        // do something complex
    }
    else
    {
        // do something else
    }
 
    $(this).after(something);
});

The each function actually iterates through all the selected elements, and runs the passed function in the context of each one. At least I think this is how you would do it.

Either way, it is really a much nicer way to program and the way you select DOM elements and interact with them is consistent across platforms. If you still haven’t tried JQuery, I highly recommend checking it out. Javascript is really a great language - it has a somewhat traditional syntax (braces and semicolons, ftw) but all the awesome features of a modern highly dynamic scripting language like Python or Ruby. The only thing that is holding it down these days is the inconsistency in which it is interpreted across browsers. JQuery fixes that issue, and draws on some of the cool dynamic features of the language to really make your life easier.

Recent conversation with the PHB regarding internal web application project:

PHB: This is all good, but these 4 items here need to have a “not available” option
Me: Ok, no problem. I’ll change it into a yes, no, n/a radio buttons instead of check boxes
PHB: Oh, no - I like the check boxes. It’s just that sometimes I want to be able to say N/A there
Me: So… You want like two check boxes?
PHB: No, just one. But with N/A option.
Me: But… Check boxes just don’t work like that - they are on/off kind of thing
PHB: Sure they do. I saw it on several websites.
Me: Oh, ok… Can you send me a link? I’d like to see how they did it.
PHB: Oh, hmm… It was a while ago. If I remember where I saw it, I’ll shoot you an email.

So… Any of you know how a 3-state checkbox looks like? Cause it beats me but powers that be seem to be dead set on having one. I could try to argue in favor of radio boxes or something more sane, but it seemed like a waste of time. So instead I decided to make it work. Just how?

I figured it would be like a toggle switch that oscillates between 3 states. Regular HTML check boxes can only be checked or un-checked so I gave up on them initially. I figured I could use a button as a toggle. It would have an attached onClick script which would change the button’s appearance and then modify a value of some hidden input field. Then I realized it was stupid. Not only was it too complex, and hackish but also completely failed if Javascript was disabled.

I really needed the form to at least half-work without Javascript - for example just default to standard on/off check-box forgetting about n/a option. And for that I needed to stick with the HTML check boxes. I would have to style them or change them up somehow. So I searched for some code that would let me do it with minimum effort and minimum dependencies.

BrainError’s script seemed like a good fit. He wrote some code that allowed me to replace check boxes with images on the fly which is really what I wanted here. Naturally I had to modify it to fit my needs. You can see the changes below:

var inputs;
var checked = 'checked.png';
var unchecked = 'unchecked.png';
var na = 'n-a.png';
 
function replaceChecks()
{
   //get all the input fields on the funky_set inside of the funky_form
   inputs = document.funky_form.getElementsByTagName('input');
 
   //cycle trough the input fields
   for(var i=0; i < inputs.length; i++)
   {
      //check if the input is a funky_box
      if(inputs[i].className == 'funky_box')
      {
         //create a new image
         var img = document.createElement('img');
 
         //check if the checkbox is checked
         if(inputs[i].value == 0 )
         {
            img.src = unchecked;
            inputs[i].checked = false;
         }
         else if(inputs[i].value = 1 )
         {
            img.src = checked;
            inputs[i].checked = true;
         }
         else if(inputs[i].value = 2 )
         {
            img.src = na;
            inputs[i].checked = true;
         }
 
         //set image ID and onclick action
         img.id = 'checkImage'+i;
 
         //set image
         img.onclick = new Function('checkChange('+i+')');
         //place image in front of the checkbox
         inputs[i].parentNode.insertBefore(img, inputs[i]);
 
         //hide the checkbox
         inputs[i].style.display='none';
      }
}
}
 
//change the checkbox status and the replacement image
function checkChange(i) 
{
   if(inputs[i].value==0)
   {
      inputs[i].checked = true;
      inputs[i].value = 2;
      document.getElementById('checkImage'+i).src=na;
   }
   else if(inputs[i].value==1)
   {
      inputs[i].checked = false;
      inputs[i].value = 0;
      document.getElementById('checkImage'+i).src=unchecked;
   }
   else if(inputs[i].value==2)
   {
      inputs[i].checked = true;
      inputs[i].value = 1;
      document.getElementById('checkImage'+i).src=checked;
   }
}
 
window.onload = replaceChecks;

This is the script. To get it working all I need is to create a form with a name “funky_form”. The original script looped through all the input fields on the page which seemed like an overkill in my case. I’m also applying this formating to the check-boxes with the “funky_box” style. My form may have 60-80 input fields, many of which are check-boxes, but only 4 or 5 of them in a very specific section need to have this behavior. I was fine with using regular check-boxes for the rest of them.

It’s also important to add that the getAttribute method does not work in IE when you try to grab the class of your element. BrainError was using it to select on type, which was working well. I’m much more selective, and it took me a while before I realized that IE borked this method. Fortunately you can use the className property instead - and it works equally well in FF as it does in IE.

The form would look something like this:

<form name="funky_form" method="POST">
      <label for="c1">
         <input type="checkbox" name="c1" value="1" class="funky_box" checked>
         Some Important Task
      </label><br>
 
      <label for="c2">
         <input type="checkbox" name="c2" value="1" class="funky_box" checked>
         Some Important Task #2
      </label><br>
 
      <label for="c3">
         <input type="checkbox" name="c3" value="1" class="funky_box" checked>
         This is a checkbox with the funky_box class outside the funky_set
      </label><br><br>
 
   <input type="submit" value="Submit">
</form>

If you want to see it in action, check out the working demo.

All my boxes all have distinct names which intended. This way I can individually access via the $_POST array from PHP when the form submits and extract their value as needed. You may also have noticed they all start checked. This is actually a requirement in the spec, but also a fall-back measure.

If you disable Javascript you will see regular check-boxes. They start with value 1, and if they are not checked (and thus not present in $_POST) they will default to 0. This way you can submit the form normally - you just won’t be able to set them to n/a.

There is a small downside - when the page loads, you can see the regular check boxes for a brief second or two. But that’s just the way this script works. Suggestions and corrections are welcome. I tested this in Firefox 2.x and IE 6.x+. Let me know if it fails miserably in your browser of choice.

For a while now, I have been searching for a good Javascript framework to mess around with. I think I finally found one that I really like. JQuery is a 15 Kb bundle of pure fucking magic. It is tiny compared to some of the other frameworks out there, and at the same time very powerful. What can it do? Tons of stuff. First thing you notice is of course eye candy things like sliding and hiding divs, easily manipulating tons of data on the page and etc.

The best thing about JQuery however are the plugins created by the very active community. For example, there is a small script out there that lets you sort HTML tables on the client side. Normally when I dumped data out of the database on the screen I would implement sorting by simply making another database query with a modified WHERE clause and then re-draw the whole table with the new dataset. But why should I use such a database intensive method when JQuery makes it possible to quickly sort a large table without even reloading the page using client side resources?

Go check out the demo on the tablesorter plugin website. It is really a great piece of work. Christian Bach deserves major props for putting this together. To tell you the truth, I never really considered sorting of tables in javascript mainly because the amount of effort it would take on my part. Implementing the sorting algorithm and the transformations would just be so much more time consuming than simply writing a quick SQL query. It somehow never seemed worth the effort to me, until now.

The way I see it, this method of sorting has two major benefits over the old fashioned server side method. First, as I mentioned earlier it takes some load of the database. Second, the sorting will seem much faster to the user because we are not reloading the page. It should even be faster than an asynchronous call as these things tend to have a visible delay. Tablesorter manipulates DOM objects which are already loaded in clients memory - there is no loading or waiting required.

It even comes with a neat pager functionality which could come in handy. Then again, I’m not absolutely convinced that paging should be done on client side for very large tables but it is a nice feature to have just in case you need it.

Just to illustrate how easy it is to apply it to an existing table here is what you need to do. First download both JQuery and Tablesorter and dump them somewhere. Then simply add following calls in the header:

<script type="text/javascript" src="/path/to/jquery.js"></script> 
<script type="text/javascript" src="/path/to/tablesorter/jquery.tablesorter.js"></script>
<script type="text/javascript">	$(document).ready(function() { $("#myTable").tablesorter(); } );</script>
<link rel="stylesheet" href="/path/to/tablesorter/themes/blue/style.css" type="text/css" media="screen, print" >

Then simply make your table id to be “myTable” and it’s class to be “tablesorter”. The first one is mandatory for the sorting logic to work. The “tablesorter” class is defined in the css stylesheet you link to and it will create nice headers and table layout for you:

<table id="myTable" class="tablesorter">
	<thead>
		<tr>
			<th>Column 1</th>
			<th>Column 2</th>
			<th>Column 3</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>1</td>
			<td>a</td>
			<td>foo</td>
		</tr>
		<tr>
			<td>2</td>
			<td>b</td>
			<td>bar</td>
		</tr>
 
	</tbody>
</table>

That’s it. You are done. Your table is completely sortable now, by every column, and is even nicely formated. It couldn’t be easier than this. And yes, you do have to use the thead and tbody tags.

There is one caveat though. When you download current release, be aware that the jquery.tablesorter.pack.js file is broken for some reason. It will work just fine in Firefox, and Opera but in IE6 it will throw some sort of cryptic bug. It might be some artifact introduced in the packing process or something like that. If you use jquery.tablesorter.min.js which is only marginally larger in size, this issue goes away. Go figure. It’s still a great tool despite this little glitch.

I think I’m sold on JQuery. It is tiny, and yet extremely powerful toolkit, and I highly recommend checking it out.

Here is a hypothetical situation: I introduce you to a total n00b - some dude who is completely green, and has no programming experience whatsoever. Let’s give this hypothetical construct some generic name - for example Guy. I bring this guy into your office, sit both of you down and say that you have 3 months to make Guy into a kick ass Java programmer. Or Python programmer. Or Ruby. Whatever floats your bout. I’m going to use Java for the sake of consistency but feel free to mentally substitute it with your favorite language of the month. Either way, you have 3 months to take him from absolute zero to a point where he can be given a moderately challenging assignment to work on. He will be working on the back end, writing complex algorithms doing some sort scientific analysis or will end up writing some crazy GUI stuff. Here is the language, here is the deadline, make it happen! This is all you will be doing, and you are free of all your other obligations until this teaching project is done. Could you do it?

Let’s assume that Guy is fairly bright student who has a good grasp of technology in general, and is fairly good at abstracting ideas and thinking in abstract terms which is kinda required here. Other than that, he is a blank slate - he never programmed before but he is eager and excited to start learning. I think this could be done - I think you could take someone like that, and train him effectively in a relatively short amount of time.

Our aim is to teach him Java but we will really be teaching him programming from scratch. He will become a programmer, and once we are done he should be able to pick up another language an learn it on his own. But we have to start with something to teach him concepts so we pick one. Right from the get go we can build a consistent curriculum that will start with the simplest “Hello World” example and slowly build him up teaching him the basic, then advanced concepts. It would be a fairly linear progression in a consistent environment. We teach him a new concept, then augment it, add another one, tie them together and so on.

The only time you actually have to shift gears is when you teach him about databases. You have to briefly take him out of the Java context to teach him SQL syntax, but at this point he should be able to grasp it quickly. You have to take him out of the OO paradigm to teach him the relational model. But that’s about it. As long as Guy doesn’t have to do any front end stuff for the web, it’s all clear and consistent linear progression. It is by no means an easy or trivial task, but it is relatively straightforward. There are few variables to worry about, and you always know where you are and where you need to go. When you finish, Guy will learn all the important concepts, and develop all the programming good habits he ought to have.

Now if I turn around and say, make Guy into a Web Designer capable of creating dynamic Web 2.0 applications the story changes a little bit. It is not an outrageous request to begin with - at least not much worse than the Java programmer one. It is still doable, but I submit that it is much more haphazard and confusing process. Web design is one of those areas that looks deceptively simple from the outside. I mean, how hard can it be? You write a simple back-end, slap together some HTML templates, dump it all on the server and you are ready to go. And it’s true - a lot of web apps are relatively simple to build. But taking someone from zero to a competent Web 2.0 designer dude it is really quite complex because all of the variables involved. For example, where do you start?

You could start with teaching Guy HTML which is easy. Every semester I teach basic HTML to my CMPT-109 students and I can assure you that all of them are from the statistical 60% population sample that will never be good at programming. But they all can manage to write simple websites that usually do not validate but look fine on your screen. I joke around that I teach them the wrong way to use HTML, but it’s kinda true. I usually don’t touch CSS because of the lovely caveat of browser support.

Anyone can write down bunch of HTML tags, but it takes patience and perseverance to learn all the quirky ways in which different browsers render certain things, and work around them. So the whole HTML experience is like a ride on an escalator that terminates in a vertical wall that must be scaled to progress any further.

You also need to teach Guy the client side Javascript which means you need to dive into imperative, functional programming paradigm with some OO thrown in for shits and giggles. You have to make a choice now - do you use Javascript to teach him programming principles? Or do you just make him learn few things by rote, and wait for the server-side language to really give him a solid programming lesson?

If you decide to stick with Javascript for a bit, you will hit another snag. It’s not consistent! Even simple things like walking the DOM often vary from browser to browser. So you are not only dealing with programming concepts but also weird quirks of client side language.

Then you have to make yet another huge leap and teach him server side stuff. We could do Java but we are on a deadline, right? And we still have a long way to go. So let’s pick something that is easier to pick up - a scripting language. PHP is a popular choice - mainly because it is deceptively easy to learn. Unfortunately writing good, maintainable code in PHP is actually a form of art in itself because similarly to Perl, PHP really makes it easy for you to develop really bad coding habits, and really ugly code. But you can probably take Guy from “Hello World” to dynamic HTML generation to DB access very rapidly so it’s good enough for our purposes.

In fact, it is probably better to start with the back-end language, teach him basic programming principles and then put him on a crash course of HTML, CSS and Javascript and XML. It’s probably more digestible this way. Either way though, you end up with a lot of context switching.

You are teaching Guy 6 distinctly different technologies: HTML, CSS, Javascript, XML, the server side language and SQL. They all have different rules, they all have their quirks and at least 3 of them are wildly inconsistent. The modern web application design field is an amalgamation of these very different technologies haphazardly thrown in together. It’s a mess! A good web designer who can envision and implement a working Web 2.0 application must wear many hats so to speak. He has to be a good back end programmer, a good client side programmer, he must have a knack for web design with css, and he has to have at least cursory understanding of databases. But most of all, he must be able to effortlessly switch between these domains of knowledge. When he finds a bug, he needs to be able to locate it - is it in the back end code? Is it in Javascript code? Is it a HTML layout issue? Or perhaps it is a problem with the way you generate Javascript code using PHP? This sort of multi-dimensional thinking is something very hard to teach.

In contrast, a Guy the Java dude who doesn’t work with web apps usually wears a single hat. When he finds a bug, he fires up the debugger in his Eclipse and steps through his code until he figures out what is wrong. It is a much more straightforward process which requires almost no context switching at all.

So can you take Guy from zero to Web 2.0 hero in 3 months? You probably could, only it is going to be messier, grittier and less elegant process. Unless of course you cheat and use a framework like Rails one of it’s many clones.

This is why Rails is just a huge hit these days. It’s because it automates a lot of this petty bullshit that web devs deal with on daily basis, and brings some consistency into the equation. It allows a single developer to whip out a decent, functional application using consistent methodology, without switching context every 5 minutes. 90% of the code he will write will be in Ruby. And while Rails does a lot of stuff behind the scenes, the programmer hardly ever has to deal with it. Nevertheless, Rails like frameworks are still just a crutch - they are code generators. They spit out relevant markup and sql when and where it is needed. The whole environment is still the same haphazard mess, it is just partially hidden from the developer. It is a step forward though.

I was watching some interview with Steve Yegge (if you don’t know who he is, look him up) recently and something he said in there really struck a chord with me. He said that perhaps we just need to come up with a brand new language for the web. Something designed from ground up with Web 2.0 in mind. Not a framework, but a language which would encompass and unify all these distinct domains under a single, consistent syntax and implementation. Something that would let us use that good old linear progression teaching model, instead of trying to force incompatible and often contradicting ideas into poor Guy’s head. You would define a display template, the model and controller logic, and client side processing and validation using the same uniform basic syntax. Then you would slap it on the server, and the relevant HTML, CSS and Javascript would be generated dynamically. Naturally I’m paraphrasing it here, but wouldn’t something like that be nice?

Here is an interesting question. Is it ethical to sell someone an expensive software suite the functionality of which could easily be replaced by simple 2-3 line shell script or few lines of code in the right place? Note that this is perfectly legal practice. But do you think this is fair? Or is this exploitation?

Let me give you an example. Yesterday I stumbled upon a very peculiar piece of sofware called CopyNo. It is a little GUI app which let’s you drag image files onto it’s interface, and generates a bit of HTML and Javascript which generates nasty looking hover effect for these images that you can copy and paste onto your web page. The author claims this script protects images from being downloaded using “traditional methods”. Let’s ignore for a second that this method does not work. Let’s forget about the fact that this hover behavior is extremely annoying. Let’s not dwell on the fact that overlaying your images with a transparent gif would achieve a better effect. It still wouldn’t stop people from copying images, but it would be impervious to the dreaded “disable javascript” method, and it wouldn’t scare or annoy visitors by displaying a big red circle on the page that essentially says “YOU ARE A THIEF!”. Hell, let’s not even think about the fact that implementing feature like that on your portfolio page is just about the worst thing you can do in terms of “first impression”. The only worse thing of course is creating your page entirely Flash in a way that would prevent anyone from actually linking directly to some image or album in your gallery. But that’s a whole other topic.

Let’s simply focus on the core functionality of this program. All it does is outputs 2 html tags per each picture, along with 2 lines on javascript inlined in the onmouseover and onmouseout attributes of the <a> tag. If I really tried I think I could teach my 109 class to do this. It’s not rocket science - it’s a trivial scripting trick which is used on dozens of websites out there.

Charging the user $20 for something even a novice user could learn in 5 minutes strikes me as bit unethical. It’s almost like exploiting your end user. It reminds me a little bit of those sites which ask you to pay a nominal fee to download open source applications. Granted, CopyNo is a little bit better than that because it actually does do some minimal work for the user. I can see how someone without any HTML or Javascript experience could possibly consider buying something like this. So this is not a scam - it’s a legitimate product. An annoying one, but legitimate nevertheless.

Personally though, I wouldn’t be able to sell something like that. I believe that a piece of software with absolutely trivial functionality that could be replaced with 1 or 2 lines of code has no inherent value. Not to me, and not to anyone. Especially if it’s as ineffective as CopyNo. I would feel like I was conning my consumers into buying something they can’t possibly need. There is the convenience factor that sometimes comes into play here. If I was aware of the fact that my software actually complicates and muddles some easy process I would feel I was simply praying on users’ reluctance or fear of learning very simple concepts.

But then again I’ve been called an “open source hippie” in the past so my views here might be skewed. Every single piece of code that I ever written was either published under GPL or flung haphazardly into cyberspace without any copyright attached whatsoever. I never actually sold software - I sell my services. So I do make a living writing code but I do it as a service to the company. So yeah, selling code is kinda funny concept to me in general. But I’m not opposed to it - proprietary software has it’s place and if you create something good you ought to be able to charge people for it.

It’s just that charging $20 for an app doing something that just about any web designer could teach you in 5 minutes for free just seems wrong to me. Wrong on very personal, subjective level. I’m sure the author of CopyNo has an entirely different approach to this. I respect his choice to sell his application this way, but I do not agree with it.

What do you think?

My company’s website was redesigned few months back. I had nothing to do with it, because I’m not really a designer. I’m a back-end dude - I live in PHP and MySQL, and while I’m no stranger to CSS, design is not my cup of tea. For one, my ’shop skills are abysmal and my grasp of composition, and color theory is fair at most.

The website they designed is nice. Personally, I would tidy up the code and dump the rolling javascript driven footer but then again, that’s not my department. Besides, the composition is nice, colors work, and the stock photos they used give the site that slick and professional look.

For example, this young lady’s smiling face ended up on our home page becoming the de-facto face of the company:

Who is she? Who knows - some anonymous model who posed for a stock photo that is being offered on few dozen stock photo reseller sites. Why do I bring her up? Because I saw her again, in more than one place. For example, here is the cover of a free Polish junk magazine published by a popular hosting company:

Where did I see that girl before? Oh, yeah - she was on our website. Needless to say, she is no longer used on our front page. You don’t want the face that shows up on cheep publications, and dozens of websites representing your company.

Stock photos are nice, but you have to remember they are not original. The really good ones - ones that catch your eye right away, are bound to get popular and start showing up in odd places. Your website represents your company, and in a way the photo that people see when they visit it is very important. If you using a very common picture, you are not really making a spectacular first impression on your customers. So, sometimes investing in original photography for websites and advertising publications is a good idea.

There are two fundamental schools of thought when it comes to web design. You can talk about different design methods, technologies, paradigms and etc but there is one very simple, binary choice that you have to make when deciding on the color scheme will have a huge impact on just about every other design aspect of your site. You have to choose to use:

1. Dark text on light background (like this site for example)
2. Light text on dark background

Everything else, kindoff ties into this choice - and there is not much in between. You can’t really pick the middle ground because you want to have fair amount of contrast between your text and your background. And both choices require slightly different design approaches - same layout or graphic may look great in one, but crappy in the other.

I always considered #1 to be the more professional looking, and reader friendly choice. For me, the stark contrast between light colored letters on dark background puts much more strain on the eyes, especially when reading long paragraphs of text.

Sometimes of course it might be appropriate. For example if you are making a page that is supposed to convey some dark, scary or melancholic mood. But even then you have to tinker with the color scheme a bit to avoid that jarring effect on white text on black background. Most terminals don’t even use that, opting for more subdued grayish hue to spare you the eye-hurt.

So I always assumed that dark text is the superior choice - this is, after all, how we print most books, magazines and etc. It seems easier on the eyes, and more accessible to people with visual impairments. And I’m not pulling this last thing out of my ass. Check out this article on web design from Whichita University - it actually quotes an actual research that tested this hypothesis by working with the elderly. Here is the relevant quote:

Studied examining the reading performance of older adults have found that colored text on a colored background typically reduces their reading performance compared to reading black text on a white background (Charness & Bosman, 1990). Moreover, research has shown that dark text on light backgrounds is generally superior to light text on dark backgrounds (Tobas, 1987). However, older adults do have an increased sensitivity to glare. Thus, it is recommended that backgrounds not be pure white, but some form of off-white color.

Lately though I’ve been hearing many people saying that if done well #2 works well, and does not really impair readability. I heard this from both web designers, and accessibility experts which really surprised me. So I did a little bit of searching and it seems that opinion on which design scheme is better is deeply divided. To contrast the research mentioned above I can easily quote an article by Lighthouse International organization (which specializes in accessibility issues) which openly advocates the light on dark scheme:

There is good evidence that for many readers who are older or partially sighted, light (white or light yellow) letters on a dark (black) background are more readable than dark letters on a light background.

So it seems that it’s a tossup - both from aesthetic and from accessibility point of view. Which one do you prefer? Let’s do a vote:

Personally I like dark on light because it lends itself to cleaner and more professional looking designs.