Who's Dabbling

Friday, May 26, 2006

Give More With Less - Nautilus Sidebar Proposal

Nautilus' sidebar seems to have had very little love since it was introduced - in fact, features that many users would find more desireable now, such as rss feeds in the sidebar [1], have been removed or were discussed but never developed [1]. With more sophisticated sidebar tools we can present less information, but give users more useful informaton reducing clutter and improving ease of use.

The Side Bar

The sidebar has the potential to be an enormously useful tol for users.

  • Because it is always visible it can unobtrusively and quitly expose features and options that new users may not realise exist.
  • It provides a quicker way to navigate the file system, and can help to disguise its complecities to new users (through using 'Places' as opposed to 'Tree', for example)
  • It's size compared to a status bar or right click menu makes it far superior to providing users with more detailed information about their files and folders.
  • It is easy to hide, or change the currently viewed pane (such as changing from 'Information' to 'Tree', so that users who feel it is clutter need not worry about it.
  • It provides a space to show and edit meta-data about a file or folder, to tag it and display tags [2], and also display dynamic information like 'Similarly named files' that a context menu is less suited to and becomes much less useful when hidden in a tab on the properties dialogue.

However, in Nautilus at the moment I feel we are not fulfulling this potential

I see several problems with the current system

  • We currently have the ability to show only one of the items (History, Notes, Emblems, Tree, Places, Information) at a time
  • The 'Information' bar shows information about the current folder or file, not the file that is selected.I remember using much older version of Nautilus where this made more sense because images and text documents opened withtin the Nautilus browser window. Now this no longer happens, the Information sidebar is much less usefull than it could be. This behaviour is also inconsistent with other operating systems from which we hope users will be migrating. Some consider it a bug[7]
  • The system does not extend beyond Nautilus - It doesn't pull in information from Tracker[3] (or Beagle, if you prefer), LeafTag, The Internet (or not since the News panel disappeared)

I'm sure there are very good reasons for these limitations, but I also think the potential advantages of a well designed sidebar make it worth further investigation.

Solutions

I am an inexperienced programmer, I have not written any code for Gnome (though I am eager to start when I get some time) and I don't know the details of how Nautilus functions. My plans for this are based on the way I have understood the themes in Nautilus implemented. If these ideas are patently ilconcieved, I apologise, please tell me politely! I have searched (and searched) for a post I read but lost again about possible ways to extend the sidebar and how to go about them, maybe it has vanished :P

I would be a fool to try and pretend this is orginal. If we look at the sidebar for Explorer (Windows) and Konqueror (KDE) (metabar) then you can get a pretty good idea of what I am talking about.





I think that Nautilus should implement a 'Sidebar Applet Container' that has no dependencies except those of Nautilus, but that can use mulitple 'Sidebar Applet Engines', which in turn can take mulitple 'Sidebar Config Files'. While mulling over this idea I read CoreyBurger's ideas on keeping everything together and not using plugins [5] to implement funcinoality. However, I a project like this needs to be modular so that teams with expertise in any particular area (eg, beagle) can write the plugin to communcate with their tool. I would also hope that, like GTK+ has a 'default' engine there could be a simple 'default' setup implemented without a plugin that displayed the information already there - specifically making use of nautilus scripts, which can provide a lot of functinoality without adding any dependencies [6].

Sidebar Applet Container

  • This would take care feeding information to the engines (plugins) (the currently selected item - perhaps the properties so that every plugin doesn't have to impliment it's own way of getting the file date, mime type etc) and recieving information to display in various forms, be it an image, a list of links, a list of programmes... I think it would control the actual display of items in the list so we keep unified looks and UI compliant. It should also be able to do basic lists itself.

Sidebar Applet Engines

  • These would interface with various tools on the desktop - such as Beagle/Tracker, gnome-vfs, leaftag, Dashboard (if that doesn't just merge into Beagle) some kind of internet tool, nautilus-scripts, an EXIF reader, the contact book, image previews, media file metadata.... They would then allow Sidebar Config Files to query them in different ways. The Engine then feeds the results of the queries back to the sidebar container.

Sidebar Config Files

  • These should be easy to write and wil be specific to any engine. They will specify the name of a sidebar field, and which queries to use to compile it (I think multiple queries should be supported - eg 'of same file type', with 'date last edited +-5' days to give a list of files the user may want. Perhaps even queries with multiple engines, but that somewhat breaks the structure up as the container would ahve to handle it, unless engines could talk to each other - I don't know enough!

So now we have a system that allows us to put relevant information about any selected file in to the sidebar.

The aim of this is not to put huge numbers of options in front of people, it is to more accurately guess what information they might want so we can present less of it and make it more accessible

Some examples I think would be really nice:

  • Photos you took around the same time
  • Files containing this file's name
  • Websites relating to the frequently occuring words in this document
  • Look up this media file (links to artist, album, song on Wikipedia or search in Google)
  • Files created in the same application
  • Files of the same name (useful for find all the gtkrcs, for example)
  • A list of people that were mentioned in a file (their contact information)
  • Advanced file previews
  • Other files with similar metadata (treeview perhaps)
  • Relevant places...
  • Relevant actions...

1. Redhat support for RH7:

http://www.europe.redhat.com/documentation/rhl7.2/rhl-gsg-en-7.2/nautilus-intro.php3

"News — shows current news headlines. Click on Select Sites for a list of news websites from which you want headlines displayed. Click on Edit to add or remove sites to or from this list. Done displays the main news tab."

See 'Shelf' idea at http://mail.gnome.org/archives/nautilus-list/2002-June/msg00226.html

Image Properties tab: http://www.advogato.org/person/snorp/diary.html?start=13

2. Leaf Tag

http://www.chipx86.com/wiki/Leaftag

3. Tracker:

http://freedesktop.org/wiki/Software/Tracker

4. KDE Metabar from

http://www.kde-apps.org/content/show.php?content=21010

5.

http://www.advogato.org/person/Burgundavia/diary.html?start=77

6 - usse of Nautilus Extensions on the sidepane is mentioned here

http://primates.ximian.com/~dave/NautilusExtensions.html

7. Sidebar doesn't update to current icon

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122365

1 Comments:

  • I love that proposal, I really miss a more usefull sidebar.

    Did you wrote a RFE bug or a blueprint in the nautilus tracking system?

    Cheers
    JD

    By Blogger JD, at 4:46 pm  

Post a Comment

<< Home