Hey out there Dedoosers! In this blog we intend to go over some processes for keeping your data safe and accessible in the event that anything goes wrong. We do our best to keep everything safe and secure on our servers but in the event that you are unable to access those servers and still need the data, what is a Dedooser to do? Well, we have options.
At any time in Dedoose you are able to export portions or the entire project. While this gets us most of the way towards having local backups of our data, this comes with one important word of warning. KEEP THE SOURCE DOCUMENTS! By source documents I mean the original media files imported into Dedoose, keep them all. It’s not a terrible idea to even have a complete copy of each file stored elsewhere as well, a usb stick, another computer or an online shared drive could serve this purpose, or all of the above if you want maximum redundancy. While getting portions of the various kinds of data exported out of Dedoose is fairly simple, the actual media files are only available for export one at a time. This can be very costly in terms of time, best to skip the need and just keep the media files handy just in case.
Which brings us to our next topic here, what kinds of export is best for backing up your data locally? It’s easy to assume that the ‘Export Project’ function has everything necessary, and assuming you keep copies of the source files you’d be almost completely correct. Although this comes with it’s own word of warning, as the project export function will leave you with a zip file that can be imported into Dedoose to recreate an entire project, in terms of opening and reviewing this data outside of Dedoose you will find the zip file lacking. Without getting to technical this is because the zip file was never meant to be an actual copy of the project, it’s a lot more like an address book of where to find all that data within our servers. This doesn’t eliminate it’s usefulness, this is still a good backup to have just in case a user preforms an irreversible action by mistake. It does mean however that you would need Dedoose to really be able to make use of this file, and while we love our application we are also aware that you may have need of the data but not within Dedoose. Good thing we kept our source files! Between those files and an export of the excerpts including the descriptor data, that’s the entire project.
This now leads us to another topic in discussing backups, I mentioned irreversible actions a moment ago. Things like retroactive upcoding, importing a spreadsheet, or deleting excerpts or media files are all irreversible. Once done, it’s done and there is no going back. Good thing for backups! It’s highly recommended that anytime you are considering preforming an action that cannot be undone to create a copy or export of the project first, just in case. We are all human after all, mistakes happen. Having backups gives us the safety net we need to preform these kinds of actions with confidence. Having to recreate an entire project from scratch is a daunting task potentially taking months if not longer, importing our most recent backup is a couple of minutes at worst. While creating regular backups may add a few minutes to the end of any given session in Dedoose, the hours it may foreseeably save are almost immeasurable.
While this may help in keeping your data accessible, it’s also important to be able to quickly identify the data without opening the files themselves. Naming conventions are an important part of working with various files throughout a study and having a consistent method of naming files can save a lot of confusion down the road. It’s not uncommon to name transcripts after the participant that took part in them, although this can lead to it’s own kinds of issues as well. If you’ve read any of our blogs on descriptors you may have noticed we always advocate for a participant ID field, and this is part of the reason. It’s fairly common for these kinds of studies to be ‘deidentified’ meaning any specific information that could identify a participant is removed, leaving only the participant ID to be able to parse out which participant is which. Let’s assume for a moment that we’ve titled our transcript files after the participant ID rather than their actual name. This helps us stay organized with our files, and even has the added benefit of making linking a bit easier. When linking documents to their appropriate descriptors having an ID field that matches the document title can make it a breeze. And that’s not even taking autolinking into account, which makes this even faster. For more on autolinking please check out our other blog on that subject, but the short short version is if you have a descriptor set field where the responses match exactly to your media titles the system can link the descriptors to the files automatically, saving quite a lot of time. This is just one example of how to title media to keep things organized, there are many different approaches to naming conventions. The underlying principal here is that it is consistent across the project, having various different ways to title media can often lead to confusion. You may want to include dates, regions, or other information in your titles depending on your needs. As long as the method is consistent this is a perfectly acceptable approach.
Would you like to see some of these processes in action? Check out our events page for upcoming webinars, soon to be featuring our very own Jose Gamez, master support specialist. Go to https://www.dedoose.com/about/events to see when the next one is and get the url to register.
Bruce the Dedoose Moose has been spotted again! This time in Key West, Florida, Bruce was found improving his tan and taking in the sights. Of course if any of you Dedoosers out there see a Bruce in your own travels grab a snapshot and send it along, it may end up in one of our blogs!
That’s going to have to do for this blog, we hope you found it helpful. As always, please forward any comments, suggestions or concerns to email@example.com, we’d love to hear from you.;