[Tfug] A sense of time

[Bexley Hall]

--- jblais <joe.blais at pti-instruments.com> wrote:

> > (sigh)  I guess my comments must be distracting
> from
> > the "real issue" -- what I consider the inherent
> > (unsolvable) paradox.  Stop thinking about
> > technology and technological solutions.  The
> > problem is in the brain of the user!  What I am
> > looking for is a good model that will help reform
> > that user's expectations (Principle of Least
> > Surprise) so that I can implement something that
> > he can *learn* to "accept".
> 
> That seems to be the problem, multiple users, and
> multiple uses!  There

Well, so far I am avoiding the "multiple users" issue;
if I can come up with a scheme that "makes sense" to
a *single* (dedicated) user, then I can find a way to
extend it to multiple instances...

> probably isn't "a" solution.
> The stuff I do gets reviewed by chemists. EVERY time
> it's different.  Change
> a GUI around once for someone, and when they review
> the changes, they want
> it back or another wants it yet another way!  It
> only ends when I say, that's IT!

Yup.  But, in that case, you *can* be The Authority.

In the time setting scenario, the *user* is (or, at
least THINKS himself to be!) The Authority.

> > The problem arises because the user isn't
> > constrained to think in any given way about
> > *changes* in that definition of time THAT HE/SHE
> > IMPOSED ON THE SYSTEM!
> 
> Perhaps sets of user definable/selectable rules for
> the various timekeeping
> needs, and let the technology work it out for each. 
> The problem then is to
> describe the various rules that we will implement,
> and how do we allow the
> user to select those rules for each of their needs,
> without making a big
> pop-up every time they click a button.
> 
> If an event happens, and we look at the clock on the
> wall, and it reads
> 1:23pm, and we record it as such. Do we expect the
> record of the event to
> read 2:23pm a week later when we reset our clock, or
> do we want the record
> of the event to still read 1:23pm MST.  So the user

Exactly.  But, the user may chose not to be consistent
in his/her expectations.  Yet, a well designed product
must "fit" (cater?) them.  :-/

> could define a rule for
> some type of event as, display relative, or display
> "absolute".  If it was a
> lunch event, we would probably have a rule that
> would show we went at 11:30
> every day, even when the clock was changed.  We tend
> to go at 11:30 even if
> our clock is "wrong", the faster the clock, the
> better.  However,  A car
> accident may have happend at 1:45am.  We won't
> change that when we change
> the time for instance if we change from daylight
> savings time, but we would
> change it if the watch of the officer was off.  "but
> really judge, I wasn't
> even there at 1:45, and I can prove it!".
> Another issue is to synchronize.  "Lets synchronize
> our watches and go at
> 2:30".. it may be 4:45, but if they all read 2:30 at
> the same instant,
> that's OK.

Yup.  Though I can handle the events that *require*
synchronization "on the sly", without the user's
involvement (i.e. deal with them on "my clock"
and ignore what the user's concept of time might be
at that point)

> You can please some of the clock watchers some of
> the time, but you cant
> please all of us all of the time.

I suspect I will stick with an immutable time
reference and just build an abstraction layer
atop it that I can "fudge" later...


      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/