Agenda
- Date widget update on progress
- not much work has yet been done, but after an interruption, we can now give it some focused attention
- see http://kimsooil.is-a-geek.net/calendar_demo/caltest_mockup4.html
- Sort order update
- Consensus seemed to be that a drag-and-drop solution is too ambitious right now
- Tool code changes?
- With the release coming out next week, can a branch now be created for the tool and CHS work?
- Other items?
Minutes
Attendees:
Francette (UNISA)
Clay (BU)
Kathy (BU)
Jim
Soo Il (BU)
Date Widget:
Clay: An update. We were unfortunately derailed a bit locally, and so weren't able to give this one much time yet, but the latest sample is at the link above. Our concern right now is trying to make sure that this is done in a way that new internationalizations aren't a big maintenance burden. The Tigra code on which it's based hard-codes the format.
Jim: It seems there are 3 pieces here. The HTML of the calendar popup, the calendar JS, and the launching page. What do you have to change when you add support for a new locale?
Soo Il: The calendar JS and the HTML page. We should be able to merge them into a single file.
Jim: I don't know that we'd need to.
Francette: The two-letter abbreviations of the days of the week are a little odd, but we can work with that.
Kathy: The calendar resizes nicely if you enlarge the Window. Maybe we should just make the popup open bigger and include three-letter abbreviations.
Jim: What about changing which day is the first day of the week? I know some locales have talked about that.
Soo Il: the Tigra code is designed to handle that. It's easy to shift the days around.
Jim: How is the calendar data internationalized, like the day of the month? That looks like it's in the HTML, so we should be able to internationalize it easily with a resource bundle.
Kathy: One other point that came out of the design discussions was that the format should be visible outside the text field.
Clay: Right, as far as the accessibility issue, Mike was saying it could be handled through attributes in the label tag for screen readers.
Kathy: It's more than that, though. You also don't want to lose it as soon as you start typing.
Jim: Are there other significant locale variations we need to worry about?
Kathy: The 24-hour clock is the important one.
Clay: It depends somewhat on how strictly we're going to follow the standards. There are all sorts of official variations if we include special punctuation, capitalization of am/pm, etc.
Kathy: I'd say we shouldn't be too strict. The meaning is usually quite clear without adhering to every last jot.
Clay: As our initial start, at any rate, we're focusing on en_GB, en_US, and en_ZA. We can add more as we go.
Next Steps:
- Validate Time field
- Perform validation when field loses focus (rather than a button)
- Try to internationalize calendar HTML with a resource bundle
Sort Order:
Jim: Mike's latest conclusion seemed to be that we should give up on a drag and drop solution for now. So where are we with other designs? The general feeling was that the visual context of the reordering should be similar to the context of the main Resources listing.
Kathy: People seem to prefer the combination of arrows and numbering, as in the last screenshot on
http://bugs.sakaiproject.org/confluence/display/RES/Reordering+Resources+UI+Document
But there are still some open questions. If it's happening on a different screen for example, how would you get to it? There are a few options suggested in those other sketches on that page (link above).
Jim: The options that have you taking a global action can be a bit confusing.
Clay: Given that you can only order one folder at a time, the option that makes the most conceptual sense is an action link within the "Actions" column. The difficulty there is the extra clutter where the space for it is already a complaint.
Jim: We may just have to live with it.
Kathy: We can put it there for now and see what people think. We can call it "Organize" or something.
Clay: How about "Sort," to keep it as short as possible?
Kathy: Well, ok for now, but I think there's a grammatical problem there.
Development Phase:
Clay: The release is coming out next week, so does this mean that we can start with the necessary tool and service work in a branch?
Jim: There are a few things I haven't had time to think about yet, but after the release comes out, yes, I think the real development work begins. I don't know that we should use a separate branch.
Clay: It would make it easier to get the work done as an option, and not something we're forcing on everyone yet.
Jim: Yes, but what we should probably really do is just make these features something that can be easily turned off. Or, in fact, turned off by default, and then allow schools to turn them on if they wish.