Home, home on the date range...

[Tim Cowan]

Hi

In my program I have a way that the user can select a start and stop date.
The dilemna comes when the user chooses a stop date that is before the start
date or vice versa. A few months ago I would have said 'throw up a dialog
and call the user stupid'.

Now I have been born again in the 'Cooperian' way of thinking. So how to
react to this temporal violation? I had considered doing nothing, i.e.
keeping the date range as it is, but this may cause the user confusion when
nothing appears to happen. I could cause some noise indicating this to
occur but it still does not really inform the user.

Going on the premis that the user is always right I decided that if they
move the stop date before the start date then the start date would be set
equal to the stop date and vice versa.

Has anyone else run into this problem? Maybe there is a solution that I
haven't considered.

Thanks

Tim Cowan

[Colin McGuigan]

Tim Cowan wrote in message <38e89c62@news.devx.com>...
>Hi
>
>In my program I have a way that the user can select a start and stop date.
>The dilemna comes when the user chooses a stop date that is before the
start
>date or vice versa. A few months ago I would have said 'throw up a dialog
>and call the user stupid'.


I'd throw up a dialog box and call the user stupid. =) Despite the
disadvantage of dragging the user's attention away from what's going on, it
has the advantage that it tells the user in no uncertain terms what's
wrong...whereas anything else may leave the user in some sort of confusion.

However, I wouldn't throw up the dialog box until the user presses a button
of some sort; not only does this avoid the standard issues regarding
dragging the user's attention away from their task during heads down data
entry, but it also gives the user a chance to expect the message box, which
makes it (slightly) more friendly. IMHO.

--
Colin McGuigan

[Shawn K. Hall]

Hello Tim,

