...
- Mike Osterman: The brothercake code is promising, particularly for accessibility (reordering can be accomplished through the keyboard), but it's distributed under LGPL, which fairly well rules it out.
- Mike Osterman: The reordering would probably need to happen on a new screen, as a special operation reached through an action link on the main listing.
- Jim Eng: This would have the added benefit of being easier to disable, if people wanted to do that.
- Mike Elledge: Should we think about incremental steps, rather than a big jump to drag and drop? The interface may need to "degrade gracefully" for accessibility reasons, and so perhaps it's just as well to begin with an interface that isn't so visual.
- We talked about how the current mockup might be made accessible. One possibility might be to make it so the user can tab to a particular item in the list and then use the up- and down-arrow keys to move an item up or down in the list (using javascript to capture keystrokes and translating them into the same function calls used by the drag-and-drop mechanism). We also discussed a couple other approaches to an accessible version. That one seemed the most promising.
- Francette: There was a lot to be said for that earlier mockup which used the up-down arrows borrowed from the reordering tabs interface from the My Workspace Preferences. Primarily because it's a familiar interface, and not only within Sakai. Have we ruled that out?
- Clay: The only challenge raised against that one was that the appearance (at least of the first mockups) was very different from the Resources listing. But if it could be done in such a way that the look of the reordering interface was very much like the look of the main listing, then it would be a good option.
- Craig: MIT has something like the up-down arrow solution with Stellar, and it works well. But now that I try it, I like the drag and drop interface, provided we make it clear to the user somehow what they're able to do when they see it. It took me a little while to realize that I could drag things around.
- Mike Osterman: Is it a bad idea to pursue the drag-n-drop option? What do we all think about this?
- Zach: I think the attempt is important, even if we don't end up going with it. It's the sort of issue we're going to be dealing with more in the future in the project as a whole.
- Jim Eng: I agree.
Conclusion: Mike is going to keep working on this, and be the lead for this portion of the sub-projectOsterman will experiment with the accessibility issues this week and report back next week.
Date Picker Discussion:
- 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: 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, even if it's just the title attribute.
- Jim: Ultimately, I think this is just going to have to be something that each tool developer will have to implement.
...