Hi Brian,
We are currently going through the same pains as you are in designing UI
widgets, particularly date/time widgets.
Before I add to your comments below, I'd like to add one important
consideration:
** The Platform is Important **
We are taking this into serious consideration when building an IE
implementation. Where possible we are trying to replicate the look and
feel of Windows. All of the widgets referenced by the WHATWG specs
already exist on many platforms. Windows already has date and time
controls as well as sliders and spinners for ranges and numbers.
We took the decision, that where possible, we would just copy Windows
look and feel. The only exception to this is the the date/time combo
control which we are still undecided about.
That said, consistency is important and we have the opportunity to raise
the level of web standards above the level of UI platforms if we
collaborate on a consistent look and feel. I am open to discussion on
this but would welcome the forming of some sort of group to focus on
these issues. A mailing list for implementers would be good. Can we set
that up?
Now to my comments. If I haven't commented it means I agree with what
you say. So basically this is a list of disagreements. :-)
Brian Wilson wrote:
2. Widget Look and Feel
--------------------------
2.1 Main Widget Characteristics
- Initial display is a read-only text box field with a calendar grid
icon on the left. Activating the widget invokes the calendar popup
sub-widget.
Why is the icon on the left? We've gone for straightforward combobox
look and feel. An icon doesn't scale as well as a tiny arrow so there is
a limit to how small the input box can be before the icon is illegible.
- The popup date selector should have a solid or beveled frame border
around it to differentiate from surrounding content.
We've gone solid ala Windows.
- Popup date chooser appearance: Suggested default dimensions for this
widget are 300px wide X 200px tall (is this ok? What should the
reasoning be? I just used a rough estimate based off the screenshot =)
We have a minimum width but no other restrictions. The height is
dependent on the font and other display properties. It is big enough to
hold a month view without scrolling. Our popup widgets will not be
scrollable.
- Popup date chooser placement: Heuristic for placement - should always
appear within the browser canvas when possible. The top-left corner of
the popup should appear just under the bottom-left of the read-only
text box. If the device window is too small to display at the
recommended dimensions, alternate layouts should be used, as long as
chooser functionality remains intact. it should display in "best"
location. Whatever the placement, chooser popup widget must be small
enough to always be totally visible even at 640x480. This requirement
may be even smaller on smaller devices.
We are using IE's createPopup method. This allows Windows to manage the
position and placement of the popup window according to the active element.
- Popup date chooser appearance: Days not in the current month on the
day grid should be either an alternate color or grayed out to aid
visual differentiation.
We don't display them. Should we?
- Popup date chooser appearance: If a day button outside the current
highlighted month is clicked on, the month and year fields are
automatically adjusted as appropriate.
This doesn't apply to us as we don't show these days.
- Date widget appearance: Once the date chooser popup widget has been
dismissed, the date in its correct localized format will be displayed
I agree but localisation is hard for us. I'm not sure how we are doing
that yet. Olav?
in the input date widget. This value is not free-form editable.
I disagree quite strongly with this. If we want to enable developers to
build web applications then rapid data-entry is a must. I'd like to try
to validate keyboard entry.
- If a value attribute is present, and valid, when the popup is
invoked, the year/month/day indicated will all be pre-set. The year
field will have initial focus.
I want to avoid anything in popup windows having focus.
- Display format for the field does not match submittal format...what
should it be?
What do you mean?
- Should the left-most day of the week be Sunday or Monday? Is this a
localization issue?
I think it is.
- Possible addition: Two additional function buttons not mentioned in
the WF2 specification could aid usability:
"Current" (set the date to the current date), and "Reset" (reset the
date to the field's value before popup was invoked).
We had this originally. The conclusion was that it added clutter. Our
implementation allows keyboard entry so you can delete text to clear.
"Current" was deemed to be 50% useless as most dates are future dates.
2.2 Widget Error/Boundary Conditions
- Value: If no value attribute is present, the current year, month, day
will be used as the default values upon entry to the popup (obeying any
min/max/step attribute values).
Is this covered in the spec? If not, it needs clarification.
- Value: If value attribute is present but not conformant to type, it
will be treated as though the value was null (""). The popup will then
behave as described above.
- Min/max: If a value is specified that is less than any valid min
value specified, or greater than any valid max specified, the field
will be set to that value. However, if the popup date chooser is
invoked, the value will be automatically set to the respective min/max
value.
- Min/max: If the min or max value violates the date format, it will be
ignored.
- Step: If no step attribute is specified, it defaults to 1 day.
- Step: Negative, zero, or invalid step values are ignored and treated
as the default value of 1 day.
- Step: If the step value is greater than the range between the min and
max...what should happen?
- Value: If a valid value attribute does not fall on an allowed
interval of min/max/step, the value will be used as the widget's value.
If the popup date chooser is invoked, the value will snap to the value
nearest the original value that satisfies the min/max/step relationship.
As per my previous response.
3. Event Handlers and the DOM
-----------------
- Input: Fires every time a value is changed in the year, month or day
in the popup.
mmm.
4. User Input
-----------------
4.1 Pointing Device Actions
- Clicking anywhere on the widget generates the date chooser popup.
Ours is modelled on a standard Windows combobox. You can type in text
and you can use the dropdown mechanism for the date picker.
- Clicking outside the calendar popup dismisses the popup and uses
the current values in the popup as the new date value.
ditto.
- If the date selected in the popup is not valid according to the
field's constraints, the value will revert to the last valid value.
We will probably disallow the selection of invalid dates. Probably grey
out the dates that are out of step or out of range.
4.2 Key actions
- ENTER: Invokes the date chooser popup
This clashes with submit. We probaly won't do this. If the popup is
visible then it counts as select.
- DOWN arrow: Invokes the date chooser popup
Yes.
- Key actions within the date chooser popup
- Popup initial focus: Year field.
We won't have focusable components in popups.
- CTRL-TAB key moves between yr/month/day regions of the popup, in
that order
interesting. what about page up/down. Erik Arvidsson has coded some
pretty complex keyboard behavior for some of our widgets. Erik?
- ESC key dismisses the popup and reverts the value to the value it
had before popup invocation.
Yep.
- ENTER key dismisses the popup using the current date settings.
Yep.
- Year has focus: UP/DOWN = next/previous year. LEFT/RIGHT = no effect
- Month has focus: UP/DOWN = next/previous month. LEFT/RIGHT = no
effect
- Day has focus: RIGHT/LEFT/UP/DOWN = navigate on day grid
- Ex. Case: Month field has focus, value=December, UP key= increase
year by 1, set month to Jan, set day focus to 1. Month field still has
focus
Erik?
5. datalist interaction
-----------------
- Input type=date widgets pointing to valid datalist elements should
behave normally with the following exceptions: all days in the current
date popup display that are not part of the datalist options are not
selectable (disabled), and are grayed out.
We will probably revert to a standard pick list (dropdown) for this
scenario.
6. Issues
-----------------
- Look/Feel: Should popup have a "Current date" button?
- Look/Feel: Should popup have a "Reset" button?
Clutter we decided but it may fit in better with the design you have.
- Look/Feel: This widget should probably be used for
type=datetime/datetime-local/date/year/month/week types. In type=date,
the week portion is disabled/grayed. In type=year/month/week, all but
the respective sections are disabled/grayed.
We are displaying year and month as spinners, date and week as calendar
style popups and are undecided about datetime controls.
- Look/Feel: Internationalization - would current LtR, Top to bottom
layout be the best flow in all languages/cultures? Would this be
changeable?
What side is th dropdown button on in Japan? Seriously, I want to know. :-)
- Look/Feel: CSS - Should it only affect the basic widget itself, or
should it be able to affect the popup widget as well?
Our popups currently inherit the following CSS from the parent <input>:
font-size
font-*
font-family (undecided but probably)
color
background-color
This is the way that <select> boxes currently work on most platforms.
- Look/Feel: How should datalist entries be visually differentiated
from regular type=date entries?
We make no distinction visually but I like the idea.
- Error/Boundary conditions: How to enable controls in response to
min/max values?
beep? ;-)
- Error/Boundary conditions: How should the popup widget and navigation
controls obey any STEP attribute that is present?
What do you mean? We will grey out any dates that are not in step.
- Key: When generating the date chooser popup, what hotkeys should
invoke it? Is ENTER and/or DOWN arrow ok?
DOWN arrow definitely. Enter usually submits a form.
- Look/Feel: Perhaps day values that don't obey the min/max/step
attribute could be disabled, or day values that do obey these values
could have an alternate color.
Yeah. I think they should be disabled.
Phew!
I think we should also collaborate about this offline too. What do you
think?
-dean