Cloud Date Entry

I might add that in the event of using [mo] [day] [year], at least the first
two could automatically tab over if two digits are entered, which is quite a
speed up in entry.

Also, unless I missed this somewhere, why could the entry preference not be
part of the login profile?

Chandru
"Peter McMurray" wrote in message
news:YZIrk.30540$IK1.28032-at-news-server.bigpond.net.au...
>
> "dawn" wrote in message
> news:ca4893ba-793a-4293-b9d8-6ec7fd7456f1-at-59g2000hsb.googlegroups.com...
>
> For casual users, you can go with the approach of having them select a
> date from a calendar so that there are no post-entry validations --
> only make the acceptable date choices available. This can be useful
> even for the not-so-casual user, although not entirely acceptable for
> any heads-down data entry (which I hear is not yet dead). cheers! --
> dawn
> Hi Dawn
> It has been an interesting set of responses. I guess some people do not
> have experience of setting data entry rythm that gets the job done quickly
> and improves the operators' experience significantly. I am delighted to
> say that I have had operators return to my sites after doing other jobs
> and tell me how great my screens are to use.
> Anyway I have taken the comments on board and written a routine that can
> handle separate or single field entry. I realised that there are no more
> key strokes to doing Day month year as separate fields or doing Day sep
> month sep year in one field. Now my only concern is can North Americans
> handle the day first :-) Mark's response seems to be yes.
> I don't think that limiting the acceptable set of entries is a goer as one
> would have to do the ISO way of Year, Month, Day and I am pretty sure that
> nobody would like that
> Peter McMurray
>>
>
>
>

Hi
I regard automatic tabbing or returns as the most iniquitous idea any
programmer ever had as they totally destroy an operator's rythm leading to
all sorts of errors. Data entry operators are not typists, they are reading
from a document not looking at the screen whereas a typist is normally
looking at the screen and using both hands which is where the disaster of
TAB instead of return has arisen.
Yes I have taken up the idea of mdy as a login flag but if one is splitting
the entries one also has to have different methods of screen display to add
complexity to one's Javascript or VB etc. This is fine for an application
but I am thinking of a wider audience such as a casual user and I abhor
exceptions.
Peter McMurray
"Chandru Murthi" wrote in message
news:PnWrk.557$w51.221-at-trnddc01...
>I might add that in the event of using [mo] [day] [year], at least the
>first two could automatically tab over if two digits are entered, which is
>quite a speed up in entry.
>
> Also, unless I missed this somewhere, why could the entry preference not
> be part of the login profile?
>
> Chandru
> "Peter McMurray" wrote in message
> news:YZIrk.30540$IK1.28032-at-news-server.bigpond.net.au...
>>
>> "dawn" wrote in message
>> news:ca4893ba-793a-4293-b9d8-6ec7fd7456f1-at-59g2000hsb.googlegroups.com...
>>
>> For casual users, you can go with the approach of having them select a
>> date from a calendar so that there are no post-entry validations --
>> only make the acceptable date choices available. This can be useful
>> even for the not-so-casual user, although not entirely acceptable for
>> any heads-down data entry (which I hear is not yet dead). cheers! --
>> dawn
>> Hi Dawn
>> It has been an interesting set of responses. I guess some people do not
>> have experience of setting data entry rythm that gets the job done
>> quickly and improves the operators' experience significantly. I am
>> delighted to say that I have had operators return to my sites after doing
>> other jobs and tell me how great my screens are to use.
>> Anyway I have taken the comments on board and written a routine that can
>> handle separate or single field entry. I realised that there are no more
>> key strokes to doing Day month year as separate fields or doing Day sep
>> month sep year in one field. Now my only concern is can North Americans
>> handle the day first :-) Mark's response seems to be yes.
>> I don't think that limiting the acceptable set of entries is a goer as
>> one would have to do the ISO way of Year, Month, Day and I am pretty sure
>> that nobody would like that
>> Peter McMurray
>>>
>>
>>
>>
>
>

"Kevin Powick" wrote in message
news:2a838fcd-ab3c-421f-9873-8ee8101ac2f7-at-d45g2000hsc.googlegroups.com...
> On Aug 23, 1:11 am, "Peter McMurray" wrote:
>> Hi Kevin
>> Like Chandru I am fondly hoping that this is a joke
>
> Joking? Me? :-)
>
>> I once thought like that and many
>> years ago for a really serious error such as recovering a batch update
>> after
>> a system crash I clear the screen , draw a box and print an appropriate
>> error message followed by the words "Please Note This Error and Call
>> Excalibur". I do not have this happen very often however I can say that
>> when it does the odds of a person answering my query of "what was the
>> error?" with "Please Note This Error and Call Excalibur". are 10 to 1
>> against. Further prodding as to what preceded those magic words will
>> probably end up with a huffy "I don't know".
>
> I guess if you were smart enough to trap the error and display such a
> message, you should have logged it as well. As many operators don't
> report errors anyway, you might even want to have the application
> "phone home" and alert you to the situation.

