Let's be honest, there is nothing glamorous about a rubbish bin, trash can or archive!
But when something important is thrown away by mistake, it becomes the last pillar of hope. Only then does one realise how critical a good archive experience actually is.
In SilverStripe 3, user testing helped us identify that users didn’t actually know where their deleted pages were being stored or how to view and retrieve them. Many simply concluded that their archived pages no longer existed. Only the sharpest eyes would have been able to spot the “View archived pages” option hidden within the search filter.
On top of needing to view archived pages, several new areas introduced in SilverStripe 4, such as Files, also required an ability to view and manipulate archived items.
Viewing your archived items shouldn’t be a treasure hunt! It was clear an archive was required.
One can think of this in terms of office bins in real life.
Is your rubbish bin at the centre of your office floor, where everyone can reach? Or does every desk have its own bin? Even if it is in a central position, is it visible to the new person that just started the other day?
Like a bin in real life, an archive needs to be easily discoverable when required, yet out of the way when it’s not. On top of its visual positioning, the language used around the actions and navigation of the archive also need to be considered.
What happens when there are multiple office floors with different layouts? Can it still be in a centrally fixed position like a rubbish chute, or would it be more dynamic, placed near the main access ways?
SilverStripe 4 introduced several new sections that required the ability to archive, such as Files and Content Blocks. There would need to be some careful consideration to where the archive would live and be used, so that it didn’t conflict with existing UX patterns.
This was taken even further, with considerations to help integrate archiving for addons (modules) created by the open source community.
One of the best things about a bin in real life is how ridiculously easy it is to use. There’s very little learning involved (even if your bin had some funky mechanism to open the lid).
Translating this experience digitally is not as simple. There are 6 main experiences we need to evaluate:
1. Archiving an item
2. Finding the location of the archive
3. Navigating the Archive to find your archived item
4. Locating specific item(s) in the Archive
5. Restoring an item
6. Locating an item after it is restored
Integration with existing patterns.
When introducing a new archiving UI, considerations to how it integrates with existing UI patterns within the CMS need to be made. Would it be easier to design on top of an existing pattern or more effective to start designing a new section or even reuse an element that already exists?
Long term maintenance.
Maintainability is an area that can be easily overlooked, especially, when one is pressed for time and funding. However, in projects with ongoing development (e.g. SilverStripe), it is essential to identify a solution that does not become too costly for development teams to maintain in the long run.
We wanted to experiment with two main approaches:
1. In-context archived view.
Here we are allowing the user to view an archived item in the same place as where the items live. The example above explores the experience in the Files area, where pressing an “archive view” button repopulates the Files area with archived file items.
Because of the dynamic nature of this approach, each area of the CMS that require archiving ability, would need to be uniquely considered. This could potentially lead to a lot more development to cater to all the various types of content in other sections. This issue also extends to addons (Modules) to SilverStripe that require this functionality.
2. Central archive.
Centrally located archives are a tried and true model that most people are familiar with. They are a commonplace in operating systems and cloud storage, such as, Dropbox and Google Drive. All archived items are stored in a single central area (not in context to where it has been archived from).
The challenge with building a centralised archive is the need to be flexible enough to allow for different content types to be found. For example, some items use a Title to help identify them, whereas other items might use a Name or Location.
To accommodate this different content types were separated into individual tabs. (SEE ABOVE)
Ultimately, the direction of having a centralised global archiving was chosen on the grounds of better extendibility. This concept also gives addons and new sections of the CMS the option to easily cater to any archiving functionality needs.
Furthermore, this solution offered superior maintainability, needing only to maintain one area rather than several areas dispersed across the CMS.
As the saying goes, design never ends. For SilverStripe, this is just one step in the right direction.