Please have a look at the KDE Wiki at http://wiki.kde.org/tiki-index.php?page=KDE%20Context-Sidebar&comzone=show to participate in further discussion on this.
This is not only about whether one likes it or not, but more about whether new/unexperienced users would have easier access to KDE's functionalities.
Sidebars are/could be a very useful feature, as they allow easy access to information about the filesystem, bookmarks, addressbook you name it.
At the moment haowever they are too static and do not really interact with their environment. Best example is konqueror. Open it, go to a website, hit F9 to enable the sidebar, what do you get, the default setting (mostly filesystem I guess) instead of the sidebar noticing that it is in the context of the internet and should display bookmarks as the most likely. I know you can set this by enabling the sidebar, pick the bookmarks-tab and save the profile. So the user has to know all this and do work to configure what should be obvious and straight forward.
Context-sidebars would do the following:
They are not static and do only appear when they are of use. If so they glue themselves to the side of an app-window so that you do not have a static sidebar at the side of the screen but always next to the app that it is useful for. In that way they are partly like toolbars with text, placed at the right side of an app. However their functionality should go beyond this. In XP Microsoft got this for the filesystem, i.e. you open a folder and the sidebar offers you functionality for the selected files, i.e. copy to.. as te most simple example. Of course one could say that most of these functionalities are already there, context-menu, toolbar and menus, however my experience with most normal users tells me that context-menu, short-cuts, menus and toolbars are for advanced users, as they are not obvious enough in propagating their funtionality. It is not even straigth forward for most new users to simply hover the icons in the toolbar to see their funtionality. Further they do not know that they can enable text next to the toolbar-icons and, as this is useless at the top (too wide), place the toolbar at the side.
So what do I want? I think that definitely for the normal user and also for the advanced user, though in other areas and only if configurable, context-sidebar should offer information and functionality that is otherwise hidden in context-menus or icon-only-toolbars. They should be the obvious link to apps and functionality meant for the selected files or environment.
--
I guess examples are the best way to show what I mean:
Examples in kmail:
You open/click on an email, the context-sidebar displays (all) available information about the sender so you can answer the email either by calling, IM, a letter or even by email
, without having to look this information up in the adressbook. For CustomerRelationsManagement there could also be some information about the client, his/her last emails, documents...You compose an email, the addressbook is next to the composing window, useless if you need only a few recipients in the TO-field, but very useful if you want to add some to TO, some to BCC,CC, some to IM, some to SMS, some to fax. Simply select them and click on the button representing the address-type you want to use. If recipients are chosen, activate the field in the composing window.
At the moment you would have to open the pick-address dialogue, pick the people, close it and then activate the BCC, or CC-field manually. The latter can also be set to permanently, I know, but this wastes a lot of space if you do not need them. On the other hand at the moment these fields are not even activated automatically if the email has recipients in these fields.
You might argue that space is limited for an efficient address-list, thus when clicking into the list it should expand so you can work with it and when clicking back on the email-text become small again automatically. If you need it, it's big, if you do not, you can see it but it does not disturb you. And even if you do not like a list at this point, put a button Adressing there instead of that ... behind the TO-field.
Examples from the filesystem:
You have selected music-files, or are in a directory that consists of only music files, the context-sidebar provides access to a media-player similar to amarok's small window, i.e. more functionality than the sidebar-media-player in 3.1.x had, there is a possibility to add the selected files or the whole directory to the library, or playlist, one can burn songs, or simply display information about the artist. So if you click a button it opens a window with the app the button belongs to, i.e. as if you would chose it from the context-menu and chose add to playlist...
You open a CD/floppy in konqueror, if it's RW/floppy the sidebar provides access to erasing/formating it, a mini-burning-list to drag&drop files from different directories to and burn them, if it's an audio CD it offers KsCDs functionality, or to rip it, if it's a video-CD to play it, rip it...
If you select an cd-image-file the context-sidebar gives you information about the image, the possibility to mount it (there is a script at kde-look.org that can do this) or to burn it.
Selecting an image gives you access to its properties, to start editing it, rotating it, burning them to get them to a photo-shop, connect to you camera, make a slide-show...
Misc. examples:
Addressbook's context-sidebar would offer the possibility to call, chat, arrange a meeting with..., write an email to...
Internet's context-sidebar should offer bookmarks as well as a button to add, edit hem, a button to start an IM-app, or to start an email-app, online-banking-app, IP-telephony...
--
So apps would not have to program their own functions to burn a playlist with k3b or rip that cd but simply use an interface to the sidebar, passing on needed information to do the task. As screens are getting bigger, icon view is standard for KDE and most new users and some notebooks even have over-wide screens, I think that space would not be an argument against this, especially not, as the sidebars can be turned off, all-in-all, or per app/context.
The great benefit would be to have functionality and information, available for the eyes of every user without an extra click.
If I am not the only one that is interested in this feature I would setup a site to put more screenshots on. This way ideas about functionality and look could be discussed before it is coded.
Ratings & Comments
14 Comments
First of all I like the idea, I do how ever have a question/suggestion. They are drawn as being attached to the right side of Konqueror, I think it should be possible to place the context-sidebar in the navigationpanel, I'd like it to be filesystem/folder dependend. I also see you have an entry called Instant Message, I think it could be cool i there were a kopete plugin, so ones contact-list were accessible. And for CD-burning, a plugin for K3b. Another thing I think might be cool, and this is if it were a navigationpanel, a kaffeine (xine-lib) or mplayer plugin for previewing video-files. 100% optional of course. One other idea popped in my head, just now :-) It'd be cool if one could use this to make a playlist for amarok, xmms, juk and other. It'd make creating a new playlist a lot easier. Some people (i know) use the longest time creating a playlist from their mp3/ogg library, drag 'n drop from their filemanager to their audio-player. I use the term plugin because I couldn't think of a better one ;-)
Maybe you want to have a look at http://wiki.kde.org/tiki-index.php?page=KDE+Context-Sidebar (click on the comments link at the bottom of the wiki-article-page) as people already added their thoughts and comments their. Your ideas are mostly already in the suggestions for the feature. There is a d&d window in the context-sidebar which can be used to collect files and then do whatever you want, e.g. create a playlist from them, burn them, send them by InstantMesssenger etc. If you find any suggestions that have not yet been included, please add them to the WIKI article, so that they can be used by developers interested in this feature. The issue with the sidebar being attached to the side of a window instead of the side of the screen is also discussed in the comments section at the bottom of the WIKI-article. I hope you join the WIKI-article!
i think that if this can be implemented, it would be bery usseful, but you neee to polish the graphics up a bit. heres another idea, make it have the same functionality, but make it on the side of the screen with auto-hide like the longhorn sidebar instead of in each window. i think this would help to save space. if its on the side, transparancy will also be possible.
As I mentioned before, the images are just to give an expression of the idea and in no way meant to represent a final/polished result. Further I do not agree with the Longhorn thingy, as this is not close enough to the app. Screens/resolutions are getting bigger and even wider so there is no space issue that would be as important as to sacrifice the closeness to the app/window. Autohiding isn't that good in my view either because people easily get annoyed when the sidebar pops-up because they came to close to the edge of the screen and second you hide the content of the sidebar and the user cannot see, whether it changed and offers the functionality he/she is looking for without going to the edge of the screen every single time he/she has selected files.
hmm... the idea is not so terribly bad, but i doubt that it is really useful. it will take up lots of space on the desktop. very precious space that gets wasted imho unless there is a chance to make it smaller. and please, don't let it look like the office xp sidebar. it looks very much like it in my opinion.
if it's autohiding, you won't waste any space - right? ;)
Is the sidebar in konqueror a waste of space? Not really, because how can space that makes KDE useful to new/unexperienced users be seen as wasted? If you do not like it you could enable it, however I think that a lot of unexperienced users need this and thus do not care about 250px or so less on the screen. Furthermore screens and resolutions get bigger and wider, obviously there would be problems on 800x600 and mybe even a few on 1024x768 but again, the gain of funtionality outweighs the loss of space by far. And for the people who do not think so, they can easily disable it.
the gnome folks already started work on something like this: http://www.nat.org/dashboard/ the dashboard is a context-sensitive sidebar which displays information. i think they did not implement your idea of adding program controls to it, though. here is a kde.org discussion about it. http://dot.kde.org/1057985977/1058022061/ now, for kde, we have an advantage and a disadvantage in context to gnome - our problem is that, unlike gnome, kde isn't much for metadata currently. our advantage is dcop - if every program would release all the needed info via dcop, writing such a sidebar would actually be quite easy.
Hi! I had a look at Dashboard and as you already mentioned it is not so much about bringing functionality and apps to the user but mainly information. I mean in the case of kmail, IM and so on that is sensible and useful but for other environments such as filesystem etc. apps and functionality seem more important to me than information. I'll move this to the wiki.kde.org site and see, whether some developers like this idea too.
A few comments 1) The up and down arrows look a bit too big. Could they be smaller? 2) It's hard to tell visually where one input control ends and the other begins. Perhaps enclosing them a'la WinXp (http://www.geocities.com/prashanthudupa/QpuListView.html) would help distinguish them. Yes, i'm talking about nicely shadded boxes around them. 3) What kind of information will be displayed here and how will it be accessed. Yeah i know i'm getting ahead of myself but it's got to be considered.
Hi! I was just drawing some pictures to get across the idea, obviously these are not as nice as they should be. I just thought, who would read the long text if there were no pictures. ;) I like your ideas, I'll move this to the wiki, as proposed and hope that developers will like the idea too.
i misunderstood him, but i thought he was rather thinking of some kind of contest sensitive (autohiding) toolbar replacement than about dashboard (what will make it necessary to write a comm protocol first, where this should really align to the gnome Dashboard protocol)
And you seem to have indeed thought a lot about it :) Though it's not nessecary to start a whole new site for this, you could simply start a new section on http://wiki.kde.org where much discussion could happen in a relatively ordered fashion :) It is a very good idea, and I would love for it to be implemented. I of course don't know if you are aware, but GNOME has something like this, called Dashboard. Now, I am not saying we should just copy that, but it is a proof of concept in a way that we should not disregard that it is a thought through bit of programming, and thus we could learn from their mistakes, so we don't have to make them :)
Well, I tried to describe as detailed as possible what I thought would be a good improvement. I did not know that gnome had something like that but will check it out. I hope that there will be some developer interested in this, as I think that this is too much for my narrow knowledge of programming. Anyway, I'll have a look at that wiki and post the idea there too, hoping that there are enough people sharing our interest! ;)