Skip to end of metadata
  • Created by Former user, last modified by Former user on Jun 22, 2006
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Agenda items

Minutes/Outcomes

Attendees:
Jim Eng
Mike Osterman
Zach Thomas
Francette Myburgh
Craig Counterman
Mike Elledge
Clay Fenlason
Kristol Hancock
Soo Il Kim

Quick Review of our current state:

  • UI design of Add/Revise pages reflects the consensus to date, and is essentially done (although further tweaking of the language, etc. is certainly possible).
  • UI design of new Date Picker has narrowed to two possibilities: one text field to hold both date and time, or a separate text field for each.
  • Kathy has put up a good document detailing the UI requirements for the Date Picker. It may however be controversial at a couple points.
  • Mike has a working mockup of a drag and drop reordering interface.

Reordering Discussion:

  • 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.
  • 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-project.

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: 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.

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.
  • No labels