I think John that your points raise some good questions in what user scenarios are we envisioning for the date picker.
- Will the date picker only live in the Sakai assignments tool? - Should we be looking at a broader scope of user scenarios? (which is what Gary and I were thinking when we did our heuristic evaluation). - As a Fluid component, we may want to make the date picker more flexible in that it can sync with calendaring to check for other events on a given day because this would increase its ability to be used in different user scenarios? - Perhaps we want a phased approach to the date picker design where the current design doesn't sync with a calendar but down the road add in that functionality? For a small component I think there are still a lot of user scenario questions we need to consider before we finalize the design. This heuristic evaluation is just a step towards bringing these questions to for forefront. Barbara On 13-Mar-08, at 8:35 AM, John Norman wrote: > > 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.) >> > 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. >> · I would echo the comments about a way to get to “Today” >> quickly and easily. >> >> · The notion of a “day view” instead of the clock dial or >> some other way to view “conflicts” with the date-time your picking >> is interesting. Some Sakai contexts might well benefit from >> that. For other Sakai contexts though, knowing of such conflicts >> isn’t that important, and users might end up more frustrated with >> the delay in the fancier view loading before they can move along. >> (I found sites with pop-up calendars that take awhile to load, but >> always load, even if I just want to type in a date, very >> frustrating to use as they interrupt my train of thought.) >> > I posted a comment on the wiki page for this: I'm not sure I agree > with the comments about looking for conflicts in a [personal] > calendar. I feel this would only apply if you were picking dates > for an event in the personal calendar and in this case the page in > which you are creating the event can handle event conflicts. For an > assignment setup, you would presumably need to look in the site > schedule tool for conflicts, but will it always be the same > calendar that contains the potential conflicts. This seems to me > like a nice idea that is fraught with implementation difficulties. > I would suggest we might want to develop the use-case scenarios a > bit more before trying to implement it. >> ... >> >> · I’ll also mention one other scenario for your possible >> consideration here that is a bit of a thought experiment about >> other potential uses of the date-picker. It is a scenario that >> Sakai currently does not support, but is desired. I might call >> this the “relative dates” scenario, where you use something like a >> date-picker to specify a pattern relative date-times. Say you >> give the same Assignment each week in ten different lab sections >> in your class, however, you want the open date for the assignment >> in each lab section to be different; you want each lab sections’ >> version of the assignment to open for a given lab section at the >> date-time that specific section meets. Similarly, you want the >> due date to be one week later, at the beginning of each lab >> section the next week. You don’t want to have to create 10 >> different assignments in the Assignment tool (or ten different >> items in the Gradebook). You want to create one Assignment, but >> give it open and due dates relative to each sections’ meeting >> time, so you might specify the open/due dates for the first lab >> meeting of the week, and have the rest automatically set by some >> relative date-time offset. Maybe a date-picker would be used in >> some way to specify a relative pattern of date-times to use for >> each section in some as yet un-defined interface. However, you >> also need to accommodate weeks where some labs don’t meet, perhaps >> due to holidays, but others do, so you need a interface to help >> you manually override your regular pattern by picking a new date- >> time for a specific thing. >> > Again I see this as logic that belongs in the event setup page. > However, the ability for the date picker to open with some date > selections passed into it from the event setup page seems valuable > in principle... > > John _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
