Explore alternative default behaviors when double-clicking on archive files; Archive Manager is complicated

I disagree. Double-clicking on any file will open it to view the contents. This should not be different with an archive.

The proposed behavior could result in very bad behavior: if the user is in a directory with many files and the archive has many files, extracting the archive will be mix them together, making it very difficult to clean up.

The user can right-click and choose "extract here" if he wants does not want to view the contents before extracting the archive.

That is exactly why extracting the files would create a new directory with the archive name, to avoid the mixing of files. Extracting an archive by double clicking it will always result in a new directory being created, regardless of the archive contents.

I am pushing this request forward because probably 95% of the times if not more I extract the archive. Opening it to view its contents is irrelevant to me as a user because I am interested in accessing the files stored in the archive I've just downloaded.

I believe this is more user friendly than displaying the file-roller interface. Non-technical users don't really understand the concept of archiving, all they know is that they want to double click something to get to their received/downloaded files. The proposed behavior would simplify this task.

Extracting to a new folder and opening that folder in a new window makes sense to me, although how well would this work if it is a large archive that will take some time to extract? In this case, opening file-roller would be quicker.

During the extraction process a window with a progress bar and a cancel button will be displayed. If the user wishes he can just cancel the extraction process and open the archive with file-roller, although if his goal is to extract all the files there is no point in doing so.

I agree that big archives are a valid concern, but I think that users are more likely to work with archives the size of megabytes.

I very strongly disagree, if I open an archive, I expect it to open, not extract or anything. 100% of the times I open an archive I want to inspect the content before I decompress. Unpacking blindly only creates much more work, because I have to copy the stuff where I want it, deal with overwriting files myself and probably have to sort them by hand.

For me this suggestion is an absolute no-go, neverever change to that behaviour.

Let's user test this. My intuition is that users expect double-clicking a file to "open" it, and "open" means extract for most users when they open an archive. The idea of opening an archive as viewing its contents without extracting is very technical.

I don't agree with this. I think automatic extraction upon double click will be very annoying for anybody who has previously used any archives (which is most people, and certainly all of us here). Perhaps instead, there should be a dialog box saying 'Extract Files Here?' with Yes and No options, the No option just opening File-Roller as usual.

Or rather the buttons should say 'Extract Files' and 'View Files', not 'Yes' and 'No.' The text on buttons should always be verbs!

This is a new way of handling archives and I agree it will seem strange at first, but please test this for about a week or two and see if it's an easier way of handling archives or not. I use Ubuntu more as a home user and to develop software at home and I find using file-roller a slower process than it should be.

Worst case, a configurable option should be given to the user to allow this behavior.

I absolutely disagree with this idea.

Setting importance to High, as this might merit user testing.

I just want to add that I rarely extract archives. Most of the time I open them using file roller and then select a specific file inside the archive to open.
I also think that this (the current way) is very consistent and intuitive. I can open an archive just like a folder (and from a user's point of view there really is not much difference IMO), just that it opens in file-roller instead of Nautilus. I then open a file from inside the archive by another double click within file-roller.

Extracting on double click is really bad IMO, since
a) this is not what one would expect, i.e. showing the content of a file/archive
b) In folders with many files in it, a user might not notice that the archive has been extracted. The folder and hard disk fills up and the user wonders why nothing happens when clicking the archive. On novice Windows users' computers I often see folders like "New folder"/"Unnamed folder" (don't know how exactly they are called in the English version). This is because creating a new folder happens easily by mistake but the user does not notice that they has done anything!
c) there may be security concerns, since files may unintentionally be written to some place without further approval and then e.g. the file manager starts to generate file previews or files may have bad file names (say with weird Unicode file names, that look like something else).

As a conclusion, it may IMO be feasible to ask the user on double click if they wants to extract of view/open the archive. On the other hand I think that defaulting to open and having "extract here" in the context menu is the far better solution for me at least.

A basic rule of usability is not doing something the user doesn't expect. If you do what you are considering, some users will be pleased, but lots of users will be disappointed for an unexpected (and maybe unwanted) behavior.

If you want to make it quicker to extract files... I don't know, a possible solution would be to open a dialog asking the user whether he wants to open it or to extract it. This way, it'd be quicker to extract it.

But anyway, I find it a bit meaningless as it's really easy for anyone to do right click -> extract here. That's what contextual menus are for :)

I agree with Pablo Quirós. Current way of handling archives is very well. And that behaviour:
"A new directory with the archive's filename should be created as well"
Actually, clicking right button mouse and selecting "Extract" will do this. Moreover, if the archive contains only one file, a new directory won't be created. In comparison to Windows XP's "Creator", "Wizard" or whatever else it works VERY well. Please, don't change this.

Anyway, why this 100 paper cuts aren't discussed on Brainstorm? I cannot simply agree or disagree with these changes. And don't know if they are 'in development', 'discussing' or 'won't implement'.

Please dont do this.
I also like one of the above commenters and many other users use many archives daily and many of them contain many, many files and i only wish to work on of them which i double click on inside the archive window and there it opens. Hence satisfying the above requirements. Also dialog to ask me what i want to each time as suggested above is a bad idea. it would be annoying.

And the best reason for not doing this is to maintain uniformity between ALL OTHER OS's and distros eg windows from xp onwards just opens the zip file inside the file explorer. maybe something similar can be done in nautilius. but pleas dont extract on double click. extracting huge archives is a time consuming task especially on older machines.

People are certainly against this "feature" but I think this stems mostly from not trying it.

So here's what I propose: letting the user choose via a dialog that appears on double click which reads something along: "You double clicked an archive, what do you want to do with it?" and two buttons "View contents", "Extract contents". A checkbox should be present as well, above the buttons, reading "Remember my choice".

This way people can keep their habitual ways of handling archives and the lazy ones can easily work with their archive files.

Regarding the security risk, I must add that if the destination folder exists under no circumstances should file-roller overwrite it. If the user is trying to extract the file Archive.zip and the Archive already exists on disk, file-roller should create a new directory named Archive 2. If that folder already exists it should progress with the numerical suffix until there is an available path (Archive 3, Archive 4, etc.)

I agree, show a dialog box asking the user what to do. We do the same thing with scripts ("execute" or "view").

Basic rule in GUI design: if a user has to right click to achieve something, you're doing it wrong.
(especially if right clicking gives the user a list of over 10 options... confusing!)

-1, also to the on-open dialogue. I regard this as equally annoying as the "register now" popup of winrar *shudder*
If a user wants to extract the whole menu there is the "extract here" option in context menu (which could be made a little better visible), but extracting stuff by default or plopping up a dialogue every time you open an archive is imo counter productive.

