Responses to Error Management Workshop
Pawan Vora, pawan@nextag.com, NexTag.com
Here are the responses to my workshop on Managing Errors in Transaction-based Web Applications (Internetworking, 2.3). What I was asking readers to do was send me an e-mail on the preferred method of formatting for entering date in a form. The options I had listed were:
Here are the responses:
From: Kristin Arnold, Reynolds & Reynolds
You asked for comments on which method we prefer for entering in a date on a web page.
Overall, I would prefer #2 only if each field is automatically tabbed after the entry. Then the user does not have to worry about typing in the '/' or hitting the tab button.
If automatic tabbing does not happen, then #1 would be my first choice. Here, the user does have to add in the '/', but doesn't have to worry about tabbing, which I feel (personal opinion) is slower than hitting the tab to enter a simple date.
I do not like #3 - this combines tabbing and potentially clicking on the down-arrow (depending on how these controls are used), making for a clumsy way of entering simple information. However, if the database required a 3 character month and a one or two digit day, then this option may be feasible, but then I would suggest changing the database!
1) Birth Date: <<...>> (mm/dd/yyyy) 2) Birth Date: <<...>> / <<...>> / <<...>> (mm/dd/yyyy) 3) Birth Date: <<...>>
I completely agree that nature of the application makes a difference. If the user must choose from a list of specific items and what they enter has to be exact, the drop-downs are great. But, in entering in a "simple" date, as long as the format is given, I saw the drop-downs as overkill.
I also do agree that all factors (application, frequency of use, and user expertise ) do (or at least should) come into play when designing a site or application.
From: Heather L. McQuaid, Interaction Designer, MAYA Design Group
In your paper "Managing Errors in Transaction-based Web Applications" you asked for comments on the solutions you proposed for showing the formatting requirements for date fields. I'm not sure whether you were interested in opinions about which solution was better or which of the examples representing solution 2 was better. So, I'll give both.
Solution 1 simply showed how people should enter the dates: (mm/dd/yyyy), whereas Solution 2 broke up the date field into 3 fields, so that people did not have to enter the "/".
I'm assuming that to implement Solution 2, people must use the TAB key (or move their mouse) to progress to each field. As a more experienced user, I prefer to enter all the information in one field, without tabbing. But, I know people who have difficulty distinguishing "/" from "\". So, perhaps the lesser of two evils would be the 3 date fields. As for which example was better, I prefer the first (no drop-down list boxes). It's fast enough for me to type 3 characters (e.g., Jan, Jul) without having to deal with the drop-down list that appears.
But, again, it might be easier for less-experienced people to select from a list of prescribed options (example 3).
Of course, the disadvantage of using words or abbreviations of words, is the added difficulty of translating them into multiple languages. Numbers require less translation, since many countries have identical "number languages". But, if designers decide to use a numerical format for dates, it's important to provide an example that clearly distinguished dates, which can range from 1 to 31, from months, which can range from 1-12. Thus, an example such as 10/06/99, could be interpreted as "October 6, 1999" or "10 June, 1999". A better example would be 10/14/99, because the "14" indicates that it cannot be the month field.
From: Dani Burbank, EPSS Analyst/Designer, WPI, Inc.
I just thought I'd sent you my opinions, since you asked, about the preferred date field format in your article/workshop, "Managing Errors in Transaction-based Web Applications. Personally I find the mm/dd/yyyy year much easier. I know exactly what goes there, it's intuitive. The second format required me to click something (pull down) to find out what even went there. There are less mental steps in the first format and no questions as to which numbers are needed and that they are numbers, not abbreviations.
What do I think? As a human factors/UI design person, I'll have to say "It depends" :-) As you can see in the above responses, the approach one should use would depend on the type of audience (US vs. non-US vs. any), application, and frequency of use. In general, for the US audience, I'd look at the context in which the date was being used. If this was a sign-up form, which a user will fill out only once, I'd feel comfortable using drop-downs (#3) or #2 with a more appropriate example as Heather points out. Whereas I'd recommend using #3 with drop-down (or pull-down) menus for a diverse audience (both US and non-US) and to avoid any confusion. I'd also use letters (e.g., Oct) for the month drop-down. However, if the application was designed for customer service application, where they needed to enter dates frequently, I'd consider using #1; in this case, I'd also consider if entering the date was really necessary and if the system could generate it and store it without user intervention. For self-service applications, such as making flight reservations, I'd probably be in favor of using #1 because it's likely that a user may try out different possible dates before making a reservation.
The differences in opinions and situations that we encounter as designers clearly underscores the need to identify the audience for which the page is being designed and the user tasks. Also, testing with the potential users would be the best validation!
I had also given some examples of presenting errors, which elicited the following response (see the screenshot in Section III Communicating error messages to the users, #2, on the Managing Errors in Transaction-based Web Applications page):
From:Barbara McManus
Looked good - just a brief comment. When you tell the user to click something, ensure that there is a 1:1 mapping between what's on screen and the text you use, eg Click Sign In, not Click Sign Up.
-
Author's response: I can see how it may appear confusing because I didn't include the Sign Up link in the screenshot. The message is meant for new users. It says that 'if you're a new user, click "Sign Up."' So it doesn't apply for registered users who have made a mistake in signing in. By not including the Sign Up link (or a button) I created the confusion. I apologize.
Thanks to all the respondents for sharing their thoughts and demonstrating that design of even a simple issue of date entry in a form requires considerable thought and understanding of users, their tasks, and environment. Thanks again... and keep those e-mails coming.
© Internet Technical Group
Last update: April 15, 2000
URL: http://www.sandia.gov/itg/newsletter/mar00/responses_to_workshop.html
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.