...
- Jim: Did we decide how the locale should be determined? Would it be set by the server or the user?
- Clay: The consensus seems to be the user. We can't assume that the user and the host server are in the same locale, particularly for distance education institutions.
- Jim: OK, and then the date would be passed back to the server through some universal format.
- Mike Osterman: What about the number of text fields? This seems to be almost a religious debate.
- Mike Elledge: From an accessibility standpoint, separate fields with text labels are going to be easier to handle for screen readers.
- Clay: If I can channel Daphne for a moment, I think her usability argument was that keeping them separate made them easier to think about and manipulate, because you don't have to try to take in as much information at once.
- Craig: There's also flexibility. It makes it easier to not include the time if it's not needed.
- Jim: Could someone channel Vivie? I think her position is that two fields make it harder to copy-and-paste dates from one item to another and that Melete uses the date/time widget in a list view where two fields would take up too much screen real estate.
- Jim: Ultimately, I think this is just going to have to be something that each tool developer will have to implement. We may even design our widget to have two different configurations to treat these cases, but that's essentially the same as having two different widgets, as far as the UI is concerned.
Consensus: We'll move ahead with two text fields, for the reasons given. Two widgets are still better than five. - Mike Osterman: On another screen real estate point, what about the date formats appearing as labels for the fields?
- Mike Elledge: It's important for accessibility for the format to be included in the labels somehow.
- Jim: Ultimately, I think this is just going to have to be something that each tool developer will have to implement.
Other questions:
- Jim: Do we need to reach out to other Sakai groups for comment and input? What about sakai-dev?
- Clay: I think we will need to do that, but over the short term I'm concerned about how much more discussion we can afford. It's going to bog things down if we're rehashing things we've already been debating here, in sakai-dg-ui, and in i18n. I'd prefer it if we go with what we have for now, for our own September needs, and then we'll have a little more time to consider other things during the Fall, and really polish this for the next Sakai release.
- Kristol: We at IU have been posting things publicly on Confluence and asking for comment, and usually we don't get much at all.
- Craig: We can at least make clear the reasons certain decisions were made, so that new conversations are not just rehashes.
- Craig: If we go ahead and try something based on immediate need, we'll at least have usability data that can help decide things later when we have a little more time to consider alternatives.
Consensus: We'll move ahead with the input gathered to date from the resources, UI, and i18n groups, and broaden things further once the deadlines are met.