[Deploying Sakai] [Using Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)
Diego del Blanco Orobitg
diego.delblanco at samoo.es
Tue Jan 10 04:22:52 PST 2012
Hi everyone:
A variant to the Andrews 1st option that we have used in one of our
customers is to create that repository course but enroll the students with a
modified role without the site.visit permission but with content.view
permission. So you dont need to have the contents public, because only
enrolled users will have access to the contents. And they dont notice that
they are enrolled in that site.
The problem (depending of the flexibility of your SIS more or less complex)
here is to enroll the users in both sites, the normal site and the
repository site.
Diego del Blanco Orobitg
Director de operaciones
diego.delblanco at samoo.es
Tlf Oficina: 673 80 32 69
Tlf Móvil: 653 683 489
www.samoo.es
De: sakai-user-bounces at collab.sakaiproject.org
[mailto:sakai-user-bounces at collab.sakaiproject.org] En nombre de Beith,
Linda
Enviado el: lunes, 09 de enero de 2012 23:41
Para: sakai-user at collab.sakaiproject.org; production at collab.sakaiproject.org
Asunto: Re: [Using Sakai] [Deploying Sakai] Requesting Help In Copying
Courses from One Semester to Another (without breaking links)
Hi everyone,
I did send a response to Andy but thought Id also share our solution with
everyone else as well.
Our initial migration process was to copy all Blackboard content into each
faculty members My Workspace Resources site (except of course tests and
quizzes which had to be reformatted using Respondus). We then walked the
faculty through making each course content folder publicly viewable (moving
out anything they did not want students to see). So a typical faculty My
Workspace Resources folder looks like this:
Description: cid:image001.png at 01CCCC6B.EF034E40
Currently we have an SIS integration with our Datatel administrative system
that automatically creates our course shells, connects the instructor
accounts (which are external AD accounts) and updates the rosters on a
nightly basis. For the initial course development we walked faculty through
the process of copying their URLs to their course content stored in My
Workspace Resources that they had made publicly viewable and then pasting
the links to the folders as web links in their new Fall course Resources
folder. Now when they do an Import from Site into their Spring courses, they
are rolling over just the links to their content that is stored in My
Workspace, which are absolute links. This way they dont duplicate the
content from semester to semester taking up unnecessary server space and
also dont have any problems with links. This also accounts for the
occasional removal of old courses from the server (which we havent figured
out a schedule for yet!) so that they dont mistakenly lose their original
content stored in an old course. So a typical Fall or Spring course
Resources folder would look like this:
Description: cid:image002.png at 01CCCC6C.5ECF25F0
This conceptually is a sound practice however here are a couple of
challenges that we have had with it:
· Faculty have a difficult time understanding the difference between
putting things in My Workspace Resources and then linking back to them from
their course Resources
· Faculty forget that they have linked to a folder in My Workspace
Resources and when they want to add to a folder or remove documents in their
course they cant find the original source location
One issue weve run into with the way we are creating courses is that we
cant take advantage of the Section option which would be attractive to many
of our lab/lecture type of courses where the preference would be to populate
a parent course and then link to the content from the child sections.
Another issue is because weve integrated the course shell, instructor and
student roster weve hampered the ability of our faculty to combine rosters
or to add non-registered students (for example those making up an Incomplete
from a prior semester). When faculty try to combine multiple sections of the
same course into a single course shell, or those who are team-teaching or
cross-listing courses want to combine their students into a single location,
all the students are moved back each night when the update runs. As you can
imagine this is very frustrating. Since we havent had the opportunity to
change our SIS integration process yet, what weve done as a workaround is
create a separate Student role that contains all the same permissions and
access but is named MStudent (for manually created student). So when faculty
combine rosters they have to go in and change the role for all the blended
students to MStudent in order to keep them in the course while providing
full access to all the tools. Its time consuming initially but it lets them
do what they want for the duration of the semester since the update process
only recognizes and verifies against the Student role.
We were thinking of the course creation model that University of Rhode
Island is using that connects the rosters only to the faculty accounts but
then relies on the faculty member to go in each semester and create each of
their course shells, attaching the rosters according to their preferences
during the creation process. Our only concern is that this is expecting a
lot of our faculty who up until now expect that we will do all of this for
them J
Providence College is planning on doing a modified approach where they
automatically create the courses each semester and attach the faculty
members. However they will not integrate the rosters into the shells. The
faculty who want to use Sakai will have to go in at the beginning of the
semester and attach their own rosters. This way the rosters will still be
updated daily and will only be available to the specific faculty, but there
is no automated connection to the actual course shell so they can mix and
match rosters at will. I don't believe theyve put this in place yet but I
know that this is the plan. If they can pull this off, well probably adopt
that process since it seems to be the most flexible while still automating
most of it.
Sorry for the long-winded answer. Hope this helps.
Linda
From: production-bounces at collab.sakaiproject.org
[mailto:production-bounces at collab.sakaiproject.org] On Behalf Of Valenti,
Andrew P.
Sent: Friday, January 06, 2012 2:30 PM
To: sakai-user at collab.sakaiproject.org; production at collab.sakaiproject.org
Subject: [Deploying Sakai] Requesting Help In Copying Courses from One
Semester to Another (without breaking links)
Hi Sakai Colleagues!
Happy New Year!
I am writing to solicit ideas, suggestions, and solutions to problems that
occur when links to tools & content in one course site are created using the
Import from Site tool to bring content into a new course site.
The Problem
In the Tufts instance of rSmart Sakai CLE 2.7 (which we call Trunk), we do
not use Sakai Course Management. A new course is created each semester,
automatically triggered by the appropriate SIS information; under our course
management process, course shells are not reused from semester to semester.
In some schools, it is a common practice that instructors create a syllabus
using an HTML page in which they insert links to their course materials
using the FCK editor and these links will be absolute meaning they point
to the resources contained in the original course site. The first time the
course is created theres no problem as the instructor/site owner has
permission to access them. Lets suppose that in a subsequent semester a
new instance of the course is created and the instructor decides to populate
it using the Import from Site tool. If the instructor selects the check
box for importing Resources (along with whatever else is needed), the tool
will bring in the syllabus and the course materials. If no further action
is taken to modify the links that are in the copied syllabus, the following
will happen.
To the instructor clicking on a link in the copied syllabus, the instructor
is able to access the content and everything appears to be working. To a
student, confronted by an HTTP access error message, the links appear
broken; what has happened? The absolute link in the copied syllabus
points to the course material in the instructors original course site for
which the student does not have permission to access. Thus, the instructor
can see it but not the student. Interestingly, the course material copied
from the original site is orphaned with no links pointing to it. Emerging
from discussions with our internal support team and our Sakai vendor,
rSmart, were three alternatives:
Option 1 Use a non-production site as a Sakai content repository
a. Create a root site that serves as a content repository and make the
content public.
b. In the original course design, ensure that the syllabus uses links
pointing to the desired content in the repository site
c. When the course is copied over, the links in the syllabus will work
because they correctly point to content that has been made public. Since no
actual course material has been copied to the new course site, there is no
orphaned content.
Advantages:
* Instructors dont have to be aware of relative vs. absolute
addressing
* Maintains single copy of course materials in a repository
Disadvantages
* Requires thinking though an information architecture design for
content stored in Sakai in order to oversee and maintain protection of
copyrighted information
* Difficult to prevent multiple repository sites from proliferating
which adds to content management woes
· Ultimately, wed like content to be stored in a repository outside
of Sakai which will allow us to provide more sophisticated content
management services such as, access control, capacity planning, and more
sophisticated search capabilities
Option 2 Copy content/fix addressing
a. Change the FCK editor so that the instructor creates relative
links to course material when initially creating the syllabus.
b. When the course is copied using the Import from Site tool, the
relative links correctly point to the course material copied into the new
site.
Advantages:
* Material is kept in course sites which simplifies the management of
copyrighted information
* Doesnt require instructors to be too aware of relative vs.
absolute address and doesnt require them to set up a non-production
repository site.
Disadvantages
* Changing a pervasive tool such as the FCK editor can have unintended
consequences which even thorough testing may not surface. It also creates a
fork in the application code tree that wed have to maintain.
* Course material is duplicated from site to site, gradually consuming
file storage
* Moving to an external content repository will be require scooping up
information from individual sites
Option 3 Use Duplicate Site tool
Advantages
* The tool maintains the proper link addressing and might be the
simplest solution.
Disadvantages
* In our current design, the duplicates sites would not be
automatically populated from our feed. Wed have to undertake a manual
process to populate them with the roster.
* Currently instructors dont have access to this tool. Wed need to
think through this workflow.
* Continues the duplication of course material.
Why we need your help
Each solution has advantages and disadvantages which might be balanced
differently based on an institutions LMS strategy and course management
process. Since the course duplication seems like it would be a fairly
common process across the higher education Sakai community, wed like to
know what approach your institution has taken to populate new instances of a
course and how youve overcome the aforementioned problems. If there are
additional options that weve not identified, wed certainly like to hear
about them!
Thanks in advance for the time youve taken to help a fellow peer
institution!
Cheers,
Andy
Andy Valenti, MSc., PMP
LMS Project Manager
Educational & Scholarly Technology Services
University Information Technology (UIT)
Tufts University
108 Bromfield Road
Somerville, MA 02144
Tel 617.627.3814
Email andrew.valenti at tufts.edu
_____
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 10.0.1416 / Base de datos de virus: 2109/4132 - Fecha de
publicación: 01/09/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 42709 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 35639 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0003.png
More information about the production
mailing list