Of mice and men

Kellie has generated some heated controversy over data entry and methods of
doing it.

I looked through the thread and noticed that most people in it are not in
favour of date pickers, even though Richard offers a choice between GUI or
text for dates, as do I.

I think Kellie has some good points.  I further think that, as we have seen
here many times, people tend to favour what they are familiar with.

The 'perceived wisdom' is that keystrokes are quicker for data entry. I
wouldn't argue that they certainly are if you are a trained data entry
professional and the input is all numeric, but what about the average user
just entering data to an application?

Gavan suggested that his keystroked date entry had unassailable advantages
over any other form of input. How many clicks would it take on your date
picker to do this (very contrived and narrow) task?

Could it be done in less than 30 key strokes?
Yes. Certainly.
Would it be worth doing?
That depends... what's the saving?

Prompted by this 'challenge' I decided to have another look at the whole
business of data entry in the 21st century and see if the 'perceived wisdom'
really stands up.

Now, if you don't have access to a GUI environment, you might as well stop
reading here. (Besides, your mind is already irretrievably closed and you
might as well just keep banging away at the keyboard and be happy until
retirement...:-))

I decided to do some tests and see if the mouse is REALLY any more
difficult than the keyboard, for the average non-professional, user.

Some of you might like to try it for yourselves:

http://taurangawriters.org.nz/CLCentry.htm

Obviously, when designing data entry and user interfaces there are  a myriad
things to be considered. That was what prompted Kellie's post in the first
place. I wasn't happy about the way some of her ideas were dismissed, and
the perceived wisdom, or prejudicial opinion was trotted out as being Holy
Writ. (There has been more than enough religious discussion in this forum of
late and it doesn't need to extend to computer programming.)

It's time there was some rethinking in the way things are done. Fresh minds
bring fresh ideas. (An idea should be considered 'good' until it is seen not
to work, not just imagined not to work...).

It will not surprise me if different people arrive at different conclusions
from the same set of tests in the above.

Get someone who ISN'T a COBOL programmer. Let them try it out, preferably
before you have suggested what the desired result should be, and post your
conclusions to this thread.

At least it will be on topic...

Pete.

Frankly, I was really surprised the results I obtained from the link above.






Why not consider the whole business of data entry in the 21st century and
try it woyhout preconception.

I don't mind mice - but code needs to be written for people who choose not t
o
use them.

My laser-disk player doesn't have all the buttons I like.   I put in a DvD, 
and
it spends its eternity to get to the main menu (teaching children patience),
 and
then it wants me to press ENTER to start the movie.    My player doesn't hav
e an
ENTER key, so I need to use the remote control.   Remote controls are OK, bu
t I
need my glasses to use them.    I've heard ads for the latest Boise wave rad
io -
it doesn't have any buttons, people who use it don't have any choice - they
*must* use the remote control.   (When did "remote" become a noun?  I'm sooo
 out
of touch with things).

Give us alternatives.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1115014840.900145.99880@o13g2000cwo.googlegroups.com... 
> since the 
>
> That was simply to dispell the view that 'without a graphical UI the
> program must be stone age'.
> 
>
> How can commenting on _Cobol_ be a digression here ?
> 
> :-)
>
> OK. It is _much_much_ faster to enter using the keyboard, but that is
> because using the mouse just doesn't work:
>

Hahaha! Fair enough... :-)

> * Error: thissound.Play is not a function
>

Looks like the Sound object didn't get instantiated. I only added it so
there was a 'click' when people clicked. I tested it in eerie silence and
decided it wasn't giving feedback to the user. I then grabbed a sound
routine from other pages I have.

Your input makes me think I probably need to revisit all the serious pages
where I use this code. Thanks.

> My adblock also shows up where your 'embed' tag is, probably because
> embed is not html.

Hmmm... 'embed' is actually supposed to be preferred to 'object' ... (or
maybe I have that the wrong way round...)
>
> * Error: tabmonths is not defined
>
> While tabmonths is a table your reference to it is a MSism shortcut.
>
Oh yeah, I forgot to qualify it back to the document. IE doesn't require
that but other Browsers do.
>
Bugger! Thanks for trying. I can see that people who don't use MS software
have all kinds of trouble :-)

Sorry, I really wasn't waving a red cape. It was something I did in a hurry
and it is aimed at MS Browsers. Works fine on those.

