Re: Requiring a date be entered as mm/dd/yy on a form field.
- From: Tim Harig <usernet@xxxxxxxxxx>
- Date: Mon, 06 Jul 2009 16:17:33 GMT
On 2009-07-06, Garrett Smith <dhtmlkitchen@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-06-27, Garrett Smith <dhtmlkitchen@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-06-19, Garrett Smith <dhtmlkitchen@xxxxxxxxx> wrote:Then use arrow keys.
1. They all but require a mouse to use effectively. Tabbing
through 28+ entries is just not efficient.
1. Arrow keys still require me to remove my hands from their normal
position on the keyboard.
For someone who prefers keyboard navigation, that should not be an issue.
Actually, for somebody who prefers keyboard navigation this is a cardinal
sin. If I have to move my fingers from the home keys then I might as well
have to move my hand to the mouse. The natural flow is broken.
2. They don't provide much more effeciency then tabbing in most cases. In
a web browser, for instance, arrow keys still follow the order of
the elements. This could be fixed; but, it requires special care
that I have not seen in any calendar widgets.
Unlike Vista's OS calendar, Opera's |input type="date"| calendar limits
the arrow keys to within the current month.
http://www.brucelawson.co.uk/tests/html5-date-test.html
That page just asks me when I want to depart and gives me a free form
text box to enter information.
3. It is still just faster to type in the date directly, even as dropdowns,
then it does to navigate to a date directionally.
Still stands.
It should be possible to navigate years.2. They can be combersome for working with dates too far in the
past or future as one must normally page though them month
by month.
Navigating through the thirty some years to my birthday is a real pain.
Still stands.3. They can be a hassle to create from scratch if you are not
working with a library or framework.
They're a hassle to write, but I don't agree with the clause "if you are
not working with a library or framework."
The point still stands. They're a hassle to write.
Again, calendars are a great supplimental widget; but, inefficient or4. They work poorly without Javascript (which I know you haveNo, they don't work poorly without javascript, they are disabled without
already answered for.)
javascript, and degrade to a text input, or, if you would rather,
degrade to your "three fields" UI, which could be placed in an element
with id="calendarFallback".
unavailable on their own without alternative methods of input for the user.
A usable fallback is important. You seem to be of the opinion that
YYYY-MM-DD is unusable. I disagree with that. The error can be caught on
the server and reported back to the user.
Anything is usable. Some solutions are just more usable then others. The
point I have been using all along is that it is much less annoying just to
get the user to do the right thing in the first place then it is to require
them to re-enter incorrect data. If an external user has to correct their
entries too many times in a form, then they will just leave and you will
have lost a sale.
3) After a selection is made, the input is updated to show the date inOnce again, requiring the user to do the right thing or be be hassled to
YYYY-MM-DD format.
re-enter their information should the decide to edit the date.
Not countered.
Are you are referring to requiring the user to re-input data in
the even that they enter their date in the wrong format? I don't consider
that to be a fallback. I consider that to be a UI failure.
I know.
Think of it this way. WWSJD (What would Steve Jobs do?).
Most people will enter dates as they have been used to entering themAnd if javascript is turned off, placeholder text won't be there, but
everywhere else (including paper forms). Some may be smart enough to look
at comments with the form that specify how the date should be entered.
Others will not pay attention it until your app forces them to enter an
acceptable format.
displaying the format conspicuously, as in the label:
Arrival (YYYY-MM-DD): [_____________]
It becomes hard to miss.
My weblogs and form logs show that many users ignore formating instructions
in the form if given the opportunity to do so.
Saved form data exists on a per-input basis. When focusing a text-input,
the saved form data may be accessed by pressing down arrow key. So, if
the user gets the fallback text-input, and has saved data, it can
autocomplete easily. AFAIK, there is no "per-input" data with a select.
The affect is mostly the same. Full autocompletion can be added with
Javascript if you desire.
Unnecessary choice makes
UIs more difficult without providing any benefit. Text fields give users
a freeform area to make mistakes. In essence, it gives them an illusion of
which which does not exist. Split dropdowns removes unnecessary choices
so that users input data in the correct format each time/every time.
Split dropdowns still allow users to make mistakes, just as a "name"
field. Any user input allows room for mistake. Granted, a normal user
won't mix up "month" and "date" as easily.
I cannot prevent general mis-entered dates. People will always make
mistakes irregardless; but, I can eliminate the entire class of errors that
comes from entering dates in the wrong format.
To what standards are you basing your conclusion.
Calendar:
* common idiom that users are familiar with (OS, travel sites)
Most sites that I have used allow direct entry even if they also offer a
calendar. I have already said that they calendar is a great complimentary
widget -- just that it is inefficient to use by itself.
* easier to navigate to, and enter data into one field than three.
Users have no problem navigating a split date dropdown set. It is no more
difficult to enter data, aside from pasting, then in an free form or
calendar entry.
* a correct calendar (#days per month, etc), as opposed to Feb 29, etc.
If javascript is enable then I can also remove those *7* invalid dates that
you are having such a cow over. Without Javscript, your plans offer no
more means to remove them.
* copy-paste works
This is the only compelling reason that has been brought up so far (long up
in the thread now). But pasting also doesn't work efficiently if the date
your pasting from is not in the format that the page wants. Since most
applications, in my experience, give dates in a native format this is going
to offer considerable difficulties for you using a YYYY-MM-DD format.
Calendars are equally difficult to paste into. Furthermore, it makes
date formatting errors even easier to do. In that respect, it becomes
something of a feature.
* fallback is simple
Three fields works almost identical either way. The only difference is
that with Javascript disabled, it falls back to naive entry (which your
freeform box amplifies into a general entry error problem).
Fallback: use a date field:-
* Easier to type a date much faster than negotiating dropdowns
I can type into drop dones just as fast as a free form.
enter number -tab- enter first to letters of month -tab- enter number
* simpler to test and easier to develop a second strategy
Testing is the same irregardless and this opperates as its one second
stategy.
I am basing mine on
removing errors (first); simplity and clarity for the user (second);
overall user satisfaction (third); and finally efficiency where possible
(fourth). I measure these things from the logical proof of removing
entropy, logs of user interaction, and from personal accounts where
possible.
The three fields does not remove the possibility of user error.
No, it does not preclude the ability to make general errors; but, it does
remove an entire class of formating errors. Users cannot enter anything
they like; so, anything they enter must at least be a validly formated
date.
It is harder to and more tedious to navigate three dropdowns than one
text input. It clutters the form.
Your picking at straws. It is no more difficult to "navigate".
Consider an event with time and fields for the time:-
From: [hh]:[mm] [AM|PM] [month_name] [date] [yyyy]
To: [hh]:[mm] [AM|PM] [month_name] [date] [yyyy]
Your example fully fits on my 80 column terminal with room to spare. If
you don't like it, you can split the time onto a second line inside of a
field frame. Even if that somehow assaults your delicate sense of
aestetics I will take good function over good looks in a form any day.
NB: Second example uses a time-picker and a Calendar widget.
I have already stated (many times) that a date widget is a good addition to
to any date entry when not used alone.
We don't have a real web-based comparison of Calendar widget vs. "Three
fields" approach. Without that, its hard to say which is more satisfying.
Once again, I have no problem if a calendar is used with a three fields
entry. They compliment each other. I hate only being able to use a
calendar widget as it is far less efficient. Yes, I have had to use
applications where only calendar widgets were available.
The three fields can work, but the Calendar widget is less cluttered.
This makes the form completion process simpler, as Date is one thing,
not three.
Nobody has ever considered my designs cluttered. If anything, most people
remark that my designs are increadibly streamlined. That tends to come
from the fact that I develope on Unix and do not accept anything that
doesn't fit on an 80 column terminal Window.
My weblogs, internal critique, and other metrics have been unambiguous in
this regard. The users prefer it, more customers fill out the forms and
purchase our products, and less time is required to fix input errors.
Doesn't require localization for the order of fields and the month
names. Users of other locales might prefer a different order and would
prefer the month name in their language.
Localation is quite possible -- either at the server or using Javascript
based on location. I can let them order their fields however they want and
I can give them local language month names. I can even let the Chinese
enter in year-animal names if desired.
[SNIP]Avoiding requiring a format and designing a UI for each field of the
date is one approach. That approach avoids the problem of formatting a
date. Users might find that design annoying. More than a few will wonder
[SNIP]Feedback comes in two forms:
1. Verbal or written feedback is available for applications that
are used internally. Ideally, I prefer to work directly
with the people who will be using the application when
developing. That way their domain specific ideas can be
Though it's dangerous to let the client design usability. They can
sometimes ask for things that won't work well.
I don't although that has never been an issue. I designe my apps based on
what my metrics tell me works best for my criteria. All users prefer
precision, unambiguity, and not having to re-enter fields.
2. External web pages can be monitered from mining the server logs.Sounds useful for catching more significant problems.
Also for catching small problems. Once again, besides the large grain web
logs which only monitor server requests and thus per page information,
I also have provisions for capturing any field that was not entered
correclty the first time. This gives me very fine grain information
smaller then any single page.
Clicking in the text field brings up per-field "autocomplete" options.I don't see how that UI would help the user get it right the first time.I don't see what you are driving at here. Split drop down fields can be
If the user has a stored expiration date for credit card expiration,
it would be filled in, for a first-time user.
filled in just as text fields or calendar widgets can. They can also be
left completely blank to help prevent users from missing a filed and
leaving a default by accident. They are functionally similar in this
regard.
The select boxes don't have that, or if they do, I am not familiar with it.
1. Autocompletion is a good source of errors if the users are not sure to
check what they autocompleted.
2. Autocompletion like behaviour can be added to drop downs using
Javascript if desired.
3. Autocompletion doesn't work well for dates which are not very distinct --
especially when entering the year first which is most likely to be
similar between entries.
The only functional difference, asside from a slightly different entry style
for typists, is that the user is given the entry format as a directly as
inherent to the form structure, rather then having to infer what the form
created intended in comments external to the form.
I don't understand that.
Anotherwords, the format is already there. The don't have to read any of
the the instructions on the form to figure it out. Many ignore those
instructions until they are forced to re-enter information -- which annoys
them. With drop dones, they don't have to read the instructions for the
format -- they just have to enter the information.
Requiring the year to be entered first would seem strange if the yearwhy they have a UI with 31 days in the month of February, though serverWhen possible, the Javascript can match the number of days for a given
validation will catch an invalid date like that.
month and year; otherwise, naive entry is good for at least 28 days out of
every month. If I want to be really annoying, I can remove or grey out the
month and day fields until the year has been entred.
appears later in the page. I think users might be confused or annoyed by
that.
If the year isn't entered first, irregardless of the display order (and I
have stated elsewhere in the thread that I do place the year first), then
the system simply uses naive date handling until the year and month are
entered.
That sounds like it requires javascript. What's the fallback for that if
javascript is disabled?
Naive date handling *is* the default without Javascript. If the user does
not enter the year first, then it just falls back to that default.
Then it is true that a user may enter up to seven invalid dates
that the user might have to re-enter using the naive drop downs; (even
this is a stretch as people will usually be entering dates that they know
to be valid) and, all seven of the invalid dates will be in the desired
format.
I thought your point was that there is no format, right?
Your comment is non-sequitor. The point is that even being forced to use
naive date entry there are seven possible invalid dates in a given year
and only six for leap years. Even these will be properly formated.
Even these seven days are not all that likely because the user should have
some idea that they date they are entering is a valid date. It would not
be very bright to try and purchase a plane ticket to Jamaca on Febuary
31st. Most likely the user will have a real date in mind that they are
trying to enter then just making one up.
Using your system, they can enter any date, whether valid or invalid, in
any given number of formats, that your application has ruled out as
invalid.
Compare that to a text field which allows them to enter 372 dates inLeading 0's could be a problem where year is < 1000, but that is an
invalid forms, (not including a number of given ways including totally
unwanted information with letters, weird separators, leading zeros or not,
etc, etc), whether or not they are actually valid dates.
uncommon case. It should not be a problem in month or date fields.
The point is that by giving your users the ability to enter a free-form
field, you give them the ability to enter *anyting*. Any date format they
choose. I could enter "11 Jun 1935" or "January 1st 2003", "2009/7/11",
"12th May 2010". All of these may be 100% valid dates but your form
will not accept them.
Then there is the possiblity of entering totally non-valid dates
"200i8-06-12", "Three days after the 12th", "next week", 2006-I2-6,
2OO9-7-15 etc. You have no idea how many times I have seen the last one.
It can be very difficult for the user (much less somebody else looking
at it) to figure out what is wrong with it if they are using a font that
does not fully distinguish the difference between the two different
characters.
Thats 7 possible errors versus a virtually unlimited number -- or even just
the 365/366 restricted to valid dates that are entered in a single
incorrect format. I will take the 7 errors any day. Three fields may not
be perfect; but, it does significantly reduce the number of statistical
possiblities for errors.
Ambiguous date formats, especially the one in the subject field
mm/dd/yym are problematic.
Agreed. My solution eliminates that problem -- no matter what order the
user sees them in.
The three fields avoids those problems, but with some drawbacks. The
Calendar requires care to develop a decent fallback for browsers without
javascript (such as Firefox running NoScript).
It needs a fallback in general as calendar entry is not at all efficient.
To conclude, you have managed to level two weak but valid arguments:
1. My method does not allow pasting. Your method does, as long as the
information that they are pasting from is already in the right
format.
2. Autocomplete on type requires Javascript to work on three dropdown
fields. Oh well.
Sorry, once again, my data indicates the benefits of of three field
dropdown outway the drawbacks. When I stated my criteria for determining
the interface above, I stated that I consided error reduction to be a
primary consern while I took efficiency into account fourth. Both of these
drawbacks are efficiencly related. Therefore, by my given criteria, I will
take the three field dropdown any day. My logs, comments, and feature
requests, along with risk analysis and cost assciated with fixing errors
(including customer perception), still indicate that it is far preferable
over the free-form text entry method and confirms my choice in criteria.
Of course, a calendar widget compliments my system; but, does not replace
it either with or without Javascript.
I will be traveling, for some time, out of Internet connectivity range
soon; therefore, not hearing from me doe *not* mean ascent to any of your
arguments.
.
- References:
- Re: Requiring a date be entered as mm/dd/yy on a form field.
- From: Garrett Smith
- Re: Requiring a date be entered as mm/dd/yy on a form field.
- Prev by Date: Re: DIV tag innerhtml
- Next by Date: Re: DIV tag innerhtml
- Previous by thread: Re: Requiring a date be entered as mm/dd/yy on a form field.
- Next by thread: formating javascript source
- Index(es):
Relevant Pages
|