You could change the background color of the errant control red (or
off-red so it's not too dark). This is still un-interruptive and if
you have several controls of the same data type (in this case dates)
it points out the exact error in no uncertain terms.

Regards,

Shawn K. Hall
Programmer / Analyst
*Please* post/respond in the newsgroups!


"Tim Cowan" <tcowan@golden.net> wrote in message
news:38e89c62@news.devx.com...
> Hi
>
> In my program I have a way that the user can select a start and stop
date.
> The dilemna comes when the user chooses a stop date that is before
the start
> date or vice versa. A few months ago I would have said 'throw up a
dialog
> and call the user stupid'.
>
> Now I have been born again in the 'Cooperian' way of thinking. So
how to
> react to this temporal violation? I had considered doing nothing,
i.e.
> keeping the date range as it is, but this may cause the user
confusion when
> nothing appears to happen. I could cause some noise indicating this
to
> occur but it still does not really inform the user.
>
> Going on the premis that the user is always right I decided that if
they
> move the stop date before the start date then the start date would
be set
> equal to the stop date and vice versa.
>
> Has anyone else run into this problem? Maybe there is a solution
that I
> haven't considered.
>
> Thanks
>
> Tim Cowan
>
>

[Larry Rebich]

Tim,

I usually include a 'status bar' with the application. Warnings and progress
messages are displayed in it. If the user enters an invalid item I show some
text in the 'status' bar then 'beep'. I don't use the standard status but a
label in a bottom aligned picture box. That way I can show error messages in
'red' and 'bold'. If the user enters a 'finish' date earlier than the
'start' I will force the later date to be at lease the earlier date.

Cheers,
Larry Rebich

larry@buygold.net
www.buygold.net


"Tim Cowan" <tcowan@golden.net> wrote in message
news:38e89c62@news.devx.com...
> Hi
>
> In my program I have a way that the user can select a start and stop date.
> The dilemna comes when the user chooses a stop date that is before the
start
> date or vice versa. A few months ago I would have said 'throw up a dialog
> and call the user stupid'.
>
> Now I have been born again in the 'Cooperian' way of thinking. So how to
> react to this temporal violation? I had considered doing nothing, i.e.
> keeping the date range as it is, but this may cause the user confusion
when
> nothing appears to happen. I could cause some noise indicating this to
> occur but it still does not really inform the user.
>
> Going on the premis that the user is always right I decided that if they
> move the stop date before the start date then the start date would be set
> equal to the stop date and vice versa.
>
> Has anyone else run into this problem? Maybe there is a solution that I
> haven't considered.
>
> Thanks
>
> Tim Cowan
>
>

[Larry Rebich]

Brad,

It is responses like yours that cause me to avoid providing 'design'
responses to people who ask for advice... Get a life...

Cheers,
Larry Rebich

larry@buygold.net
www.buygold.net


"Brad Siemens" <ebsf5@golden.net> wrote in message
news:38ea9ec2@news.devx.com...
>
> Larry Rebich wrote in message <38ea61f0$1@news.devx.com>...
>
> >I usually include a 'status bar' with the application. Warnings and
> progress
> >messages are displayed in it. If the user enters an invalid item I show
> some
> >text in the 'status' bar then 'beep'. I don't use the standard status but
a
> >label in a bottom aligned picture box. That way I can show error messages
> in
> >'red' and 'bold'.
>
> In this instance simply changing the background color of the control would
> accomplish a visual cue that something is amiss. A text idicator could
also
> be incorporated. It shouldn't stop the user from proceeding, should it?
>
> >If the user enters a 'finish' date earlier than the
> >'start' I will force the later date to be at lease the earlier date.
>
>
> Why force anything? If there are two dates it becomes obvious that one is
> before/after the other regardless the order. Test to see which is
which...a
> range is subsequently defined and return data accordingly. If the user
> wants to run a query on future dates, let them.
>
> Brad
>
>
>

[Brad Siemens]

Tim Cowan wrote in message <38e89c62@news.devx.com>...

>Going on the premise that the user is always right I decided that if they
>move the stop date before the start date then the start date would be set
>equal to the stop date and vice versa.



Another option would be to consider the two controls as neither stop nor
start dates per se. Simply use the one that has the earliest date as the
start date and the one that has the lastest date the stop date.

BWTHDOIN

Brad

[Brad Siemens]

Larry Rebich wrote in message <38ea61f0$1@news.devx.com>...

>I usually include a 'status bar' with the application. Warnings and
progress
>messages are displayed in it. If the user enters an invalid item I show
some
>text in the 'status' bar then 'beep'. I don't use the standard status but a
>label in a bottom aligned picture box. That way I can show error messages
in
>'red' and 'bold'.

In this instance simply changing the background color of the control would
accomplish a visual cue that something is amiss. A text idicator could also
be incorporated. It shouldn't stop the user from proceeding, should it?

>If the user enters a 'finish' date earlier than the
>'start' I will force the later date to be at lease the earlier date.


Why force anything? If there are two dates it becomes obvious that one is
before/after the other regardless the order. Test to see which is which...a
range is subsequently defined and return data accordingly. If the user
wants to run a query on future dates, let them.

Brad

[Colin McGuigan]

Brad Siemens wrote in message <38ea9ec2@news.devx.com>...
>Why force anything? If there are two dates it becomes obvious that one is
>before/after the other regardless the order. Test to see which is
which...a
>range is subsequently defined and return data accordingly. If the user
>wants to run a query on future dates, let them.
>
>Brad


I don't know if I'd agree with this one. Assuming that the controls are
labeled 'Begin Date' and 'End Date' doing this kind of behind the scenes
checking and manipulation might produce results that the user doesn't (and
arguably can't) expect. But that's IMHO.


--
Colin McGuigan

[Brad Siemens]

Larry Rebich wrote in message <38eab6a5@news.devx.com>...

>It is responses like yours that cause me to avoid providing 'design'
>responses to people who ask for advice... Get a life...


So as opposed to poking holes in the method, attack the man. Very
professional response. Must have been by 'design'. Be interesting to see
what Tim implements!

Brad

[Brad Siemens]

Colin McGuigan wrote in message <38eb4fbe$1@news.devx.com>...

>I don't know if I'd agree with this one. Assuming that the controls are
>labeled 'Begin Date' and 'End Date' doing this kind of behind the scenes
>checking and manipulation might produce results that the user doesn't (and
>arguably can't) expect. But that's IMHO.


If we assume that the user knows what they are doing and they wish to use
one control as 'Start' and the other control as 'End' I see no reason to
stop them. In essence, all they are trying to accomplish is to define a
date 'Range'. This will accomodate that regardless of which control's value
is most recent, etc.. The label of the controls don't have to be 'Begin'
and 'End' as you pointed out.

As to what the user should expect; I would think they should expect to have
data returned based on the dates they supplied. If there is no
corresponding data, this is indicated in the interface. If there is, there
is.

Testing the date range could be entirely subjective within the context. If,
in one context, data is unavailable for any reason, the GUI should be able
to short circuit the query. Posting the 'No Data' message.

It seems to me that the context is paramount, If they are searching for when
to Schedule Vacations (as a colleague pointed out!) they certainly need to
define a date range in the future, among other examples.

The default value of each control is also a factor, Handedness of the user
(which control is closer - if they are using a mouse). As someone else
pointed out, whether it is heads down data entry or not.

I am not advocating anything other than giving the user the providence to do
it as they choose to. Enough rambling...

I have a appointment scheduled to get a life. Must be off.

Brad