> While ideally I tend to think users should not have to care about > applications, but only about content, i.e. documents, people, websites > and so on, I fear we've not tackled many issues with that approach. I > think we really have applications that have the status of first-class > objects: think of Rhythmbox, F-Spot, Evolution, even Firefox and > possibly OpenOffice.org. > > These applications can be used to work with a collection of contents, > and we're not going to fill the recent documents list with e-mails, > music tracks or photos. You could make them be a single meta-document > called "Music Library", "E-Mails" or so, maybe, that's a debate. > > Designs about that are welcome! But IMHO that's not so easy to replace > without losing functionalities, and would require a complete redesign of > our desktop conception (we're here to do so!). My thought on this is that the desktop has the need to be both document and application-centric at the same time, where some tasks require different kinds of workflows. A basic example is that a game is thought of as an application that the user directly executes. Another example is that a shell like F-Spot, Evolution, Banshee or Nautilus is application-centric; you open it to get at documents. An issue right now that hurts the document-centric approach is that applications are only really presented in one way (the towering Applications menu, which can quickly become a monstrosity since every application is in it). Further, there is nothing to help the user move content between them. In fairness, I have yet to see a system that does /better/; everything is equally bad at it. There are a few feeble pipes like drag and drop, and the file chooser widget in any UI toolkit, but nothing fully functional. In the process of getting a document from one place to another, the abstraction we have will inevitably burn down, leaving the user to contend with raw file management. The most obvious example is when uploading a photo to a web site. It very quickly stops being a "photo" and starts being a "file," because the only integration we possess with the local system is the file picker opened by the web browser. Two solutions. The bad one everyone seems hung up on is over-engineering the one, poor, generic file manager so it does everything from rating music to playing slideshows and paging through PDFs. Don't do that. I've been pondering this issue, poking REALLY cautiously at a dead simple framework that should accomplish better interconnection between applications for the end user. Going against common sense, I'll post a link to some early ponderings... http://docs.google.com/Presentation?id=dgv4sbqn_23857c92hg The reason I'm poking carefully is because it feels too trivial and I'm afraid of building "yet another component framework" or a bizarre clone of drag & drop without the dragging. The plan is to plug in to what exists today for most types of data, allowing for seamless transition to awesomeness with very little extra infrastructure. It's really more about the design philosophy. My writing skills today are seriously broken, so I'll leave it to that little slideshow thing. Basically, I'm thinking of a framework and UI toolkit stuff that lets an application say "I provide content" or "I take content". This way applications could better interconnect, for example with nice context-sensitive application choosers. Opening a file from an application? Get a list of applications to browse for that file with. No more clicks than with a generic file manager, though considerably more logical. For example, the user may want a photo, so he chooses to open a photo and conveniently has the option to find said photo with F-Spot, or gThumb, or whatever application he had "stored it in" to begin with. It's about glue. It has to work both ways and it must be applied in lots more places. You can't have a towering menu and call that sufficient gluing, even if we do have drag and drop:) On the other hand, this also suggests that I think calling GNOME Shell "the shell" is somewhat flawed. The underlying philosophy with Calcium, no matter where it goes, is that /everything/ is the shell. (Hence the name; shells have a lot of calcium. There, if it has a pun THAT great, it must be awesome!). When an application is added to the system, it is an addition to the shell. Rhythmbox's music library should be no less a part of the shell than Nautilus or the GTK file chooser. It abstracts the storage of files, in this case music, allowing the user to choose them for some purpose. If we can accomplish that type of seamless, smooth bridge between everything, users will never need to think "files" unless they want to. Bye, Dylan PS: Sorry, my homework-fatigued brain thinks this message may be a complete jumble. Hope it isn't too bad...
Attachment:
signature.asc
Description: This is a digitally signed message part