GNOME Bugzilla – Bug 325024
Redesign "Basic" tab of file properties dialog
Last modified: 2008-05-23 16:25:27 UTC
I'm currently revising the file properties dialog of Nautilus, and it has various flaws, the most notable ones being: - basic dialog spacing is not HIG-compliant - "Title:" labels are bold and right-aligned - The icon pixmap keynav is not ensured (no accel) since we put the whole custom icon functionality into one icon button I'd like to get some feedback on the proposed design, which also partially doesn't match the HIG, which I'd like to discuss.
Created attachment 56406 [details] Old layout That's how the dialog used to look.
Created attachment 56407 [details] New proposed layout That's how I think the dialog should look like. Please ignore the unintuitive "Permission" semantics for now, they'll be revised in a later iteration.
Created attachment 56408 [details] New proposed layout That's how I think the dialog should look like. Please ignore the unintuitive "Permission" semantics for now, they'll be revised in a later iteration.
Created attachment 56409 [details] [review] Proposed patch The patch which yielded the (uploaded twice) layout.
I'm interested in usability-related comments, i.e. for instance whether the "Icon: [ ... ]" "Name: [ ... ]" construct is better than "[ ... ] Name: [ ... ]" http://developer.gnome.org/projects/gup/hig/2.0/design-window.html suggests to use the latter, but I think that for increased keynav it's better to have an "_Icon" accel. http://developer.gnome.org/projects/gup/hig/2.0/windows-utility.html contains a screenshot which is still from the days when we had separate "Custom Icon" buttons, i.e. GNOME 2.12 and older. It also seems to use bold "Title:" labels, but this isn't recommended anywhere else in the HIG, is it?
(In reply to comment #5) > http://developer.gnome.org/projects/gup/hig/2.0/design-window.html suggests to > use the latter, but I think that for increased keynav it's better to have an > "_Icon" accel. Is it possible to have both an image and a label inside the button? It would look something like this: /---------\ | | | /!\ | | | | _Icon | \---------/ I'm not sure what the HIG says about that, though. Just throwing out ideas, because personally I think the old version looks better -- that might be because I'm used to it, though. I'm not convinced my proposal will look good at all either. I'm not familiar with any guidelines saying the labels should be bold. I think this dialog could maybe have right-aligned labels as suggested in GNOME HIG chapter 8, section "Spacing and Alignment", under Guidelines, point #2: "Left-align components and labels, unless all the labels in a group have very different lengths. If they do, right-align the labels instead, to ensure that no controls end up too far away from their corresponding labels."
Using a mnemonic on I is generally bad, as with sans-serif fonts, it is often very narrow, and thus very hard to see. With the attached screenshot, I had to actually look at the I and find the _ under it. It did not appear as quickly as the other mnemonics in the window.
First, let me say these changes make the properties dialog look much better. I have only two questions. On the Basic tab, why is there extra spacing between the "free space" and "modified" rows? Also on the Permissions tab, do we need the horizontal separators? IMHO, the separators just add visual noise.
(In reply to comment #6) > I think this dialog could maybe have right-aligned labels as suggested in GNOME > HIG chapter 8, section "Spacing and Alignment", under Guidelines, point #2: > "Left-align components and labels, unless all the labels in a group have > very different lengths. If they do, right-align the labels instead, to ensure > that no controls end up too far away from their corresponding labels." Right-aligned labels would look better. Also, a point was recently made on the usability list that the labels are going to be different lengths at least in some translations. Would it make more sense for the text view and number view of the file permissions to be directly beneath the checkboxes to set permissions?
I would disagree with the previous posts which recommend using right aligned labels. On the basic tab, the labels are all one or two words in length. They do not have very different lengths.
In my opinion the new layout looks "less chaotic, more ordered". Depending on the language, the user/group/others labels could be a bit too far away from the corresponding checkboxes. Not sure if there is a nifty way to solve this. I wouldn't move text view and number view of the file permissions. They are useless for the average user, just confusing. In the basic view the free space item does not correspond to the file/folder regarded to. I suggest seperating it along with the volume item. Both are somewhat related (free space, on what volume?). Since the volume is related with the file/folder, put it first, free space later. The remaining should be grouped together.
Created attachment 56589 [details] [review] New proposed patch Thanks for all your feedback! Changes wrt the last patch: - Use "Ic_on" accelerator - Regroup labels on first page - Only show "Accessed" when we show "Modified" (the latter is not done for dirs ATM) - Move "Link target" up - Group volume and free space together - Remove "Last changed" from Permissions page. The algorithm for determining this one is not very obvious, IMHO - Replace "Text view"/"Number view" by "Symbolic view" and "Octal view", as seen in the chmod manpage - Replace horizontal separators by a blank row
Created attachment 56590 [details] New proposed layout
I like the removal of the bold, not so much the rest ... "Icon:" is weird, since that picture can be there for no other reason. It's like a caption underneath a painting saying "This is a painting". As for label alignment, the labels do indeed have very different lengths: "Freier Speicherplatz:" is much longer than "Typ:" or "Ort:", so it's unnecessarily difficult to see what the latter two refer to. The way to fix that is to use right alignment. There are other problems with this window more severe than its layout. What's "Basic" about a MIME type? Why does "Open With" need an entire tab? How dare the word "execute" appear in a GUI? The "Sticky" option has lots of room, so why isn't it self-explanatory? And so on. Christian, would a fuller redesign now be convenient, or are you more interested in polish?
> "Icon:" is weird, since that picture can be there for no other reason. I've never heard any other term for symbolic representation of a file. > "Freier Speicherplatz:" is much longer than "Typ:" or "Ort:" Please don't refer to the German screenshot. I used it by accident to illustrate the changes I made before the usability audit happened. Joachim pointed out in comment 9 that there is general alignment problems with various languages, but I don't know any smart solution to the issue, and I think people will be confused by mixed alignment (i.e. it will be considered random and inconsistent) even if somebody comes up with a smart length-detection alorithm. Left-alignment has its advantages when trying to scan for a particular label. I agree with Dennis (comment 10) that the label length is not very varying. Measuring label lengths in words a very good approach, and the German word "Speicherplatz" above is actually a composed word, so the issue is that the German translator (IIRC, that was me) used three words instead of trying to stick to one or two. Considering attachment 56590 [details], you can clearly see that in English this is not an issue. One could for instance translate this a bit more terse with "Verfügbar:". > There are other problems with this window more severe than its layout. I totally agree and pointed out that "(this dialog) has various flaws". > What's "Basic" about a MIME type? I also agree. IIRC, it was proposed to remove it but we concluded that in many situations (for figuring out if something got wrong) the MIME type is useful. Maybe we could merge the two labels like: Type: foo document (application/x-foo) Or add the MIME type as tooltip. The latter is IMHO not very discoverable, though. > Why does "Open With" need an entire tab? Where else would you put it, and what would the proposed GUI look like? I think a tree view is good for having a list of available applications that can be scanned rapidly. > How dare the word "execute" appear in a GUI? UNIX permissions are arcane, and I discussed some means of hiding them in my blog [1,2]. It looks like not all people liked those drop-down boxes. We have to do some study what is more intuitive. > The "Sticky" option has lots of room, so why isn't it self-explanatory? Because stickyness is not a very simple concept and means different things in various contexts. Please refer to man 1 chmod for details. > Christian, would a fuller redesign now be convenient, or are you more interested in polish? In both actually. We're totally open to conceptual improvements, but these have to be discussed and well thought-out. While you pointed out some issues, you didn't offer clear concepts or ideas how they can be improvement. Thanks for nailing some issues down, though. [1] http://blogs.gnome.org/view/cneumair/2005/12/26/0 [2] http://blogs.gnome.org/view/cneumair/2005/12/28/0
Created attachment 56649 [details] different logic to choose rwxrwxrwx
Created attachment 56650 [details] alternative way to choose rwxrwxrwx just an idea, i thought that assigning u,g,o-level to read,write and execute could be a better to understand for fresh users. This would reflect the impact o+x would do better than the old way of having 9 checkboxes.
Created attachment 56713 [details] Another mock-up Some of my ideas: * Group items together with a bold label. * Show the MIME-type next to the "Type" property. * No "Emblems"-tab but a button "Edit emblems..." next to the icon. This will bring up Nautilus' "Background and Emblems"-dialog, users can now drag and drop emblems to the icon. * No "Open with"-tab but a combobox on the "Basic"-tab. Mac OS X seems to do it this way, don't know how it exactly works. Anyone an idea? * Many file-types already have a type-specific tab in the properties dialog. Make such tab default (an "Audio"-tab for audio files, "Directory"-tab for directories, "Starter"-tab for starters etc.) and put "Notes" at the bottom of that tab. * "Permission"-tab proposal: Same as KDE. In place of "Advanced permissions"-button an "Advanced"-expander. Clicking the expander will deactivate the simplified view above.
I'm for this in general, however I really don't like the Icon: label. Just having the icon button in the top left corner with the rest under it would look so much better. Its very obvious that this is the icon, and the way the Icon label gets placed due to the height of the icon button makes it look very bad. The icon button is still keyboard navigatable by using tab and enter. Its not as efficient, but I doubt this particular feature is used often enought for that to matter.
Alexl: I have at least one user who disagrees, see http://bugs.debian.org/384918 He's basically asking for an easy way to change the icon, just like in the panel properties dialog. BTW, I think the properties dialogs should be unified between nautilus and gnome-panel, this is an inconsistency that doesn't look very nice.
Created attachment 96600 [details] [review] Proposed Patch Modifications compared to my last patch (comment 13): * Remove MIME type row, use tooltip in type row * Display icon on the top-left of the other rows like in the panel's property dialog * Swap accessed and modified rows (accessed should be before modified)
Created attachment 96601 [details] Proposed Layout A typical screenshot of the proposed layout.
Renaming bug report from Properties dialog should be HIGified to Redesign "Basic" tab of file properties dialog Regarding comment 16 and comment 17: They refer to the permissions tab, which has been redesigned already. Regarding comment 18: Thanks for your interesting ideas, Tim. The very first step is a cosmetic clean-up, we'll then evaluate your rearrangement proposals.
Created attachment 96711 [details] [review] Proposed Patch This one also implements the "MIME type description (MIME type)" behavior for the type file property instead of using a tooltip. Paolo Borelli requested this on IRC.
I tried the last patch on truk but when I open the preferences window on a jpeg image i get a freeze (nautilus:18189): GLib-GObject-WARNING **: specified class size for type `FMPropertiesWindow' is smaller than the parent type's `GtkDialog' class size (nautilus:18189): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
How's the progress? I believe we should bring this bug up again because I would like to see a major GUI revamp in GNOME 2.24
I committed a modified and fixed patch, which also removes useless properties for trash, computer, network and burn locations: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14188 Closing as fixed.