AhHah! You are assuming ultra modern connections many of my clients have
only recently come across the internet so yes one can do that now. By the
way EXXON auditors enforcing their version of Sarbanes/Oxley do not allow
auto dial up even now. In fact they insist on the banking being done
through a separate workstation in a locked room using the "brilliant" idea
of SneakerNet to prepare a floppy from the server then carry said floppy to
super separate workstation .
Peter McMurray



>
>> OR asking for it as INVOICE DATE d [ ] m [ ] year [ ]
>
> I tend to like it when there is no ambiguity and, as indicated
> earlier, the above input method does not introduce any extra
> keystrokes.
>
> --
> Kevin Powick

Peter:

I'm not sure where you get the idea that tabbing is unjust (or unfair), or
that a typist looks at the screen. Your definitions are something with
which I am unfamiliar; thus your analysis is based on assumptions I would
have never made.

Bill

"Peter McMurray" wrote in message
news:ZM0sk.30873$IK1.3934-at-news-server.bigpond.net.au...
> Hi
> I regard automatic tabbing or returns as the most iniquitous idea any
> programmer ever had as they totally destroy an operator's rythm leading to
> all sorts of errors. Data entry operators are not typists, they are
> reading from a document not looking at the screen whereas a typist is
> normally looking at the screen and using both hands which is where the
> disaster of TAB instead of return has arisen.
> Yes I have taken up the idea of mdy as a login flag but if one is
> splitting the entries one also has to have different methods of screen
> display to add complexity to one's Javascript or VB etc. This is fine for
> an application but I am thinking of a wider audience such as a casual user
> and I abhor exceptions.
> Peter McMurray
>
> "Chandru Murthi" wrote in message...
>>I might add that in the event of using [mo] [day] [year], at least the
>>first two could automatically tab over if two digits are entered, which is
>>quite a speed up in entry.
>>
>> Also, unless I missed this somewhere, why could the entry preference not
>> be part of the login profile?
>>
>> Chandru
>>
>> "Peter McMurray" wrote in message ...
>>>
>>> "dawn" wrote in message...
>>>
>>> For casual users, you can go with the approach of having them select a
>>> date from a calendar so that there are no post-entry validations --
>>> only make the acceptable date choices available. This can be useful
>>> even for the not-so-casual user, although not entirely acceptable for
>>> any heads-down data entry (which I hear is not yet dead). cheers! --
>>> dawn
>>> Hi Dawn
>>> It has been an interesting set of responses. I guess some people do not
>>> have experience of setting data entry rythm that gets the job done
>>> quickly and improves the operators' experience significantly. [snipped]
>>> Peter McMurray
>>>>
>>>

On Aug 24, 7:43*pm, "Peter McMurray" wrote:

Well said Peter.
High praise indeed when the folks using your software fly through the
tasks at hand and save their explicative deletes for other topics,
taking the software for granted - it’s just there and does what it’s
supposed to do without a lot of excess effort.
As to the “ time cloud” - I would have a global option flag per
operator (set once) as to their preference and then have the software
do all the work.
The bigger problem for the “cloud” is time-of-day when the parties are
separated by multiple time zones. The world had a terrific opportunity
back prior to 2000 when they were focused on adding the century to
their data. They should also have added a GMT offset into all date/
time data. This is certainly lacking in the MultiValue world. We brag
how our dates and times are easily converted and stored. While that is
true I can only wish that we were storing the GMT offset in our data
as well. That way all date/time data could be handled in the “cloud”
as it all would be based on a standard “universal time”.
All military apps figured this out eons past. Business is just now
beginning to recognize the problem. It will happen sooner or later.
The www has forced it on us.
Regards, Tom

On Aug 24, 11:54*pm, Tom Phillips wrote:
> On Aug 24, 7:43*pm, "Peter McMurray" wrote:
>
> Well said Peter.
> High praise indeed when the folks using your software fly through the
> tasks at hand and save their explicative deletes for other topics,
> taking the software for granted - it’s just there and does what it’s
> supposed to do without a lot of excess effort.
> As to the “ time cloud” - I *would have a global option flag per
> operator (set once) as to their preference and then have the software
> do all the work.
> The bigger problem for the “cloud” is time-of-day when the parties are
> separated by multiple time zones. The world had a terrific opportunity
> back prior to 2000 when they were focused on adding the century to
> their data. They should also have added a GMT offset into all date/
> time data. This is certainly lacking in the MultiValue world. We brag
> how our dates and times are easily converted and stored. While that is
> true I can only wish that we were storing the GMT offset in our data
> as well. That way all date/time data could be handled in the “cloud”
> as it all would be based on a standard “universal time”.
> All military apps figured this out eons past. Business is just now
> beginning to recognize the problem. It will happen sooner or later.
> The www has forced it on us.
> Regards, Tom

