Redesign the nautilus filemanager (part 2)

My work on nautilus continues with this new post (click to know more about the first part) focusing on how to improve the way people interact with it. Let’s start with a short overview of the topics discussed:

Grid system

Mockups are built over a concept of Grid view. The grid view, inspired by the CSS grid system, shows files with a different approach and replaces the Nautilus icon view

Animations

Small and clear animations can preview the effect of an action, draw attention on a change, or visually explain a task. Selection, file transfer, drag&drop are common tasks where to integrate them

Responsive Icons

The most used approach to interact with icons in a file-manager currently is the right click mouse button. A different and unobtrusive technique is discussed

Grid system & Responsive icons

A grid view is a modified version of the Nautilus icon view in which elements have all the same size and a selection area appears when your mouse is over an element.

Grid view details

Contiguous selection in a grid view

Close to a CSS grid system (used in website content organization), the main purposes is to clean the interface and clearly define item borders. Items in such a grid appear as follows:


Responsive icon in a grid view

Actions over a contiguous selection

  1. Moving the mouse pointer over an element shows actions on its edge. The use of the edge is intentional: showing actions in the middle of an item can be dangerous, you can click the “Move to trash” button even if you want to simply open the document
  2. Actions list could be static or dynamic and appears only on big icons (minimum size required)
  3. Actions can be showed over a contiguous selection. It may be a good point to show them over non-contiguous selection. However, I failed to design this difficult interaction (any idea is welcomed)

 

The switch to a Grid view present some difficulties:

Text truncation

Current text truncation creates icon alignment problems. In my opinion, 2 lines are a good compromise for filenames. Obviously increasing the zoom of an item makes lines longer and more characters may be visible in the 2-line filename. A tooltip (containing the full filename) should appear when the mouse is over a truncated name.

Different icon size on the same view

Different size for icons at the same zoom level

I’m not telling to use the same size for all icons, but icons cannot exceed a defined limit. As you can see (pictures above) icons with previews have a different size than the others.

 

Animations

Animations make life easier. Great animations make hard tasks simple, preview the effect of an action, provide useful feedbacks to users and help people avoiding errors by drawing attention on a change. Unlikely other file-managers, Nautilus interface has always been poor of animations. I focused my work on common tasks such as the selection and moving of multiple items, drag&drop and cut&paste. Below the results:

Multiple selection animation

Drag to folder (left panel) animation

Drag to folder animation

Cut & paste animation


I believe all animations are clear enough and I’m not going to analyse them further. However, I want you to notice the grey icons in the “Multiple selection animation”. Selecting a group of icons and dragging them shadows the original item location. The animations clearly points out that you are in a transitional state (you are moving them from one place to another) and provide feedbacks.

That’s all. I hope you enjoyed this post, let me know your thoughts…

4 thoughts on “Redesign the nautilus filemanager (part 2)

  1. Pingback: Neue Vorschläge für ein Redesign von Nautilus | Softwareperlen

  2. – Grid System
    I agree with that, but as far as I see, the only change against nautilus 3.6 is the fixed height and the polishing. The problem with long filenames would be fixed by cutting everything down that doesnt fit – but renaming a file would probably stay as ugly as it is now (the filename box floats over the icon beneath)
    – Responsive Icons
    You should keep in mind that the gnome-shell tries to be usable on touch-devices. The most usable way (imho – i’ve got a convertible running gs 3.6) to initiate a context-sensitive action with and icon/folder/file is a long-tap (as known from icons in gnome-shell, android, etc). it will be very hard for to hit those little icons in the corner on a touch device.
    – Animations
    Animations are great – as long as they stay in the background. I fear that some day every application will have it’s very own eyecandy-animations, and the will be absolutely no consistency. I have to admit, that i’ve got no idea how those animations are realized – but i think it would be great if they were kinda using the same backend – at least it should be possible to deactivate the animations centrally (gnome-control-center)

    Since I’ve got Gnome-shell running on a touch-device i could tell you a lot of things in Nautilus that do not work reliable/intuitive/good on touchscreens.

    • Hi, thanks for your long and detailed comment. I’ll try to answer to all your doubt.
      The target of my work wasn’t mobile or touch devices. I’ve never tried gnome on a touch device but I hardly believe that the gnome-platform (all gnome apps not just gnome-shell) is touch ready. I may be wrong and you already experienced it on a touch device so let me know if I said something untrue.

      I agree with you, hit the small icons on the corner of an item may be hard, but the Nokia N9 already implement something like that (the close button on the right corner of an application). See this link http://blog.wapreview.com/15554/2011-10-19_12-35-42/ for an example. Probably for a touch device the best approach is to only keep the move to trash icon at the top-right corner and remove all other actions.

      Let me know about your troubles and problems experienced using Nautilus and other gnome apps on a touch device. I’ll try to design some solutions to it and It may be a great starting point for a future post.

  3. – Grid System
    I agree with that, but as far as I see, the only change against nautilus 3.6 is the fixed height and the polishing. The problem with long filenames would be fixed by cutting everything down that doesnt fit – but renaming a file would probably stay as ugly as it is now (the filename box floats over the icon beneath)
    – Responsive Icons
    You should keep in mind that the gnome-shell tries to be usable on touch-devices. The most usable way (imho – i’ve got a convertible running gs 3.6) to initiate a context-sensitive action with and icon/folder/file is a long-tap (as known from icons in gnome-shell, android, etc). it will be very hard for to hit those little icons in the corner on a touch device.
    – Animations
    Animations are great – as long as they stay in the background. I fear that some day every application will have it’s very own eyecandy-animations, and the will be absolutely no consistency. I have to admit, that i’ve got no idea how those animations are realized – but i think it would be great if they were kinda using the same backend – at least it should be possible to deactivate the animations centrally (gnome-control-center)

    Since I’ve got Gnome-shell running on a touch-device i could tell you a lot of things in Nautilus that do not work reliable/intuitive/good on touchscreens.

Leave a comment