Re: [Usability] New Paradigm of Computing for GNOME 3.0

[Allan Caeg <allancaeg gmail com>]

Hi All,

You might want to check out Gloobus http://gloobus.net/ . It consists of 3 projects that let people browse through and open files on Nautilus. It does the job quickly, efficiently, and in a presentable way. It also feels very integrated to the file manager. This is one of the ways that can help us change the way we interact with files. 

Got ideas? :)

Regards,

Allan

On Sat, Feb 13, 2010 at 1:07 AM, Dylan McCall <dylanmccall gmail com> wrote:

On Sat, 2010-02-13 at 00:32 +0800, Allan Caeg wrote:
> Hi All!
>
>
> Thanks for the ideas. To be clear to everyone, I never proposed the
> removal of access to files through a file manager. You're right. On
> the desktop, there's a number of reasons why the file manager should
> be available. Actually, I believe that the file manager should also be
> visible on the iPhone and iPad. It's nice if things work smoothly
> without needing a file manager, but there are some instances when we
> need one.
>
>
> I agree with Allan Day's idea of a document manager. Perhaps, this is
> one of the things operating systems need. It's nice that, by default,
> distros have folders like "Documents", "Templates", "Music", etc.
> However, like what Ian said, I think it would be better if the view of
> the file manager is more fit for the nature of files inside a certain
> folder in general and not just for documents. Actually, I know people
> who play music on the file browser. They look for their songs on the
> file browser then double click them to play them on the media player.
> Personally, I also don't use an image browser. I view them all on
> nautilus.
>
>
> What can you suggest? :)
>
>
> Regards,
> Allan (Caeg)

This discussion (and the Actions spec discussion on FD.org) is quite
interesting to me. I've been quietly poking at something which may work
here :)

Nothing to show yet, since it's mainly just a rough design at this point
(I'm working on a basic implementation, albeit amongst too many other
things, in the interest of having a cohesive vision before putting it
out there). The idea is for individual applications to define sinks and
sources for files. So, Cheese acts as a source for files of type
image/png, Banshee is a sink and a source for various music formats.

Then there's a switchboard daemon running in the middle which will be
aware of all these sinks and sources. Applications looking for files
talk to it, and it provides them a list of possible sinks / sources that
will provide a file of the given type. Ultimately the application
decides on one, so a transaction is created and the application
communicates with the selected sink to either give it a file or get a
file (or multiple files) from it.
It's a little bit unusual because "an application deciding on something"
is usually it asking the user to choose / create something.

This basically allows any application to act as a file save or file open
dialogue. LOTS of cool stuff then appears:

     * As discussed here, we aren't torturing the user with the file
       system. There is a SERIOUS problem in the current approach.
       Applications such as Rhythmbox, Banshee, Cheese and F-Spot try
       to abstract files away so that they are music and photos. This
       works great, but as soon as the user wants to do something not
       supported by those applications (such as uploading a photo as an
       identi.ca profile picture), they turn back into photos. This is
       WORSE than having no abstraction at all. (And that's saying
       something, because making users work in the limited world of
       files and folders is ridiculous).
     * Android has file pickers running out of process for a fantastic
       security goal: an application is only given access to the user's
       files if he explicitly chooses them. That could be done here.
     * Today's file managers don't work well when we have multiple
       applications for a given file type. So, while we're at it, we
       can kill off the Open With menu and reinvent the double click.
       One click opens a bubble with information about the selected
       file and a list of applications which will do stuff with it. A
       second click on the file icon opens it in the default
       application, or the user can pick a different tool really,
       really easily.
     * A bit of fiddling with sources and we could have a button
       wherever a file does not exist but could. Clicking it could open
       a picker much like the file open picker, but to create a file.
       The point here is to create a consistent flow of steps for
       people, so they don't need to switch erratically between opening
       applications from the main menu and opening (or saving) files
       from the file browser.
     * Hints (open-ended key / value pairs) every step of the way. For
       example, I'm jealous of how MacOS's Finder gets a little
       animated transition when a folder opens into a new window (it
       shows that new window coming out of the icon). I think we can do
       better :P

So, err, basically I'm doing something along these lines. If someone
wants to beat me to it, I would love to know so I can help out! :)
Most of the trickery here will be in how the surrounding applications
use it, after all.

Bye,
Dylan McCall

_______________________________________________
Usability mailing list
Usability gnome org
http://mail.gnome.org/mailman/listinfo/usability