Having said that I am aware that this is also a narrow view.... :-)

Pete.

Dan,

I can't thank you enough for this.

Superb.

Did you try it with the changes you suggested?

If you find it is OK in Netscape/Firefox, please mail it to me and I'll post
it to the server.

I understand if you don't have time; I've still learned a bundle from your
post and will make the changes when I get time. At the moment I'm trying to
write a very complex corporate report that is driving me up the wall and
occupying most of my energy. And I have a number of people I must see this
and next w which means some travelling and fairly intense negotiation
(even though I love it, it is still draining... :-)).

Comments interspersed below...

"LX-i" <lxi0007@netscape.net> wrote in message
 news:3508f$42783ecd$45491c57$18828@KNOLO
GY.NET...
> Pete Dashwood wrote: 
something 
>
> My Firefox (under Linux) wanted a plug-in to play the wav file.  (Odd,
> but it should still work without it.)
>
That's just for the click.
 
I 
>
> You could install the latest Firefox for Windows - just be sure to make
> it *not* your default for anything, and it should leave your web
> shortcuts opening in IE the way they do today.  :)
>

It's just too risky for me at the moment. On Friday I have a session
scheduled with a local vendor to supply hardware to my spec. I'm looking at
a notebook with 17in screen (built in video camera), P4 3+ GHz processor,
100GB HD (2 of these; one external for image copy), wireless and the works.
I'll load XP Pro on it and MAY set up a dual boot  partition with Linux.  (I
am also getting two other systems built for friends, so we should get a
reasonable deal...) Until I have that lot configured and working, and have
transferred everything from the existing machine and backed it all up to the
external hard drive on the new machine, I won't be installing anything new,
anywhere... :-)
 
use 
is 
>
> Richard has already hit on some of this, but I decided to look at the
> code, when the timer didn't work after I started typing.  (By the way -
> XHTML?  I'm impressed!  :>  )  Let me also preface this by saying I
> realize you've probably spent more time on it than you wanted to to
> begin with, so if you don't change this particular page, it's no skin
> off my back.
>
I do want to get the cross browser stuff working because I need the
knowledge for other things. This page is an experiment in more than one way.
I just don't have the time right now to finish it as I would like to.

> You're using shortcuts that Microsoft lets you get away with, but other
> browsers do not.  (Why that is, I don't know.)  For example, on line 176
> (at least that's the line in my browser) you reference "tabmonths".
> This is where JavaScript gets more verbose than COBOL!  ;)  For it to be
> "portable", you have to qualify everything up to the document element.
> (You can define variables to use as shortcuts as well.)
>
> So, instead of just saying...
>
> tabmonths.disabled = true;
>
> ,you can say...
>
> document.getElementById("tabmonths").disabled = true;
>
I knew I needed to qualify it to the document, and I tried:
document.tables.tabmonths.disabled = true;  Of course it didn't work and I
really didn't have time to bugger about with it. I've never seen
'getElementById' and it is so ... :-)

> ...or, if you're going to reference it a lot...
>
> var tabM = document.getElementById("tabmonths");
> tabM.disabled = true;
>
It just gets better and better !!

> (You can put the "var" statement outside all of your functions, and
> it'll be globally scoped, so any functions can access it.  We use that
> at work to select the documents in different parts of the frameset.)

Yes, I learned that one early on in the piece. You probably saw that I
included my globals with the globals for the stop watch.

>
> I'll bet, if you qualified all your form references with something like
> the above, it would work for everyone.  There is also a "forms"
> collection, which you can use to reference your various input elements -
> these are accessed either like this...
>
> // This blanks the value of this input element
> document.forms[0].nameOfMyInputElement.value = "";
>
> ... (where [0] is the index on the page), or like this...
>
>
> // This does the same thing!
> document.forms["myFormName"].nameOfMyInputElement.value = "";
>
I read about the collections in the DOM and understand indexing into them,
but I avoid it because it looks so clumsy. I need to revisit this. Thanks
for the pointers.

> This is some stuff that I've just recently come across, and it is really
> nice, especially that getElementById method.  Gone is the feud between
> document.all and document.layers - just name it and change it!  :)
>
yeah, it's neat...
 
>
> Not quite sure, but I think the capital "C" may be throwing you off
> (especially using XHTML).
>

Oh no! I'll check that out too. I understand and am careful with case
sensitivity in JavaScript but I may have goofed on that one...

