Page Comparison

...

• Jira and branch for IU's UI proposal has been created, see link above
• Harriet reviewed the outstanding widget bugs that gave Colin pause, and found that one applied to a widget we wouldn't use, while another seems fixed already
  • general consensus that we should move ahead with bringing this into trunk and the post-2.4 branch (but not the maintenance branch), even ahead of a 1.0 release for the widget
  • need to follow up with Colin about licensing question
  • Action item: Clay will follow up with Colin about licensing, and the licensing group as needed
• Resources Viewer status
  • Mike has been working on some blocker issues about displaying the title and multiple RV tools; is past the hump on the former, and should be able to get Josh Ryan's help on the latter beginning next week
  • will then begin to appeal for more help on the resources list for closing other issues that have surfaced
• Maintenance Branch
  • Two outstanding issues listed as "blockers" for maintenance branch work:

    • Jira Legacy
      SAK-9526 SAK-9526

      is about the Dublin Core stuff, and Harriet's going to have a few people test it further to make sure the current work provides what people expect

    • Jira Legacy
      SAK-10309 SAK-10309

      : Steve Lonn is working on this
  • at some point soon we'll need to shift away from maintenance branch work for the 2.5 stuff.
  • Action Item: we'll individually review outstanding JIRAs and promote to Blocker or critical status as appropriate
• Proposed Deadlines
  • Deadlines listed above are adopted

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.