Hi Tobias, Hmm. let s see if I can come up with a couple of reasons where it might be a bad idea: The application as a whole has lots of places where numbersMessage 1 of 42 , Jul 10, 2006View Source
Hmm… let’s see if I can come up with a couple of reasons where it might be a bad idea:
The application as a whole has lots of places where numbers are entered – but in most cases the number of digits that can be entered isn’t limited – rather the user is given a validation message next to the field when a number too large is entered. Limiting in this situation would be inconsistent. Don’t know why that would be horrible – just inconsistent – makes the software look rough.
Another case: I find that when I’m transcribing a number I’m looking at data on some other sheet of paper and not the screen. Let’s say I’m transcribing the number 12345678. I start entering it in the field and as I’m typing my finger stutters on the 2 such that I enter 122345678 – but since the software has limited me when I get to the 8 it just beeps at me. Or, even worse, the software moves me to the next field where I enter 8 into it. Eventually I look up and wonder – “hey – what’s going on here?” I hit the 8 a few more times and nothing happens – then I notice I’ve repeated the 2 [after deciding this software stinks]. At no time did the system let me know – explicitly – that I was trying to enter a number larger than I should. Certainly if the software had lots of fields that limited input like this, and I used the software frequently enough, I’d catch on and realize the software’s way of telling me my number was too large was to stop me from typing any more. I’d get used to it. But, me personally, I just hate software that blocks my keystrokes – stops me from doing a thing “in my own best interest.” But, even as I say that, I know it’s an example of self-centered design – it’s what bugs me – and not necessarily what bugs the target user. What I’d be interested in is what really happens when the functionality is implemented and how it feels to use.
One more thing: have you ever encountered a form that asks for a social security number, phone number, license plate number, or credit card number – but it won’t let you enter delimiting spaces, dashes – or the normal stuff you might enter if you were filling it out on paper? It makes the number you’ve entered hard to read – and if you have entered it wrong, harder to detect exactly why because you don’t have those comforting spaces to break things up into readable chunks. That’s why in my original post I mentioned I need to ask what this number was exactly.
But all that said, limiting number input is a small detail. I can’t imagine the strategy an interaction designer chooses here affects the design of the UI significantly. That’s why I was hoping that, in spite of the fact that I personally am unwilling to say that “the best way to do this is….”, that someone else had already done so and that I could quote them. That way I’m not culpable if it’s a dumb decision given the context of this application. ;-)
Hope that gives some context.
Thanks for posting back.
For me, I found sequence diagrams work well. Buy it may just be my style. Chris Pehura firstname.lastname@example.org 630-696-8101 ... From: Desilets, AlainMessage 42 of 42 , Jul 14, 2006View SourceFor me, I found sequence diagrams work well. Buy it may just be my style.
From: "Desilets, Alain" <alain.desilets@...>
Date: Fri, 14 Jul 2006 07:20:27
Subject: RE: [agile-usability] Interaction design rules of thumb - do they exist?
BTW, one of the things that doesn't work often enough is asking the users to report what they were doing. Many times I have seen users do one thing and then tell me that they did it differently. I would have doubted my sanity if I hadn't had co-observers with me.
Does this happen even in talk-aloud situations?