Question about display of date select functionality

17 Jul 2007 - 3:03pm
7 years ago
4 replies
628 reads
visual hokie
2007

I need some help.

I am working on an application that requires the user to select a
start and stop date. This function is similar to a travel sites'
Depart Date and Return Date fields. The main difference is that we
want to constrain the dates that can be select to only those dates
that the user receives service.

I immediately wanted a calendar display because it provides context
to service periods and days of the week. This context is important
because users can select dates up to a year in advance, so they might
know they are leaving for vacation on Friday during the week of
October 11th, but not know that Friday's date is October 12th. The
calendar provides this context and allows us to show dates that are
'selectable' based on service periods.

So, if we used the pattern the has an text entry field and a calendar
popper, we would have to validate any typed in dates against service
periods which would require a significant amount of coding.
Developers have concerns that we will not be able to meet our
deadlines if we take this approach.

I didn't want to display just the calendar because it would take a lot
of vertical space. However, I am beginning to rethink that this may
be the better choice.

Given the above constraints, I chose to recommend a text entry field
that pops to a calendar overlay (hiding the text entry field) once a
user tabs / clicks into that field. The user selects a date from the
calendar and it is displayed in the field.

We understood that this broke convention when we designed it; however,
thought that it may be a viable solution. We now have some concerns
that by displaying the text entry field we may cause some confusing
for users who want to type in a date. Some UI developers on our team
think that a calendar icon is more appropriate and would display the
selected date after the field label colon.

We have user testing schedule prior to launch but we really do not
want to wait until then to resolve this issue. Is the text field entry
that pops to a restrictive calendar confusing? Is an icon all we need?
Is the icon confusing? Do you have any thoughts for a better
implementation of this?

Thanks in advance!

brian

Comments

17 Jul 2007 - 4:06pm
visual hokie
2007

Maria,

The problem is that if we allow users to type in a date, we have to validate
against the service period. That is potentially an enormous amount of code.
We really need to constrain the input to only 'allowable' days.

Thanks for the post.

brian

On 7/17/07, Erwin, Marla <Marla.Erwin at vignette.com> wrote:
>
>
> Regarding text field vs calendar, Google Calendar has a
> one-size-fits-all implementation: A text field you can type into, with a
> calendar that pops up below it without hiding the text field, and an
> auto-complete list that overlays the calendar popup if the user starts
> typing in the text field.
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-
>
> Given the above constraints, I chose to recommend a text entry field
> that pops to a calendar overlay (hiding the text entry field) once a
> user tabs / clicks into that field. The user selects a date from the
> calendar and it is displayed in the field. ... Is the text field entry
> that pops to a restrictive calendar confusing? Is an icon all we need?
> Is the icon confusing? Do you have any thoughts for a better
> implementation of this?
>
> Thanks in advance!
>
> brian
>
>

17 Jul 2007 - 4:16pm
bminihan
2007

Don't you have to build the code into the calendar, so it only lets
you choose the correct days?

If you build your validation into the calendar on the client, then
send the contents of your text field to that validator, you won't have
to create a separate validator for the text field.

Alternatively, if you really have to remove the text field, I would
make sure the calendar icon looks like a button, replace the text
field with a built-in label (so people don't think they can click it
directly) and let people tab into the button, THEN press space or
enter to pop it up. Of course, clicking the button directly should
work, as buttons usually do.

It seems dangerous to automatically pop the calendar control up, for
two reasons:
1. People may just be "tabbing through" to get to something below the
date, and you've just given them 31 new things to tab through
(assuming the calendar is tab-able)
2. "Launching" something in a page, even something as innocuous as a
calendar control, should be the user's discretion, not the form's.
3. If the calendar automatically opens when you click it, how do you
close it? Click it again? What do you click, if it overlays the
button and/or field or something else?

Bryan
----- Original Message -----
From: visual hokie <visualhokie at gmail.com>
Date: Tuesday, July 17, 2007 5:08 pm
Subject: Re: [IxDA Discuss] Question about display of date select
functionality
To: "Erwin, Marla" <Marla.Erwin at vignette.com>
Cc: discuss at lists.interactiondesigners.com

> Maria,
>
> The problem is that if we allow users to type in a date, we have
> to validate
> against the service period. That is potentially an enormous amount
> of code.
> We really need to constrain the input to only 'allowable' days.
>
> Thanks for the post.
>
> brian
>
> On 7/17/07, Erwin, Marla <Marla.Erwin at vignette.com> wrote:
> >
> >
> > Regarding text field vs calendar, Google Calendar has a
> > one-size-fits-all implementation: A text field you can type
> into, with a
> > calendar that pops up below it without hiding the text field,
> and an
> > auto-complete list that overlays the calendar popup if the user
> starts> typing in the text field.
> >
> >
> > -----Original Message-----
> > From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-
> >
> > Given the above constraints, I chose to recommend a text entry
> field> that pops to a calendar overlay (hiding the text entry
> field) once a
> > user tabs / clicks into that field. The user selects a date from
the
> > calendar and it is displayed in the field. ... Is the text field
> entry> that pops to a restrictive calendar confusing? Is an icon
> all we need?
> > Is the icon confusing? Do you have any thoughts for a better
> > implementation of this?
> >
> > Thanks in advance!
> >
> > brian
> >
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

