Re: Applications Unnecessary

[José Luis Ricón <artirj gmail com>]

What you are proposing would require the apps to expose their capabilities (maybe through Dbus) and luckily there's a GSOC project on that line, so the base will be there if needed.

2009/5/3 Dylan McCall <dylanmccall gmail com>

> 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...

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list