[AccessD] Quarter hour increments

Hi Scott

First, you forget the original questioner, Gina. I don't think she has a business layer. If so, the frontend is where to put sophisticated business rules as only simple validation is possible at the table level. Still, if a business layer should be present, I agree that would be where to put it.

Second, I'm not telling you what to do with your specific users in your particular scenario. My opnion is general and nothing more than that.

Third, no rules can take care of allowed but incorrect input. If the user types 27 for 07 minutes that would be rounded to 30 for 0, no more no less. 27 is a valid input but if the user meant 07, it is incorrect, and so is 30 minutes. As you user probably is typing into a textbox, he/she can study the input and decide wether it is correct or not before moving on. If this is a time sheet, it probably has an Accept button, and the user has the responsibility to check the filled in data before pressing that button.

Finally, if you wish to tell the user that a rounding occurred, send a Beep, or - if the rounding would be an indication of a possible incorrect user input - pop a messagebox telling the user that "The 27 minutes were rounded to 30 minutes." which leaves the user with the option to correct or accept it.

In our time billing application we have put a lot of efforts in helping the users to not type in figures that may be incorrect. We don't round to 15 minutes but to one minute, you have the option of typing decimal hours as well as time duration in hours and minutes where automatic correction of time (0 to 24) and minutes (0 to 59) without typing the separator colon and eventually passing Midnight is an exercise on its own. But users appreciate it very much.

/gustav


>>> marcus at tsstech.com 24-10-2005 15:09 >>>
Gustav,

<< Hi Scott
<<
<< That's right, but you were suggesting validation at the table level.

And the other solution offers it at the application level. That's still
not a middle tier. To make it a middle tier, could be a silly decision.

<< Thus your business rule should catch this "error" silently,
<< and gently and/or quietly guide the user to the desired input
<< which - according to your business rule - in this case
<< would be to round up, down, or to closest quarter of an hour.

If you just round, the user gets accustom to that so that when they
really 'fat finger' the entry (27 oops I meant 07), it is rounded
(likely incorrectly) and probably ignored. I don't like that solution. I
would rather the user put in valid data than just rely on the program to
fix the time. I have learned that time tends to be very import (in my
case peoples pay depends on it) I want no mistakes when entering it. To
each his own...

<< Details like these handled in a way that has the user in
<< focus add quite a lot to the total user satisfaction.

And the first time you get called into a meeting as to why the data is
wrong and someone has to cut another check, you try explaining how you
thought it would make for a better user experience, you'll understand
where I'm coming from.

Scott Marcus
IT Programmer
TSS Technologies Inc.
www.tss.com