If you’re an avid user of the GNOME Desktop Environment and follow the development of it, you may well be aware of one of the hot topics currently doing the rounds on the internet, and that is: The User Interface Of The Nautilus File Manager And Why Is It So Awful?

There may well be some of you out there who are currently thinking, “It’s not that bad…” to which my response is: in terms of user interface, there are much better file managers available for GNOME than GNOME’s default file manager (two, off the top of my head: Thunar, default for the Xfce Desktop Environment and PCMan File Manager, or PCManFM). Plus, if you’ve ever used a Mac with OS X, then what you’ll be looking at there is the King Of The File Managers.

But we can make it better…

ANY_CHARACTER_HERE

The Deconstruction of Nautilus

I’ve labelled each individual element that is problematic or, at least, up for questionning:

So we have these little arrows either side of the forward/back navigation arrows. What are they? Well, clicking on either brings up a history of your progression through the file system. What’s the problem? I’ve never once used them. Never. You’ve already got an at-a-glance visual indication of your progress through the file system and it’s the pathbar/location bar, right there, at number 8. So it’s duplicated functionality and takes up valuable space. They can be removed easily. However, if it’s in some way necessary to keep that History Navigation function it would be more elegant, in my opinion, to merely right-click either the forward or back button to bring up a history pop-up.

Another Navigation Arrow, this is the Parent Folder button. If you’ve jumped from your Documents folder to another folder called Wallpapers then the Back Arrow and Parent Folder have different purposes, but are usually confused for having similar behaviours. Clicking the Back Arrow would take you back to Documents; clicking the Parent Folder Arrow would make you climb up the folder structure by one level i.e. in my case, clicking the Parent Folder Arrow from Wallpapers takes me to Pictures because: /home/hex/Pictures/Wallpapers. See? However, even this button is up for debate. It’s duplicate functionality again. How? You can climb up the parent folder structure, once again, using the pathbar/location bar buttons (8), making the Parent Folder button redundant.

The stop button. More useful in web browsers, if you want to stop the web browser from loading a page, completely useless in a file manager, where file accessing times are considerably quicker than web browsing times. You simply never have an opportunity to stop the file manager from loading a page. It’s an old relic. I’ve never used the stop button.

This is the reload/refresh button, which again has similar properties for web browsers; you “refresh” the window you’re on to see any changes that have occured in the current directory. I think there still is a need for a refresh function, but I feel it can be executed more elegantly. See the pathbar/location bar (8) again? You’ll note how the button currently selected is “Season 2”, indicating where we currently are in the file system. Now imagine a little refresh symbol right next to the “Season 2” text on the button. Just clicking that button would refresh the page. This means we can remove the standalone refresh button. More toolbar space has been saved.

Home Folder button. Duplicate functionality again. See the sidebar? See the folder called “sam”? That’s your home folder. Just click that. Seriously, it’ll be fine. There’s no need to have another button for it.

The Computer Folder button. It has a necessary function: it gives you an overview of your system devices as well as the file system. But this button can be better represented in the sidebar. I’ll expand on this one later.

Search button. Very necessary and a crucial part of the file manager. We need to keep this function but redesign it. I like the way that KDE4.x’s file manager, Dolphin, has rendered this. A text entry bar. It invites you to enter search terms.

The pathbar/location bar. Crucial to a file manager, it gives an at-a-glance visual indication of where you are and where you’ve been. I feel, though, that the function of the pathbar/location bar can be enhanced without overcomplicating it, and for the design and new functionality of the pathbar/location bar I feel that Dan’s Elementary Nautilus Mockup is heading in the right direction. Check it out. The image really does speak a thousand words. And so does he.

Icon Zoom: does what it says on the tin. This control adjusts the size of your icons displayed. Useful and necessary, so that it follows Human Interface Guidelines, but can definitely be redesigned more intuitively. Again, check out Dan’s Nautilus mockup to see how he’s implemented this.

This button changes the view mode of your file manager, the options being “Icon View”, “Detailed List” and “Compact View”. We need to keep this, but again it can be redesigned in a way to provide an at-a-glance, more economical interaction. Apple got it right with OSX’s Finder; you’ll note the four icons next to the back/forward navigation icons? They allow the user to quickly switch between different view modes. Very simple, economical and intuitive. You’ll find that Dan implemented a similar spec in his mockup.

ANY_CHARACTER_HERE

Let’s Rebuild a Better Nautilus

So here we are – my reconstruction of the Nautilus File Manager, after addressing each of the problems above.

Firstly, please note that this is only a mockup. I’m no coder or programmer. I wish I had the coding skills, but all those letters and numbers whiz over my head. But perhaps what I can do is demonstrate a better interface through my skills as a GUI Designer. Let’s address the improvements here:

Single toolbar: the original Nautilus interface had two toolbars plus a menubar. It just takes up too much space that could be put to better use. This Nautilus has only one toolbar.

