Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Dropbox notifications considered
    • Need to make a determination for 2.5 fairly quickly here, since we've already agreed to a July 16 deadline
    • requirement might also be met by "Recent Activity" tool, though it's not clear whether that's in a working state
    • Since Resources already has notifications, the email notification route might be easiest
    • Action Item: Harriet will pursue some mock-ups and preliminary design work for what's really needed here. Enough for us to at least make some judgment about whether this (or how much) can be done for 2.5. By July 16!
  • Page for Drop Box notification - http://confluence.sakaiproject.org/confluence/x/obY
  • Review of filepicker situation:
    • We've started with some task-oriented walkthroughs of how attachments appear now - is this approach helpful?
    • For some tools, it quickly becomes very complex as you try to think about all the different ways you might want to work with attachments in course sites or research sites or other forms of collaboration.
    • It's a valuable insight that there is a strong separation up-front in the user's mind between linking and attaching. Conflating them into a unified filepicker has technical/structural advantages, but from a usability perspective it may be counterproductive.
      • That's fine as an end-goal or vision of where we're heading, but that might be too disruptive an approach for now.
    • we've given ourselves until Aug. 1 to determine what can be done for 2.5. What's the low-hanging fruit here that we can start with?
      • there are so many potential use cases to deal with that we need to break it out piecemeal in order to make headway
      • there is some interest in the Fluid project about taking the filepicker on as an early focus
      • a natural connection might be to focus on those areas where an embedded attachment widget like the mailtool has (i.e. instead of a new filepicker screen) might bring real value. This is something where both Fluid and the Resources team could be natural partners.
      • we could just pick a few such instances of those cases, the ones that stand out as being real conceptual/usable choke points, and keep the scope small enough that way for 2.5. Go for the 80% (or maybe 40%), and then set the stage for expanding on this further post-2.5. We wouldn't have to try to solve all the problems at once.
    • Action Item: we still need to flesh out some of these walkthroughs, then, to get to the point where we decide which are the attachment/linking areas that we want to take on. The Adopt-a-Tool program will continue asynchronously.