The adoption of a standard, high quality date widget across Sakai has been a long-term issue SAK-1399, SAK-7000, SAK-8069. Work on this issue is now being tracked under the umbrella JIRA SAK-7000, and considerable discussion has taken place on requirements at Date widget improvements.
Development of a candidate widget has taken place, currently delivered only within the RSF web framework. This page attempts to focus these requirements and assess which remain to be met, as well as to set out roadmaps for future work.
Major Requirements
The two most visible drivers of requirements for the Date Widget have been the Gradebook tool, and Resources. However, a standard widget should be possible to roll out amongst not only these tools, but all tools within Sakai.
Keyboard-only textual entry of dates and times
Expert users, as well as those unable to use a mouse, require keyboard-only entry of dates in a straightforward textual form. Widgets involving multiple drop-downs greatly increase the number of clicks or keypresses required to enter a date.
Popup on demand showing "calendar" widget allowing direct mouse selection of days
For quick selection by users equipped with a mouse, a calendar widget should pop up which allows direct selection of a day by means of a single click.
Should this pop up i) when a particular icon is clicked, or ii) when focus enters the text entry box
Fully localized with language and timezone information
Each Sakai user has the ability to set their own localization preferences for their UI, as well as each Sakai deployment setting an installation-wide default. The date widget should follow the correct algorithm for determining the appropriate Locale, and present the date and time information using
- correctly localised Strings for months and days,
- correctly oriented calendar accounting for "day 1" of a week,
- correctly localised representation of an overall date, whether yy/mm/dd, yy/dd/mm etc.
- correct appreciation of local timezones and cutover days when entering times
Configurable to allow date, date/time or time only entry
These three modes cover the typical specification requirements that an app requires.
Melete has requested a single entry field, however most other requestors prefer separate fields for time and date when required.
Efficient use of screen real estate
When "dormant" the widget should occupy no more than one line's worth of text.
Should the widget "self-edit" In-Line Editable Date Widget or appear as a normal entry field when required. Many users find this dynamic interface (a la Flickr) very convenient once understood, but can take a while before user discovers the edit functionality. A "mouse-over" cue would probably help. However, self-edit widgets will not degrade easily in a non-Javascript browser.
Available across all tools in Sakai
Historically this is the most challenging requirement, hampered by the fact that the deployed core tools within Sakai use a wide range of highly diverse view technologies. At the minimum, the adopted widget needs to be available in Velocity, RSF and XSLT with a possible requirement for JSF. Other candidates for porting might include plain JSPs, Struts and Wicket. The widget needs to function identically from the user point of view in each technology, with the additional challenge of not violating other user expectations within the hosting app.
Minor or conflicting requirements
Prompting or confirmation for particular localized form
When entering a date in a broken-up textual form like yy/mm/dd, the user needs added confirmation in some other form of the particular localized order. It will not be sufficient for the user to "trust" that the localized form is the appropriate one, since they will have wide experience of UIs which present them with date entry in an inappropriate locale.
Acceptance of more "free-form" textual date specifications.
Some users request wide flexibility in text parsing, for example "Jun 13th, 1879" or "1-Feb-08" could be recognised as date specifiers. However, others consider that the space of acceptable input could be hard to document, as well as leading to confusion in ambiguous cases, and that a fixed, prompted format would be superior.
Ability to specify valid date ranges checked on the client side
Based on server-side information, the available date range on the client should be constrained. This may be highlighted in the calendar popup by "greying out" impermissible dates, and/or by a temporary validation message representing the cause of error. Advanced points: i) constraints may be based on the state of a further widget on the same page (for example start/end dates), and ii) constraint violation should not reject user input or "back them into a corner" forcing a particular sequence of specifications amongst a related set.
A layout suitable for horizontal as well as vertical layout of widgets
(From Clay Fenlason). It is not clear how the design might be modified to better accommodate a horizontal layout.
Requirements status
We rate the performance of several deployed widgets in Sakai against the requirements above.
| Requirement | Historical | Melete | RSF |
|---|---|---|---|
| Keyboard-only |  |
 |
|
| Calendar popup | |
|
|
| Localized | |
|
|
| Efficient | |
|
|
| Cross-technology | |
|
|
| L10n prompt | |
|
|
| Free-form | |
|
|
| Validation | |
|
|
Future development and roadmaps
The most urgent requirement is that of being made cross-technology. This implies that the resultant widget be easy to use purely in terms of markup, as well as being potentially packaged as a "widget" in multiple server-side presentation technologies. Currently the portability of the RSF widget is impaired by the fact that it requires an AJAX cycle in order to make use of timezone/L10N information kept on the server. However, this AJAX cycle is stateless, and could be deployed as a standard central service within Sakai. Another route would be to rewrite the widget such that the majority of the date processing logic took place on the client side. This would increase both performance and portability, but would represent a significant coding and testing effort.
The Javascript used within the widget also needs to be vetted with respect to upcoming requirements on widgets themselves embedded in AHAH/AJAX "worlds" as described in Helpers and Gadgets within Sakai, Writing and using SuperHelpers within Sakai