Data Recognition

We all recognize things, objects familiar to us.  Familiarity is a comforting phenomenon — it tells us we've been here before and we can make certain assumptions.  It's when we encounter the unfamiliar — the unrecognizable — that we begin to have second thoughts.  How we get stuff done, our jobs, our daily routines, it's all been done before.  When we learn something new — either at our job or something we've set out to do based solely on curiosity, we're building up our repertoire of certitudes.

Now imagine that we didn't have this ability to recognize things within context. Imagine every scenario we encounter was brand new.  We'd have to learn on the fly.  We'd have to take in external stimulus, compare it with only our must unchanging fundamental knowledge and build up a mental representation.  No ability to react in a split second.  No ability to store new knowledge so that next time, we have something to reference.  What would that be like?

It's kind of like the fatal flaw in how we're approaching data recognition in software development.  We merely have the illusion, as users, that the computer knows something we don't.  That it's really able to determine facts for us that we're simply incapable of doing and are thus powerful aids in intelligence.  But software doesn't recognize data.  Not the way we do.  Every time we give software input and tell in to act on that input, it goes through the same motions as every other time.  Even if the input is the same.  Now, this isn't true of all software — artificial intelligence is geared toward learning.  In an effort to simulate real human behaviour, some software can actually recognize certain data, attach meaning to it, and store new information that is applied in the next round.

Should we be taking this type of software more seriously?  That is, should we not view learning software as more of a fundamental necessity for all types of applications?  I think the answer is yes, because until we can effectively build software that can recognize data, the current levels of complexity will soon become recalcitrant.

The Best Help
Imagine using software that could display meaningful error messages.  I know, probably not going to happen in our lifetime, but one can only dream.  What is a meaningful error message?  Well, we're typically used to seeing things like "oops, you forgot the last name field".  This is helpful enough, and probably won't go away until forms vanish from the face of the earth.  But what about errors that tell the user something they have no control over — these usually take the form of "an unknown error occurred" or "the system is a experiencing higher that normal traffic levels...".  You've got to wonder, why even bother.  Why not just say, "this software has bugs, so not your fault".  This is another category with which the user has no control over whether or not the error message gets generated.  So until software just works, we're stuck with these annoyances.

But let's revisit the problem of form entry errors for a moment.  If the user is providing the data, it's much easier to tell them they've done wrong.  They can relate to the message because it's clearly of their own doing.  Most software frameworks have form validation sub-components that supply a primitive form of data recognition.  That is, the field validators can recognize if the supplied data is in fact an email address or if it is in fact a phone number.  These little helpers make the lives of developers writing the software easier and the lives of users supplying input.  The developers know that they can read phone numbers and email addresses from the form.  The users know exactly what they've done wrong in the case of submission failure because the get back meaningful messages.

However, we could take this principle of recognizing what the user has supplied us with to make their lives even easier.  Instead of returning an error message if the email address cannot be recognized. or at least before returning the message, maybe the framework makes an attempt to fix the user's typo.  For example, perhaps the @ character is missing and the first part of the string begins with a human name such as davidcompany.com or david company.com.  The data recognition framework could save the user some typing if all it needs to do is come back with a suggestion — did you mean david@company.com.  Obviously, that's exactly what I meant — good job software.

So is this the best we can do with data recognition in terms of understanding what the user is trying to say?  That is, is the confirmation really necessary?  Do we really need to go back and check if that is in fact what the user meant?  The problem with not checking is that a false positive could result in a much worse situation than if they had simply been given an opportunity to correct things.  And I don't necessarily think that implies that the software is weak or that in stands in the way of the traditional method of input correction.  What it does do is gives the user a sense that the software does know what they're trying to do.  It leaves a feeling of being coached along an activity, not taunted in a guessing game.

I think its a huge win for not only users, and not only developers that create these systems, but more of a collective win for a society that relies on software interactions.  Any good software system must produce fantastic documentation, enabling their users to navigate through the system themselves.  The documentation is simply learning material, some of it will no doubt be memorized, other parts referred to when necessary.  But is thorough text the best learning solution for using a piece of software?  Or is it better to give the users a brief overview — just enough to get them started.  And this is where the data recognition end of thing comes into being for providing users with the ideal help system. The ultimate goal being to recognize what the user is trying to do and to offer advice of how to better achieve their goals.

Effort Required
It's easy to dream about software that recognizes data, correspondingly, making assumptions about what we want to do.  It's a completely different story when it comes to putting these ideas into code.  There simply isn't enough demand for this type of software-assisted user experience.  Well, that might not be entirely true — Apple has made it abundantly clear that we cannot expect anything less than cutting edge user experiences from any of their products.  Even still, the old routine of having to understand, often in some level of detail, what the computer is expecting from us, is somewhat ingrained in our experience.

We can't use the software because it requires training — reading manuals and perhaps some guided practical exercises.  Everyone knows experience is the best teacher — why not streamline that wisdom even further if we have the ability to do so?  Build in some of the mistakes that you'll expect your users to make.

This is part of the challenge — at the intersection of time to market and innovative data recognition solutions.  I have nothing but the utmost confidence that we're able to apply the most sophisticated recognition techniques to almost any software and that we'd see absolutely incredible results.  When push comes to shove, it's hard to justify such efforts.  Which is too bad in my opinion because an investment into data recognition is an investment into customer behaviour.

Data recognition isn't just about users, it isn't just about saving them from typing a few extra characters. More broadly, it's about flexibility in how intent is expressed between actors that exchange information.  Standards are good but only if the two communicating systems speak the same standard.  If we could simply think of more intelligent ways to lower barrier between what the user envisions doing in their head and what that means supplying the keyboard, we'd be well on our way to quality data recognition.