As the community starts to explore development of new "content" tools in the wake of the move from CHS to JCR, it's worth bearing in mind a couple of previous efforts to extend Sakai's capabilities in this area:Content Viewer and Melete, aka Modules. Both of these applications fundamentally attempt to split off the function of general file presentation from centralized file storage and management. This requirement has led to the as yet unresolved issue of "siloed" files within Melete, which is still not a core Sakai tool despite its long history and the fact that it fulfills a basic functional need for any LMS, VLE, CLE, what have you. The research and modeling informing the designs of the Image Gallery tool now under development have only underscored the same basic requirements implicit in these other applications and the need for a new Sakai file management model.
The Limitations of the Current Model
Sakai's current "Resources" application attempts to cover two areas of functionality:
- Context-specific delivery: Straightforwardly assemble various pieces of (mostly uploaded) digital media of various types on a page. (For example, "Week 1 Readings" and "Reference Images" might be provided to students inside folders in the site's Resources tool.)
- Administration and central delivery: Provide "file management" in a central location. Give a central place to find all available downloads regardless of media type or context.
Over time it's become clear that these two goals conflict if forced into a single UI. Digital artifacts need to belong to more than one application context: they need to be attached to emails; they need to be embedded in announcements, discussions, and wikis; they need to be arranged in slideshows and displayed in quizzes. But the current Resources tool UI assumes that Resources "owns" the displayed media. To avoid the issues that come with shared ownership, Resources typically doesn't display "attached" files - but then that eliminates any chance of centralized administration and forces users to make extra copies of what may be very large files.
Goals
Split the functional goals and our user's lives become easier.
Files in anywhere
- Make it easy to add a reference to a downloadable file in any tool.
- Make sure there's at least one very simple "web authoring" application to construct pages with embedded file references. (For example, "Readings" might be a page that includes a textual introduction and lists of files for each week.) Present embedded files in a media-specific fashion (e.g., a titled image thumbnail inside a DIV).
- Track all internal references to each file.
Files from anywhere
- A site-wide application allows administration, tracking, and downloading of all available files regardless of context or media type.
- Files can be viewed either in a compact text-based table (for easy searching by size or media type) or in media-specific fashions.
- References to a file are displayed and used (e.g., to warn users before files are deleted).
- An embeddable tool helper allows media references to be added from "all available files" on the site or by importing files. File import approaches need to be pluggable to allow for future extensions. Known use cases include upload from the desktop, or through DAV, or import from another site, or import from an institutional digital repository, or as a soft link to a shared resource....
The start of some functional requirements and distinction
| Files from Anywhere | Files in anywhere |
|
|---|---|---|
| What is it? | View into the file manager persistently available from anywhere in Sakai | Presentation of files in Sakai tools that enables specific presentation needs for the context.. |
| Where is it? |
Persistently available - cuts across sites and tools. Perhaps it's a link to "my files" in the wrapper with login & preferences or just another link in the left nav. |
Any Sakai tool should make files available in the presentation format needed for its context and the various files types. |
| Examples | Doesn't currently exist but metaphors include: diva, windows explorer, Mac Finder, Catalyst. | Image Gallery = thumbnails, Resources could be "Course files" (stripped of global file management functions) = folders of course material, Content viewer = various, wiki = various, etc |
| Filtering, sorting, faceted navigation |
Traditional folder hierarchy, automatic filters/faceted navigation (i.e. file type, contexts used, who's using it, etc. | Specific to needs within tools context. Image Gallery is an example of one-to-many, "playlist" like presentation and navigation needed since an image may belong to the "week 1" collection, the "Picasso early work" collection and the "Final exam study sheet" collection for example. In other contexts like "Course Files" the need may be more hierarchical and based on traditional folders. And in something like the wiki, embedded presentation requirements are more likely (rather than a list of files). |
| Metadata & information | Knows about data that lives with and pertains to the file always. Also knows about information that has been attached to the file in particular contexts. And keeps track of file usage: where, how, who, etc. |
Context specific metadata & information (i.e. description of this image is specific to what it means in this particular collection of images but it will mean something different grouped with other images) |
| Sharing |
Allows hierarchical and ad-hoc group sharing (institution, department, team, course, etc.) | Site specific but allows sub grouping within site (sections, teams, collaborators, etc.) |
Whiteboard notes
- view into file manager
- cuts across sites & tools
- intereating ways to sort & filter
- file type
- context
- who's using
- etc.
- Data specific to file always
Files in anywhere = Image Gallery, content viewer, resources w/file management pulled out - Presentation of files = tools
- Metadata & information specific to this file in this context = context meaning
- Import from within this context
- By pulling up file manager & it also gets added to this context Questions: * Connected with representations of files
- Protect files based on usage
- Usage = some things other than tools
- Where is it at?
- Who's using it?
- What are the versions?
What are the contexts? - Wehre can you delete from?
- What about all the places it's used
- Contexts
- File management display
- Media specific application
- Presentation of files
- Resources = site files
- Media specific presenation (thumbnails, podcasts, etc.)
- Context Specific
- Metadata important to the content only
Comments (2)
Mar 07, 2008
Ray Davis says:
Not sure where the place is for it, but I want to acknowledge the University of ...Not sure where the place is for it, but I want to acknowledge the University of Washington's Catalyst / Solstice team for helping crystallize our ideas on this – they're delivering the same split in an upcoming release.
Mar 11, 2008
Oliver Heyer says:
Not sure if this is relevant, but the phrase "digital artifacts" used above remi...Not sure if this is relevant, but the phrase "digital artifacts" used above reminds me that Josh Ryan is also working on an "Entity Viewer." I hope that quizzes, e.g., are not being treated as "content" in this current round of work. To ignore that files are a privileged and distinct form of content for Sakai users would be a big mistake, IMHO.