Tag Archives: number entry

Controlling Number Entry Using Sifteo Cubes

As you have probably gathered, I am really interested in Number Entry. I’ve been thinking a lot about how we enter numbers – whether we think of them as a series of digits, or as full numbers. This has implications for the way we might ask people to enter numbers on an interface.

I was given an opportunity to test this out recently at the CHI+MED interface hack day. Last Friday (9/8/13) a group from CHI+MED came together at Swansea university to hack some interfaces to investigate novel number entry methods.

I got a chance to play with some Sifteo Cubes. Sifteo Cubes are fun little blocks with screens that are aware of which other blocks they are next to. This allows for some fun physical interaction, with the user picking up and moving the blocks around.

At a previous idea generation session, we came up with the idea that you might want to let a user enter numbers on the sifteo blocks using both a digit and number strategy. The difference between the two meaning that you could either control the number digit-by-digit (that is, incrementing the digit 9 in the number 659 would result in 650) or by controlling the whole number (that is incrementing the digit 9 in 659 would result in 660).

Using one Sifteo block as the “controller” and the other two as the numbers, I created a system to allow the user to enter numbers using any strategy they like. See the video for an example. You can see that they can control each block separately. When the blocks are joined, the entire number can be incremented (by placing the control block to the left or right) or just the digit can be changed (by placing the control block above or below).

Programming the Sifteo blocks was an interesting challenge. You need to program in C++ (a language I haven’t looked at for a few years) and at first, reading the example code was a bit daunting. But after a while I managed to hack it together. The really strange thing about doing this was working with images. Unlike many programs where you can directly write text (or numbers) to the screen, when programming for the Sifteo cubes you are dealing with lots of static images, and swapping them in and out as you need. Meaning in my application in the video, I have 10 different image files, one for each digit.

I enjoyed the experience of hacking and playing with the blocks. I think there are some interesting questions that could be explored using them. We will see!

Tagged , , ,

Double blogging

To save me talking about my most recent published work for a second time, here’s a link to my Digit Distribution work on the CHI+MED project’s blog.

Tagged ,

Punctuation and number entry

I was recently told a story by JW which made me reconsider by focus on purely digits and the decimal points. I now consider the comma to be an interesting character in the world of number entry.

J explained how he was trying to set up a monthly payment online for a particular bill.  He wanted $170.00 to be automatically taken out of his account, and sent the billing company.  On the website, he got to the text box in the form that asked for the monthly amount he wished to pay, and he entered in 170.00:

Only this isn’t what he typed. He typed this out on a laptop keyboard and so used the top row of numbers, and the full stop as a decimal place. When he typed the decimal place however, his finger slipped and what he actually entered was this:

A few weeks later, J gets a call from his wife, frantically asking him why their bank balance is so incredibly low all of a sudden. After inspection, it turns out that for two months, $17,000 has been leaving their account each month. Oops.

When J submitted the form, he didn’t notice his mistake, there was a difference of two pixels between the decimal point and comma character in the font on the web form. He saw there was something there between the first to zeros and understandably assumed it was the decimal point he’d gone to press.

The first error was typing a comma instead of a decimal point and not noticing it. But really, if this wasn’t picked up by the human, it so easily could or should have been picked up by the system. That comma is in a weird place – if it were representing a thousand marker, there should be an extra zero, or is should be between the seven and the zero. This was a malformed number entry. And the system did not pick up on this. Instead, it chose to ignore that comma, and strip it out of the input, leaving only 17000. And resulting in an incredibly angry customer.

Conclusion: Think about the erroneous characters people enter, even in number entry. Don’t ignore them without thinking about why they might be there.

Tagged ,

Digit distributions

If you’ve ever wondered what numbers people are typing into those funny machines whilst watching Casualty of a Saturday night, here is a video explaining some of the initial work I’ve done looking into the types of numbers used in hospitals.

The results proved interesting with obvious patterns occurring with some of the digits – nought gets used A LOT. The digit nine gets used a lot in surgery too. Look at the video to find out why I think these sorts of distributions are happening.

Tagged ,

Number Entry isn’t interesting you say?

I did some stand-up comedy based upon my research into number entry interfaces in hospitals. Don’t believe this can be done? See the video for proof.

Tagged , ,

Fat Finger Trades

I know the title might not sound that appealing but this is quite an interesting and widely documented phenomenon in the world of financial trading.

Millions of dollars have been lost and entire markets brought down a few points due to a fat finger trade (FFT).

What is a FFT then?  A FFT is an error that occurs when the user attempting to buy or sell shares accidentally hits additional keys to those they are targeting.  The Hindu Business Line provides a nice lists of examples of these errors.  The error normally results in trades being made for 10 or 100 times as much as intended.  As you will find out, context is everything for this type of error.  No big deal if you are working on your home computer and are able to correct the mistake but when dealing with amounts in the millions, this can have a huge impact upon the companies involved, and as listed above, an entire market.

The problems don’t end there.  Occasionally a FFT can have even worse consequences for the company involved.  In December 2005 the Times reports an instance of a FFT occuring at the Japanese company Mizuho Securities.  Instead of selling 1 share at 610,000 Yen, the employee typing this in accidentally sold 610,000 shares for 1 Yen each.  Not only did the error result in huge monetary discrepancies but the company actually sold far more shares than they had, in fact it represented “more than 40 times the total number issued by the company”.  Yikes.

