Give More With Less - Nautilus Sidebar Proposal
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




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 JD Evora, at 4:46 pm
 JD Evora, at 4:46 pm
	   
Post a Comment
<< Home