As an aside, I have always been amused that while China spans 5 (or
more, I forget) times zones they only have 1 official time zone. This
has worked well for them internally, BUT when they attempt to join the
"cloud" they too will need to adjust their time calculations. I wonder
if there is any MV in China.

Hi Tom
We don't need to go to China to see what can happen. You should see the
muddle here when we have only 3 time zones but different states go there own
way on Summer time. Since the contract prices for fuel run midnight to
midnight and it is perfectly reasonable for a log truck to take 1000L plus
at 2am at some remote unattended interstate location :-)
Then just to rev things up some more a major petrol pump company decided not
to have year 2000 compliant software. They genuinely expected a couple of
our major clients to spend North of $500,000 to replace perfectly good
systems with new you beaut devices that were capable of letting drivers
purchase airline or show tickets with their fuel! Funnily enough this
option was not greeted with great joy :-) We fixed it by setting the time
and date at the pump back 30 years as the calendar repeats on a regular
basis then just adding the missing years back in Pick.
At the moment we are using the time as recorded at the sale point - every
till or remote dispenser is a separate sale point - but as you guessed I am
now concerned about someone in another location not controlled by me. I
have been convinced by this discussion to go with the flag. and offer both
single field entry or 3 field entry to the designer for the dmy/mdy and even
the ymd selection as the validation routine couldn't care less so long as it
gets fed the 3 items to work it's magic.
As for the military, the wondrous muddle caused when they repositioned the
GPS satellites was quite spectacular. Those fishermen that just hit the
button to go back to where they left the craypots then moseyed off down
below for a game of cards or a couple of cold ones wound up in some very
interesting places :-)
Peter McMurray

"Tom Phillips" wrote in message
news:3eca6fc5-3827-4336-9115-37c9bfac1bf5-at-c65g2000hsa.googlegroups.com...
On Aug 24, 11:54 pm, Tom Phillips wrote:
> On Aug 24, 7:43 pm, "Peter McMurray" wrote:
>
> Well said Peter.
> High praise indeed when the folks using your software fly through the
> tasks at hand and save their explicative deletes for other topics,
> taking the software for granted - it’s just there and does what it’s
> supposed to do without a lot of excess effort.
> As to the “ time cloud” - I would have a global option flag per
> operator (set once) as to their preference and then have the software
> do all the work.
> The bigger problem for the “cloud” is time-of-day when the parties are
> separated by multiple time zones. The world had a terrific opportunity
> back prior to 2000 when they were focused on adding the century to
> their data. They should also have added a GMT offset into all date/
> time data. This is certainly lacking in the MultiValue world. We brag
> how our dates and times are easily converted and stored. While that is
> true I can only wish that we were storing the GMT offset in our data
> as well. That way all date/time data could be handled in the “cloud”
> as it all would be based on a standard “universal time”.
> All military apps figured this out eons past. Business is just now
> beginning to recognize the problem. It will happen sooner or later.
> The www has forced it on us.
> Regards, Tom

As an aside, I have always been amused that while China spans 5 (or
more, I forget) times zones they only have 1 official time zone. This
has worked well for them internally, BUT when they attempt to join the
"cloud" they too will need to adjust their time calculations. I wonder
if there is any MV in China.

"Ed Sheehan" wrote:
>You have to scroll forever to find it, but it's well worth the effort.

And like masses of unquoted quotes intermingled with original content,
I get a kick out of downloading 319 lines of text in a thread (that
I've been avoiding) for a single line of content.

Just ignore me today, I feel grumpy and not very restrained.
Best,
T

Mea Culpa gentlemen. Nay Mea Maxima Culpa.
In f uture I shall stick to top posting regardless of the wails from those
bottom posters. I really did not expect anyone to scroll past my signature
after Chandru's response. I should, of course, have trimmed the rest but I
was deep in thought about the subject.
This has been great for me as I am really interested in how users respond to
a methodology so that I can write better software.
Thanks to all for the participation it has gone on much longer and more
intensely than I anticipated.
Peter Mcmurray

"Tony Gravagno" wrote in
message newsdf8b454no96mpua4q1vf68ra7suum0frs-at-4ax.com...
> "Ed Sheehan" wrote:
>>You have to scroll forever to find it, but it's well worth the effort.
>
> And like masses of unquoted quotes intermingled with original content,
> I get a kick out of downloading 319 lines of text in a thread (that
> I've been avoiding) for a single line of content.
>
> Just ignore me today, I feel grumpy and not very restrained.
> Best,
> T

YEA! A convert to posting the way God and Gore intended.

"Peter McMurray" wrote in message
news:O60tk.31571$IK1.15436-at-news-server.bigpond.net.au...
> Mea Culpa gentlemen. Nay Mea Maxima Culpa.
> In f uture I shall stick to top posting regardless of the wails from those
> bottom posters.