How easy is it to place checks and guards into trading software to ensure that trades aren’t made for 40 times the company’s worth?  The task seems a trivial one so why has it not been implemented?   It could be that in the dynamic and changing world of financial trading the task would involve a fair amount of computation.  But these are just the type of calculations that most pieces of financial trading software are made to deal with.  We could explain the lack of safe guards on poor User Centred Design.  The companies commissioning the trading software will focus on the efficiency and speed at which their employees are able to trade at.  In the fast moving world of stocks and shares speed is key to buying lowest and selling highest (fact generated by me based on films I have seen).  There is no incentive for the software to be designed to do anything else any better.

Well it seems like feedback from these errors is reaching those in charge of designs.  This article in the Sunday Morning Herald of Australia suggests that the FFT is being weaned out due to increased checking in the trading software – fantastic.  Turns out it wasn’t an impossible problem.  The article speculates that perhaps the recent dip in the Dow index was not down to a FFT but rather some error resulting from the program itself.  At this point it isn’t human error, I say hooray and leave the analysis of the computer program to someone more interested in analysing the code of financial trading systems than myself.

One last thought on the FFT example from Mizuho Securities – is this a FFT at all?  It seems like the issue here wasn’t pressing additional keys by accident but rather confusing the two numbers and entering them into the wrong locations in the interface.  This could have been caused by a confusing interface or a lack of experience or simply mixing the numbers up in the employee’s head.  It seems that the term “Fat Finger Trade”, in the media at least, is being appropriated for all types of error that occur in the financial market.  How important is this generalisation?  Well if we just want to read about traders doing stupid things, it’s a pretty useful search term.  But, as a student researching types of number entry error, I really think this generalisation hides the more interesting information.  If we break the generic FFT error down into more accurate descriptions of what’s going on, we can begin to look at causes (were they distracted? keyboard too small? numbers too hard to read? numbers too similar? confusing interface? no training?), and the myriad of possible cures.

So newspapers, you can have your buzz words but when you the reader see it, think about what’s really going on – it’s far more interesting.


The price of electricity is on the rise

Tony Leventhal received a shock in 2007 when his credit card company called to ask him about a rather large payment to the electricity company. It turns out a reasonable £170 bill had turned into one for a massive £17,000Source BBC News. Full story.

How might this have come about? Well we’ll put this one down to human error. There are a few scenarios I can see that may have caused this error. Firstly, let’s look at the mistakes that could have occurred whilst reading the number to be entered. So the operator who was typing in the amount (at whatever stage in the process) is fairly new at this job and is working on transcribing bill amounts into the system. He’s a little distracted thinking about lunch whilst working. He sees the amount £170.00 and does one of two things. He might misread the number, by ignoring the decimal (making it £17000) or he reads the decimal point as a comma, albeit misplaced (reading it as £170,00). Both of these instances result in him inputting an amount 100 times larger than intended. How can we solve this issue? Well it all comes down to how this information was presented to the operator. Was it printed neatly? Was it scribbled down on some paper from a customer’s home meter reading when their electronic gadget went wrong? Who knows, but there are a few conventions we can take from the medical domain to help people read decimal numbers more accurately. One of which is to make the decimal point large. Don’t hide it at the bottom of the text, we don’t need things to look pretty, we need them to look readable. Another convention that works in conjunction with the large decimal is writing the decimal portion of the number in smaller numbers (see the Design for Patient Safety page). With these simple additions, reading and transcribing numbers can be easier and a lot more accurate.
Now let’s think about the possible slips whilst typing. In the following cases the operator has correctly read and knows the right number he is to enter. An error occurs however, due to the keyboard or display, and the operator is not aware when he makes a slip. I don’t actually know what the input layout is like on screen but let’s take a quick look at two possible form layouts and the associated error causes.
The first layout theory is simple and probably what you’d expect:
In this situation the operator may have aimed to type in £170.00 and accidentally missed the decimal key for whatever reason (he was distracted by something, the keyboard was still sticking from that time he spilt coffee on it etc.) Without the all important decimal place, the operator inputs the huge amount of £17000. As far as the operator knows, there’s no reason the decimal point hasn’t been inputted, he thinks he typed it and so does not double check the number. How could we prevent or protect against this error? One way would be to assume and check that every number typed into the system has a decimal point, even if the amount only comprises of pounds and not pennies. With this check in place the operator, upon entering the erroneous number with no decimal point, will be presented with an alert requesting they add a decimal point to the number. At this point hopefully the operator will look at the number they entered, the one they thought they typed a decimal place in, realise and correct their mistake.
Another way of fixing this problem might be to separate the pound and penny fields. This layout looks a little silly but who knows, this might be how it works! I’ve seen crazier input systems.
So this layout ensures that pounds and pennies are split. The operator doesn’t have to worry about decimal points! Hooray, hurrah! But really this doesn’t actually solve the problem. Now the operator has the option of accidentally not pressing an entirely different key, this time the tab key. Now our operator goes to type in the amount but doesn’t press the tab key, again for the same reasons, resulting in the first field being filled with 17000. And again, this problem is solved by having the system check the second field is filled with some value.
In both possible input systems, the small check to ensure that there is a decimal portion of the number would prevent the error we see above. It seems like this system could add a bit of time to the number entry process with operators having to type in the penny amount even if there are none. But only one in every hundred bills will be a round pound amount. If the operator is used to typing in the pennies then typing the two trailing zeros will mimic their usual typing pattern (type the pounds the ‘decimal/tab’, ‘digit’, ‘digit’).
I can’t say for sure that this error did occur by human error but I think the evidence and suggested scenarios are compelling and plausible. Let me know if you have any other suggestions for what happened and ways to prevent it. Or if you have any inside information about how this process actually works!