DRAFT Goals/Requirements for Date/Time Widget UI

Basic UI

¿ It should be possible to enter both date and time as text.

Rationale:
Drop-downs are cumbersome for most users and present particular problems for the visually impaired. The inconvenience is magnified if the user is setting many dates and times, which is not the case when booking a flight but may be when loading multiple Resources onto a course.

A calendar or datebook grid may require a user dependent on a screen-reader to tab many times to reach a desired square.

¿ Date and time should appear as two separate fields.
Rationale:
Someone skipping through the site using tabs or headings will be less likely to make an error if the time component is separate. There is otherwise too much opportunity for user error--1) have to recognize that time is mixed in with date, 2) have to worry about putting two different formats on the same line. (Increased cognitive load.)

¿ The widget should display "Date" and "Time" labels on behalf of screen readers.
(A date label is included in the Style Guide.)
from Mike: "label for" and "id" tags must be included to associate text fields with labels.

¿ Date and time fields should be available on both the "Add" and "Edit" pages for resources. The user should not have to go to a dedicated page to schedule each resource. This implies that the interface should occupy a limited amount of screen real estate.

¿ Once the user sets dates and times for a resource, the next resource to be added or edited should inherit the dates last set as a start time and as an end time, for the duration of the session.
from Mike: Inherited, as well as default, dates and times should be displayed whenever users are assigning them to resources.

¿ The widget should allow the user to set date only, defaulting to midnight of the date set. The widget should be configurable to show only a date in tools where time is not required.

¿ The widget should provide a pop-up calendar. See Style Guide pp 31-32.
Rationale: The user often wants help mapping day-of-week and intervals of time onto a day- of-month. Many sighted people will find this interface convenient. (Calendar appears in Style Guide.)

¿ The size of the calendar icon displayed after the text field should be larger than is shown in the Style Guide or appears in existing Sakai tools.
And/or
Daphne has suggested that the calendar pop-up might appear as the user selects the corresponding text field.

Internationalization

¿ The widget should allow a user to enter a date as
dd/mm/yy
mm/dd/yy
yyyy/dd/mm
(See David Horowitz post, entered at http://bugs.sakaiproject.org/confluence/display/RES/Date+widget+improvements)
from Beth: I believe if we stick to the "SHORT" date formats, we shouldn't be affected by the variability noted by David Horowitz.
Others?
from Daphne: I know you'd like to see more flexibility in formatting; can you define what you'd like?
from Beth: The date format should be dependent on the format defined for the current locale by the Java DateFormat class for the most flexibility.

¿ Once dates have been entered, the widget should display dates in the format corresponding to the locale defined in user preferences. That is to say, a South African student taking an online course set up by an American should see the dates as they are customarily displayed in South Africa, not as they were entered by an American professor.
from Mike: Where will the user set time and date formats? In Worksite Setup?
from Beth: Users should not set time and date formats – they should define their language/locale under user preferences, and the corresponding date/time format should be displayed.

from  

¿ The widget should allow a user to enter a time assuming a 12-hour or a 24-hour clock.
from Beth: The time format should be dependent on the format defined for the current locale by the Java DateFormat class

¿ Style Guide p 31:
Date Entry Format Tip: Show the appropriate format for entering the date. This is determined by the Sakai installation's date-format configuration.
(Time entry should show similar, configurable, hint.)
Mike: does it matter to a screen-reader whether this is presented inside or outside the text-entry box? Daphne had some concerns about the hint disappearing during use if it's presented in the text field.
from Beth: The current locale's date format (relying on locale in user preferences and Java DateFormat class) should be queried and displayed
from Mike: It should be part of the label so that it is announced to screen reader users. Ideally, it should be visible to everyone, in case the date is ambiguous, ie. 07/05/06.