@DarthTibault: hm... are you using a Mac with one-button-mouse? Right button sits in our mouse not only to be symmetric...
Oh, so maybe, when the user double click an image, we should ask if he wants to print it? A MP3 file: "Convert it or just play?" It's so annoying like the dialog "$file is executable text file. Run it or just open?" (It even doesn't work with bash script as I expected.) I think that the user is certain what he wants to do, and if he wants to extract it, he will know where to find that option.

Please, leave it as it is (or at least give an option to turn it off)!

-1

@DarthTibault:
I'm not sure where you are basing you right-click theory on!

@ David Seigel:
This Bug , is a bad implementation... since if i want to edit an archive... this makes it harder. the present behavior is what users are used to in ALL OS...

1] This is a problem for editing archives , i would have to recreate archives , which would be would not be necessary if the archive doesnt extract on double click.

2] And .deb archive types are installers ,

3] some tar.gz files are themes and some are simple archives, how do you decide which is which? you have to make sure that these[.deb / .tar.gz] archives dont extract! So i think it might not be a simple papercut.

4] Several viruses from the windows world are packed in .rar/.zip files . So accidental extracting them without knowing the contents "can" affect the wine files , and might spread in email attachments, so this is kinda HUGE security problem.
Archives as a rule contain files which are hidden to the user, which WE CANNOT access before viewing the archive.

More than NOT being a usability issue, I would say NOT extracting the files is a security feature.

"and two buttons "View contents", "Extract contents". A checkbox should be present as well, above the buttons, reading "Remember my choice"."

In my opinion "Extract contents" should pop up a windows so the user can choose a location to extract to. A button to extract the files in the current directory should be called "Extract contents here".

We are all geeks here, and we all know what's an archive.

My first reaction was please don't do that !

But then I remember my father who does not know what is this strange attachment (archive) attached to his mail.

I understand disagrements but I think that we should try to test this proposition (double-click->extract and open nautilus on it) on Karmic and see users feedbacks. I suggest to add a notification "archive successfully extracted".

For us (geeks), it will be a simple reflex to change, but for "simple" users I think that it will be better.

@Patrice Vetsel: yeah, I suppose my father also don't know what an archive is, but when he double clicks it (in Vista), it opens up showing the _contents_ of archive and not extracting. In my opinion, it's good.

@Patrice Vetsel: I'm not entirely sure about opening a new nautilus window after extraction. This may be annoying. An option should be given to the user to select or deselect this behavior. My aim with this feature is to reduce any needless mouse-clicking when handling archives, therefore I don't support the notification idea. An audible cue should be played though on operation completion.

@Patrick Roberts: The same as what I said above, my goal is to reduce mouse clicking. The faster the user can work with his archived files, the better. The behavior you describe could/should be in effect if there was an option in the context menu that said "Extract contents to...".

@Serious: the "Remember my choice" checkbox would ensure that if you wanted to use the current way of handling archives, you would be bothered only once with the dialog. I agree, displaying that dialog every time is definitely bad.

Ah, and to add to my post from earlier: Extracting an archive on double-click is also not standard-behaviour on any other system I know of, so it's unexpected behaviour and imo if users (esp. the unexperienced ones) get unexpected behaviour they normally freak out completely and set the monitor on fire ;)
Seriously: for me there is nothing worse than unexpected (overreacting) behaviour. Programs should not do stuff based on assumptions about what the user might like. I tell the program what it shall do and it does it, it's that easy.

@Alin Claudiu Radut
Regarding: "I'm not entirely sure about opening a new nautilus window after extraction."
I am just curious: How do you normally use archives?
You say that "The faster the user can work with his archived files, the better.", but what sense does it make to extract an archive and then not be able to do anything with the contents?
I think that a user nearly never really wants to "extract" an archive for extraction's sake. What a user usually wants is to open a file inside the archive (for me, this constitutes about 80%), put the contents of the archive somewhere (which includes extraction, but does not stop there), add a file to the archive etc.

If you want that the archive just gets extracted and you not even want a Nautilus window to pop up afterwards, I am curious what you normally do with archives. Extract them and just leave the content there without ever touching it again?

This is not a personal offense or something at all, I just really would like to understand what your use case is, when you are talking about "working with archives". Because at the moment I do not know what you really want to do with your archives apart from extracting them (which, as said before, IMO almost always is the way rather than the goal).

@danielmewes: No offense taken, rest assured. You are correct, the expression "working with archives" would be better rephrased as "extracting archive contents"

The use case would be the following:
a) I download, receive via email or IM an archive and save it to a location (desktop, Downloads folder, etc)
b) I navigate via Nautilus to it (if needed)
c) double click it/hit enter if I'm relying on the keyboard
d) archive extracts to a new folder with the same name as the original file, bar the extension in the current folder
e) I enter the new folder and do whatever I have to do with the archive contents

I think I judged too quick the new window issue. If I don't save the file somewhere on the disk and double click it in Thunderbird, for example, the file would extract to the system temporary folder, and I would have no way to get to it but to figure out what that folder is. So perhaps, yes, a new window would be needed.

I see a problem with my take on this issue pertaining to opening files when asked by Firefox and/or Thunderbird. I don't find working within the browser's temporary folder very user friendly (or recommended for that matter). I would appreciate some input on this from anyone who is willing to support this issue.

I'm totally against it. it seems more like somebody's pet bug than something useful for the majority of users (including newbies).

When somebody gets an archive, they want so see what's inside or work on it. On both cases, extracting the contents isn't required at all, and would be unexpected. Working inside the archive is better, because else you'd have to manage duplicates with different contents. You'd have to delete a file in the folder, then delete it again in the archive - or delete the archive, then recreate the archive again (provided you're technical enough to have noticed the exact format the archive was in, which is impossible unless you've learn what different archives there are, and their usual extensions.

Then there's the numerous times you need to read some documentation on a tar.gz that's somewhere where you don't have write permissions. You can't extract it in the same repository, so you'd end up having an error message (really bad) or two different "default" behaviours for the same tool (even worse).

The bug reported might have developed a special work flow, but asking everybody to go with it is a bit far-fetched, and the results are not only confusing for non-technical users, they'd introduce new bugs and usability issues.

As for opening a confirmation dialog, it's also going backwards usability-wise (the "Extract to folder" is already easily accessible, and doesn't get used often) and a new source of confusion for users ("What should I choose?") who don't know the difference.

