What is the best Date Entry/Selection Widget You've Ever Seen? What Makes it the best? Same question for Time Entry/Selection.

28 Jul 2011 - 9:37am

Last reply:
3 years ago

2 replies

1571 reads

Mjmc_coy

2010

I'm putting together a design standard for the best possible widgets for date and time entry/selection. Anyone have examples that fit all or at least some of these requirements? I understanding that this is contextual and there is no one size fits all):

3. Does not require user to enter static data such as colons, spaces, forward slashes

4. Prevents the user from entering invalid dates and times within reason.

5. Clearly communicates the required format to the user prior to data entry using a good default value or input prompts), rather than providing this information after invalid data entry via an error message.

6. Accepts and interprets the format the user chooses to enter date and time values, and does not force the user to enter the values in the format that the system is programmed to display it (“forgiving format”). For example: recognizes 0130, 1:30 and 01:30 as 1:30 AM, and AM as well as am or a.m. Forgiving formats do not require a user to enter system required data (such as the leading zero in 01:30).

7. Displays dates in the format mm/dd/yy consistently onscreen and in print. a. This rule can be modified if real estate or data set requires it. For example, if the data set requires ‘yyyy’ format due the likelihood of the need for crossing centuries, this is acceptable both in print and onscreen. If real estate it tight the leading zeros can be dropped. If exceptions are made, please aim for consistency within as many views as possible.

8. Displays times in the format (h)h:mm AM/PM (e.g.: ‘10:30 AM’ and ‘1:30 PM’ on screen and in print.) a. This rule can be modified if real estate or data set requires it. For example, leading zeros can be added if the times read better in tabular data in print and onscreen. If exceptions are made, please aim for consistency within as many views as possible.

10. Displays time zone business rules when applicable. For example, if the time must not be converted to local time zone, this should be clearly communicated when the user is entering time zones.

Comments

29 Jul 2011 - 5:05am

DrWex

2006

I think this is a great standard if your user base and task
descriptions fit a certain profile. Let me suggest that in other
cases I've found it useful to have date entry widgets that:

supported paste operations. That is, users had a full date/time
string elsewhere and just wanted to copy it over to a new system in as
few clicks as possible. A bit empty box with some strong
pattern-matching behind it was rated most highly.

separated input areas from display areas. In some systems I've
worked on users have complained of the "clutter" involved in multiple
input widgets associated with date/time. To ease the visual burden on
the user we added a separate display area that updated as the user did
the input. The display rendered the output in an English
sentence-like form that would have been horrid to input but was rated
very easy to read.

On Fri, Jul 29, 2011 at 6:18 AM, Mike McCoy wrote:
> I'm putting together a design standard for the best possible widgets for
> date and time entry/selection. Anyone have examples that fit all or at least
> some of these requirements? I understanding that this is contextual and
> there is no one size fits all):
>
> 1. Supports multiple input methods – mouse (click and scroll), keyboard
> (explicit values as well as arrows, tabs, spacebar, enter) when the platform
> allows it.
>
> 2. Requires as little user input as possible to complete the entry -
> minimize keystrokes, mouse clicks, mouse movements, keyboard-to-mouse
> switches, and screen touches.
>
> 3. Does not require user to enter static data such as colons, spaces,
> forward slashes
>
> 4. Prevents the user from entering invalid dates and times within reason.
>
> 5. Clearly communicates the required format to the user prior to data
> entry using a good default value or input prompts), rather than providing
> this information after invalid data entry via an error message.
>
> 6.* Accepts and interprets the format the user chooses to enter date and
> time values*, and does not force the user to enter the values in the format
> that the system is programmed to display it (“forgiving format”). For
> example: recognizes 0130, 1:30 and 01:30 as 1:30 AM, and AM as well as am or
> a.m. Forgiving formats do not require a user to enter system required data
> (such as the leading zero in 01:30).
>
> 7. Displays dates in the format mm/dd/yy consistently onscreen and in
> print. a. This rule can be modified if real estate or data set requires it.
> For example, if the data set requires ‘yyyy’ format due the likelihood of
> the need for crossing centuries, this is acceptable both in print and
> onscreen. If real estate it tight the leading zeros can be dropped. If
> exceptions are made, please aim for consistency within as many views as
> possible.
>
> 8.* Displays times in the format (h)h:mm AM/PM* (e.g.: ‘10:30 AM’ and ‘1:30
> PM’ on screen and in print.) a. This rule can be modified if real estate or
> data set requires it. For example, leading zeros can be added if the times
> read better in tabular data in print and onscreen. If exceptions are made,
> please aim for consistency within as many views as possible.
>
> 9. Provides alternative support for mobile device’s (phones, tablets,
> PDAs, etc) limited and specific input methods.
>
> 10. Displays time zone business rules when applicable. For example, if the
> time must not be converted to local time zone, this should be clearly
> communicated when the user is entering time zones.
>
> (((Please leave all

29 Jul 2011 - 6:06am

Fredrik Matheson

2005

Great initiative.

I'd add "supports local date and time formats" + week starting Sunday or Monday. These vary around the world.

> I'm putting together a design standard for the best possible widgets for date and time entry/selection. Anyone have examples that fit all or at least some of these requirements? I understanding that this is contextual and there is no one size fits all):
>
> 1. Supports multiple input methods – mouse (click and scroll), keyboard (explicit values as well as arrows, tabs, spacebar, enter) when the platform allows it.
>
> 2. Requires as little user input as possible to complete the entry - minimize keystrokes, mouse clicks, mouse movements, keyboard-to-mouse switches, and screen touches.
>
> 3. Does not require user to enter static data such as colons, spaces, forward slashes
>
> 4. Prevents the user from entering invalid dates and times within reason.
>
> 5. Clearly communicates the required format to the user prior to data entry using a good default value or input prompts), rather than providing this information after invalid data entry via an error message.
>
> 6.* Accepts and interprets the format the user chooses to enter date and time values*, and does not force the user to enter the values in the format that the system is programmed to display it (“forgiving format”). For example: recognizes 0130, 1:30 and 01:30 as 1:30 AM, and AM as well as am or a.m. Forgiving formats do not require a user to enter system required data (such as the leading zero in 01:30).
>
> 7. Displays dates in the format mm/dd/yy consistently onscreen and in print. a. This rule can be modified if real estate or data set requires it. For example, if the data set requires ‘yyyy’ format due the likelihood of the need for crossing centuries, this is acceptable both in print and onscreen. If real estate it tight the leading zeros can be dropped. If exceptions are made, please aim for consistency within as many views as possible.
>
> 8.* Displays times in the format (h)h:mm AM/PM* (e.g.: ‘10:30 AM’ and ‘1:30 PM’ on screen and in print.) a. This rule can be modified if real estate or data set requires it. For example, leading zeros can be added if the times read better in tabular data in print and onscreen. If exceptions are made, please aim for consistency within as many views as possible.
>
> 9. Provides alternative support for mobile device’s (phones, tablets, PDAs, etc) limited and specific input methods.
>
> 10. Displays time zone business rules when applicable. For example, if the time must not be converted to local time zone, this should be clearly communicated when the user is entering time zones.
>
> (((Please leave all