Best practices for archiving AGOL maps and applications

160
3
11-12-2019 08:56 AM
Labels (2)
Highlighted
New Contributor II

I am fairly new to ArcGIS (so bear with me) but I am trying to sort our a decent workflow for better archiving of student produced content on our AGOL organizational account.

We have a robust undergraduate research program - and some of the students' capstone or theses projects take the the form of a StoryMap. We would like to be able to archive them in some form as we do with textual theses and dissertations from our colleges.


We don't have enough seats in our account to keep every student ever enrolled on our organizational license. Our "good enough" method has been to use the delete protection checkbox on the item, and transfer ownership to one of our admins when the student graduates.

It's not really "preservation" though and certainly isn't scaleable. I'm interested to hear how other institutions have worked with similar challenges.

Thanks!

Reply
0 Kudos
3 Replies
Highlighted
Occasional Contributor II

Preserving or archiving interactive web content in general is a complex problem. I too would be happy to hear if someone has solved it for StoryMaps 🙂


The classic Cascade StoryMap app supports PDF (see Printing a Cascade Story), and such support is planned for the new StoryMaps. You lose interactivity when you export a StoryMap as a PDF, however, you might be willing to make that sacrifice to gain longevity in terms of preservation of one view of the StoryMap's content.


What time period are you shooting for in terms of "preservation"? 


As you observed, simply continuing to store a StoryMap somewhere in its original format does not mean you have preserved it for the long-run. Esri continues to evolve StoryMaps and I do not believe they are making any guarantees about the longevity of the format, nor about tools for accessing content in that format. The StoryMaps Roadmap, for instance, notes that Classic StoryMaps will enter mature support in 2024, less than 5-years from now. Plus, Esri has no control over what web browser developers will choose to do over time.


So for now expectations for an achievable StoryMaps preservation time period end up being relatively short. I would suggest estimating how many additional Named Users you might need over that period, and check with Esri on the cost. Then compare that to the cost of the time it will take staff over the same time period to archive the content by transferring ownership. I think you will find the former is much less expensive.


Like your "good enough" method, we experimented with transferring ownership to an admin, and then the admin found it hard to use their account for other purposes as their content filled up. We addressed that by switching to using a dedicated "archive" account as the transfer destination. We then realized, however, that the amount of content needing archiving meant we would be spending more on staff doing the archiving, than it would cost to add more users. (As I'm sure you are aware, it often it is not just a case of archiving the StoryMap itself, but also identifying, locating, and archiving the web maps, web scenes, feature layers, etc. a student created and used in their StoryMap.)


One could script such a process, however, developing those scripts costs time as well. And, remember to include the time you will spend updating those scripts every semester or so when Esri adds or changes something StoryMaps or the API that breaks your script.


Of course comparing costs between software and staff-time is not always apples to apples. Funds for each purpose may come from different sources, and it might be easier to raise money for additional staff time than purchasing more seats, or vice versa... 


So perhaps the main takeaway message -- until the problem of archiving StoryMaps for the long-term is solved -- is to ensure your StoryMap users are aware of the limitations. Ensure students and instructors understand the trade-offs they are making when choosing StoryMaps between an innovative, engaging dissemination experience and the inability to preserve or archive content for the long-term.


Hope that helps.

Highlighted
New Contributor II

Thank you, Peter - this is helpful. We are still in the process of assessing what is needed (and reasonable) in terms of preservation of these sites.There are a few different interests and use types on our campus that probably need to be treated differently. For example - some of our student researchers are contributing to years-long undergraduate research agendas under a faculty supervisor. We may want to save the individual student's StoryMap for their end of term project, but also make the data layers available to to the faculty to and future students to contribute to the larger research project.

A lot of communication and clear project chartering I think will help us.

And yes, we're doing a bit a scripting. As a novice Python programmer, I'll say your comments about use of time are well-put.  

Not specifically related to StoryMaps, but there is a Data Curation Primer for geodatabases that outlines some good practices that we might be exploring as well: GeoDatabase (.gdb) Data Curation Primer 

Thanks for your thoughts!

Reply
0 Kudos
Highlighted
Occasional Contributor II

The use case of students contributing to faculty research is something we handle a bit differently than what we've discussed so far regarding archiving. In those cases our expectation is to transfer ownership of the StoryMap (and related content) from the student to the faculty member to meet long-term needs. 

That is not unlike the expectations for other things a student might do on behalf of the faculty member for a research project. Having a faculty member think about such things in terms of an off-boarding processes, which includes the handling of ArcGIS Online content, can help.

When a student leaves a project there are often many things that need to happen, return keys, hand in their lab notebook, deal with data in geodatabases (as you've noted), change ownership of Google Docs from the student to the faculty member (which they can do themselves), turn over word docs, spreadsheets, PDFs for the project, ensure the latest version of source code is checked in to the repository, etc. So it can be as simple as adding an additional step to the off-boarding workflow: checking to see if any ArcGIS Online content needs to have its ownership transferred.

We set the expectation that at the end of a student's tenure on a project, it is up to the student and faculty member to email the ArcGIS Online team requesting an ownership transfer. We ask the student to acknowledge that they are willing to give up ownership, and provide a list of items to transfer (or the name of a folder they have put everything in). We ask the faculty member to acknowledge they are willing to receive ownership. This process helps document everyone's approval, if questions later arise. 

One thing we do as part of the ownership change is to tag each item being transferred with a specific tag of the form <timestamp>_<from user>_<to_user> (e.g., 2019111933_peter_jeanine). We do that for the occasional situation where someone changes their mind or realizes that they listed the wrong item. The tag makes it easy to find and pull things back, especially if the faculty member has reorganized the content after receiving it.

Or, more commonly, the student realizes they want to retain ownership to tweak the content some more and include it in their portfolio (i.e., a StoryMap), in order to show off their work to prospective employers. At which point we do not transfer the ownership back, but rather create a full clone of the content, so that both the student and faculty member have their own copies of things to do with as needed.