It’s broken because we designed it that way

Scott Hanselman’s recent post, on a week of annoyances caused by troublesome software, was entertaining because we’ve all been there. Thankfully it managed not to indulge (or at least I could stomach) the allusions to a lack of “passion” and “craft” and the comments were mostly sane, albeit I didn’t necessarily agree. I must confess to occasional astonishment at how much does work, not only in the world of IT but the world in general; yet we can do better, and if we didn’t think so then what’s the point?

It doesn’t have quite the same impact, but many of his gripes would be more accurately described as “less than perfect” rather than “broken” and it strikes me - in development, now more than ever - that “less than perfect” is not only allowed, it’s actively encouraged - I’m thinking of “release early, release often”. For example, I like Agile - since customer requirements will evolve it’s helpful to have an adaptive method that anticipates this - but it comes with an understanding that what’s initially released isn’t the finished article. Ironically the separation of concerns afforded by such patterns as MVC and MVVM not only enable this, but necessarily come with additional code you’d expect with any abstraction.

One can argue the difference between internal and external releases, and there is a balance, but if we don’t release early then any perceived advantage from user feedback becomes moot. The point here is that “less than perfect” is something we accept, as quicker and better is expected in the long term. The business challenge is to ensure as much effort is extended to the updates as the early release - which in turn requires challenging (or should that be refining?) an “if it ain’t broke” mentality.

A further confession: I’m not particularly understanding when “less than perfect” hits me; though yesterday’s example was a bug. In creating an online account to manage my Barclays mobile phone insurance I discovered the password format validation was different to that on logging in; the latter was strictly alphanumeric, the former allowed for what would have been more secure. Thus the telephone call I’d hoped to avoid by creating said account became inevitable; not that I could explain the problem to the person on the other end.

Sharing via AddThis

A long time ago I decided to add some ‘social sharing’ into the blog; the how in this instance being more important than the why. I didn’t care for the layout of Blogger’s own set of share buttons so hacked an alternative, adding in the Google +1 button when it became available. Sometime (or was it immediately?) after the launch of their new social networking platform the +1 button was extended to “recommend on search, share on Google+”. Whilst this was kind of OK - platform first, then API - it twisted the metaphor; when, I wondered, would Google+ have a function dedicated to “Share”? It happened so quietly - back in April - I hardly noticed; the share buttons on YouTube had altered, specifically Google+ no longer referenced +1. This is much better; the lack of direct sharing must have further limited people’s use of Google's offering.

My first thought was to enter the HTML jungle representing this blog - in which there has been far too much messing around - and code up a new button. My second thought, which occurred shortly after escaping said jungle, was to look for something else. Something unobtrusive and easily configurable, I settled on AddThis. Using their “Install Blogger Widget” option places some HTML-generating JavaScript in a widget. Done this way it’s easy to remove - always reassuring - and still relatively easy to customise, of which there are a plethora of options.

It's early days, but so far I've only three gripes. Visually I'm not keen on the two-column pop-up menu showing the other bookmarking and sharing options, and I don’t really want to spend time overriding the styling. Having said that my two other concerns are addressed if I hide the menu header. The first of which is if I select one of the services the header changes to “Share successful!” irrespective of whether I have shared. The other is something that happens in Chrome (but not IE or Firefox) as a result of the following piece of AddThis code:

<a id="at15sptx" href="#" onclick="return _atw.clb()" onkeydown="if(!e){var e = window.event||event;}if(e.keyCode){_ate.maf.key=e.keyCode;}else{if(e.which){_ate.maf.key=e.which;}}if(_ate.maf.key==9){ addthis_close(); _ate.maf.sib.tabIndex=9001;_ate.maf.sib.focus();}else{alert(_ate.maf.key)} _ate.maf.key=null" tabindex="9000">X</a>

It took me a while to track down as I hadn’t noticed that I’d explicitly closed the menu, and then I assumed I’d left some code of my own hanging around; it is in truth the kind of thing I’d do in testing. Then I noticed this behaviour everywhere. For example, using the Chrome browser I tried this out on the official London2012 page detailing the Olympic opening ceremony: Hover over the “Share” icon, explicitly close the pop-up menu by clicking on “X”, then press a key, (almost) any key; I typed “A”. Well, it made me smile.

'Fun' with CSS

For further fun I have been aiming at horizontal (only) scrolling, for the purposes of displaying code samples. Taking a previous post; it overflows correctly in Chrome and Firefox but fails to do so in Internet Explorer 8, and I presume earlier versions. Worse - or to make it more convoluted - I can specify exact width, extract the CSS and the HTML and have it working in IE8, but the same code still fails within the context of Blogger. I’ll trace the cause eventually (and use the <pre> tag rather than a <div>) yet it’s possibly a little obsessive; in all my posts I’ve only displayed code twice, and only once has it required scrolling.

‘Fun’ with JavaScript

With some on-going tinkering yesterday evening - styling the search widget on my blog - I wasted hours on a difference between how Chrome and Internet Explorer (and later, I discovered Opera) executed some JavaScript compared to Firefox. ‘Hours’ because I managed to side-track myself with the onblur event, and the problem was something far simpler. I put it down to rustiness - an accidental mixing of syntaxes - though the truth may be less kind; never mix alcohol and coding, kids.

<html>
<body>
<input name="search" type="text" size="10" /><br />
<input name="search" type="text" size="20" /><br />
<input name="search" type="text" size="30" /><br />

<script type="text/javascript">
var x = document.getElementsByName("search");
var i = 0;
for (i=0;i<x.length;i++)
  {
  document.write(x(i).size+' ');
  };
</script>

</body>
</html>

As usual it was a case of reducing the code to something more manageable. On executing the example above, Chrome (my default browser) and Internet Explorer will write out the sizes of the three text boxes, whereas Firefox will not. The reason is all to do with brackets; we use square brackets to access an entry in a nodelist, and parenthesis (rounded brackets) for the optional arguments to a function or method call. Chrome and others are effectively treating item as the default method on a NodeList object - hence the example JavaScript works, whereas FireFox isn’t - and the example JavaScript fails.

In bed with JavaScript

Option A.

If only I’d had more time I could have given my daughter that holiday, mowed the lawn, cleared out the garage, read that JavaScript book… when you’re as ill as I was last week you start making all sorts of rash promises. The JavaScript pledge came not only as a result of my near death experience, but my tinkering with the blog and the acceptance that fun though it can be, “try it and see” isn’t always the most effective way to learn.

Option B.

I’ve been playing around with a “Tweet this” function for a while and plugged in Tweetmeme, though I’d looked at Topsy and for a short while implemented Blogger’s own share buttons. Being me, despite everything working fine as it was I decided to change it all around and spent an age “rolling my own”. Hence the thought that tucked away on my shelf were a few books that might explain what it was I was playing with.

But do I start on these or after a month-long cessation of hostilities resume the war on Troy? Having started as a challenge it was proving to be a really good read until I managed to distract myself with work. It’s early in the story; Paris has been rescued from death at the hands of Menelaus and spirited away to have his way with Helen, whilst the armies give battle outside the walls of the city. So it’s a choice between thousands who live or die at the whim of the Gods, or one developer who will live or die at the whim of JavaScript. Maybe I’m overselling it?