Web development and Usability

Senior citizens' first iPad encounter

2010-06-16T22:18:00.008+01:00

Last week I had the opportunity to witness an elderly couple try out the iPad for the first time. They each had some limited experience of using email and web browsing on a slow old PC. They are a little scared of computers on the whole. One of them has impaired vision, unable to see a whole screen at once and what can be seen is somewhat blurred.

Before this began I was anticipating that the iPad's screen size was going to be a problem and that it would be too fiddly for some not-so-dexterous hands. I also expected that the on-screen keyboard would prove awkward and we may have to resort to a full size external keyboard for typing emails etc. What transpired came a bit of a surprise.

I gave them almost no instruction other that to say what the device might be used for.

First impressions
Both subjects immediately remarked on how clear the screen was. They were rather nervous of touching it to begin with, worried that they might press something wrong and break it. Indeed they were not sure where to press at all. Once shown the email and web icons however, they soon got the hang of navigating with a tap of a finger. Some confusion was caused when not every tap was accepted but they got more accurate and confident with their taps after some minutes.

Playing
Once they got into the mindset that they they weren't going to break it they transitioned from helpless "battling" to confident "playing".
Interestingly the more relaxed approach also lead to both subjects picking up the iPad with their other hand. Prior to this evolution they had dared not pick it up. This seemed to help with their confidence and feeling of control.

Accidental drags
Some difficulties continued to arise from accidental taps and drags. Particularly drags. Some taps became drags because of lack of dexterity or other parts of the hand touching the screen. Again, this improved with practice and the realisation that you can't rest your hand on the screen!

Scrolling the wrong way
One curious expectation that the subjects had was the direction of vertical scrolling when content extended below the visible area of the screen. They found it odd that the content scrolled up in order to move down it. The rest of us take the scrolling direction for granted and never think to question it.

Feedback
After the session the subjects were generally pleased with the iPad. Both agreed it was the easiest computery thing they had used.

They made a couple of intriguing points:

They loved the way iPad's single button returned them to the main menu. They saw it as a way to escape from trouble. To "get me out of here". It made them feel safe.

The on-screen keyboard turned out to be much favoured over a separate keyboard because they did not have to re-focus their eyes to look at it. It was definitely a feature that made the device more accessible for them.

One last experiment...
Out of interest I let the couple loose on a MacBook after using the iPad. It was described as "ok" but both subjects found they disliked having to locate and move a little pointer around the screen now that they were used to point-and-tap.

DDDSouthWest 2010 jQuery AJAX slides and demos

2010-06-08T21:57:00.003+01:00

Here we are DDDSW folks, my slides and demos.

DDDSW jQuery AJAX Demos all zipped up

DDDSW jQuery AJAX Slides (AKA Agenda! ;o) all zipped up

A great crowd. All up for a laugh so thank your for your enthusiastic feedback etc!
@GeorgeAdamson

DDDScotland jQuery slides and demos

2010-05-13T21:29:00.004+01:00

You lot asked for the slides and demos so here they are.

Many thanks to those who attended my jQuery session at DDDScotland, and for the lovely feedback and mentions. Glad you enjoyed it. (Apologies for the two who did not find it "structured" enough! ;o)

Looking forward to speaking about AJAX with jQuery at DDDSouthWest on 5th June 2010

Cheers,
George

New Twitter "lists"

2009-10-29T16:14:00.000Z

It seems that Twitter has started offering a new "lists" feature to a limited number of users. Playing with my lists today I think they could be useful for organising followers into related groups. Not sure how helpful the current implementation will be for organising large numbers of followers but what they've done so far is nice.

There's some more info on a twitter blog.

Merb "select" list form field causes error on create or save new

2009-10-15T15:00:00.001+01:00

A little note for Merb enthusiasts...

