Internal compression

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:

compress_menu_item

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

compress_radio

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! 🙂

Advertisements

39 thoughts on “Internal compression

  1. 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.

    Like

      1. .tar.xz should use the same compression as .7z (LZMA2). Also “Linux only” for tarballs isn’t quite accurate just requires third party tools.

        Like

  2. 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.

    Like

  3. 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…

    Like

    1. 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?

      Like

      1. 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.

        Like

  4. 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.

    Like

    1. 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.

      Like

      1. > 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.

        Like

  5. 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.

    Like

      1. 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”

        Like

  6. 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!

    Like

    1. 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!

      Like

  7. 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.

    Like

    1. 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.

      Like

  8. 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.

    Like

    1. 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.

      Like

  9. 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.

    Liked by 1 person

  10. 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.

    Liked by 1 person

    1. 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?

      Liked by 1 person

  11. 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?

    Liked by 1 person

    1. 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?

      Liked by 1 person

  12. 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

    Liked by 1 person

    1. 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.

      Liked by 1 person

  13. 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).

    Liked by 1 person

    1. 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.

      Liked by 1 person

  14. 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 !

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s