This phoku is throwing the baby out with the bathwater
July 4th, 2009
Yesterday and today I’ve been rewriting my jQuery crossSelect plugin (probably over half of the code has changed) to; a) Fix the serious bugs brought about by trying to bring my plugin closer in line with how it’s supposed to be done, without fully understanding the implications in advance; b) make the code more efficient, in part applying the ideas in this excellent article; and c) prepare the code for bringing in more functionality in later releases.
With regard to c), the main thing I needed to do was rewrite all my selection and removal functions so that moving many items into the selected column at once could just be the move one item function iterated a number of times. I’ve now ( I think) found a pretty efficient solution (each move many function is only 3 lines long), but along the way I came across an interesting dilemma.
My selectOne() function essentially moved a list item and then checks how many items are in each list before adjusting the buttons appropriately. Now, to do a selectAll() or a selectMany() the obvious thing to do is just to iterate that selectOne() function over all list items – just a handful of lines of code – … but this unfortunately leads to a less efficient (and probably slower) function. Writing a selectAll()/selectMany() function from scratch would enable me to only adjust the buttons once and, in the selectAll() case, not have to care about tracking which list item I’m dealing with as they all get moved over in the end… but this way would not only be less elegant, I feel, but also lead to more lines of code.
I’d always assumed that optimising code meant two things – faster and smaller – and I’d always thought that one more or less implies the other. Turns out I was wrong.
In the end, the escape from this trade off involved removing the button adjustment from selectOne() and putting it in selectNow(), a new function triggered by a click. But this required a feature of jQuery which I’ll talk about in some other post.
Yesterday I railed against the useless, so-called functionality added to web pages by websnapr. However, I did close by adding that the technology is impressive, if only somebody could find a use for it that isn’t sanity-shatteringly pointless.
You’re expecting me to say I/someone else has succeeded, but I’m not going to.
What I will point to instead is another service, very similar to websnapr, which is in fact very useful (though still suffering from the same problems as websnapr in a lot of cases). It’s called snapshots (and it, rather than websnapr, would also appear to be the market leader for this sort of thing).
Snapshots still suffers from the pervasiveness of the same annoying, information-scarce tiny screenshot provided by websnapr but, where possible, it makes that extra step (probably less technology intensive, in fact) to genuinely improve the user experience. Two examples I’ve discovered so far are:
These things which are both useful to see at a glance, not necessarily requiring loading a full web page. And there may be more examples where the snapshots preview is more than just eye-candy… so kudos to them. I just doubt, somehow, that they have an option to turn off the default screenshot previews.
You’ve all seen websnapr at work most likely. Or rather, you’ve been one of its unsuspecting victims, innocently surfing the net when, suddenly, the rules all change and you’ve no idea which way is up and which way is left any more.
What websnapr does is convert any link on a website (or a select few chosen by the site’s publisher) into a useful preview thumbnail of the website in question, thus enabling the user to preview what’s at the other end of the link before clicking and wasting their time with something so time-consuming as as a visit to the site (see screenshot below). And it’s very easily installed by means of inclusion of a javascript file.
All well and good, you say… but is it? Is it really?
If you don’t want this heightened user experience it is quite obtrusive and off-putting; Accidentally drifting the mouse over a link while reading an article leads to bits being obscured and a brief “what was that?” moment, breaking your concentration. One of the golden principles of usability is to more or less stick to accepted norms of page layout and interface behaviour. Yes, these norms can be broken if you know what you’re doing, but websnapr is just added willy-nilly by website publishers who think it’s cool, without any real consideration for the fact that, to most of their visitors, it will make the website odd, and as for the most part we want our visits to websites to be straightforward, it will be a turn-off.
Related to this point (though slightly less subjective) is that only a minority of sites on the internet use websnapr, and it’s likely to stay that way. Possibly (notwithstanding my next point) I could accept that if every external link on every site gave a preview of the webpage it points to then this might be useful, but as this isn’t the case we all have to develop our own methodology for choosing which links to click. For instance, I hold down ctrl and click all the links that look interesting, to open them in new tabs. It’s surprising how automated this process is; I go for the ctrl key without even thinking. Showing me unexpected, thumbnail previews gives me more information than I’m used to and, it’s reasonable to suggest, could actually slow down my web browsing. (And for people who like to have the previews on all sites, there are firefox extensions (and probably ie7 by now) that achieve the same thing).
This interpretation becomes even more plausible when we take a closer look at what the thumbnail previews show us. Look at the one above for CNN. What preview information does it give us?
It tells us the website is CNN.com by virtue of the logo… and that’s about it. The text is too small to read, even the headings (and out of date to boot – today’s site has a big picture tribute for Michael Jackson, conspicuous by its absence in the screenshot). Is it useful to know the website you’re being directed to? Yes, definitely, but it hardly merits making a tiny visual copy of the site, which in many cases might shoot itself in the foot by obscuring the website’s identity as not all logos are legible at small resolution. You could argue that the preview also gives you a more holistic feel for the site; a glimpse of the design gives you a hint of the website’s tone, a guess at the intended audience etc…, but even this is shaky justification. The design’s impact and general feel are largely lost in the shrinking.
And finally, I can’t help thinking that websnapr goes against the spirit of the internet. Contrary to it’s probable aim of making it easier to discover and filter new sites, it actually devalues the most useful tool of all for doing this: the link itself! Links don’t just appear from nowhere. They are put there because the author of the piece you are reading thought you might like to visit an extra site. If you value the author’s opinion – whether due to a long-standing readership or being impressed by the current article – that should be enough to justify clicking through.
After all this, I don’t want to put too much of a downer on websnapr. I think it’s useless as a tool for making clicking on links more productive, but it’s still impressive that you can get a screenshot of any site on demand. There has to be a use for it somewhere… but what??
We’re often told that London is a very green city (by which I mean leafy, rather than environmentally friendly), and it is definitely one of its better features. In Amsterdam there are far fewer parks, and these are absolutely rammed on a hot day such as today. Whereas in London it’s easy to find a quiet spot to sit and read, here next to the Vondelpark the best I’ve achieved recently is a damp patch where wet dogs bothered me, and a spot beneath a tree weirdly covered in spider webs… which later revealed themselves to be colonies of caterpillars – COMPLETELY covering the tree (no exaggeration – it took a while to realise it wasn’t a prank involving lots of halloween fake cobweb), several of which had fallen and squirmed around in the grass next to me.
Which is why I’m indoors writing a blog post as opposed to soaking up the rays, though it is on a subject which desperately needs sharing with the world.
When I was 17, after the fall of Britpop and the rise of Girl Power (OK Computer not only was a great fin-de-siecle album, it was also a great death knell for good, mainstream British music), I was forced to abandon the charts in search of better aural fodder. At this time I discovered some great bands whom I still love – The Delgados, Grandaddy
, Mogwai
, The Beta Band
– but a possible standout was The Crocketts
. They played angsty cowboy punk and, perhaps more importantly, they were from Wales (sort of), were Skinny and Wirey and nobody else had ever heard of them. They were my band. A painful moment for me was when I heard they were playing live in my hometown for the first time… about a week and a half after I left for uni.
A couple of albums later they disappeared… but I discovered yesterday that the Drummer and lead singer are back (have been for about three years) as The Crimea. A very different sound to The Crocketts – less angst, more passion; less punk, more soulful – but a great band nonetheless. Reminiscent of Arcade Fire. And they offer their latest album for free on their website so by all means repay the favour and go and see them live as they’re supposedly breathtaking. I know I will be.
So, as I sit here contemplating if the time is yet right to retry the caterpillar and bikini infested park, I am happily listening to the return of a great band.
One big selling point of jQuery – so everyone says – is the ability to nest/chain selectors, so that using oen string you can, in theory, pick out any element in the DOM. But this has eluded me somewhat until today; until I realised the usefulness of setting a context for jQuery selectors.
I noticed a few days ago that my new crossSelect plugin was a bit inefficient, in that it queried the DOM far too often. It used to have something like the following code:
$(this).parent().parent().find('.target1').children('li')...
$(this).parent().parent().find('.target2').children('li')...
But the next iteration was going to have something like this instead – far sleeker.
var context = $(this).parent().parent()
$(context).find('.target1').children('li')...
$(context).find('.target2').children('li')...
But it bugged me that I couldn’t pick out the <li>’s with a string selector. This is because context is an object, not a string, and therefore can’t be a part of a selector string. But then I discovered setting the context on selectors (easy to miss as it’s not linked to from the selectors bit of the documentation site). So that led to the following:
$(context).find('.target2').children('li');
is equivalent to
$('.target2', context).children('li');
which can be rewritten
$('.target2 > li', context);
Far more elegant, I think you’ll agree. So it’s jQuery context setting all the way for me. From now on I will only use find when I need to find a child element on the same line that I’ve already done something to the parent; it really has no place at the begining of a line of jQuery code.