As for the use case:
a) I download, receive via email or IM an archive and save it to a location (desktop, Downloads folder, etc)
b) I navigate via Nautilus to it (if needed)
c) double click it/hit enter if I'm relying on the keyboard
d) archive opens
e) I immediately access the contents of the archive.

Which cover the most frequent use cases, and is simpler (you don't have to delete a folder + the archive when you're finished, or move a folder + an archive, or move an archive and delete a folder, or re-create the archive (if your "solution" would be to automatically delete the archive after extraction) when you want to forward it to somebody else ,or send it back with your changes in it.

The method used now is simpler, less confusing and doesn't introduce hard to fix bugs.

@Loïc Martin: If you mean opening an archive like a folder in Nautilus, but without extracting it, I'll vote for it. Maybe some kind of notice, like this one already implemented "This volume (drive?) includes photos. [button]Open F-Spot[/button]"?

"This is an archive. All changes here will be saved as $filename_of_archive [button]Extract these files[/button]"

Am I clear? What do you think about this?

When I first started using Mac OS X many years ago, I was uncomfortable with the way that archives were handled. However, that discomfort did not last long. In OS X, double clicking on an archive causes it to be extracted to a folder of the same name as the archive, in the same directory as the archive. Creating an archive is as simple as right clicking a folder or group of files, and clicking Compress. Having used Windows, OS X, and Linux for many years, I can honestly say that the Mac way of working with archives is the most productive and quickest for me.

As a developer, I consider myself to be a fairly advanced computer user. That being said, I have NEVER found myself in a situation where I have left the need to manage the contents of an archive without actually extracting it. For most users, a program like FileRoller is overkill, and is better left as an optional install.

If Ubuntu provided a simple tool (like OS X's Archive Utility) that would extract the archive contents upon double clicking the archive, and a contextual menu item to create an archive out of a folder or group of files, this would cover 95% of common use cases. In order to perform more advanced tasks, such as to change the content of the archive, one would merely have to double click on it, perform the file management tasks, and then rearchive it. There are situations where this would not be an efficient method, such as for very large archives, but these situations are very unlikely to arise for the vast majority of users.

For more advanced tasks and more advanced users, FileRoller would still be available in the repositories, and could be added with just one invocation of apt-get.

Correction: *felt the need

To be honest, I don't see the need to change the behaviour of file-roller/nautilus.

In the end, it comes down to each user's individual user preferences, and what he/she does with archives immediately after downloading.

Here are my specific user cases:
1. Installing a piece of software - usually involves the command line, and thus "tar" is invoked in the command line, bypassing this issue altogether.
2. Looking at individual files in an archive, as in the case of manuals and/or picture collections

Specifically, there have been times when blindly extracting into a subfolder is not ideal, either due to permissions problems, or the general lack of a need to. If I'm just going to look at one file in an archive, I don't need the rest of the support files, especially if they're readme files or other superfluous files.

The best use, in my opinion, is the one that's already in place. File-roller decompresses the archive in its viewing mode, but doesn't extract the files anywhere, saving on unnecessary hard/flash drive wear and tear. If need be, file-roller also functions excellently as a drag-and-drop client, allowing you to open a destination folder in another window (or the same nautilus session, if you so wish), and extract the file there directly.

If I double-clicked on an archive and had the entire archive dumped into a subfolder, I'd have to clean up everything that remains once I'm done with the contents. Why should I, when I could have avoided this "mess" (and I use that term conservatively) in the first place?

Specific user-cases also apply which this solution cannot account for:
1. What if the user double-clicks an archive which can be read, but its parent folder cannot be written to?
2. What if the user is using the archive as a form of compressed storage, opens the files within on the fly, and does not require the contents to be extracted? This would present an extra menu to access, when traditionally, there would be none.
3. As previously mentioned, what if the archive is several gigabytes in size?

You may be considering adding a conditional... perhaps "default to file-roller when archive > 1GB". This is a terribly inelegant solution, and just adds another layer of complexity to an otherwise simple program.

File-roller appeals to the lowest common denominator - by just showing you the files, and essentially saying "what do you want me to do with them?"

Let's not change a thing.

First of all, thanks SY for supporting my case.

On Thu, Jun 25, 2009 at 6:51 AM, Julian Lam <email address hidden> wrote:

> Specific user-cases also apply which this solution cannot account for:
> 1. What if the user double-clicks an archive which can be read, but its
> parent folder cannot be written to?

The solution would be to display the "Extract archive to..." dialog.
Displaying a "Cannot write to directory" message does not help the user the
least.

2. What if the user is using the archive as a form of compressed storage,
> opens the files within on the fly, and does not require the contents to be
> extracted? This would present an extra menu to access, when traditionally,
> there would be none.

I find this more of a corner case. The changes I suggest to file-roller
behavior need to be user-tested, and draw conclusions only afterward. My
theory is that users rarely do this. If a lot more users want to extract the
archive with photos they received from a buddy, without editing or
selectively accessing the archive it makes some sense to consider them as
well, especially if they account for a larger % of the userbase,

>
> 3. As previously mentioned, what if the archive is several gigabytes in
> size?
>

> You may be considering adding a conditional... perhaps "default to file-
> roller when archive > 1GB". This is a terribly inelegant solution, and
> just adds another layer of complexity to an otherwise simple program.

Why would you add such a conditional? The user can cancel the process at any
time if he figures that it takes too much time. If he wants to extract an
archive a gig in size, let him.

Let's not change a thing.

I kind of understand this resilience to change, but please let's just
user-test this and see where it takes us.

> In order to perform more advanced tasks, such as to change the content of the
> archive, one would merely have to double click on it, perform the file management tasks, and
> then rearchive it.
It's not "merely", it's actually a pretty complicated and resource intensive task, whereas right clicking on the archive for the few times where you really need it to be extracted is simple and doesn't hog resources like needlessly decompressing and re-compressing a file each time you want to check or read its contents. Detecting and remembering the compression method used for an archive (including the options used, which isn't trivial) is not an easy task, and I fail to see how people new to computers will deal with that.

> There are situations where this would not be an efficient method, such as for very
> large archives, but these situations are very unlikely to arise for the vast majority of users.
Who are you to decide what is "likely" to arise to the vast majority of users? If you can't find compeling arguments to justify the many problems this behaviour is going to cause, please don't resort to extrapolating your own preferences and deciding "most people" have the same use case you have.

> I kind of understand this resilience to change, but please let's just
> user-test this and see where it takes us.

Please don't dismiss the concerns of everybody in this thread as if they just need to "try it". We already try it everyday we deal with archives - and I can tell you, the amount of times I need the archive to be extracted in a folder and the original archive destroyed represents 1/10 of the times I deal with archives. The rest of the times, either I need to check 10 other archives first to find the one I need to decompress, or I just need to read one (or a few files) file inside the archive.

>> 1. What if the user double-clicks an archive which can be read, but its
>> parent folder cannot be written to?
>
> The solution would be to display the "Extract archive to..." dialog.
> Displaying a "Cannot write to directory" message does not help the user the
> least.

Nope, it's confusing and introduces an useless overhead - why would we ask users to decide a good directory to uncompress the archive (they would also need to check there's enough free space, and check how much space the data would hold _uncompressed_) when they can just double click on it and access its contents?

