[AccessD] Short Date Input Mask question

Brett Barabash BBarabash at TappeConstruction.com
Wed Mar 17 14:43:00 CST 2004


>I do not believe that providing a pop up calendar is incorrect especially
as 
>the users can tab into a date field and use a keyboard in any event.  

You missed my point.  This is EXACTLY my sentiment.  

I said:
>One of my biggest UI pet peeves is fields that disallow keyboard entry.

My response was to someone who doesn't allow the user to tab into a date
field and forces them to open up a calendar instead.  In my opinion, this is
a lazy way of avoiding date validation code.

Have you ever used a program or website that forces you to use a calendar to
enter your birthdate?  (I have!)  Personally, I find it a PITA to click a
button to open a calendar, navigate to 1975, select May from a dropdown and
then click on the 6.  I'd like to type 05/06/1975, but some lazy programmer
decided that it's way more elegant to launch a special screen to guide me
through this complex process.

OTOH, Outlook gives you several different options for date selection.  To
schedule a meeting for tomorrow, I can type...
03/18/2004
March 18, 2004
2004 Mar 18
...or click on the box next to the field if I want to see a calendar.  

The developers put a lot of thought into this and because of its inherent
flexibility it is easy to use by all types of users.  I wish other pieces of
software were as ambitious.


-----Original Message-----
From: Jürgen Welz [mailto:jwelz at hotmail.com]
Sent: Wednesday, March 17, 2004 1:45 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Short Date Input Mask question

At one point a few years ago at this list I made a similar comment saying I 
provided a doubleclick pop up calendar and received a similar response.  As 
a result, I once logged usage of:

    Double click pop up calendar
               vs
    Key down with form key preview on, Alt-d pops calendar if screen active 
control had a standard input mask property.

I also considered a keyboard autokeys macro call a runcode that did the same

thing but never did implement this version.

Logging indicated that well over 98% of the data entry was by double click 
popup calendar.  Granted these were very 'unsophisticated' users but the 
majority of their daily tasks involved interaction with the application.

I do not believe that providing a pop up calendar is incorrect especially as

the users can tab into a date field and use a keyboard in any event.  IIRC, 
I had changed the display format and input mask dynamically in the past so 
that a user could key in 'mm/dd/yy' but the display format whenever the 
control didn't have focus was 'mmm/dd/yyyy'.  I also added a label 
displaying the input format at each date entry textbox so there was never a 
question as to the required input sequence.

I also believe that one of the reasons that my users like my pop up calendar

is because it also displays appointments and blocked off dates for that user

and other office staff (selected in multiselect list).  It can be popped by 
keyboard or by doubleclick and can be navigated by mouse or cursor or page 
keys (for months) and you can tab into a year textbox.  The months are each 
on a tab wtih Alt-character navigation and cursoring down past the end of 
one month moves to the next month (and up to previous).  Finally, the Enter 
keys accepts the date, sets the source textbox and dismisses the calendar 
and the Escape key dismisses the calendar without setting or changing a 
date.

I am a firm believer in always providing a keyboard navigation method, but 
that never precludes adding a mouse alternative that does exactly the same 
thing.  A pop up calendar can be entirely keyboard controlled at a cost of a

few extra keystrokes for the rich graphical information that it can present.

  And just because it's there doesn't mean a user ever has to use it.  It 
just turns out that my experience is that they will even though I have a 
prejudice for preferring to use the keyboard wherever possible.  I suspect 
this prejudice afflicts most programmers.

If only browers were more keyboard friendly.


Ciao
Jürgen Welz
Edmonton, Alberta
jwelz at hotmail.com





>From: Brett Barabash <BBarabash at tappeconstruction.com>
>
>I bet the data entry people love you!
>
>It may "work for you", but I'll bet that there are some users out there 
>that
>feel otherwise.  One of my biggest UI pet peeves is fields that disallow
>keyboard entry.  One record or 1000 records, it's still annoying to move
>your hand off of the home row of your keyboard and click around to select a
>date.
>
>
>-----Original Message-----
>From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com]
>Sent: Wednesday, March 17, 2004 8:22 AM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] Short Date Input Mask question
>
>
>My solution to date entry is simple - I never let user's type in a date.
>They always pick the date from a simple calendar form (though I don't  use
>the MS Calendar control). Click on a date field and up pops the date 
>picker.
>While this would not be suitable, perhaps, in applications where massive
>numbers of dates need to be entered, I find it works just fine for me.
>
>Lambert
>
> > -----Original Message-----
> > From:	Arthur Fuller [SMTP:artful at rogers.com]
> > Sent:	Tuesday, March 16, 2004 5:47 PM
> > To:	'Access Developers discussion and problem solving'
> > Subject:	[AccessD] Short Date Input Mask question
> >
> > The standard short date input mask (99/99/0000;0;_) has a shortcoming
> > that I hate: you have to type 04/04/04 to get April 4th 2004. The year
> > handling is nice but the month and day suck. The mask won't let you type
> > 4/4/04. Is there an alternative mask that will respond intelligently to
> > such input? Or should I instead just remove all the input masks from all
> > the date fields?
> >
> > TIA,
> > Arthur

_________________________________________________________________

--------------------------------------------------------------------------------------------------------------------
The information in this email may contain confidential information that 
is legally privileged. The information is only for the use of the intended 
recipient(s) named above. If you are not the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or the taking 
of any action in regard to the content of this fax is strictly prohibited.  If 
transmission is incorrect, unclear, or incomplete, please notify the sender 
immediately. The authorized recipient(s) of this information is/are prohibited 
from disclosing this information to any other party and is/are required to 
destroy the information after its stated need has been fulfilled.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is performed by SurfControl E-mail Filter software
in conjunction with virus detection software.




More information about the AccessD mailing list