17 Jul 2007 - 5:49pm
visual hokie
2007

Bryan,

I will bring the point about validation up with the developer tomorrow.
Thanks.

What do you mean by built in label? I think I need some clarification here.

Other thoughts that might clarify the issue:

1) The date fields are required. They are the only two fields before
submitting/ processing the transaction.
2) in the next release we want to give the users the option to type in the
date or point/click on the calendar. A development period just doesn't allow
us this luxury for the initial release
3) Our current thinking has the date selection close the calendar. There is
also a close button to all the user to close the calendar without selecting
a date.

Thanks for the help!

brian

On 7/17/07, bjminihan at nc.rr.com <bjminihan at nc.rr.com> wrote:
>
> Don't you have to build the code into the calendar, so it only lets
> you choose the correct days?
>
> If you build your validation into the calendar on the client, then
> send the contents of your text field to that validator, you won't have
> to create a separate validator for the text field.
>
> Alternatively, if you really have to remove the text field, I would
> make sure the calendar icon looks like a button, replace the text
> field with a built-in label (so people don't think they can click it
> directly) and let people tab into the button, THEN press space or
> enter to pop it up. Of course, clicking the button directly should
> work, as buttons usually do.
>
> It seems dangerous to automatically pop the calendar control up, for
> two reasons:
> 1. People may just be "tabbing through" to get to something below the
> date, and you've just given them 31 new things to tab through
> (assuming the calendar is tab-able)
> 2. "Launching" something in a page, even something as innocuous as a
> calendar control, should be the user's discretion, not the form's.
> 3. If the calendar automatically opens when you click it, how do you
> close it? Click it again? What do you click, if it overlays the
> button and/or field or something else?
>
> Bryan
> ----- Original Message -----
> From: visual hokie <visualhokie at gmail.com>
> Date: Tuesday, July 17, 2007 5:08 pm
> Subject: Re: [IxDA Discuss] Question about display of date select
> functionality
> To: "Erwin, Marla" <Marla.Erwin at vignette.com>
> Cc: discuss at lists.interactiondesigners.com
>
> > Maria,
> >
> > The problem is that if we allow users to type in a date, we have
> > to validate
> > against the service period. That is potentially an enormous amount
> > of code.
> > We really need to constrain the input to only 'allowable' days.
> >
> > Thanks for the post.
> >
> > brian
> >
> > On 7/17/07, Erwin, Marla <Marla.Erwin at vignette.com> wrote:
> > >
> > >
> > > Regarding text field vs calendar, Google Calendar has a
> > > one-size-fits-all implementation: A text field you can type
> > into, with a
> > > calendar that pops up below it without hiding the text field,
> > and an
> > > auto-complete list that overlays the calendar popup if the user
> > starts> typing in the text field.
> > >
> > >
> > > -----Original Message-----
> > > From: discuss-bounces at lists.interactiondesigners.com
> > [mailto:discuss-
> > >
> > > Given the above constraints, I chose to recommend a text entry
> > field> that pops to a calendar overlay (hiding the text entry
> > field) once a
> > > user tabs / clicks into that field. The user selects a date from
> the
> > > calendar and it is displayed in the field. ... Is the text field
> > entry> that pops to a restrictive calendar confusing? Is an icon
> > all we need?
> > > Is the icon confusing? Do you have any thoughts for a better
> > > implementation of this?
> > >
> > > Thanks in advance!
> > >
> > > brian
> > >
> > >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
> >
>

19 Jul 2007 - 12:25am
Will Parker
2007

On Jul 17, 2007, at 3:49 PM, visual hokie wrote:

> 1) The date fields are required. They are the only two fields before
> submitting/ processing the transaction.

I recommend you offer a confirmation step before submission.

> 2) in the next release we want to give the users the option to type
> in the
> date or point/click on the calendar. A development period just
> doesn't allow
> us this luxury for the initial release

For future revisions, here's something to consider - is there any
required minimum duration for any classes of offering? For example,
will you allow the user to pick two adjacent days, or are there
offerings or other conditions that require an interval between the
start and end dates?

If the user can't pick two adjacent dates, you'll want to find some
way to visually signal that required buffer interval in the calendar-
style date picker.

> 3) Our current thinking has the date selection close the calendar.

If the user has selected a start date but no end date, why not leave
the calendar open and change the surrounding instructional text to
show that your app is now ready for the customer to complete the date
range selection?

> There is
> also a close button to all the user to close the calendar without
> selecting
> a date.

In this case, think about the user's state of mind and why they might
stop the date selection process. Is there any help you can offer to
keep them interested in completing the process?

Is it cost? Is it lack of information about their personal schedule?
Would it be useful to the user (and tangentially, to your business)
to offer to save their current progress within the data entry task
until they've sorted out their uncertainty? Can you offer any
inducements that would keep them interested in completing the date
selection and finish the entire process.

If the user cancels out of a process, that's an implicit sign of a
problem. It may not be _your_ problem, but don't let go of it until
you know you've done all you can -- and the user knows you're still
ready to help.

- Will

Will Parker
wparker at ChannelingDesign.com
206-228-3187 (cell-preferred)
206-783-1943 (home office)

“I wish developing great products was as easy as writing a check. If
that were the case, then Microsoft would have great products.” -
Steve Jobs

Syndicate content Get the feed