The method of decompressing any archives before you can see what's inside, access it and work on it sounds more like a bad understanding of what you can do with archives. You can access, view, work with and archive content and modify it _without_ having to decompress it to a folder.

>>2. What if the user is using the archive as a form of compressed storage,
>> opens the files within on the fly, and does not require the contents to be
>> extracted? This would present an extra menu to access, when traditionally,
>> there would be none.
>
>I find this more of a corner case. The changes I suggest to file-roller
>behavior need to be user-tested, and draw conclusions only afterward. My
>theory is that users rarely do this.
Our experience, combined with what we see users do, poin...

@roffik:
>If you mean opening an archive like a folder in Nautilus, but without
> extracting it, I'll vote for it.
That behavior has been implemented in some file managers for about as long as there are file managers. Nautilus doesn't do that by default, it shouldn't be difficult to add it, but that could be a conscious decision from the Gnome team (less confusing? in which case extracting the contents of the archive and deleting the archive would be even more confusing...).

You can already work without extracting the archive first with the default behavior - double click on an archive, it opens a window showing the contents of the archive, and you can work inside the archive as you'd do inside a folder already. The behavior could be improved (some file managers do that better than the default Gnome), but adding the overhead and problems that comes when defaulting to extracting the archive contents _before_ you can access them seems like trying to fix the wrong quirks.

@Loïc Martin: my impression is that you are not even trying to see my point of view in this issue. I have been using archives as well since the DOS era and it turned out I enjoy this way of handling archived files better, but everyone's mileage may vary.

I submitted the idea, documented the process as well as I could, drew some conclusions from my and my coworkers' experience, as far as I am concerned my job here is done. It is up to the developers or whoever owns the hundred papercuts issues to decide whether this workflow merits attention or not.

If more details regarding my take on this issue are required I will happily provide them.

@Loïc Martin: Maybe you're right - I've never tried to work with an archive like with a folder, just thought it'd be useful...

All right, maybe some sort of summary?

Solution #1: Double click on an archive to decompress it
Solution #2: Leave it as it is
Solution #3: Integrate file-roller with Nautilus to be easier for users to navigate inside an archive
Solution #4: Opening an archive in file-roller would uncompress its contents in background in /tmp to fasten the process of decompression, if user will decide to
Solution #5: Double click an archive should show a popup: "Open an archive or exctract the files?"

I vote for #2.
(Why on earth this is not disscused on Brainstorm!?)

I want to warn of Solution #4. Extracting an archive, especially big ones (some GB) totally brings my diskI/O down, I can hardly use my PC at this time. If there is no way to open the archive without decompressing, they'd be nearly unusabe.
Still, my voice goes to Solution #2. Extracting via right-click is just one click more, for doubleclick systems it's even the same amount.

My voice also goes to Solution #2. Solution #5 would be second choice (but it has to have an option to remember the my choice and there have to be the choices "Open archive", "Extract here" and "Extract to...").

I have to say that the current behavior is in line with how every other archiving program I've ever seen handles things. I've never seen an archived be decompressed by simply double clicking it in any OS.

To add my 2 cents, I'm against the feature, using the following logic:

Users either know what an archive file is or do not.

If they do, they realize it's a file that you open to view the contents of an archive. If it auto-extracts, they'll be surprised and (I at least would be) annoyed.

If they don't, then what they see is a file named xyz.zip, and when they double click on it their computer starts humming and everything slows down, and a mysterious folder named xyz/ shows up. If they know that the contents of xyz/ are the contents of xyz.zip, then they fall into the category of "know what an archive file is." If they don't, then they'll be surprised and probably confused.
Furthermore, what if they don't immediately realize what happened, and 'open' it twice? Some sort of "overwrite existing directory?" dialog would have to come up, and the user in question is left in the dark as to which directory, why it's being overwritten, and what all this has to do with opening a the file xyz.zip.

The root of this bug seems to be that archives are confusing, and not that Ubuntu handles them poorly. If we change something, I'd recommend something like a first time dialog in file roller in the flavor of "What is an archive file?" Or else make the archive file interface and the Nautilus interface similar/the same.

(incidentally I'm ignoring implementation issues like what to do with *.jar files, or on my computer *.exe files seem to default to opening with archive manager. Plus what if the user lacks write permissions in the folder? Double click on the archive and get an "Extraction Failed: Permission Denied" error? Then the user is spared from knowing what an archive is, at the expense of having to know what file permissions are. This is particularly applicable to downloaded archives stored in /tmp, or archives from another's home folder)

Anyways, that's my opinion on the issue. Giving opinions is always easy...

I'd also like to offer my 2 cents.

Automatically extracting the contents of archives when double-clicking on an archive seems like a really, really bad idea, and completely ignores the purpose of file-roller as an archive management tool.

This change is *not* going to improve the user experience, it's only going to annoy a lot of people. Even Windows has the foresight not to extract archives automatically (archives are opened within the interface of Windows Explorer as though they are regular folder, but if you click on an executable within an archive, it displays a prompt suggesting that the entire archive may need to be extracted for the executable to work correctly).

An archive is not a folder, and if we wish to re-invent the concept of an archives, then we should implement some kind of FUSE layer in which an archive can be "mounted" into a special folder and modified like a folder on a normal filesystem.

-1

I *frequently* download archives, inspect their contents, and either extract only a few files or delete the entire thing. Automatically extracting them is the wrong choice. If you feel file-roller needs work to be more usable, then let's improve that interface, not change the paradigm for how the desktop works. I can't think of any program that works on the idea of "you double clicked a file, so we'll get rid of the original, replace it with something similar, but not the same, and then open that".

If you really want this behavior, you can change you file association for archives from "file-roller" to "file-roller --extract-here", but don't break it for others.

I feel that due to the contention on this change, it should not be included in paper-cuts. Paper-cuts should be about bugs/issues that everyone can agree on, not feature requests.

