My project continues with support for internal compression in Nautilus. The operation comes with integrated progress feedback and support for undoing and redoing. Also, the new archive will be automatically selected once the operation is complete. The feature is available from the context menu, where the menu item from file-roller’s extension would normally be:
Since this operation is functionally similar to “New Folder with Selection”, we chose to make the UI for it similar as well. However, we ran into a little issue as we could not decide how to offer compression format options. These are the ideas we came with:
Combobox / List of all available formats
Radio selection, as suggested by Allan Day
Trading supported formats for UI simplicity has proved to be a touch choice. Even so, would users actually use most of the formats displayed in the first version? Would they be fine with having only 2 or 3 options available? Would it be acceptable to use an archive manager for the other options? These are the points that have been debated for the past few days. Feedback and suggestions on the matter are even more appreciated now, as they could really help us decide which way to go!
Well, that’s about it for compression and for this part of integrating file-roller into Nautilus. Looking forward to GUADEC where I hope to see and meet as many of you! 🙂
razvanchitu 
The more fine grained compression format will still be available in file-roller, right?
I don’t mind the lesser amount of formats in this quick-compress case, if it solves the majority of the use cases. I don’t have any data on what others use, but I don’t remember using anything but tar.gz and zip for the last 10-15 years myself.
LikeLike
Yeah, we are not changing anything in file-roller. I personally haven’t used anything but .zip and .tar.gz either, but when we brought the issue on #gnome-design people mentioned 7z as having better performance and compression rates. Allan even tried extending his mockup (https://dl.dropboxusercontent.com/u/5031519/nautilus/creative-archive-dialog2.png) but as you can see it doesn’t look too well if you add another option.
LikeLike
.tar.xz should use the same compression as .7z (LZMA2). Also “Linux only” for tarballs isn’t quite accurate just requires third party tools.
LikeLike
@TingPing
Thanks for the mentions. Descriptions are not final yet.
LikeLike
Personally, I like the drop down list because you can offer more options. I also agree, however, that there should only be a few of the most used formats: zip, gzip, 7zip, and maybe bzip. If a user needs more options, they should use file-roller or some other application.
LikeLike
Yeah, reducing the number of options in the combobox sounds reasonable. I have a feeling that this could be the final “compromise”.
LikeLike
Nice work, and always fun to comment on mockups 🙂
How about combining them? Have the dropdown but also include a text describing the format selected?
I often want to create the archive in a different folder, can’t see how that is possible from the screenshots…
LikeLike
Thanks! Hmm, adding descriptions to each format makes the combobox kind of wide. I’ll have to ask Allan Day, maybe he has an idea of how to make it work nicely.
About creating the archive in a different folder, I wanted to emphasize the similarity between compression and “New Folder with Selection”. If you want to have your archive elsewhere, I guess it can be just moved once the operation is complete. Note that the archive will be automatically selected then. By the way, what’s your use case for creating an archive in a different folder?
LikeLike
I think the option to create archives in other folders should not be solved here. I have seen that GNOME designers have long discussed an option to “share” similar to smartphone operating systems, so in that case case could “share as file” and then choose the destination.
LikeLike
The one with radio button and only two options is really the best, especially with the explanation texts.
You have two possibilities, and you make a tradeoff between efficiency and compatibility, depending on who will receive the archive.
The only thing is, should it say « GNOME » instead of « Linux » ? After all, someone might use GNOME on a BSD, or someone might use GNOME and not even know about Linux.
LikeLike
Having options with nice descriptions will indeed help guiding the user. My fear is that people will object to our choice of the 2 options. Oh, and I forgot to mention this in my post but the descriptions are not final, they were more like proof of concept.
LikeLike
> My fear is that people will object to our choice of the 2 options.
Someone always will object to anything you do. You can’t make everyone happy, that’s why you need to make the tough choices. 🙂
And in this specific case, file-roller (and the command line) is still available for those who want the flexibility and see all formats.
One thing to consider, is that even though you present only two options for **creating** archives, you still support **extracting** archives in all formats.
This way, if you chose zip and tar.xz, and later on you realize tar.bz2 would have been a better choice, then you can easily replace tar.xz by tar.bz2 in the next version. Users will still be able to open all their archives, they’ll just start creating new archives in a different format. Lots of those users won’t care, and might not even realize the change.
In fact, how about inverting the presentation: instead of offering the choice between zip (compatible) and tar.xz (efficient), offer the choice between compatible (zip) and efficient (tar.xz).
That would have the benefit of deemphasizing the format, making it less important, insisting on what actually matters (“I need the compatible one, as I’m going to send this archive to my friend who uses Windows” vs “this is a backup just for me, it should take as few space as possible”), and people might thus care even less about which two you chose.
Of course, you’ll find people who will complain, but you’d find people who would complain if you displayed all formats (I’d be one of them ;P ), so just do the right thing for the majority of users (not confusing them), and provide an escape hatch (file-roller) for those who really need the ability to create cpio archives.
LikeLike
Here my two cents.
My general use of archives is as follows: I use *.zip files them to interoperate with other systems, *.7zip when I require advanced settings (password and volumes) and the classic tarball for personal projects or data will only be used in gnu/linux.
I think Allan’s proposal is the best, because for advanced options will remain available file-roller, but if you add 7zip and RAR if available in the system, as they are very popular and used by users. Another possible way is to “create file-roller” button to directly obtain the advanced options that we seek (Although the compression-level option does not have GUI in file-roller). Cheers.
LikeLike
@haevalencia
Hey, thanks for the feedback! Here’s how Allan’s proposal looks with more options added to it: https://dl.dropboxusercontent.com/u/5031519/nautilus/creative-archive-dialog2.png. In my opinion, it doesn’t look as good as the one with 2. What do you think? Also, I don’t know what to say about a file-roller button in the dialog. Will have to ask my mentor and Allan, see what they think too 🙂
LikeLike
I think the simplest option is the best and as I mentioned in my comment I use 7zip for advanced options and if these are not available, is not very different from using an efficient tarball (*.tar.xz).
7zip and RAR are popular and recognized by many users (especially new ones), but there is not much difference in usability when you only want to compress a file. The first model of Allan with zip and tarball solve 90% of cases. Think of other pieces of software that show only the option to compress (use *.zip format) as many email clients or as an option to share as archive (the old “send to…”)
Note: “Linux and Mac only” is a bad label, it is better to use something like “More efficient but UNIX-like only”
LikeLike
@MathieuBridon
Deemphasizing the format really sounds great, thanks!
LikeLike
The second method (Radio selection) is much more clear and informative for normal users, however, I would still love to see an “Other” selection that then opens of an additional list box dialog. I don’t think features should be stripped away from power users.
It might also be better to say “Compatible with *most* operating systems”, I can’t think of an OS that doesn’t support zip but I’m sure one exists and someone will bring it up.
Either way it looks great!
LikeLike
Hey, thanks! Heh, I would laugh if someone would bring that up. Anyway, the descriptions are not final and will probably be adjusted. I would feel bad about limiting options just because I know someone spent his time adding support for all those formats, but I think I’d feel better to know that normal users have an easy time with this. *Maybe* there could be a preference for alternating between simple and power mode, but it would probably be the last resort. We’ll see!
LikeLike
Radio button with two should be enough for the almost everyone. Don’t remember when I used anything else.
But what about possibly to override by providing full file name? Like you can do in a lot of save dialogs.
LikeLike
You mean type in a custom extension? We could do that, sure. I guess we could just check if the provided file name has an extension and if it has we won’t add the typical archive one.
LikeLike
How about showing the users most recently used formats, and then having an a dropdown for others?
That way, if you deploy a lot using say .tar.xz and you need that, you can do it.
A persons format may change, but they are likely to need to do a few of the same – e.g. maybe they are are into emulation and need LHA semi often.
LikeLike
Yes, my thoughts exactly. Maybe have a drop down with the 2 or 3 most used compressions then with “others compressions” that will popup the full list?
LikeLike
I guess we could cut a few options from the combobox. Some of them are quite obsolete.
LikeLike
Are you suggesting a combination between the radio design and the combobox, where the radio options would be the most frequent? I don’t know how that would work. Any way, the combobox version will keep the last used option at the top of the list.
LikeLike
I don’t think a 2-size fits all is really going to work here. I myself use .zip, .tar.xz, .tar.gz and .7z quite regularly.
If you look at other software which supports a large number of formats (e.g. word processors) they typically have a text input for the filename and then below that a drop-down list with the most common formats shown first and a short description for each one. The filename input and the type drop-down are typically the same width on screen and aligned.
So why not get rid of the radio buttons and replace them with a wider drop-down selector, with a few common formats and possibly a “Other…” if you want to keep things simple.
LikeLiked by 1 person
Hmm, your proposal is interesting, thanks! I guess users are familiar with that kind of format selection, so it might work. Will have to discuss with Allan and my mentor though.
LikeLiked by 1 person
Have the issue with lack of charset information in zip-files been solved? I have repeated issues with file names being mangled when moving zip-files between Linux and Windows 7, if they contain e.g. Swedish characters. For this reason, I try to use 7z as much as possible.
LikeLiked by 1 person
I tried compressing a file called ääääåååååééééööööää into ääääåååååééééööööää.zip and it worked. Then I extracted it and the result was ääääåååååééééööööää. All done in Nautilus with the new operations. Want me to try with any other characters?
LikeLiked by 1 person
Alan’s suggestions is really nice. As long as file-roller is available, then it’s fine that Nautilus only solves 99% of all problems 🙂
LikeLiked by 1 person
If this proves to be the final design, I hope most users will have the same opinion as you do! 🙂
LikeLiked by 1 person
What if you could type any (supported) extension in the file-name and it would compress accordingly? You could still have radio-buttons for the two most common formats, but if you type anything else, the radio-buttons get deselected. If you choose one of the given options after that, the extension is removed from the file-name so as to reflect normal operation. I still don’t know how to give feedback so that a user knows the extension he typed is actually supported.
Maybe you don’t want to introduce hidden features like this?
LikeLiked by 1 person
Thanks for the suggestion! I think the solution you propose is quite complex though and might confuse the general user. Also, we would assume people know what extensions to type, wouldn’t we? And even then, what if they type no extension or an invalid one?
LikeLiked by 1 person
I have some questions. I did a little survey at the office about using compressed files. I also checked all your blog posts and there are some things that are not very clear.
Is it intended to replace file-roller? at least its nautilus plug-in?
In conclusion of my mini survey, the most important is the extraction of compressed files. Usually the sources are diverse and come in different formats, password or volumes files.
Is the extraction will support of volumes and password transparently? (All of the above as long as the backend is available on the system)…
On the option to compress much miss the options currently offered by the file-roller nautilus plug-in. Generally the most used option (advanced) is to add a password to the archive and unfortunately a *.zip file or tarball does not allow that.
Proposal:
• Keeping the basic design with *.zip and *.tar.xz options.
• Add a button on the header that opens advanced options
• When enabled, change the options available (radio selection)
– Tar with other options to compress tarballs (only the most common like *.tar.gz and *.tar.bz2)
– 7zip with the option to add password, encrypted list, divided into volumes and change the compression levels.
The main reason is to offer the same options of file-roller plugin with a simplified design, especially those offering modern format like 7zip without showing a long list of other formats.
You could even use the mock up with three options (* .zip, *.tar.xz and 7zip) and you choose 7zip, more options appear with advanced features (my favorite). As I said before, not worth including 7zip if they are not available some or all of its advanced compression options.
Cheers
LikeLiked by 1 person
Woah, thanks for having the mini-survey, good to know what people want!
In reply to the points you made:
– this project aims to offer a good alternative to file-roller’s extension but in the end it will be up to the distros to decide on replacing it.
– multi-volume and password support for extracting archives are not in Nautilus at the moment, as they are not in the backend we use. However, both features can be added to the backend so I’ll discuss adding them with my mentor.
– I like the idea of being able to customize your radio options for extraction!
– about multi-volume and encryption, I’m not fond of adding them to the dialog. They are rarely used features, aren’t they? I’m not even sure if the library used by our backend supports multi-volume compression.
LikeLiked by 1 person
Sorry for all this information, just try to transmit this… 😅
I imagined gnome-autoar was a little limited, but what I mentioned in the previous message, extracting files is key to provide a good user experience (Always have access to content). Just stay add an informative dialogue “this operation is not allowed” or “this format is not supported”.
What now happens if you try to extract a file with password for example? It would be frustrating for a user does not know is happening and not knowing what to do.
For compression, the simple design of Allan still the best solving most use cases. It is a good choice to add to the list the 7zip format but personally, only is useful if I can set some advanced options (only password maybe?).
At least in working environments where I work, always use password feature (RAR o 7zip formats). It is good to give users this option with 7zip, (Enabled by default encryption file list).
LikeLiked by 1 person
Interesting. I confirm that for business and home use is widely used encrypted compressed files and 7zip is the best. Please do not support proprietary formats such as RAR, only to decompress using free software.
LikeLiked by 1 person
Maybe a good idea (but I can’t evaluate the amount of work involved) would be to have the Allan proposed 2~3 choices interface with an additional button “Advanced compression” that opens the full featured compression utility (fileroller for example). But the content of the choices should take in account the statistical usage of fileroller. I mean if one choose to use file roller to compress in not available-7zip format next time 7zip should be one of the choice.
Here we have many possibilities :
1) all choices are the most used format from fileroller (if no historic is available we should give good defaults of course)
2) one of the choice is the most used format from fileroller (if no historic… blah blah… same as abose)
3) one of the choice is the last used format from fileroller (if no historic… blah…)
I prefer 2 and 3 since we could really have a semantic behind it :
– first choice is always the “compatible” .zip
– second choice is always the “efficient” .tar.gz
– third choice is provided by contextual use of fileroller maybe we can label it “custom” or “last used” or whatever fits the best
But all this relies on the ability to collect fileroller format usage statistic/history… and I really don’t know the difficulty of that peticular task…
I also think having a way to manually configure what is the “compatible” and what is the “efficient” format could be a good idea… if this is the kind of configurability we want for this nautilus-plugin (I don’t know).
But whatever happens about these little ideas and the other proposition from the other comments : keep up the good work, this is just great and – for me at least – the way to go for nautilus compression UI !
LikeLiked by 1 person