[Sigia-l] Calendar Control and date/time input

[Heller, David]

Ok, to break down the problem.

Want to avoid formatting errors among different international groups. While
validation is possible, avoiding formatting problems in the first place is a
nusance.

Giving visual clues to the user so they know the context of a date w/ other
calendar elements: day of week, week in month, etc.

Keep validation on the server side to a minimum to speed up response time.

As for the time issue. The problem is validation as well, but less of a
problem b/c the format types are limited to fewer possibilities and are more
standard. 

I think Ziya's point about the slowness of DHTML systems is good to point
out. The Expedia example that is in my mind I am often frustrated with b/c
it is calculating the calendar after I click for it and thus doesn't give me
the instant reaction that I crave from this tool.

Does that help? Add more to the conversation? Etc?

-- dave

David Heller
Sr. UI Designer - User Experience Group
Docuemtum, Inc. (Pleasanton #6025)
1-925-600-5636
http://www.documentum.com/
david.heller at documentum.com
AIM: bolinhanyc // Yahoo: dave_ux //MSN: hippiefunk
 
-- "If it is not useful, it will never be usable."


-----Original Message-----
From: Ziya Oz [mailto:ZiyaOz at earthlink.net] 
Sent: Friday, April 12, 2002 3:48 PM
To: 'SIGIA (E-mail)'
Subject: Re: [Sigia-l] Calendar Control and date/time input


"Heller, David" wrote:

> I've been contemplating the use of calendar controls (ya know, a 
> calendar popsup in month format and allows you to click on a date to 
> fill out a date
> form) as I'm creating an app that currently has a requirement for this.

What exactly is the requirement? What is the (perceived) problem?
 
> What do people think of the use of this control?
> Why isn't there a similar control for time used on the web?

Many of these controls work best when they are smooth, instantaneous,
nimble, unambiguous, and easy to use. That's not a problem if the app runs
locally, but on the web there are issues. DHTML hacks can be slow and not
universally compatible with various browsers. Ones that require a separate
trip to the server are slow. Etc.

But, again, the more interesting  question is: what problem are you solving?
There's, for instance, a problem in acquiring date/time info from an
international userbase. There's also the problem of excessive overhead of
having to parse all these fields at the server for accuracy and consistency,
if the fields are designed to take accept free-form input or input not
customized for a given location.

I think you'd save time if you broke down the problem into discrete issues
that you know to be problematic either at the user-end or at the back-end.

Best,

Ziya


_______________________________________________
Sigia-l mailing list
Sigia-l at asis.org
http://mail.asis.org/mailman/listinfo/sigia-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.asis.org/mailman/private/sigia-l/attachments/20020412/ba8f723b/attachment.html