Page Comparison

Connection Info

• Conference Code: 348
• PIN: 72524
• IP Address: 129.79.6.44
• Telephone: 812-856-7060

Time

4:00pm GMT Corresponding times

Agenda

A. Updates on last week's action items:

• IU's branch for the pop-up description: http://bugs.sakaiproject.org/jira/browse/SAK-10581
• Following up on dijit drop-down widget (Harriet)
• Status of Resources Viewer (Mike)
• Maintenance branch status?
  • QA for 2.4.x
• Decisions on proposed deadlines from last week:
  • Resources tool feature freeze: July 16
    • this will be for settling on the scope of any UI changes we'll consider for 2.5
    • probably no more than the pop-up idea IU is floating, but we'll give ourselves a week to think it over and get additional input
  • File-picker feature freeze: Aug 1
    • for settling the scope of any file picker (attachment helper) changes
    • need a little extra time to think through this one, as user expectations are a little murky
  • Specification freeze*: Aug 15
    • final designs/specifications for what will be completed for 2.5
    • this will be surfaced to the community as what they can expect to see in the release
  • Code freeze: Sept 15
    • changes delivered in a working state (i.e. tested to a first order)
    • this should involve a level of QA before the freeze, to make sure Resources isn't completely broken going into the release cycle
  • String freeze: Oct 1
    • we may not need this, but any message bundle work will be finalized by this point
  • Branch freeze: Oct 15
    • target for the release as a whole
  • Release: Nov 1

B. Review of filepicker situation:

• defining implementation scope for 2.5
  • which contexts/tools?
  • new widget?
  • what are the resource commitments?

C. Dropbox improvements?

• Could we look at

  Jira Legacy
  SAK-7812 SAK-7812

  for 2.5 (Email notification sent when item is added to Drop Box)

Attendees

• Jim Eng
• Mike Osterman
• Sean Keesler
• Daphne Ogle
• Clay Fenlason
• Kathy Moore
• Harriet Truscott

Minutes

Quick Updates:

• 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 are experienced 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.