RE: L-date fields

Scott,

I don't know. If you're in the habit of typing 19xx instead of just the 
year, I think you're just as likely to mistype 1998 instead of 1898 whether 
or not the year defaults.  That is why the confirmation is immediately 
displayed. When you exit the field (not the panel) the full date is 
inserted. Thus allowing the user to type in either 1998 or 98.

And the underlying code would never need to be changed. The default century 
should always be the current century or the next century, unless you're 
dealing with birthdays, then it should always be the current century or the 
prior century.

I am not a fan of code that "makes the user" do things so that the 
programming job is easier. I believe in inviting correctness, but being 
flexible enough to allow the user to EASILY stray from the normal process. 
Heck, we are the servants. We work for the end-user. They should not work 
for us.


Here's an example, on an inquiry screen, would you code this?

+-----------------------------------------------------------------------  
------------------+
+
+  Type the customer number or search name, then press Enter.
+
+    Customer Number: ________
+
+   or
+
+    Customer name: ____________________________
+
+-----------------------------------------------------------------------  
------------------+


Or would you code this?


+-----------------------------------------------------------------------  
------------------+
+
+  Type the customer number or search name, then press Enter.
+
+    Customer:  ____________________________
+
+-----------------------------------------------------------------------  
------------------+


A lot of applications still have the first panel design. I don't really 
understand why. There are instances where this kind of design is require, 
such as when the customer number is character-based. But if the customer 
number is numeric, can't the application look at the input data and 
determine "hey, this stuff is 7-characters or less, and is all numeric. 
They must have typed in a customer number... let me check."

This is the way I would do it.

So anyway, I understand your point, but I am always going to believe that 
we should help the end-user understand their own requirements, then suggest 
a simplified interface and then go out and code what they want.

Another method of decided whether or not to force 4-digit years vs 2-digit 
years or allowing both is to use the 80/20 rule.  If the end user has to do 
extra work for EVERY transaction just because they may occasionally need to 
type in 1898 instead of 1998, are they going to like the software more?

If I were an end-user, and I am a lot more lately, I think I'd prefer the 
package that allowed me to do the bulk of my work as effectively as 
possible, and provided an simple path to take for the occasional 
exceptions.


Bob Cozzi
Bob@RPGIV.COM
www.rpgiv.com
AS/400 Books:  http://www.rpgiv.com/as400Books.html


On Friday, September 12, 1997 7:55 AM, Scott Johnson 
[SMTP:sjohnson@highsmith.com] wrote:
> Bob,
>
> I have to ask the question that if we are not going to ask/demand 4 digit
> years from the user how are we going to know for sure what century they
> are talking about???   Programs cannot read minds.....
>
> Sure the programmer can do some fancy  programming to default it to
> some century when the year is less than some year, and some other
> century when greater than some year. BUT then that code would have
> to be 'fixed' in a few years.  We have some of this wonderful code in 
some
> of our programs now.  And I personally don't like it. It is a band-aid.
>
> Also, the programmer code write some code that defaults to the current
> century when on a 2 digit year is entered by the user.  Which I would
> guess is happening in that program you saw..  But I feel this would open
> the database up to A LOT of key errors and bad data.  The user would
> get into the habit of always just typing 2 digit years.  A customer will
> come along who is born on 09/02/1898.  The user in all their habits
> enters 090298.  Does not recheck the field when it gets resolved to
> 09/02/1998.  And the customer becomes not born yet in the database.
>
> --  Just my Two Cents Worth
> ------------------------------------------------------
> Scott P. Johnson              sjohnson@highsmith.com
> Programmer/Analyst
> Highsmith Inc.
> W5527 Hwy 106, PO BOX 800
> Fort Atkinson, WI 53538-0800
> TEL:  920-563-9571            FAX:  920-563-7395
> ------------------------------------------------------
> ----------
> From:         Bob Cozzi[SMTP:BobCozzi@ibm.net]
> Sent:         Thursday, September 11, 1997 5:38 PM
> To:   'MIDRANGE-L@midrange.com'
> Subject:      RE: L-date fields
>
> I agree with Jon on this.
> But what I've seen is that "entry programs" tend to allow the user to 
input
> only the 2-digit year, and then instantly convert it to a 4-digit year 
when
> the cursor leaves the input field.  This seems to be _the way_ users are
> going to expect this to work. I hope the DDS guys are providing something 
> like this!!!!!!!
> Of course the end-user can always enter the full 4-digit year if they 
want,
> but the user only has to enter something like this
> 091197
> and the program translates it on the screen, instantly to
> 09/11/1997
> I saw this today in action. It's pretty nice.
> Bob Cozzi
> Bob@RPGIV.COM
> www.rpgiv.com
> AS/400 Books:  http://www.rpgiv.com/as400Books.html
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
> | To unsubscribe from this list send email to MAJORDOMO@midrange.com
> |    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
> | Questions should be directed to the list owner/operator: 
david@midrange.com
> +---
> uucp
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---