Requirements
A natural outgrowth of the scheduling of releases has become the resolution of another requirement:
http://bugs.sakaiproject.org/jira/browse/SAK-7000
DRAFT UI Requirements for post-2.2 Calendar Widget
Working samples of similar widgets
Tigra calendar (which Melete uses)
Mock-Up for 3 locales (en-GB, en-US, en-ZA)(final version with test cases)
Design mock-ups
FIGURE 3
FIGURE 3a: Same as above, but shown in a non-US format.
Kathy Moore 6-19-06
Comments (34)
Jun 15, 2006
Mike Osterman says:
And in sakai.properties, something like: dateMask@org.sakaiproject.foo=mm/dd/yyy...And in sakai.properties, something like:
dateMask@org.sakaiproject.foo=mm/dd/yyyy
timeMask@org.sakaiproject.foo=hh:mm tt
The mask formatting would need work - this is just to illustrate the idea.
The only change I'd make to this mockup for il8n purposes is moving the am/pn into the text box. As I understand it, some prefer to use 24-hour time.
Jun 16, 2006
Jim Eng says:
Cool idea to have a pattern for the date format. It might already be codered in ...Cool idea to have a pattern for the date format. It might already be codered in one of the relevant Java classes.
Jun 17, 2006
Mike Osterman says:
I'm sure you're right about it being in a class somewhere. There are about a zil...I'm sure you're right about it being in a class somewhere. There are about a zillion date/time mask formats out there - it bears investigation which one is for Java.
Jun 17, 2006
Mike Osterman says:
Looks like java.text.SimpleDateFormatLooks like java.text.SimpleDateFormat is a class we could use.
Jun 16, 2006
Jim Eng says:
Several issues: 1) Some of the datepicker popups have a time field built in. Doe...Several issues:
1) Some of the date-picker pop-ups have a time field built in. Does Melete's? If so, it would need to be redirected to populate the second text field instead of appending the time in the same text field as the date.
2) Could this be on one line with fewer internal labels? It would be nice if it was more compact.
3) One of the issues with many of the current text-entry widgets is the ambiguity of dates in the first part of the month (say the 1st through the 12th). What if we validated dates and displayed them in this format (appropriate to the locale): 16-Jun-2006 ? If a user enters 1/2/2006 in South Africa, we'd accept it and display it as 1-Feb-2006. In the states, we'd accept it and display it as 2-Jan-2006. Hmmm. Go ahead, shoot that one down quickly if you like. But think about some alternatives.
4) Seems like the biggest challenge here is dealing with that ambiguity. We have at least three things to think about: what are the localization settings on the host sakai server, what sakai preferences have been set on the server for the current user, and how is the user's browser and/or OS configured. The latter point has to do with the fact that many date/time widgets use a client-side Javascript Date object to validate and reformat user inputs. The user may be on a different continent from the sakai server (take collab, for example).
Jun 16, 2006
Jim Eng says:
I'll accept it gracefully if people tell me I'm making it too complicated.I'll accept it gracefully if people tell me I'm making it too complicated.
Jun 16, 2006
Vivie Sinou says:
Why two separate fields for date and time? I hope you realize that you would be ...Why two separate fields for date and time? I hope you realize that you would be adding a fifth way that Sakai handles dates/times if you do this.
Jun 16, 2006
Kathy Moore says:
Can you help me find an example of how it's done on one line elsewhere?Can you help me find an example of how it's done on one line elsewhere?
Jun 16, 2006
Aaron Zeckoski says:
Look at this one:Look at this one: http://www.travelocity.com/
Jun 16, 2006
Jim Eng says:
Good question, Vivie. This is the first phase of this discussion, and we hope wh...Good question, Vivie. This is the first phase of this discussion, and we hope when all is said and done there will be one date/time widget in Sakai. That's if we get it right. Or if we get it so wrong that someone else gets it right
I think we did not have a full discussion of why two text fields. I think I may have said two fields, but maybe it was someone else. One argument for two fields is that if you chunk it that way, it may be easier to follow the patterns for dates and the patterns for times (by thinking about them separately). But it makes pasting a date-time a multi-step process.
Jun 16, 2006
Clay Fenlason says:
"2) Could this be on one line with fewer internal labels? It would be nice if it..."2) Could this be on one line with fewer internal labels? It would be nice if it was more compact."
Yes, I don't know that you need the "Date" and "Time" labels. The default text in the text fields could do the job just as well. I think something like mm/dd/yyyy makes the point well enough for the date, and that's how many web apps seem to handle it.
Also, it would be better to use a single text field much like Melete does it in Vivie's attachment.
Jun 16, 2006
Vivie Sinou says:
Sure. I just attached a document (see tab above) for the four ways that Sakai To...Sure. I just attached a document (see tab above) for the four ways that Sakai Tools handle this already: Schedule, Assignments, Tests & Quizzes, and Melete - each handle it differently. This adds a 5th way for Resources.
Jun 16, 2006
Clay Fenlason says:
The goal, I think, is to find a single way that will satisfy all those tools, an...The goal, I think, is to find a single way that will satisfy all those tools, and contribute back a more usable, internationalizable, and accessible Date UI widget that all Sakai tools could leverage. One widget to rule them all.
We're using the Melete widget as our starting point. The Sakai ones with all the drop-downs, in particular, were judged to be woefully inadequate.
Jun 17, 2006
Clay Fenlason says:
I hunted this up again we're essentially going after another requirement:I hunted this up again - we're essentially going after another requirement:
http://bugs.sakaiproject.org/jira/browse/REQ-21 (Standard calendar widget)
Jun 17, 2006
Mike Osterman says:
1 for going with the Melete date/time widget. I think it makes more sense to hav...+1 for going with the Melete date/time widget. I think it makes more sense to have the two combined, especially if it's stored in the RDBMS as a datetime datatype.
I'd like to see a flexible widget that, in default format, would provide a date/time, but if given a "date only" arg, would be capable of removing the time controls/formatting. If I recall, some temporal properties in Sakai are datetime while others are just date.
Jun 17, 2006
Vivie Sinou says:
Fron a practical perspective (screen realestate and efficiency) and obligation t...Fron a practical perspective (screen real-estate and efficiency) and obligation to our users, there is no way we would adopt a two-field date/time widget for Melete. We considered it back in the summer of 2004. There is no space. Taking users to another screen for these "common" functions (term-to-term) is not acceptable for us. A major requirement for our users is the ability to change the start/stop date/time of their modules from ONE screen (table of contents), without having to click on each module to make date/time changes, as it's done in assignments, Samigo, and many other tools in Sakai.
Faculty are crying for really efficient ways to manage their courses, especially as they prepare for a new term, so that they can focus on designing creative activities and giving meaningful feedback to their students. They want to do the term roll-over, brainless tasks quickly. Our goal is to find ways to remove these barriers by observing where the workflow frustrates them.
I realize that we all have to make tough decisions as to what goes to the top level "list" (table of contents) screen. It is not easy.
Jun 17, 2006
Mike Osterman says:
Just to be clear, I am talking about and am in favor of a onefield widget rather...Just to be clear, I am talking about and am in favor of a one-field widget rather than two.
In looking in the document you've attached, when given a "date only" arg, the text field would not include time characters, and the picker pop-up window would not display the "Time:" section at the bottom to avoid confusion.
Jun 17, 2006
Vivie Sinou says:
Yes, I saw your note. We are in agreement....Yes, I saw your note. We are in agreement. I wanted to underscore the critical importance of "efficient" design in the hopes that we wouldn't begin arguing about things that were already reviewed two years ago now - not that fresh reviews are not a good thing.
Jun 20, 2006
Kathy Moore says:
From Mike Elledge melledge@yahoo.com, whom Daphne enlisted as an accessibility e...From Mike Elledge [melledge@yahoo.com], whom Daphne enlisted as an accessibility expert:
My suggestion (despite Vivie's concern about space) is to use figure 3.
Someone skipping through the site using tabs or headings will be less likely to make an error if the time component is separate. I am worried that there is otherwise too much opportunity for user error--1) have to recognize that time is mixed in with date, 2) has to worry about putting two different formats on the same line.
Limiting date entry to a calendar means lots of tabbing to get to the date you need.
Jun 17, 2006
Stephen Marquard says:
Noting some related JIRAs for completeness and crossreferencing:Noting some related JIRAs for completeness and cross-referencing:
http://bugs.sakaiproject.org/jira/browse/SAK-892 (date picker should validate dates)
http://bugs.sakaiproject.org/jira/browse/SAK-2772 (inconsistent selection widgets)
http://bugs.sakaiproject.org/jira/browse/SAK-2023 (am/pm indicator)
http://bugs.sakaiproject.org/jira/browse/SAK-2023 (invalid date inputs)
Jun 20, 2006
Beth Kirschner says:
I'd take a look at the predefined formats outlined inI'd take a look at the pre-defined formats outlined in http://java.sun.com/docs/books/tutorial/i18n/format/dateFormat.html. The changes made to the BasicTimeService use the user preferences for both Time Zone and Locale when formatting the date & time, and it would be good if the widget could do the same. In addition to dd/mm/yy vs mm/dd/yy issues, AM/PM is not universally used in time displays (many countries use what we call "military time" – a 24 hour clock).
Jun 20, 2006
Mike Osterman says:
Beth thanks for this. I was trying to figure out what the SHORT, MEDIUM, etc. ac...Beth - thanks for this. I was trying to figure out what the SHORT, MEDIUM, etc. actually meant.
The date picker we are looking at does validation and formatting based on a hard-coded value. To make it work (someone tell me if I'm wrong) one would need to anticipate the different locales and create a version of each of the pickers that matches each locale's date formatting mask.
Jun 20, 2006
Kathy Moore says:
David Horwitz dhorwitz@ched.uct.ac.za adds: For those of you not on the L18N lis...David Horwitz [dhorwitz@ched.uct.ac.za] adds:
For those of you not on the L18N list, a caveat about Suns date locals, particularly the MEDIUM data format. Most locals have medium dates like :
20 Jun 2006 (en_GB) or
Jun 20 2006 (en_US)
however a number of locals, particularly for secondary language areas (i.e ones that were probably added to the JRE later) have dates like:
2006/06/20 (en_ZA)
I've noticed this difference between es_ES and es_AR; as well as pt_PT and pt_BR as well. This could lead to unpredictable behaviour in certain locales
Jun 22, 2006
Diana Lee Perpich says:
Concerning locale, the current calendar in the datepicker shows Saturday and Sun...Concerning locale, the current calendar in the date-picker shows Saturday and Sunday at the right, instead of Sunday at the left and Saturday at the right with the weekdays sandwiched between.
https://ctools.umich.edu/access/content/user/dperpich/share/selectdate.jpg
Users often get confused about this. They create a new Schedule item or Assignment and use the date picker but pick the wrong date. For instance, they mean to select Friday but select Saturday. In the U.S., isn't the standard to start the calendar view with Sunday? That's what we do in both the monthly and weekly calendar views in the Schedule tool:
https://ctools.umich.edu/access/content/user/dperpich/share/month.jpg
https://ctools.umich.edu/access/content/user/dperpich/share/week.jpg
Seems like this should be tied to the locale. [dlp]
Jun 22, 2006
SOO IL KIM says:
It's easy to set the way to start The day (Monday or Sunday) in calendar.html (T...It's easy to set the way to start The day (Monday or Sunday) in calendar.html (Tigra Calendar).
// day week starts from (normally 0-Su or 1-Mo)
var NUM_WEEKSTART = 0;
Jul 14, 2006
Wytze Koopal says:
I've been following this thread for some time now: most of what I read seems rea...I've been following this thread for some time now: most of what I read seems reasonable and right. The comment by Diana Lee Perpich is sooo right.
And then.... the last comment by SOO IL KIM makes me wonder. This gives me the impression that this setting (on which day of the week does a week start) is buried deep in properties etc... This is not what I want! I want this setting to be configurable for the end-user!
Here's my use case: It might well be that a teacher has a preference (because he is American) for another starting day than the ordinary student (who is Dutch) that is following the course of this teacher... We need to accomodate for this (I think).
Jul 14, 2006
Jim Eng says:
I think we all share your interest in this, Wytze, including Soo Il Kim. He is w...I think we all share your interest in this, Wytze, including Soo Il Kim. He is working hard to give us an improved date widget. In this case, he was answering a question that also came up in our telephone conference, which was whether the day week starts was configurable. It remains to be seen whether that can be dealt with through site preferences and/or user preferences. We are in the process of trying to make the date widget respond to users' needs and expectations as closely as possible. Thanks for bringing up that use case. It helps us understand the importance of trying to get this to happen seamlessly. No promises about whether we can achieve that this summer.
Jul 14, 2006
Clay Fenlason says:
I think one thing to keep in mind is that the development thus far is not in the...I think one thing to keep in mind is that the development thus far is not in the context of a Sakai tool. It's merely the bare-bones HTML and Javascript, and that's what Soo Il is talking about here. When we make it a Velocity tool (or JSF, or RSF) we'll have more options for how Sakai may be used to configure and present it.
Jul 17, 2006
Wytze Koopal says:
Ok, thanks for clearing this out for me.Ok, thanks for clearing this out for me.
Dec 22, 2006
Antranig Basman says:
I have placed an early demonstartion of the internationalised date widget that I...I have placed an early demonstartion of the internationalised date widget that I developed for RSF, with reference to the requirements on this page, at http://ponder.org.uk/RSFComponents-test/faces/test-components-index .
Firstly apologies for the somewhat slow hosting - also this implementation uses the Yahoo UI library's date widget which causes quite a fetch burden since the Yahoo library is factored into a number of files which must be fetched separately. Alternatives are still actively under consideration.
Also please note that the markup currently is only good for use in Firefox - I will be doing work with IE and Safari over the next week or two.
Since this is RSF, the actual view template for the date widget may be independently browsed at
http://ponder.org.uk/RSFComponents-templates/content/templates/yahoo-date.html
The main purpose of this round is to get another complete round of comments on how well this markup and in particular the annotation style I have chosen (boxes signalling required date format and valid strings) meets the various requirements of accessibility, efficient use of visual estate, flexibility, etc.
From here there are two main strategies for further development, and also to bring this implementation into the other two remnant technologies in Sakai of JSF/JSPs and Velocity. The first approach would be to shift more of the validation logic from the server to the client and make the widget more "autonomous" - more similar to Soo's implementation above. The second approach would be to deploy a standard "RSF date validation service" within Sakai, which would be available to any instantiation of the widget from other technologies (this suggestion from Ian Boston).
Looking forward to your comments, Antranig.
Mar 13, 2007
Antranig Basman says:
I received the following two comments on the implementation. Firstly from Mike E...I received the following two comments on the implementation. Firstly from Mike Elledge, who evaluated the widget for accessibility:
> At long last, here is my report. All functions work with the
> keyboard only.
>
> Tool works functionally using JAWS, but needs to have labels
> associated with form inputs for users to know what keys do; months
> not associated with days in calendar, < and > are undefined
>
> Also, would be great if focus returned to edit field after it is
> updated, otherwise starts at top of page and have to scroll down.
The widget was updated to deal with the focus issue - the other issues are related to the underlying calendar widget implementation (Yahoo UI) - if anyone can locate a preferable implementation from the various JS libraries it would not be too much work to switch to it.
The following response from Kathy Moore:
> I finally got around to looking at this, and the results puzzled me. I
date, and... well, I'll let you look.
> intentionally put in a bad
This (accepting "33" as a day number) was resolved by disabling "Lenient" mode parsing at the Java side.
The live demo at http://ponder.org.uk/RSFComponents-test/faces/test-components-index has been updated with these fixes, as well as portability fixes for IE and other Firefox versions, and will be committed to Sakai SVN tomorrow.
May 14, 2007
Gissur Jonsson says:
It looks nice, Antraniq, one thing though: The Danish locale (dkDA) seems broke...It looks nice, Antraniq, one thing though:
The Danish locale (dk_DA) seems broken - it parses the dates and present it in correct danish format (for instance May 14th becomes 14. maj) but the input field seem to expect year as first element, and that is not right for the locale (we use dd-mm-yy almost exclusively. I guess it's a missing specification problem where the input field just uses the default setting.
Jan 03, 2008
Antranig Basman says:
Thanks Gissur... it seems that the South Africa (ZA) Locale is broken in various...Thanks Gissur... it seems that the South Africa (ZA) Locale is broken in various ways as well. When I decided on this server-side architecture, one of the main benefits I saw was taking advantage of the standard JDK Locale information which I had presumed correct, but over time problem after problem is coming to light. It looks like an important task will be to draw up our own data format for Locale-specific overrides (which should reside on the server, but perhaps should be in a form which is interpretable by clients too) to enable Locale managers to provide correct information. IBM's icu4j might be a better source of valid localised info but I have not looked into this. Hopefully work done together with Fluid will be aimed at this task.
Jan 03, 2008
Clay Fenlason says:
One extra note while I'm thinking about it. The design above (and the current RS...One extra note while I'm thinking about it. The design above (and the current RSF widget) is unsuitable for displaying two such widgets horizontally adjacent. It becomes hard to see where one leaves off and the other begins.
An example of a place where this might matter: interfaces that ask you to display open and close dates, or open and due dates. Laying them out vertically might seem like a natural response, but some of these dates are part of tabular listings where they might really need to appear horizontally adjacent.