Archives

Contents

Archives

Introduction

We need an improved design for how we handle file archives.

Archives (.zip, .tar.gz, .rar, etc.) are files representing a collection of files and folders, used for transferring a collection of data from one person to another, often through the Internet. Most archives are sent through email, chat, or uploaded to a website.

Designers

William Jon McCann

Objectives

Support use of "Download all attachments" from GMail or similar
Don't expose filesystem details if possible

Constraints

Relevant Art

Discussion

In many or most cases archives are purely an implementation detail. They are used as a way of batching a group of files or transferring an existing folder collection.

I think it makes sense to reuse our existing designs for how to preview content within applications and extend that to include archive preview. The user will be free to examine the contents directly and be offered the option of storing it for later use.

Example:

I click on a zip file link containing photos in Web. Web starts to transfer the contents locally in a new window/tab. When ready it displays them with the option of saving to Photos. When I click that option it saves them as a new album in the Photos library.

Archives in file manager

As detailed above, applications should try hard not to save raw archive files to disk when they can, but in some situations we might end up with archive files on the file system anyway. We currently have an external application handling such files (file-roller); some distributions also leverage on the gvfs archive backend to offer an alternative "mount" option for archives, which allows them to be browsed in a regular Nautilus window. Here's a comparison of a few approaches:

Separate application (status quo)

very visible distinction between archive files and regular folders
ability to have features specific to archives
easy to extract a single file from an archive
extraction either through application or through an extension to the context menu
creation of an archive trough the application or an extension to the context menu
activating a file from inside the application needs to extract the file into a temporary directory (file-roller does it under ~/.cache/), which is usually bad

File browser window

no visible distinction between archive files and regular folders
could be easily achieved by leveraging on the gvfs archive backend and mounting archives transparently
would need to have an archive "magic mode" in Nautilus if we want to have specific features
extraction/adding of files could be done trough copy/paste?
activating a file could use the gvfs facilities and read directly from the archive without the need for a temporary file, but do you really want "Save" to mean "replace this file inside the archive"?

Just decompress it

OSX approach
delete the original file on decompression or not? (IMO: no)
hard to extract just a single file from an archive
addition of files trough DnD?
no problems with file activation/saving back of changes

GSoC 2013 Brainstorm

Since quite a lot of people asked me some more background on the idea for Google Summer of Code 2013, I'm attaching below a more detailed brainstorm of my thoughts on the best approach for this (CosimoCecchi).

Archives are in general quite painful for users to deal with, as they typically require them to realize they are dealing with an archive, and a lot of manual managing.

This means that sometimes the fact files are in an archive is "in the way" of the goal you want to accomplish; editing/saving is especially bad in this regard, as when opening a file from inside an archive it's typically extracted in a temporary directory.

If you think back as to why archives exist at all, I can find mostly two good reasons:

compression
transferring multiple files in one batch

Compression is not really that interesting nowadays - except for backups I doubt anyone e.g. zips files on the hard drive to save space. Transferring is more interesting and still applies though; for instance we don't have any other way to transfer a directory by mail, or download it from a website. My feeling is that this use will get less and less relevant over time, as data moves in the cloud, but it will stick for a long time still.

I think it'd be interesting to explore how we can make these use cases better for our users. One possible approach we've been talking about is trying to have archives be as "transparent" as possible, limiting their exposure to the only part where they're needed, i.e. transferring data. The workflows I'd really like to see promoted are where the user doesn't necessarily need to know at all an archive was involved in a transfer. Say you download a zip file containing a music album from Bandcamp, or a zipped folder attached to a mail, or want to send a number of pictures to a friend. In all of those cases, what you care about are the contents, and the archive is only needed to technically ease the transfer between the two ends. It would be cool then if the archive was hidden from the workflow, both when sending and when receiving, and contents routed directly to the final application it belongs.

My advice is, in a nutshell, to think about the problem from the perspective of the user. Part of the project is figuring out the integration points and the desired workflows together with the Gnome design team, and then writing the code needed to enact that plan.