Many people are suggesting to take the Windows explorer approach where the archives are opened like folders. In fact, this feature is in ubuntu right now. You can right click on an archive and select "Open with Archive Mounter" which mounts it like a disk drive. This is probably the best way for novices (as they can interact with the files just like a normal folder), so we should set that as default. However, advanced users could set the default action to be to open with the Archive Manager (file-roller).

Automatically unpacking an archive on doubleclick doesn't fit with how other things work in ubuntu, so such a change would be unexpected for users.

The Archive Mounter is a much better idea than auto-extracting, but is it ready for widespread use? Choosing "Open with Archive Mounter" with an archive does not change the current directory in Nautilus, and if you blinked, you would have missed the archive being "mounted" as a drive in the Places sidebar.

Automatically changing the directory to the mounted archive would make this a lot more user-friendly, but the idea of "mounting" and "unmounting" archives still seems quite strange (and would confuse new users, I think).

I dont know why we have to reinvent the wheel !

The problem is that the archive is presented as a list view in the archive manager. Which would surprise the average user. Other than that AFAIK there is no element of surprise for the users!

Instead of auto-opening the archives ,
1: *just make the archive manager display the files in the nautilus window* (this probably needs an archive-manager nautilus plugin) [or]
2: *make the archive manager display files in icon view* . [or]
3: If the average user is not understanding what an archive is ,then it is better to present with a dialogue window explaining that this file is an archive.[in as little words as possible] containing unknown files, Do you want to "Extract" or "Just view it". With an option , "Dont ask again,Do this for all archives".
These are non-papercut solutions ,

     But they are better solutions than auto-opening archives because:
1: Can overwrite files [as already pointed out]
2: Content of the archives are not know to the user[users do download unknown archives from the internet] , so unless they are sure of the files, *it should not self extract* . This is behavior would be a security risk.
3: Not everyone needs all the files of the archive, if this is a large compressed archive , then while extracting all the files the user has unnecessary write operations ! leading to poor system response during such operations ! and then we will have complaints of poor performance !

*If the average user is not understanding what an archive is* , that is the only problem! > they didnt understand it,
*So we need to think in terms of better ways of explaining it to them* . we only have to present it better.
We need to teach them to fish , Not spoon feed the cooked fish!
Just because it is a little hassle for some users, such auto-extract/auto-open behavior should not be encouraged.

"I feel that due to the contention on this change, it should not be included in paper-cuts. Paper-cuts should be about bugs/issues that everyone can agree on, not feature requests."

True.

"make the archive manager display files in icon view"

No, please don't do this. I hate icon view. First thing I do after installing an operating system is switching from icon view to list view.

Icon view is not optimal for archives. Remember that many document types are thumbnailed (such as PDF and videos). If we are going to treat archives as regular folders in Nautilus, it would mean that files would have to be extracted (so the thumbnails can be generated) when you merely browse the archive contents.

While the varying opinions on how to change archive management on Ubuntu are worth discussing, the solutions proposed here seem too complicated to be treated as paper cuts.

I also agree, this is much too much based on individual user preference. I personally like to only view archives when I double click on them, I will right click to extra them... Perhaps in the future, there should be a small expand button near the archive that will allow users to extract with a single click for convenience much like how removable devices have a quick eject feature in Places?

There's another point that should be considered:

If the archive is exctracted on double-click into a new folder and the new folder is opened with nautilus some users might allways double-click the archive to get to the files again. In result, there are a lot of folders with the same content, but named "archivename1", "archivename2" etc. Because the user thinks that he has to double-click the archive file in order to get to the files.

I think the whole archive thing is a problem to new unexperienced users. Maybe, the first time file-roller is opened, there could open a window with some explanations about archives.

I think the fact, that there is a new folder, when the archive is double-clicked would only confuse the user.

There have been over 50 comments so far, with an array of ideas, suggestions and worries.

I have taken the liberty of creating a wiki page where ideas can be fleshed out and worries answered. I have added a few basic issues that can be found in the current way of doing things, but feel free to add your own.

At the bottom of the wiki is a template you should use for your ideas - taken from Steve Dodier.

Please move your discussion to https://wiki.ubuntu.com/OpeningArchiveIssues, thanks!

=== Extract on double click without prompt

We are used to the usual file compressor technique, right click the selecting "extract" or double click, open the manager then click the extract button.

Reasons why we shouldn't change this
1. Every file compressors work like this, including WinRAR, WinZip, 7Zip and file roller.
2. By opening the archive manager, you get more extracting options than the usual technique of right click then select "extract"
3. What if someone accidentally double clicked the archive?

So in a minor case, people switching from Windows or migrating to Ubuntu could be confused when something happens on Windows but something entirely different happens on Ubuntu. In conclusion, I think we should just leave it the way it is.

=== OR... Extract on double click with prompt

What we could do is when a user double clicks the archive, a dialogue comes up prompting user to either view its contents or extract...now that would be useful!

How is adding a prompt useful? All that is doing is making the right-click context options ("Open with Archive Manager" & "Extract Here") redundant. This will also annoy users who expect the normal behaviour to occur immediately, which is to open the archive with an archive manager.

This has been debated to death already. I believe the concensus (with a
small minority of dissenters) is to keep the functionality unchanged.

This bug should be closed as invalid, since it's definitely not a paper cut,
since it's not even a UI bug, but a functionality change wish.

On Wed, Jul 15, 2009 at 10:27 PM, Conn <email address hidden> wrote:

> How is adding a prompt useful? All that is doing is making the right-
> click context options ("Open with Archive Manager" & "Extract Here")
> redundant. This will also annoy users who expect the normal behaviour to
> occur immediately, which is to open the archive with an archive manager.
>
> --
> Have the file-roller automatically extract an archive on double click
> https://bugs.launchpad.net/bugs/389176
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The FileRoller Archive Manager: New
> Status in One Hundred Paper Cuts: Confirmed
> Status in Nautilus: New
>
> Bug description:
> More often than not, when a user double clicks an archive will then proceed
> to extract all the files from it. The file-roller application should
> automatically extract the file contents to the current directory. A new
> directory with the archive's filename should be created as well, for example
> double clicking "documents_and_images.zip" would extract the archive
> contents to "./documents_and_images/"
>
> If the user wants to selectively extract files from the archive he should
> be let to do so by right clicking the archive and choosing "Open with
> Archive Manager...".
>

--
Julian Lam
(416) 843-4323
http://www.kareeser.com

Julian, can you please point us to where this has been debated in the past by posting a link or other resources on the wiki page: https://wiki.ubuntu.com/OpeningArchiveIssues

We can "debate" all we want, or we can user test this. Would you object if we test this with users, as I suggested? What if testing shows a different conclusion than what has been reached by developers?

