Re: Recently Used Files Proposal



Emmanuele Bassi wrote:
> On Fri, 2005-06-03 at 10:14 -0400, Luis Villa wrote:
> > On 6/3/05, Emmanuele Bassi <ebassi gmail com> wrote:
> > > On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:
> > > > Emmanuele, really the best way to provide access to recent items in
> > > > application is menu.
> > >
> > > Even if I could agree, I'm still skeptical about this.  A menu is what
> > > it is used on some platforms, but I don't know if it's indeed the best
> > > way to provide all the data we need to know about a recently used
> > > resource.
> >
> > You're thinking this way, I'd suggest, because your use cases are
> > overly complicated. Consider this ridiculously common use case:
> >
> > * I want to open a file that I know I saved in the recent past.
> >
> > That's it. Very simple, very common. Currently, I can open one menu
> > (Places->Recent Documents) and 'solve' that user problem.
>
> What if you have more than one document with the same name?

That's a user problem. He shouldn't have more than one document with the
same name.

> What if one is a copy you keep on a network share?

What's the problem there?

> What if you want to open a document you edited some time ago (but not
> too long), and it went out of the menu?

Then it's not a Recent Document.

> This is what happens now with the Places -> Recent Documents menu; the
> recently opened documents menu item in the applications File menu
> currently cuts down the list size, but it is limited to a bunch of items
> (some times the limit is customizable, but commonly is hardcoded) - and
> having a menu with fourty items (many of which don't say anything about
> their state/location/whatever) is a complete waste of the user's time.
>
> > Covering that use case is the whole point of every recent file menu on
> > every OS. People don't care what month it was opened, or what day it
> > was opened, they just know that they opened it in the recent past, and
> > they want to open it again without digging into crappy FS hierarchies.
>
> Exactly.
>
> But users also don't save their documents with meaningful names;

That's their problem. Maybe
http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserDialog.html
should have a quick help or tooltip on how to correctly name files, if
you don't want to get mad later looking for them.

> sometimes they don't even look where they save their files - and this
> means that they have multiple copies around; they wish to get the file
> that they opened some time ago "surely not today, maybe yesterday or the
> day before"; users don't want to search - sometimes they don't even know
> how to search for a file.
>
> > Covering the more complex user problems is nice, but if you make it
> > too hard to solve this very basic need, you've defeated the point for
> > most users.
>
> I was just saying that a menu, even if commonly used, might not be the
> best way to convey the needed informations.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]