I failed to add. It's all about flow and not breaking it. When the person is in one context (into music/photos/documents/etc), we do not want to break his flow by letting them go to different places. The person does not need to jump to different places to get things done. A "hub" or "context" has all relevant tools collected in one place.
On Mon, Mar 1, 2010 at 10:26 AM, Allan Caeg <allanc...@gmail.com> wrote: > Hello Timothy, > > The Gloobus apps extend the file manager's features by adding quick and > attractive ways of browsing and opening files. They are better than nautilus > without them because they save valuable time of people and computer > resources. > > This is great for people who use the file manager to open files. I'm > thinking about a user like my cousin, who opens every music file on the file > browser instead of searching music on the music player's library. This is > also great for me, who doesn't use a photo manager. > > The idea I have now is to integrate the apps that manage files and open > them. That's just a quick idea, though. Feel free to suggest. > > The objective behind is to create "hubs" for contexts. If a person wants > music, he goes to one place where all tools related to the context are > available and integrated. That could be the "Music" folder opened on the > file manager, where files (songs) are presented that is fit for the file > type and all the other apps related to music are easy to access from there. > Gloobus preview opens a file very quickly when the user presses the space > bar. > > Looking forward to hearing more from you on this list. > > Regards, > Allan > > On Sat, Feb 27, 2010 at 7:09 PM, Timothy Czyrnyj <tczyr...@gmail.com>wrote: > >> Hi Allan C. >> >> I'd love to hear more of your thoughts about these projects you've been >> linking to. I think you've given a good overview of how they work, but I'd >> be interested in hearing a more critical evaluation of them. >> >> What do they do well, what do they allow the user to do that they couldn't >> before, or why is it more efficient? Conversely, what do they do more >> poorly than what we have now? Why should we want something like that in >> gnome? >> >> (also first time posting, so hi everybody) >> -- >> Timothy >> >> >> On Fri, Feb 26, 2010 at 9:55 PM, Allan Caeg <allanc...@gmail.com> wrote: >> >>> 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 >>> >>> >> >> _______________________________________________ >> 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
