> -----Original Message----- > From: John Norman [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 8:36 AM > To: Knoop, Peter > Cc: Barbara Glover; Gary Thompson; Daphne Ogle; Allison Bloodworth; > erin yu; Shaw-Han Liem; [email protected] > Subject: Re: Heuristic UX evaluation of Date Picker > > > On 13 Mar 2008, at 00:13, Knoop, Peter wrote: > > ... > > * There are a lot of suggestions in Sakai's Jira regarding > > "calendar widgets" that you might find informative for your design > > too. For instance, SAK-12373 (incorporated into SAK-7000), which > > talks about preventing a user from selecting a "due" that occurs > > prior to already selected "open" date by graying out the relevant > > dates and/or performing some data validation. (Unlike the need for > > revisionist history cited above, I haven't seen a request yet for a > > user to be able to violate this sort of relative date order > > enforcement.) > > > Norman, John wrote: > > I think we want to be careful about what event-related logic belongs > in the event setup page that contains a date picker and the date > picker itself. The picker may become overloaded and difficult to > reuse if we put too much logic in it.
Right, but since some of the logic is likely to work best if accompanied by visual cues and when supported by specific interaction behaviors, it seems like it needs to get considered in the design process at some point. In addition, even if it not everything to goes into the component itself, it's important to avoid putting things into it that prevent desired behavior down the road, such as being able to pick dates in the past. (Maybe I'm getting ahead of things though, and the design process still has a way to go before its at that point?) -peter _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
