...
- We've started with some task-oriented walkthroughs of how attachments appear 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.