Original requirement
http://bugs.sakaiproject.org/jira/browse/REQ-375
"Faculty want finer grained control over when resources are visible to students. They want to be able to upload resources, yet constrain the dates/times at which they are available and dates/times at which they are no longer available to students. They would like to be able to manually release document(s) that are in the Resources tool but currently hidden."
Further requirement thinking
There are actually two separable components of this requirement, even if they will appear alongside one another. Separating them has some value for considering the UI for this work.
- The first such component is the maintainer ability to spontaneously and manually hide/reveal resources from an access (or similar) role.
- The second component is the ability to schedule this hide/reveal operation.
Use Cases
- An instructor wants to pre-load all her resources at the beginning of the term, but organized into one folder for each week of class, and each folder is automatically "turned on" at the beginning of each week.
- An instructor wants to upload exam solutions to the site, but set them to be visible only at midnight following the exam day.
- An instructor wants "stale" content to disappear from the student's view after two weeks, yet still wants to keep the content visible to teaching assistants and instructors of the site.
- An instructor wants to upload lecture notes for an entire term in one go, but set them to be revealed to students only after the scheduled lecture.
- An instructor may want to post answer sets to homework assignments, but only make them available after the due date of the homework, and yet would like to have them all uploaded and available for teaching assistants at the beginning of the semester.
Requirements
- A site maintainer should be able to set any given resource to be hidden from 'access' roles (e.g. students) but visible to others (e.g. instructors and TAs).
- Content thus hidden should also not be visible through a WebDAV connection for an 'access' role (i.e. WebDAV should not present a security hole).
- When the content is uploaded the option must be available for it to be automatically hidden. It should not be necessary to have the file exposed for a period of time until a subsequent action is taken to hide it. WebDAV uploads should be similarly covered.
- A site maintainer should be able to constrain "start" and "end" dates and times for an item's visibility (i.e. to schedule this in advance).
- A site maintainer should be able to indicate just one or both of the start and end date properties. Using one property should not require the other.
- There should be some visual indication of which resources are currently 'hidden,' when the instructor/TA views the resources.
- This functionality has no meaning within a "MyWorkspace", and should not be available there.
Potential pitfalls
What happens when resources that are attached in other tools (like Announcements, Wiki or Schedule events) are hidden?
What happens in the Search tool?
Comments (18)
Apr 24, 2006
Mike Osterman says:
These satisfy match all the known use cases at Whitman College.These satisfy match all the known use cases at Whitman College.
Apr 24, 2006
Mark J. Norton says:
While this may be outside the scope of this effort, I believe that selfpaced lea...While this may be outside the scope of this effort, I believe that self-paced learning will someday be a part of Sakai. As such, it would be useful to release a document "nnn days after an event". These events might include a homework submission, completion of a test, etc. This is a style of learning I've given some though to adding to Sakai, but somehow haven't found the time to do it.
Apr 24, 2006
Joseph Vaughan says:
It could be very useful to release a document based on certain types of event,.....It could be very useful to release a document based on certain types of event, for example an online quiz that is released based on the grade in the midterm; or based on the grade from a previous class that was a prerequisite for this one; or even to prepare students who intended to enroll in the next class in a series.
Apr 24, 2006
mekstrom says:
It may be useful to consider the UI a bit. For example, we might want to specify...It may be useful to consider the UI a bit. For example, we might want to specify some calendar screens, which could get pretty complex and probably require integrating with existing calendar tools. For example, we might want role-based highlighting of resources for the instructor (e.g. student-viewable in grey, TA-viewable in green, instructor-viewable in yellow), so the instructor can create various time spans of visibility for different roles.
Apr 25, 2006
John Leasia says:
Another consideration do we need to provide the ability to specify a start/end d...Another consideration - do we need to provide the ability to specify a start/end date for one resource for more than one group? For example, fileA is viewable between date1/date2 for GroupZ, and between date3/date4 for GroupY. Given that you will be able to specify that a file be viewable to one or more groups, adding the additional layer of a different time for each group may be more complexity that we want to deal with. But it's something that should be explicitly figured in either way.
Apr 26, 2006
Clay Fenlason says:
Good point. But to clarify, I think we're talking about rolebased filters rather...Good point. But to clarify, I think we're talking about role-based filters rather than group-based ones. What you're saying is still true, however, for multiple roles.
The use cases we're looking at so far suggest to me that the default behavior should involve filtering for only a single role (e.g. student) which might be set through a config property.
Apr 24, 2006
Mike Osterman says:
For Whitman's use, our primary goal is to mimic the functionality of Blackboard ...For Whitman's use, our primary goal is to mimic the functionality of Blackboard 6 for our full-scale conversion.
In the case of Blackboard, the controls for these properties reside in the "edit" view.
I recall seeing the "Date Issued" field under "Optional Properties" and initially thinking the feature was already there. Perhaps this is most logical place to store this information for the first pass?
Apr 24, 2006
Mike Osterman says:
Continuing off the previous post, it's worth investigating where this "Date Issu...Continuing off the previous post, it's worth investigating where this "Date Issued" field is stored. I hear this field is here for OSP, but could it serve a dual purpose through added a "Date Retracted" field?
Apr 24, 2006
Juliette Mai says:
At Stanford, instructors have the option to set the 'begin' and 'end' date when ...At Stanford, instructors have the option to set the 'begin' and 'end' date when they upload course materials (course materials are equivalent to resources in Sakai). Instructors can modify the begin and end date after a course material item has been added to a course site.
When copying content from one course site to another course site, instructors have the option to have course material items be hidden in student view. If instructors select this option then they will be able to go in at a later time and select specific course materials to be made visible to students. By default, all assignments copied from one course site to another course site are automatically not visible to students.
Jun 09, 2006
Sean Michael DeMonner says:
Questions: How does this feature behave for resources accessed through the Show...Questions:
How does this feature behave for resources accessed through the Show Other Sites view?
Will a resource hidden on site A be viewable via site B? In other words, does the show/hide info apply at the resource level across sites or just within a given site?
There is mention in the requirement that this feature doesn't apply to MyWorkspace? Why not? I could imagine someone wanting to use a single resource in MyWorkspace on multiple sites with different show/hide parameters for each site.
Will hidden items be accessible via URL (e.g. via the Home Page or Syllabus redirect tool; via a link in an Announcement exercised after the resource becomes hidden)?
Jun 09, 2006
Clay Fenlason says:
The visibility of an item would need to be determined at the service level, or i...The visibility of an item would need to be determined at the service level, or in this case the CHS. So there shouldn't be any special route of access that opens up visibility if it has been hidden in the site where it is stored. If it's hidden there, it's hidden everywhere.
I think the MyWorkspace note simply indicates that none of the use cases treat the MyWorkspace. You can't hide something from yourself, you can only hide it from another, less-privileged role/group in your site. I'm not sure I understand the use you're suggesting.
The retraction of items that are attached elsewhere and how to handle them has been the trickiest part of this discussion. We don't have a firm answer yet, though it's been acknowledged that the problem already exists for deleted resources. One possibility on the table is simply to punt on the question, and provide only for a release mechanism, not retraction. The use cases seem to care a great deal more about release than retraction, and releasing doesn't have the same problems.
Jun 09, 2006
Per Wising says:
Great work, everybody. These improvements should be very much appreciated. Howev...Great work, everybody. These improvements should be very much appreciated. However, I have a couple of comments on the UI as suggested in timed_release.pdf e. g. page 2:
I assume the Status attribute really is a 'true' boolean? If so, the widget is a bit awkward since a pair of check boxes implies that both may be selected (which clearly would not be the case?). Instead may I suggest one of the following:
1. If a 'Status' attribute value is required for each resource item, I would suggest the use of radio select widgets to indicate Shown/hidden. If there is a default value (probably 'Shown'), that value should be selected by default.
2. (Preferably--) If no 'Status' attribute value is required for a resource item, it would probably be more in line with UI patterns to use a check box to indicate a non-default value, such as: "Status --> [ ] Hide this resource".
Also, two general problems with the 'Status' attribute UI:
Problem 1: it is somewhat unclear for whom I hide the resource. Members? All roles except access? Students?
Problem 2: The colour blurbs that indicate a 'Status' attribute value for a resource item are probably one too many: an icon or literal attribute value should only be used for the non-default value.
Jun 09, 2006
Clay Fenlason says:
What comments would you have about this alternative instead?What comments would you have about this alternative instead?
http://bugs.sakaiproject.org/confluence/download/attachments/17927/toggle2.doc?version=1
Jun 09, 2006
Joseph Delaney says:
I wonder if the scope of this discussion is slightly too narrow. Rather than "ti...I wonder if the scope of this discussion is slightly too narrow. Rather than "timed release of resources", shouldn't it be "conditional release of resources" with "time" being just one of several possibilities? Already the discussion above has brought up the issue of "release to whom", but it would also be possible and pedagogically useful to release based on an assignment grade.
If the scope is expanded, to the use cases I would add:
Jun 09, 2006
Clay Fenlason says:
Yes, we've already separated in our discussions the ability to "toggle" visibili...Yes, we've already separated in our discussions the ability to "toggle" visibility from the ability to schedule that visibility. I think that's what you're getting at.
The immediate driver of this work is the scheduling facility, but we'd be well-advised to make sure that we're treating it in such a way that other events can serve as triggers - for future work.
Jun 09, 2006
Joseph Delaney says:
Another thing to think about is whether folders should have a different UI than ...Another thing to think about is whether folders should have a different UI than regular documents. Currently, folders have a "permissions" page where the "read" permission can be turned on or off by role (meeting one of the requirements that I just added in the above comment), but that is potentially confusing if an essentially similar setting is accessed in a completely different way depending on whether the item is a folder or a document. And what if it is a document within a folder? To make sure something is visible, a site maintainer would need to check the document "properties" and the folder "permissions", but not the folder "properties"! The hierarchy is confusing enough without the UI inconsistency.
Jun 11, 2006
Jim Eng says:
One thing to notice is that resources is a hierarchy of folders (like a file sys...One thing to notice is that resources is a hierarchy of folders (like a file system) and permissions can only get more open as you go deeper in the hierarchy. So if students start with read permission at the root folder in a site's resources, then students have read permission for everything below in the hierarchy – every folder and subfolder. Setting something as "hidden" will not involve permissions. We have yet to work out the exact mechanism, but I believe it will be similar to the way group access is controlled.
Jul 24, 2006
Harriet Truscott says:
Another thought to muse on for the future this may be unique to the UK, but we h...Another thought to muse on for the future - this may be unique to the UK, but we have copyright rules for scanned documents which involve a time limitation. It would be interesting for us (in the longer term) to have a copyright option which is 'copyright: UK scanning license' and then the time limitation would automatically need to be filled in...