Hidden Menubar: I’m not going to take sides here on whether we should still be having a menubar in applications or not; it’s another minefield of opinions and flaming. I’m personally fine with a menubar inside the application, but I also happily use applications that tuck away the menubar under a single icon (think Google Chrome). But I do think that we should have the option here. In my mockup, all the menubar settings can be brought up with the settings icon (first icon after the pathbar). But if you would like to see the menubar permanently then this, too, should be an option.

Simpler Navigation: back/forward arrow buttons plus a location bar. That’s all you need. If you want a text editable pathbar displayed instead of a clickable location bar, then this should be an option in the settings. You can also see my implementation of the refresh function; a small refresh icon that sits itself inside the button that shows where you are. You just click the button and the directory refreshes.

Improved View Modes: after the settings icon, we have three view mode icons. A simple click allows you to instantly change from Icon View, Detailed List to Compact View. Just one click. That’s it.

Highly Visible Searchbar: there’s no denying what that bar on the right of the toolbar is, that’s where you enter text to search for. It even says “Search…”. Isn’t that handy?

Enhanced Sidebar: previously in Nautilus the sidebar was only used to display your “Places”, like your Home Folder, the Computer etc., and your bookmarks, or directories that you commonly view. We can do more with the sidebar without overloading it and keeping it very simple. The “Places” section displays our home folder plus bookmarks, and the “Devices” section clearly shows any devices on our system including the root filesystem (thus doing away with the Computer icon mentioned earlier). This section would also automatically update itself whenever new media is detected and mounted, such as inserting a CD or external HDD. There are two other sections in my Nautilus and they are “Recently Accessed” and “Commonly Accessed”. I will go into those later. Those are the really exciting features.

Icon Zoom: along with the usual status information in the status bar at the bottom we also have a highly visual and intuitive zoom slider on the bottom right. Simply sliding the slider from left to right increases or decreases the size of the icons. Much simpler but a more powerful way of interacting with icon sizes.

The keen of eye will note that this mockup of mine is not all that different from Dan’s Elementary Nautilus mockup and you’re right. In terms of user interface I think he’s got it bang on. Really, all that’s different in my version is a different theme, a separate search bar and a more enhanced sidebar. But now I’m going to present what I think are the really exciting features in this Nautilus mockup of mine…

ANY_CHARACTER_HERE

Zeitgeist and GNOME Activity Journal Integration

Ok, what the hell did I just say there? Well, if you follow the active development of GNOME as much as I do, you may have heard of two recent technologies actively being developed. They are Zeitgeist and the GNOME Activity Journal. What are they? Well, Zeitgeist is a little, unobtrusive daemon that ticks quietly away in the background and records every file you access, every image you edit, essentially every event you perform on your computer and keeps a chronological Journal of this information for other applications to use. This is the core engine that runs quietly in the background. The frontend to this is the GNOME Activity Journal – an application that allows you to browse and search through Zeitgeist’s recordings of your activities and interact with that information. One of the developers of the GNOME Activity Journal posted a very handy video showing it in action. I use it myself and it is very handy. I also use Docky2 on my desktop that has Zeitgeist interaction. One of the options when you right-click on a launcher in Docky2 is the Journal entry, that allows you to browse through recent events and files accessed in that particular application. A stroke of genius. Again here’s a handy little video demonstrating Docky2 with Zeitgeist integration.

So… where am I going with this?

I personally think that having a separate application, the GNOME Activity Journal, to browse through your events and files chronologically is superfluous. What I’m advocating is that Zeitgeist and GNOME Activity Journal get integrated inside the Nautilus File Manager. Use just one application to browse in different ways!

An image speaks a thousand words, so…

Here we have it: my mockup of Zeitgeist and the GNOME Activity Journal integrated inside Nautilus. You should be able to do everything you can in the current GNOME Activity Journal inside Nautilus, same interface and everything. You can access this particular browsing function simply by clicking the “Recently Accessed” section in the sidebar. This particular section can also filter the journal results as well. So if you just want to see a window showing what you’ve accessed Today, then simply click that in the sidebar. This would then bring up your recorded events that occurred today, but in more detail. This is a function already possible in the GNOME Activity Journal.

ANY_CHARACTER_HERE

Going One Step Beyond…

This is not all that I’m suggesting though. Oh no. This next feature, I’ll be honest, I’m not entirely sure is possible; I’d basically need to have a chat with the Zeitgeist and GAJ devs to see if this particular method of journalling and searching is possible, but I’m going to suggest it anyway…

As well as being able to browse and search through events and files chronologically, the purpose of Zeitgeist and GAJ, I also feel that you should be able to perform a search of events that occur often. Consider: all good application/start menus usually have a “Favourites” section, essentially a list of applications you commonly use on your system (Windows Start Menu has it, KDE’s Kickoff and Lancelot also have it among others). But I feel we should be able to view a list of files, documents, images, websites etc. that get accessed frequently and present that information to the user in a simple way.

