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 <dylanmcc...@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 > >
_______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