I'm in your debt.

Thanks.

Pete.

"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:M2Wde.5235$VL3.376047@news20.bellglobal.com...
> Pete Dashwood wrote: 
These 
the 
it 
I 
alleviate 
cross 
so, 
> I think the fact that a screen is static is a major determining factor
> in whether a mouse or keyboard is faster.  I work over PCanywhere on a
> machine that is a timezone over, and when the connection is slow, the
> mouse becomes painfull, due to screen refresh. If I am running stuff
> with multiple screens, even when I know roughly where the next button
> is, I cannot click it until I wait for the screen so I can get my mouse
> into the right spot. On the keyboard, I just keep typing, and the screen
> eventually catches up. In fact, I might even miss an entire screen, as I
> know it is a question, and I type the answer before the screen arrives.
> Since the connection then proceeds to the next page, I might not see the
> middle one. It is quite measurably faster.
>

Yep, the bottom line is that, like so many things, either form of input may
be applicable, and it is a question of using the best tools for the job.

However, I am PERSONALLY (although I know many here won't be, and that's
fine too...) persuaded, that in the SPECIFIC instance being considered,
under the specific narrow and contrived circumstances, the mouse is a better
option.

What this has led me to think about is that it is really quite wrong to just
assume the keyboard is best. It isn't ALWAYS. Kellies idea of floating
balloons for errors, suggests to me that floating 'mousepads' close to entry
fields, could be a useful and viable form of data entry. (Drop down menus
are a step in this direction, but they can be tedious because of their
unidimensionality and consequent mouse movement.)

It comes down in the end to imagination. Kellie showed she was thinking and
not just accepting perceived wisdom. Even if her ideas don't prove to be
perfect in practise, at least she approached the problem 'correctly'.

My point is that more of us need to do that.

Pete.

PS the description of your system above sounds like there has been no lack
of imagination in designing it... :-)

In article <3drvivF6s4bkbU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>What this has led me to think about is that it is really quite wrong to jus
t
>assume the keyboard is best. It isn't ALWAYS.

*Nothing* is 'always'... including this statement.

[snip]

>It comes down in the end to imagination. Kellie showed she was thinking and
>not just accepting perceived wisdom. Even if her ideas don't prove to be
>perfect in practise, at least she approached the problem 'correctly'.

As I recall being said of the mathematician Ramanujan: 'At times he is
wrong... but he is wrong in such beautiful ways!'

DD

jce wrote:
>
> Some people with excellent planning put a TV in the kitchen
> too....some of the really smart planners have a TV embedded into the
> front of their fridge.

My cat stares at the fridge - sometimes for hours, even with no TV.

On  3-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
 
>
> I would suggest such an approach would be a *great deal* slower for a one
> handed typist!      ;-)

For various values of one-handed-typist.   I think Donald was referring to
someone who types with one hand as being a one-handed-typist.   That person 
can
use a mouse without slowing down.

It is possible to buy a foot-operated mouse.   I suppose that could speed th
ings
up, allowing full use of the hands while mousing.

"Howard Brazee" <howard@brazee.net> wrote in message
news:d5akks$j9c$1@peabody.colorado.edu...
>
> On  3-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> 
slower, 
one 
>
> For various values of one-handed-typist.   I think Donald was referring to
> someone who types with one hand as being a one-handed-typist.   That
person can
> use a mouse without slowing down.
>
> It is possible to buy a foot-operated mouse.   I suppose that could speed
things
> up, allowing full use of the hands while mousing.
>
(I cannot resist... :-))  Does it squeak when you tread on it?

Pete.

<docdwarf@panix.com> wrote in message news:d5ahu1$jk1$1@panix5.panix.com...
> In article <3drvivF6s4bkbU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
> 
just 
>
> *Nothing* is 'always'... including this statement.
>

I realise you are agreeing with me and I don't want to appear churlish here,
but I also know you enjoy a nice point, so....

I believe the 'arrow of time' is 'always', Doc...

(By definition, it started when time began and will end when time finishes.)
I s'pose one could argue that Time is not 'something', but it would be an
argument... :-)

> [snip]
> 
and 
>
> As I recall being said of the mathematician Ramanujan: 'At times he is
> wrong... but he is wrong in such beautiful ways!'

yes, if you're going to be wrong, might as well do it with style... :-)

Pete.