Keep in mind that File Roller represents an entirely new interface for users to learn. My mother and grandmother, for example, cannot figure out how to extract compressed files in Ubuntu because File Roller is (1) an unfamiliar interface and (2) expresses an unfamiliar concept of looking "inside" a compressed file without extracting it.

David,

According to the guidelines, "if you are reading this wiki, or reporting a paper cut on Launchpad, chances are that you are not the average user". This /does not/ mean that our insights are invalid, or that we are incapable of putting ourselves in the shoes of average users.

* Changing the default action of opening an archive /will/ confuse your mother and grandmother, if they have ever used, or ever will use, another operating system on the planet. *

Is it fair for Ubuntu to change an industry standard like this so easily?

By all means let's test this, but are you going to listen to feedback from users (average or not), or have you already made the decision? By what criteria will you accept or reject this proposal? The comments are already negative in a healthy majority. Even though the people who have commented aren't "average users", who else can represent the average user on a Launchpad bug report?

P.S. Anticipating user testing, the first usability bug:

Since most archives are downloaded from the internet, and Firefox's download window cannot perform Nautilus contextual actions, you'll be forcing this action of extracting files upon all users.

If a user wants to /open/ a downloaded archive, they need to:
-right-click on the download entry in Firefox;
-click on "Open containing folder"
-manually navigate to the file (as Nautilus doesn't highlight the file similar to the behaviour in Windows);
-right-click on the archive once more;
-click on "Open with Archive Manager".

That's four mouse clicks /plus/ whatever clicks were necessary to locate and navigate to the file in Nautilus. Just to /open/ the archive.

David,

Do you really believe that your mother or grandmother couldn't figure out how to extract files when there is a colourful button named "Extract" on the main interface? More likely your mother and grandmother won't even know that they need to extract files from an archive, or what an archive really is in distinction to a simple picture or a text file.

From this paper cut it seems that you want to completely circumvent average users from knowing what an archive is or does. Is that really a good idea? You needed to teach your mother and grandmother about the concept of a mouse and its relation to the cursor on the screen, and how to interact with icons, for example. Why do you want to skip the 5 minute explanation of an archive to them?

I completely agree with everything Conn and Julian Lam said.

Conn,

Yes, we plan to user test this (this is the third time I have said so).

I don't merely believe that my mother and grandmother couldn't figure out how to extract files, I know they cannot because I've tested it. My mother and grandmother use Mac OS, where this is the default behavior. You're right, my grandmother did not understand the idea of an archive, but people have been sending them to her for years, and she has managed to extract them successfully and get at the files inside them all along. On Ubuntu, she utterly failed to extract the archive, as did my mother. So, is Ubuntu "Linux for Human Beings (but not for mothers)"?

Yes, Ubuntu will break "industry standards" when we've found a better solution. Adhering to "industry standards" despite potentially better solutions is a great way to inherit historical flaws and forfeit the opportunity to be excellent.

Of course feedback on this bug is valid user data, but it is very hard to make decisions with all users in mind using information provided by the most sophisticated and often forgiving users, which you represent.

David Siegel wrote:
> Keep in mind that File Roller represents an entirely new interface for
> users to learn. My mother and grandmother, for example, cannot figure
> out how to extract compressed files in Ubuntu because File Roller is (1)
> an unfamiliar interface and (2) expresses an unfamiliar concept of
> looking "inside" a compressed file without extracting it.

Thing is, they don't have to use the file File Roller interface to
extract archives. They only do because they've been taught to only use
one mouse button, and that's not what the majority of users are taught.
The majority of users would use the right mouse button, and if your
mother and grandmother hadn't been badly taught by Mac OS, they'd have
seen the "Extract" menu when right clicking on the archive.

> Yes, we plan to user test this (this is the third time I have said so).

What do you mean by "user test this"? If you plan to change the default
behavior on Ubuntu, and call that a "user-test", that's just as empty a
promise as what was offered when the new behaviour to notify updates was
proposed for Jaunty. So far, none of the people that vouched for it came
with any data to show it lead to people installing updates more often,
and in my experience it's quite the contrary (the update manager windows
always open in the wrong virtual screen, or behind applications, and the
inexperienced users I see end up not installing even security updates,
since they don't have the icon that tell them they should install updates.

If you do that, don't call it user testing. You'd modify Ubuntu to
behave the way it works for you and the few users you know, while
ignoring what others tell you, even when they're also inexperienced users.

> I don't merely believe that my mother and grandmother couldn't figure
> out how to extract files, I know they cannot because I've tested it. My
> mother and grandmother use Mac OS, where this is the default behavior.
> You're right, my grandmother did not understand the idea of an archive,
> but people have been sending them to her for years, and she has managed
> to extract them successfully and get at the files inside them all along.
> On Ubuntu, she utterly failed to extract the archive, as did my mother.
> So, is Ubuntu "Linux for Human Beings (but not for mothers)"?

Your mother and grandmother are hardly the kind of "inexperienced users"
you should take as a reference. They've been conditioned by Mac OS
  to expect a certain behavior, and also to ignore the right button. If
Mac OS users represented 90% of the userbase, that would be a valid
input, but they don't. People that aren't experienced with computers
(and especially not Mac OS) don't mind using the right mouse button,
quite the contrary, since that's one of the first things they learn -
right button is safe, left button can lead to unpredictable results.

> Yes, Ubuntu will break "industry standards" when we've found a better
> solution. Adhering to "industry standards" despite potentially better
> solutions is a great way to inherit historical flaws and forfeit the
> opportunity to be excellent.
>
> Of course feedback on this bug is valid user data, but it is very hard
...

"The majority of users would use right-click." I don't disbelieve you,
but do you have data that shows this? What about on netbooks? What
about users of Ubuntu on Apple hardware (ignoring them because they
are a minority is not prudent).

Please stay on topic. If you'd like to discuss update manager changes,
seek those discussions in their apprpriate places. If you'd like to
accuse me of lying about user testing, please email me directly, or
contact my boss (~ivanka).

On July 22, 2009, at 5:01, Loïc Martin <email address hidden> wrote:

> David Siegel wrote:
>> Keep in mind that File Roller represents an entirely new interface
>> for
>> users to learn. My mother and grandmother, for example, cannot figure
>> out how to extract compressed files in Ubuntu because File Roller
>> is (1)
>> an unfamiliar interface and (2) expresses an unfamiliar concept of
>> looking "inside" a compressed file without extracting it.
>
> Thing is, they don't have to use the file File Roller interface to
> extract archives. They only do because they've been taught to only use
> one mouse button, and that's not what the majority of users are
> taught.
> The majority of users would use the right mouse button, and if your
> mother and grandmother hadn't been badly taught by Mac OS, they'd have
> seen the "Extract" menu when right clicking on the archive.
>
>> Yes, we plan to user test this (this is the third time I have said
> so).
>
> What do you mean by "user test this"? If you plan to change the
> default
> behavior on Ubuntu, and call that a "user-test", that's just as
> empty a
> promise as what was offered when the new behaviour to notify updates
> was
> proposed for Jaunty. So far, none of the people that vouched for it
> came
> with any data to show it lead to people installing updates more often,
> and in my experience it's quite the contrary (the update manager
> windows
> always open in the wrong virtual screen, or behind applications, and
> the
> inexperienced users I see end up not installing even security updates,
> since they don't have the icon that tell them they should install
> updates.
>
> If you do that, don't call it user testing. You'd modify Ubuntu to
> behave the way it works for you and the few users you know, while
> ignoring what others tell you, even when they're also inexperienced
> users.
>
>> I don't merely believe that my mother and grandmother couldn't figure
>> out how to extract files, I know they cannot because I've tested
>> it. My
>> mother and grandmother use Mac OS, where this is the default
>> behavior.
>> You're right, my grandmother did not understand the idea of an
>> archive,
>> but people have been sending them to her for years, and she has
>> managed
>> to extract them successfully and get at the files inside them all
>> along.
>> On Ubuntu, she utterly failed to extract the archive, as did my
>> mother.
>> So, is Ubuntu "Linux for Human Beings (but not for mothers)"?
>
> Your mother and grandmother are hardly the kind of "inexperienced
> users"
> you should take as a reference. They've been conditioned by Mac OS
> to expect a certain behavior, and also to ignore the rig...

David Siegel wrote:
> "The majority of users would use right-click." I don't disbelieve you,
> but do you have data that shows this?

More data than your mother and grandmother at least, but still you
considered the foster valid enough for the discussion. As for
right-click, yes, people that spend more than a few minutes in front of
a computer learn really fast to right-click when they're not sure what
the action is going to be. Mind you, my classes amount to a few hundred
students over the years. And yes, they have to deal with archive, since
that's how they get the matters for the lessons.

  What about on netbooks? What
> about users of Ubuntu on Apple hardware (ignoring them because they
> are a minority is not prudent).

What about users with no mouse (ignoring them because they are a
minority is not prudent)?

The whole Gnome desktop uses the right click button, ignoring this fact
because it doesn't go along with the behavior one would personally
prefer won't change that. Please seek a desktop environment that only
make use of a single mouse button, or try changing that upstream with
Gnome (but that would be a huge undertaking).

> Please stay on topic. If you'd like to discuss update manager changes,
> seek those discussions in their apprpriate places. If you'd like to
> accuse me of lying about user testing, please email me directly, or
> contact my boss (~ivanka).

You don't answer my concerns. And you're the one that put the word
"lying" in the discussion. Getting on your high horse won't bring much
more to the discussion than what you've brought this far. And I don't
see why I'd care to speak to you boss, your dad, or whoever else, I
wasn't planning to asking you to a prom.

Changing the default behavior of Ubuntu for the sake of "testing"
doesn't hold up at all. You test _before_ you propose a change, and you
submit data _before_ advocating for that change. So far, we haven't seen
any, and have to come with our own data, which shows the behavior you're
advocating is harmful at best.

On the other hand, you don't respond to any of the points in my post,
nor did you to any of the post pointing the problems that behavior is
going to cause. Asking us to "test it", then, when we do it, labeling
the feedback you don't like as coming from experienced users doesn't
sound right.

Folks,

Let's keep this civil (or at least make an effort not to mis-interpret constructive arguments from... plain arguments).

The discussion of this proposal needs to continue on the ubuntu-devel-discuss mailing list - not here.

From: https://help.ubuntu.com/community/ReportingBugs#When%20not%20to%20file%20a%20bug

"Feature and policy discussions (including suggestions to change defaults) should be discussed on the ubuntu-devel-discuss mailing list."

These discussions sometimes turn into heated arguments, with many people claiming that their data supports their view and refutes the views they do not agree with. I am not ignoring the feedback on this bug, I just said that it's hard to draw conclusions from it and that it would be more fruitful to test (I just tested two subjects) than to argue here. The information you are providing is incredibly useful -- thank you -- but it is not enough to decide the issue, just as my experience with my mother and grandmother is not enough.

Perhaps adding a design suggestion (hypothesis) to the bug description before user testing was a misstep. I am sorry that it frustrated you so much, but I am glad that it provoked a discussion. I hope it's a consolation that I do not have the authority to make this decision on my own, and user testing -- which we conduct in London every Tuesday -- will help guard against whatever bias I have.

Ivanka manages the design team and is in charge of user testing, I am sorry that I did not make that clear. Please contact her if you have suggestions for how our user testing could be improved.

This change is controversial, so it cannot be considered a paper cut.

Gentlemen,

This bug as been marked invalid as a paper cut. Paper cuts are meant to be quick and easy to fix and certainly shouldn't be provoking any controversy.

In order to agree a solution that even less technical Ubuntu users can enjoy I suggest that we conduct a more formal research study. I have initiated the project here: https://edge.launchpad.net/archive-behavior-research

We will aim to crowd-source some of the data and you are all welcome to contribute.

Kind regards,

Ivanka

@Ivanka:Thank you.

Not to add to the comments here, but *1 thing that seems to have been overlooked* .

At present , we use different icon for archives, separate from folders.
So, *if the default archive behavior is going to be similar to folders , the archive icons shouldnt be different* .
Then archives should use Folder icon with emblems or something of the like , to indicate they are going to behave similar to folders..

PS: @ All Folks, Pls dont comment to refute or support what i have said, Its just something that I wanted to add, for the UX team's future considerations.

After reading the informal user test this are my suggestions:

1) Double clicking could open the "Extracting files from X" dialog with the progress bar. The underlaying tech needs fixes so what we get a smooth and relevant progress bar, not like the one that is implemented now that jumps to 50% and then jumps in increments to completion.
Upon completion of the extraction we should open the Nautilus window with the extracted content. To stop people from trying to extract the archive multiple times the dialog should get the focus and the archive should lose it.