Case Study: let’s see that you’re a student studying for a PhD in a particular subject. Over the time of your study you’ll be creating a thesis that will be accessed, edited and updated over of the course of several years. Sometimes, it may be that you won’t touch your thesis for weeks at a time, but nevertheless it is the document that you access the most. It should be possible for the student to access a fast search showing the files that have been accessed and the events that have occurred frequently. In a Zeitgeist chronological search, your thesis may need some searching as you’ve not accessed it in a few weeks, due to research or whatever. In a Commonly Accessed search, the thesis would be the number one result.

Have I made a mockup? Of course I have!

In this mockup example of mine, clicking the “Commonly Accessed” section performs a search showing all the files, image, documents, websites or whatever that have been accessed the most. It would run from left to right, top to bottom and display immediately that which has been accessed the most. This is a mockup of what I would estimate a Commonly Accessed search on my system would bring up. Previews of images and music should be available for at-a-glance functionality. Again, like the “Recently Accessed” section, the “Commonly Accessed” section would have a couple of filters built into the sidebar, so that we can filter for images commonly accessed, documents commonly accessed or whatever. These filters should be set by the user.

ANY_CHARACTER_HERE

That’s All For Now, Folks…

So there we have it. My critique of the current user interface state of the Nautilus File Manager, my solution and a way we can make Nautilus a much more powerful file manager using new and existing journalling technologies.

I would love to hear your thoughts, opinions and criticisms. I truly hope this has given you food for thought. Pass this around the net, let’s get it seen by people and hopefully someone in the right place, with the relevant skills may one day make these mockups a reality.

Ian Cylkowski aka Izo

Logo & Brand Identity Design, GUI/UX Design

If you liked this post, feel free to share with the buttons below!
You should follow me on Twitter HERE.

Congrats man! You work is fantastic! It’s a great contributon for a better looking open source. Otherwise some geeks fanatics will say..too many mac…too many something. Wake up!! Better looking is very atractive. Aks windows 7 people!!

Fantastic mock-ups.
If only they could also get rid of the memory bloat, the slowness, the frequent crashes, the %$#@!* decision to use the same _process_ for desktop and file browser (and why the heck does it bring down/freeze the menus together? Maybe a gtk bug or weakness?)

Fantastic mock-ups.
Nevertheless it would be nice if the decision to use the same process to show the desktop and browse files was rethought, and other measures for better isolation get taken… (why does the panels get frozen together with nautilus?)

Nautilus is the one reason why I left Gnome years ago, and as a result, I have since come to prefer KDE and the new Dolphin File Manager. I really do not want to blur the definitive boundary between local files and web pages.

As a file manager, Nautilus, when it first came out, absolutely crippled my host system – brought it to its knees every time I launched Nautilus. I also lost file manager functionality compared to what I had before Nautilus replaced the default file manager that I preferred. A resource hog.

When it first arrived, Nautilus was not able to handle the file movements I was performing (back then, it always crashed and lost files I was manipulating in the process). Sure, it was immature, but it also was clearly incapable before I ever used it.

Don’t know if this is still being worked on.. but it would sure be nice if there was a way to ignore directory view settings and just use the selected zoom level and display-mode rather than the per-directory options. The use case here is sitting across the room with a wireless keyboard and needing to use zoom, without having to set it on every directory change. When i’m sitting back at the desk, i want to be able to zoom back out and again not have to do it in every flippin directory ;o) The per-directory memory is a real pain in the rump.

Very nice design and well justified opinions. However, I’d still add a button to swich between text and buttons in location bar. Button bar is good if you want to step up more than one step in directory structure, and text bar is required to copy and paste directory location. E.g. I do personally use both of these a lot. A button to swich back and forth is indeed a must.

I mostly agree but few points:
– leave the menu bar alone (if you don’t want to have menu bar in every window, check Gnome Global Menu Bar project), especially do not replicate “the gear icon is some random menu” failure of OS X finder.
– leave the view mode as drop down menu. It allows end user to read the current status instead of guessing on small icons plus it allows for easy extending in case one installs stuff like gloobus preview or gloobus cover.
– the search box should be replaced with a button with magnification glass, clicking the button (or using a shortcut key) should expand the button as search box. Notice that expansion may not be horizontal, the google chrome search feature makes sense in my opinion (search box grows out of the content area border and will slide from side to side if a matched element is under the search box).
– allow tabs and using the middle mouse button to open a folder in a new tab (try to match latest releases of firefox and google chrome where it makes sense – they are all browsers after all).

Your mock-up looks great, but just like Nautilus Elementary, it’s lacking a tree view. I could not work without a tree view. The best option would be to have a “places” view with a tree view for the file system, network and external devices.

Also, I prefer to use the list view, which is often ignored by designers. The columns are simply the fastest way of seeing info like ownership, size, type and modification date simultaneously on multiple files.