Child pages
  • Exploratory space for Files
Skip to end of metadata
Go to start of metadata

This page is to organize discussions around how files would be added to a page.

Premise: "Files" is the 3.0 equivalent of "Resources." Rather than going to a Resources tool, however, a 3.0 user should be able to upload, view, and download files directly from a Page.

-As I understand it, we are not discussing a full view of all files in a site as might be needed for moving these around, but smaller interactions involving files. These smaller insets into the page are called "vignettes." If not, we can expand.-This work is for both the full, "aggregate" view of all files a particular user has access to, as well as a "vignette" view of a particular set of files associated with a page.

Work Needed (in no particular order)

1. Finalize preliminary vignette use cases for files

click link above for details --Teaching and Learning Group was asked to expand.

2. Get familiar with approach of existing applications

Designers are going to take screenshots from 1-2 of these applications. Please create a child page for the applications you choose.

  • Facebook
  • Blogger/Wordpress (Keli)
  • Confluence
  • Diva
  • Flickr
  • Google docs
  • others?

3. Review & cull Fluid Content Management Research

4. Review & cull Fluid file management problem space work

5. Review & cull previous Sakai work & thinking around file management

6. Personas? (or maybe together with scenarios)

7. Scenarios (expand, add detail)

Daphne/Judy brought up two types of scenarios: context scenarios (tool agnostic) and key path scenarios (exactly how user works within new design. We are talking about context scenarios

The early scenarios we came up with are now linked from the page where we have invited the T&L community to give input.

There are also scenarios from Fluid from a year and a half ago.Judy, Ashish, Daphne and Keli are expanding on these Fluid scenarios here. Community scenarios might be used to augment list, or inform detail.

Questions

  • Does this overlap with the Insert function of Pages? For instance, are any inserted videos, images, audio files going to be located in the File "aggregate view" (similar to how Resources looks now)?
  • Permissions: Assuming that as in 2.0 Materials,  each file can be public, site only, or specific section. What if permissions of page don't correspond to permissions of File
  • No labels

5 Comments

  1. Kelli, with respect to your Premise statement above, am I correct in recalling that Materials is what Stanford renamed the Sakai Resources tool to? And for equivalency, you're just talking about Resources' file uploading/browsing/downloading capabilities, and not bringing its current authoring and editing capabilities into Files, right?

    1. Yes, I believe you are correct. Materials is the tool where students and instructors can store files. I guess I should change it to Resources above...

  2. One phrase used above suggests to me a point that needs consideration: "As I understand it, we are not discussing a full view of all files in a site ..." (italics added)

    In fact, I think for 3akai we would be better off dropping the entire notion of files residing "in" a site altogether. I might instead suggest thinking of access to files rather than physical location. A file might be tagged with the site names of spaces where it's embedded in pages, but it may have many such tags, and it's probably counterproductive in the UI to send the signal that a file lives in any particular site.

    1. To follow-up on the "full view" part. I believe we are still going to need the equivalent of that (aggregated view?) – wherever the files are stored – some sort of full view of all files a user has access to. That view is likely to need some sort of organizational structure as the number is bound to be high, and "sites" (and groups?) whether items reside there or are tagged as associated, would probably be a good default to start with in such a view.

  3. OK, I've updated Resources to Materials. Also, broadened description of what files we're talking about.