Learning Letters

Being a parent furnishes you with the wonderful opportunity of watching your children learn. As my older children have developed I've found that their range of learning subjects has progressed quickly to include things that are unfamiliar to me, mainly through having been introduced to the world since I was at school. This could be daunting in that I am exposed to my children seeing limitations in my own knowledge (the illusion of parental infallibility is easily shattered, for example through my cumbersome attempts at playing minecraft). Nevertheless, I prefer to see it as an exciting opportunity to learn myself and share with them the joy of learning new things.

Making Sense

One of the most interesting aspects of watching children learn comes when they start to learn how to read letters and numbers. Sometimes it takes seeing a system through the experiences of another trying to learn it to expose the flaws inherent in the system that aren't apparent to a person more familiar with it. Watching my children attempt to learn the symbols that go into making up their letters and numbers really brought home to me some of the illogical and unintuitive problems in our common symbology.

A great example happened recently with my middle son. We'd spent time learning all of his letters in a picture book, to the extent that he could recognise each letter without the pictures. I was somewhat surprised when I presented him with a pre-school story book and he couldn't identify the letter 'a'. When I pointed it out to him his response was even more surprising - he said "That's not an 'a'". I looked at the page and realised that he was quite right.

The 'a' in his story book looked like this

Whereas the one in his letters book looked like this

How could I expect him to know that the extension over the top of the letter here was meaningless, when in these two letters

A much smaller difference has a profound significance.

Another one that all of my children have found hugely confusing is when different characters are different only through reflection or orientation. 6 and 9 for example can be very confusing particularly when working with children's games such as bricks and cards which can be rotated in hand. p, q , b and d are similarly often the last ones to be confidently learned.

And don't get me started on equivalent characters such as upper and lower case. So P is a capitalised p, S is a capitalised s but a capital q is Q, what?

When you consider a child's learning journey it is hardly surprising that they get confused. We spend their very early years teaching them how to identify shapes by their properties, irrespective of their position,

a rectangle oriented horizontally or vertically is still a rectangle
a shape with thee sides and 3 vertices is a triangle irrespective of the relative lengths of the sides.

Then we introduce a language and numbering system using a series of symbols where properties are far less relevant. Characters with completely different properties can represent the same letter, and we can change a character into another one simply by rotation or reflection.

There is little logic in the system. The number of rules that we'd have to provide even to understand the basic alphabet and number characters used in English would be huge. Whilst the simple rules of character representation in learning letters may be explicitly defined for our children - through letter books and number charts and the like - the understanding of the range of different ways that the characters in our alphabet can be represented is tacit knowledge. We build up our knowledge through example and experience, incrementally building our rule set around what constitutes an 'a' or a 'q' until we have sufficient rules to read most fonts that we encounter.

Even now on occasion I am presented with a character such as this,

And have to examine the context in which it is used to establish the letter represented. In this situation I depend on a set of in-built heuristics based on how the symbol is presented - e.g. Is it in a word with other symbols that I recognise - to identify what it is intended to represent?

I'm now pretty sure it's a 'T', or possibly an 'F' , but there's still a little uncertainty. Is the word part of a phrase or sentence that makes the meaning clear?

Now the character represented is clear. So, unthinkingly, when reading the cover of this book I've applied a series of personal heuristics to identify the letter 'T'.

For the most part I am not generally aware of the depth of knowledge that I am tapping into when interpreting a new font or text. I would find it extremely difficult to construct an explicit set of instructions for a human or computer to identify this character based on my knowledge prior to seeing it.

Presenting our Software

I was recently reading this great set of tips for technical authors from Tom Johnson. One that really struck a chord with me was number 3 - "Developers almost always overestimate the technical abilities of their audience".

Developers often create products with a certain audience level in mind, and usually they assume the audience is a lot more familiar with the company's technology than they actually are.

As someone who works across the boundaries between development teams and support, I have a great affinity with this phenomenon. As we develop our software we unknowingly build rich and complex layers of tacit knowledge across the development team as we work with the system that we then rely on during development activities.

