Archiving

Overview

Archiving is the act of removing something from a current view to be organized and managed in a separate view, or an “archive”. It’s quite literally putting something (an image, a piece of meta data, content) in a deferred state where it’s not needed now but might be referenced or restored at a later point in time. Archiving is not the same thing as deleting, and primarily serves as a management function - meaning that the act of archiving something will often not have any end-user repercussions (ex: archiving a tag used on a story in Composer will only prevent someone from using that tag in the future, it won’t remove the tag from any existing stories).

How is this different from deleting?

Archiving is packaged with the assumption that you don’t need access (or want to prevent access) to an object right now, but may need it in the future. You’re storing something for later use. Deleting skips the user-facing storage. Deleting doesn’t always have to be permanent, but the implicit act of deleting something means you probably don’t/shouldn’t need it later.

Usage

In most cases, items that can be user created will often be paired with the ability to delete. Whether or not an archive function should be included is dependent on the product and use cases determined by design.

Our general recommendations are as follows:

1. If the user expects to access an item in the future - Archive
2. If the user isn’t sure whether or not they’ll need it - Both Archive and Delete
3. If the user doesn’t care, or it’s easy to replicate and recreate - Delete

Common attributes & component recommendations for archiving

The use of an archive feature is going to be different across each product, there is no one-size-fits-all solution. In most cases throughout Arc, things needing an archive usually take the form of a piece of meta data (distributors, site service, geo restrictions, tags, etc) and are usually presented in the UI as a table. In these instances, it’s important that the table accommodates components and patterns that allow the user to archive a row.

In other instances, it might not be so clear cut. Here’s a few common attributes and components you can look to use when implementing an archive.

The ability to view and select an item to be archived:

• Table rows
• List items
• Content blocks
• Images
• Videos

An explicit “Archive” action:

• Buttons
• Icon buttons
• Overflow menu item
• Text link

User feedback when an item has been archived:

• Filter options
• Archive pages

User access to archived items:

• Filter options
• Archive pages

The ability to restore or reinstate an archived item:

• Button
• Icon buttons
• Overflow menu item
• Snackbar action
• Alert action

Accessing an archive

An archive view should not be radically different from the original state an item was in. For example, if the user archived a tag from a table - accessing the archive should be as simple as filtering the table by “Archived”. It’s important to keep archived items close and easily accessible to the originals, remember, we’re not deleting!

A note on restoring

An important feature of an Archive is including the ability to restore or reinstate an item to its original state. Anything that has been moved to an archive should be paired with the ability to restore it (usually via the same means of archiving). In addition to restoring, it’s acceptable to also provide an option to permanently delete the item from the archive - though this is a very destructive action and should be carefully considered before implementing.