2) The "fancy" way:
On double click open a Nautilus window and use the "strip" (the one that apears in the Trash/UbuntuOne folder) to display the information as such:

Extracting X | Progress [#######_______]

The user can see the root folder (of the extracting archive) populate with content from the archive (since I'm guessing that it's being read sequentially). That way the user can see that there is something happening and can interact with the files that have been extracted while being informed that there are still things being extracted.

Problem cases are archive's with one file. How do we display that in #2 suggestion? Perhaps dim the icon and select and focus on it once it's done extracting?
The other problem are huge archive's that can bring any machine to it's knees. I'm guessing that for most users it's not a problem since the archive are usually small. Perhaps open Archive Manager if the archive is over 500-1000MB's and has multiple files? But that breaks both of my suggestions since the user is expecting to see either #1 or #2.

Suggestions?

Does anyone here remember ZipMagic on Windows 98?

It did something far more revolutionary than what we're still doing at the moment. It had an override on the File System, and you could navigate and use the contents of the zip file however you liked... without actually extracting it. It's major flaw was that it was a buggy buggy program, and I realize it's out of scope for the hundred cuts (indeed if some company out there doesn't have a patent on it) :( but is it worth a look?

In terms of what everyone else is doing here, I'd worry about double-click zip especially if a user encounters an (zip|archive|decompression) bomb.

Ref: http://en.wikipedia.org/wiki/Zip_bomb

I have to disagree with auto-magically extracting archive contents like this.

As has been pointed out several times, there's already a context menu item for this that works very well (including creating a folder to contain the archive contents if necessary). It's already very quick and easy to use and follows a common pattern of opening the context menu to perform file-specific actions.

I would very much dislike archives being extracted when I double-click them. Displaying a dialog seems better, but that would get awfully annoying. Now if I want to simply see what's in an archive, I have to use the context menu? I find this very counterintuitive and inconsistent. As it is now, double-clicking the archive displays its contents, just like double-clicking a folder displays that folder's contents.

I have wondered if it's possible to integrate File Roller with Nautilus so that archives can optionally be displayed within Nautilus. I like File Roller, but the only part of the dealing with archives that feels a bit off is that I can't simply browse the contents of an archive with Nautilus.

I'm not familiar with ZipMagic, but it would be interesting if some faux file system could be created to allow archives to be used without actually having to extract the contents.

To large for read all the comment's, but, disagree completly with this "idea"...

So, if i have a 600 MB zip, and no space in the FS?
and if i'm doing a "calculation" (or something that use a lot of cpu) and just want to see an compressed file?

in the best case, allow to browse compressed files as if they were folders. If I remember correctly, windows xp offered this feature for zip files...

Switching the default action to Archive Mounter seems superior to extraction:
- Doesn't modify your hard disk - no danger, no problem if low free space.
- Fully familiar nautilus interface!
- Behaves as real file system, e.g. you can move between images in EOG.

Summary of work needed before adopting it (also documenting on the wiki):

- Testing and discussion! It's also a radical interface change.
- Bug #296585: the archive is mounted but nautilus window is not opened.
  Until it's fixed, it's unusable as default action. There is a proposed simple fix.
- There has been concerns that only gnome apps can open files inside a mounted archive.
  This is AFAIK not a problem, as nowdays they are FUSE-mounted under ~/.gvfs/, which is the path passed to apps.
- It's too transparent: the archive is mounted read-only, and no clear indication for being an archive is given.
  A yellow bar with explanation and buttons ([Extract], [Open in Archive Manager] ?) would be nice.

@Beni

sounds like a good idea to me.

Putting this discussion back on the table; even if "extract here on open" is not the best solution, our current default archive behavior is /very/ confusing to casual users, and we should improve it if possible for Lucid.

Please, not "+1" or "-1" comments unless you feel your comment adds something new to the discussion.

Should existing content from https://wiki.ubuntu.com/OpeningArchiveIssues be migrated content into the new Spec page?

I think it would be better to not show file-roller at all but show nautilus when a user double clicks archive with a status button on top saying "Click here to extract files to $ARCHIVE"

in this way users can add/edit/view the files inside as if it was just files.

I think it is best to create a new folder with same name as of archive and decompress the data into that folder on double clicking the archive . Reasons for this :

1.It makes exploring the archive files easier (and more familiar) because now user can access files from within nautilus only.
2.Many times , user wants to view and may be edit the documents inside the archive . If he makes any changes to the file in the archive and saves it , he needs to accept 2 popups for this , one for the file itself and other for the archive manager (whether or not he wants to update the archive) . This behavior may be annoying .

Also a better thing would be to focus the newly created folder after decompression is finished.

Beni Cherniavsky: thanks, would you migrate the "Use Archive Mounter" solution to https://wiki.ubuntu.com/OneHundredPaperCuts/Spec/389176#Solution%20C:%20Display%20archive%20contents%20in%20Nautilus%20using%20Archive%20Mounter

Archive Mounter is the best solution. It should be more visible.

Automatic file unpacking is *not* what I would expect, and I will file a bug if you make this the default action.

1. If I want a loaded gun, I'll load it myself ... thank you, very much. This can be "dangerous" (read as PITA), especially to someone who is trying to make space on a crowded drive by inspecting archives (to see if they can be deleted).

2. It also a pain to cleanup if all I wanted to was look at the file list, or even the files (file-roller implements open on contained files).

3. I think a much better paradigm (if you'll pardon the antiquated term) would be to implement expanding the archive as if it were a subdirectory (directly in Nautilus).

4. I *like* the "extract here" in the right-click menu! I'd would like to see an "extract to $ARCHIVE directory ..." (with implied creation of that directory, of course) option added to that list.

I agree that Archive Mounter is the best solution. However, it should not add the archive as a mount point in the places pane as it does now; it should just open it. The path in the address bar should show something like this, instead of the current unintelligible junk:

/home/tweenk/some/folder/archive.zip/some/archive/subfolder

I agree with the Archive Mounter, as long as the restrictions on it will be clear, and as long as it's clear that it's an archive.
Actually, I was looking for this solution myself, and I'm glad I found it here.

Still needs design

There is a nautilus bug upstream regarding this at: https://bugzilla.gnome.org/show_bug.cgi?id=628221

I agree that Archive mounter would be the best solution, even if it only works for reading only. It could be patched to work for writing too, or provide user-friendly error messages in case of a write error, for letting the user know that he has to do something else to modify the archive. The most common use-case is extracting anyway (at least for me).

Alin Claudiu Radut, it would probably be a good idea to register a blueprint for this suggestion and link it here (https://blueprints.launchpad.net/hundredpapercuts/+addspec)

Closing this, as this is not really a papercut task. We dont have a design plan. And there is no simple, accepted fix yet.
Don't worry though, this bug has been closed only in the papercuts project. The other tasks are still open.

@Chris Wilson: No, we dont use blueprints for papercuts project.