When working with my query system, for example, there is a wealth of knowledge within the relevant development team around the shapes of queries and how they are likely to execute against certain data structures. Some queries may be a natural fit for our software and execute in parallel scalably across machines, others may force more restricted execution paths due to the SQL syntax used and the resulting stages of data manipulation required. These models that are built up over time support a level of understanding which rarely pervades beyond the walls of our development offices. When our customers first start to create and execute their queries they are typically not considering these things. Yes, they may start to build up their knowledge should a query not meet their expectation, and they work through explain plans, query documentation or work with a consultant to better understand the system. In my experience this type of activity is most often based around solving a specific problem rather than constructing a deep knowledge of query execution behaviour.

Working with my support teams helps to maintain perspective on the levels of product expertise that exist among our user communities. This is not to say that we don't have very capable users, it is simply that developing and testing a product affords us a level of understanding to the extent that expert knowledge becomes second nature and it can be hard not to code and test from this status of elevated knowledge. More than once I've seen referrals on system behaviour from the support team to a development group responded to with an initial level of surprise that the user is attempting to use the system in the manner described. With an open interface such as SQL providing high levels of flexibility over use this is somewhat inevitable. Given that some SQL is generated by other applications rather than through direct input, we can't necessarily rely on sensible structuring of SQL, let alone that it is done so in the manner that our system prefers.

Making Tea

When I was at school a teacher gave my class a fascinating exercise - we had to describe how to make a cup of tea to an alien unfamiliar to earth (who spoke perfect English, obviously). The teacher then went on to highlight our mistaken assumptions such as in an alien knowing how to 'put the kettle on', and the possibly amusing outcomes of such an instruction.

Naturally we wouldn't expect testers to have to work from such an extreme starting point of user experience. We do, however, probably want to maintain awareness of our own levels of tacit knowledge and try to factor this in when testing and documenting the system. For me it is about looking for gaps or inconsistencies in the feature set where we might unknowingly be glossing over the problems through our own knowledge.

Are there inputs that to the user could be considered equivalent yet yield different results? SQL is awash with apparently equivalent inputs that can yield different results, for example the difference between 1 and 1.0 might appear trivial, however they can result in different data types in the system with implications for query performance. The difference between these two characters

can be as trivial to the user as the editor in which they typed their text, however they can have a huge difference if copied into an application input.
Are there very different features or workflows with only subtle differences in labelling? I was recently using a web system where the "Resources" tab took me to a completely different location to the "User Resources" link in the side menu. I had taken them to be the same and so failed to find the content I was looking for.
Are abbreviations or icons used without labelling or explanation? On an internal system that I recently started using there are two areas which are referred to by three letter acronyms, one of which has the same characters as the first with 2nd and 3rd letters reversed. My team and I still struggle to know which one we are referring to in conversation. In this post I recount a situation where my lack of familiarity of the 'post' icon commonly used in android resulted in an embarrassing mistake and my rejection of a popular blogging app as a result.
Is team specific language exposed to the user in labelling or internal documentation? Internal terminology can leak out via various channels and confuse the customer. Our customers know the features according to the manuals and marketing literature, not necessarily the in-house terminology. Using team specific terms in labelling or internal facing documentation will result in inconsistency and confusion as those terms leak out via logs and support channels.
Is the same value referenced consistently throughout, or is terminology used interchangeably? A big personal bugbear of mine is when I register with an application entering my email address amongst other fields, and then on revisiting the site I am prompted for my "username". Hold on - I don't remember entering a username. Was I given a username? Should I check my emails and see if I was mailed a username? Or should I try my email address as that is what I used to identify my account? But surely if the site wanted my email address it would prompt for that and not my "username", wouldn't it? Unless they are storing my email address in a username field on the database and forgetting the origin of the value when prompting for credentials.

When exposing an interface which shares characteristics or expectations with other systems, an important consideration is whether we need to test on the basis of a generic knowledge and consistent terminology rather than application specific knowledge or organisational jargon. Otherwise we may risk a reaction similar to my son's on first encountering his "not an 'a'" when the software reaches the users "that's not a username, it's an email address!"