If Merb throws this message when you try to submit a new item from a form:
undefined method `new_record?' for "":String"

then it could be because you have a <%= select :propertyName ... %> element and you've used the property name just as you would with text_field etc. Try using the table name instead, such as :property_name_id.

Measure raw image dimensions using jQuery

2009-09-26T21:29:00.014+01:00

In a recent project I needed to be able to display the original dimensions of a bunch of images pulled from other servers. Using JavaScript to measure image width and height is fairly straightforward (as long as you don't measure the dimensions applied through CSS by mistake!). I bundled the functionality into a little jQuery plugin. Might be useful for someone.

To use it just call .imgSize(callback) on a jQuery array of images.
Provide it with a callback function as a parameter. The callback will receive the dimensions as its first parameter in the the form of an object hash of { width, height, fileSize }
(I included fileSize as a bonus, though it practice it can only be measured in Internet Explorer. It will be zero in other browsers.)

For example:

jQuery("IMG").imgSize(function(size){
 alert(size.width + "x" + size.height + "px " + size.fileSize + " bytes");
});

So why not just return the width and height right away instead of requiring a callback function? In order to measure image dimensions without reading the style values or affecting the display of the page we have to load a hidden dummy image and measure that instead. Images load asynchronously so the best we can do is let the script carry on running while we wait for the dummy image to load. When it loads we measure it's dimensions and trigger the callback function.

(By the way, Mozilla and Chrome provide properties called .naturalHeight and .naturalWidth on an image element.)

Here's the plugin: (Apologies for ugly formatting. My fault for using Blogger I suppose!)

// Measure the dimensions of all images in the current jQuery array of elements:
// Optional: Specify deep=true to also measure dimensions of all images within the array of elements.
// Required: Provide a callback to receive the measurements. (This is necessary because images are loaded asynchronously)
// The callback will be triggered for every IMG in the jQuery array that has a "src" attribute.
// The callback is passed 2 params:
// - The first param is an object of {width,height,fileSize}.
// - The second param is the temporary IMG element that was used for measuring. (It gets destroyed after callback)
// Inside the callback you can use "this" to refer to the IMG element that was in the original jQuery array. 
// Note that fileSize can only be measured in IE. This value will be 0 in browsers that doe not support IMG.fileSize.
jQuery.fn.imgSize = function(deep,callback){

 callback = callback || deep;
 var $images = this.filter("IMG[src]");
 if(deep) $images.add( this.find("IMG[src]") );

 $images.each(function(){

  var origImg = this;
  var url = $(origImg).attr("src");

  $("<img>").load(function(){
   var $dummy = $(this), size = { width:$dummy.width(), height:$dummy.height(), fileSize:0 };
   try{ size.fileSize = parseInt($dummy.attr("fileSize")) || 0 }catch(e){};
   jQuery.isFunction(callback) && callback.apply( origImg, [size,this] );
   $dummy.remove();
  })
  // To be on the safe side, apply inline styles to prevent any css styles affecting our measurements:
  // (We use a try-catch workaround for IE7 because it raises errors when we try to set maxWidth/maxHeight)
  .css({ display:"none", width:"auto", height:"auto", minWidth:"auto", minHeight:"auto" })
  .each(function(){ try{ $(this).css({ maxWidth:"auto", maxHeight:"auto" }) }catch(e){}; })
  .addClass("imgSize-temp-img")
  .appendTo(document.body)    // The width/height would be zero if img is not added to DOM.
  .attr({ src:url });

 });

 return this;
}

Yay! UXLondon next week

2009-06-13T20:47:00.005+01:00

Very much looking forward to UXLondon next week. Some great speakers and a spot of networking. (Provides a nice break from building BBC web sites too!)
See you there...?!

Presented "Get going with jQuery" at DDD South West

2009-05-28T21:40:00.003+01:00

The other day was the excellent DDD South West conference in Taunton, UK. Many superb speakers plus me. Happily my Get going with jQuery presentation seemed to be well received. The feedback ranged from "like Eddie Izzard doing tech" to "Lee Evans" to "I think the speaker was on drugs", so I think I'll take those as compliments! Thanks to everyone who attended and a big pat on the back to the very energetic Guy Smith Ferrier and the team for organising the whole thing.

"Cosmetic" bugs are never minor for long

2009-03-01T08:17:00.005Z

It is a shame that some testers often log UI bugs as "minor"? You soldier on with their "major" bugs and then get flack when the client rants about the incomplete UI.

Whatever we create, the client (and here I also mean the real users of course) will mostly judge an app by its cover. Does not matter how many amazing layers of complex programming there are under the water level of your eye-candy iceberg, it is still only as good as the shiny bit on top.

We all do it.

Truth is, the back-end below-the-surface guys work pretty damn hard and do some amazing stuff. If the client is going to judge that work fairly then they need to be able to get past the candy layer. I find there are two useful ways to achieve this:

Mock up the parts of the page that are not complete yet. Using hand drawn doodles in place of icons or fields is useful for this. Just place them where the ui is not ready. You make it clear that this bit is not broken but incomplete. The expectation is set.
Log visual bugs as major. Get them sorted right away.

Performance of javascript object hash vs RegExp

2009-02-02T20:11:00.005Z

jQuery makes regular use of regex statements like this one, used in the position() and offsetParent() methods:

/^body|html$/i.test(offsetParent.tagName)

For situations like this I wonder if a simple object hash would do the same thing faster:

{BODY:true, HTML:true}[offsetParent.tagName];

I did some crude experiments and found that the hash technique was at least 4 times faster in IE7 and 15 times faster in FF3.

The hash above does not allow for upper/lower case variations but converting the lookup to the same case adds quite a performance hit:

{BODY:true, HTML:true}[offsetParent.tagName.toUpperCase()]

The example I chose above was being used in a loop where any performance gain would be more noticable, but this technique nonetheless be used to speed up other bits in jQuery, such as...

/^t(able|d|h)$/i.test(elem.tagName) becomes {TABLE:true,TD:true,TH:true}[elem.tagName]
/href|src|style/.test(name) becomes {href:true,src:true,style:true}[name]

I've talked about using this in jQuery but of course it could be used in your own js or other libraries. I'd be interested to hear about other people experiences with this technique.

Tssh.. which cowboy put that in?!

2006-11-15T13:25:00.000Z

Sloppy code costs the Customer more... Customers don't really give a monkey's how speedy your algorithm is or how cunning your quirk-workaround is. They see their application doing its stuff and that is pretty much all that needs to matter from where they're standing. Quite right too, they're experts at what they do so why should they care about how fab your code is anyway. They shouldn't have to really, but sloppy code will cost them more down the line when they get the next guy to tinker with the code.

Every software developer has, at some time or another, had to take on someone else's old code to fix bugs or add features etc. We'll take one look at it, rub our chin and suck air through our teeth, like some plumber that has just emerged from inpecting pipes under the sink.

Understanding old code can be a painful and time consuming process. Plenty of programmers out there will have thoughts along the lines of "Other peoples' old code just isn't a patch on the beautifully crafted masterpieces that I produce, surely anyone can see that?" Well er, no, too many programmers are as guilty as the next at producing sloppy code. Sure it might work ok, but some day another poor sucker has to work out what the heck you've done.

Well written software code is not just about churning out code that works. Surely us programmers have a responsibility to think about who else is going to read our masterpiece? Our code must make no secret of what it is up to and why, so that it is easy to follow and supportable.

Ooh, you mean you want more comments? Definately not. Light commenting is ok, but if you find yourself explaining your every move then you probably need to think of a better way to write your code. "Self-documenting code" is not about the number of comments you jam in there but about making your code self describing.

Some simple examples please...

Why use a variable called j when you could call it customerID. All of a sudden we know what you're on about.
Building a cryptic multi-command expression might make you feel like a programming god but splitting it into a few different lines with some choice variable names etc could stop the next guy from cursing your very existence.
Can your fantastic algorithm be moved to a separate function with a nice chummy name and expanded onto a few more lines of code?

There will always be some cryptic bits that we can't improve, things like Regular Expressions for instance are good candidates for a comment or two.

When we think about how someone else will view our code it changes everything. Well written code is a joy to read and maintain because it really is self-describing.