Design and Usability
The resources tool is heavily trafficked in most sites, while at the same time there are a variety of ways in which it might be used, and its functionality keeps growing. The usability pressure here is therefore especially acute - elegance must be achieved amidst complexity. An extended campaign to gather user research and use that as the basis for a new design for the 2.5 timeframe is underway.
need to accommodate new content types in 2.4 release
Comments
Oops, the TBL tool is the Gallery Tool.
You're right, Mara. Some of the changes for 2.4 will show up in the file-picker. My expectation is that once we finalize designs for the Resources tool, we will make parallel changes in the file-picker. Also, some tools create or modify resources directly without going through the file-picker. Those tools will need to identify the "type" of the resource. We'll notify developers of what needs to be done.
Yes, and at the time of writing the 'list view' page pulling in attached images is a good illustration of the separation of file use/presentation as distinct from file administration. If Resource Viewer becomes the main 'view' on the content belonging to a site, then the resources tool can focus on administrative tasks.
If we go for this separation, we should note that admin tasks like 'delete' should ideally get an alert if the file is 'in use' in another viewer application i.e. where-used information would be useful...
We've discussed keeping track of reference-counts for resources, so users could be alerted if they were modifying, moving or deleting an item that is eferenced elsewhere. Unfortunately, various tools and services make attachments in ways that cannot be kept track of easily.
The most difficult case is probably that a link to a resource can be inserted from the rich-text editor, and the link exists only in the document that it's inserted into. Then that document can be copied, deleted, moved, etc. It would be very difficult to track such references.
If we do this in a way that tracks some links and not others, we will give users the idea that they can safely modify/move/delete resources that in fact they can't. That might be better then giving no indication at all of attachments that could be tracked.
I'm not saying this is impossible. I'm just saying that it looks like a pretty huge task, and so far there have not been developer resources to take on the job.
That's certainly the direction we've been heading in discussions for the last 8 months: Resources becomes the 'file manager' while other tools worry about display and presentation. To the podcast tool we might add Melete, the Presentation tool, the fledgling Resources viewer, OSP, and so forth.
Part of me reacts against this - there's something about forcing the site maintainer to hop between 2+ tools in order to accomplish what in many cases may feel like a unified task ... something that doesn't sit well. But I can certainly agree that attempting to build the Resources tool to handle all these various presentation modes is unthinkable, and Resources as file manager provides a good coherence of purpose. We just need to think very carefully about tool integrations here.
The Resources Viewer is still not available, so it may be premature to talk about what it might become. But I'll do that anyway.
I share Clay's concern about requiring work in two or more tools to accomplish a fairly simple goal. But I see the Resources Viewer as a first step toward a better world.
I hope the Resources Viewer becomes the foundation for two new tools:
An "entity" viewer that allows a site maintainer (instructor) to assemble a collection of things from various tools (for example, discussion threads, resources, chats, podcasts). My hope would be that the maintainer would be able to launch other tools to author or configure content to be viewed in this future "viewer" tool, and that the maintainer could set permissions for other users to allow them to participate in a chat, upload files, etc, as appropriate.
A better Resources tool that focusses on its role as a GUI for a file-system and solves some of the problems of the current tool.
This is a good point Clay and I share your reaction. One thing idea that has come up is that the kind of interactions happening within a tool might inform how this is handled. So in a tool like Image Gallery where we expect instructors do to some work arranging their images, adding context, getting a presentation ready (for art history class for instance) it seems like this split is OK. Additionally, once a collection of images is created and ready for students to view/study it would be nice for the entire collection to be accessed and viewed with all the other course content for that week or topic. This seems like where something like the Resources Viewer or an integration of the Resources Viewer and the Syllabus Tool could really become that global view of the stuff relevant to this course or even this week of this or this day of this course.
Clay makes a good point. Perhaps it would help to try enumerating some of the possibilities for the relationship between the Resources Tool and Tools That Reference Resources (TTRR).
Resources is the place to upload, store, and manage things that are either used directly by users or by other tools--the TTRRs. TTRRs have to know where in Resources things are, but Resources doesn't have to know who uses which resource. Thus a site maintainer has to keep track of where resources are used so that TTRRs don't get messed up.
Same as the previous one, except that the Resources Tool either tracks or can discover all the places a given resource is used and can warn maintainers when they try to move, delete, or even edit the resource.
Resources in the Resources Tool can be managed directly, but it is also possible to manage resources indirectly/invisibly from a TTRR. In these cases, Resources becomes a service that is used by TTRRs. In this case it may still be possible to discover and manipulate TTRR-specific resource repositories within the Resources Tool itself, but the resources are hidden by default, much the same way the Windows and other OSs hide system files within the user-accessible file system.
I'm sure there are many implications of these three approaches I haven't thought through. Are there other approaches? While model do we prefer? Myself, I think I like the third one, but I would choose the second over the first.
The third item in Mark Notess's list is pretty close to the current reality. ContentHostingService (CHS) is a central Sakai service that is used by many Sakai tools to store and organize "resources". The Resources tool stores resources in CHS. There are at least three ways in which other tools store resources in CHS:
Using the file-picker to add an attachment to an entity. Calendar, Announcement, Assignments, various OSP tools, RWiki, and other tools do this. The attachments can be stored in places that are accessable through the Resources tool or in a hidden place.
Creating new resources in collections that also are accessable through the Resources tool.
Creating new resources in collections that are not accessable through the Resources tool.
All of those are possible right now.
Some tools store "resources" (files and other byte arrays) outside of CHS. In some cases that's because CHS lacked some capability required by the tool at the time it was being developed. When we've been made aware of such cases, we've tried to work with the developers of such tools to fill their needs.
I prefer #3 as well. It would be ideal if you could also choose to hide the associated resource folder to non-maintainers so students or other access members don't get confused by the Resources clutter. In a sense we are moving to thinking about the Resources tool not as a tool but as a multi-faceted repository with a content mgmt. direct view and then as a service provider to other tools. I suspect that most users will be most comfortable working inside the tool that is closest to their specific activity. The hoping between two tools is a work around.
I am sure you are taking this into account, but just thought I would add a note here for good measure. An increasing number of tools are utilizing Resources as the "place to put stuff" while providing a more sophisticated and specialized view from another tool. The podcast tool is one of these, and the to-be-launched tool is another: http://issues.sakaiproject.org/confluence/x/MIk.