This does indeed seem like a big pain point for those of us in pilot. I added Jon's scenarios and solutions as well as Eli's description of a solution to the "Issues and Possibilities with Groups" document.
Cheers, Allison On Jul 25, 2012, at 2:14 PM, Nate Angell wrote: > +1 for Eli's model for Jon's #3 (you guys know each other, right? LOL) > > FWIW: I (and Kirk at UCOE) have used existing OAE (1.1 even) > templating capabilities to clone a course world (but it should work > with a group world also), which I believe is your #1 strategy below. > Agreed not ideal, but it works. > > You can run in to issues depending on the type and complexity of > what's contained in the world (but can manually adjust in the template > file itself) and there is the added wrinkle that to actually make the > new world from the template, you have to expose the template in your > implementation (at least temporarily). > > If you are gung ho on pursuing cloning via template and want some > documentation, I may be able to get something posted. > > I'll also note that deleting the old world raises all the issues of > orphaned content, etc that we are all too familiar with from our > deleting worlds thread ;) One could remove all participants from the > old world and change its visibility/joinability settings instead of > deleting. > > = nate > > On Wed, Jul 25, 2012 at 2:09 PM, Eli Cochran <[email protected]> wrote: >> The modal that has worked for me in other systems is the "publish" modal >> which is essentially your number 3. This allows the user to create a draft >> which has different sharing rules than the "published" page. Once the user >> is ready to publish, they click "publish" and the current "published" page >> is replaced with the updated version. >> >> Welcome to the land of content management. >> >> - Eli >> >> On Jul 25, 2012, at 1:31 PM, Jon Hays wrote: >> >>> Given the recent conversation around sharing content in OAE, I thought >>> I'd use the opportunity to vent a frustration that we are feeling around >>> limitations with Sakai Docs & Groups and get a sense of whether it >>> resonates with others. >>> >>> Scenario - We have a group in our OAE instance called Help and Support >>> where we house a variety of Sakai Docs and surface them as areas within >>> the group. Now that we are prepping for a 1.4 release, we have the need >>> to significantly alter the existing content to reflect the changes going >>> back to 1.2. Unfortunately, there is no way (that we can figure out) to >>> make the changes in advance of the release without literally copying the >>> text out of the existing documents and pasting them into new ones which >>> we would then add to the Help site at the time of release. Unless >>> someone out there in the community has a brighter idea, it seems there >>> is no other way. >>> >>> I don't think I'm treading any new ground, but I thought I'd raise it >>> since it fell into my lap and since this use case is pretty similar to >>> how instructors tend to use and reuse the content that they are working >>> on for their various classes. There are a few ways that we can imagine >>> this could be less painful. >>> >>> Features that we imagine that could solve the expressed problem: >>> >>> 1. Copy Group - This is how someone would probably do this in CLE... >>> Just duplicate the group and all it's content, make the changes so >>> everything looks right and then blast or archive the old group when it >>> is time to upgrade. This seems a bit of a workaround hack to me with >>> possible externalities, but I it would meet the expressed need. Are >>> "Templates" the way the design team thinks about tackling use cases >>> where copying a whole group is needed? >>> >>> 2. Copy Content - Another strategy someone my take using the CLE... just >>> copy all of the relevant Sakai Docs, make my edits to the copies and >>> then swap the content out in the group when the time comes. Still a bit >>> hacky as now I have 2 versions of the same document kicking around, but >>> it would work. Unless we envision providing differing permissions on >>> different versions of one document, we are going to need some capability >>> to copy Sakai Docs for when people need to share different versions of >>> the same doc to different people. Even an export/import capability >>> would be helpful here. >>> >>> 3. Drafts & Version Control - this particular scenario would best be >>> solved (in my opinion) if the user was able to work on a draft version >>> of the live document and then push the new version when they felt it was >>> ready or it was time. >>> >>> Jon Hays >>> 510-672-5493 >>> CalCentral Team >>> Educational Technology Services >>> University of California, Berkeley >>> >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> >> . . . . . . . . . . . . . . . . . . >> . >> >> Eli Cochran >> Project Manager, CalCentral >> Educational Technology Services, UC Berkeley >> >> "The opportunity lost by increasing the amount of blank space is gained back >> with enhanced attention to what remains." >> - John Maeda >> >> >> >> >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev Allison Bloodworth Senior User Experience Designer Educational Technology Services University of California, Berkeley [email protected] 510-289-6627
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
