Re: [HIG] Recent files

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Aug 09, 2002 at 05:57:28PM -0500, Seth Nickell wrote:
> <snip>
> So basically, I was already aware of your card sort results, but I don't
> think they were the right tool for answering the questions we need answered.

Which is why I did more than just ask people to sort.


> > Believe it or not, I actually did some studies before writing things down.
> > To change that because you think it is "totally broken" reeks of fickle
> > irresponsibility.
> 
> Believe it or not, my change is based on studies too, studies which
> while not as precise are more appropriate to gaining the sort of
> information we need to make an informed decision. 
<snip>

What you describe is information that bears on whether to provide a list
of recent files at all; it doesn't bear on how to provide it. You say this
yourself:

> At the time I wasn't interested in File->Recent Files, and didn't really
> notice its lack of use, so I failed to inquire more in post session
> debriefing.


> Contrasting this relatively sparse Recent Files use in GEdit with the
> nearly 100% try rate seen in users of Office products, and about 60% for
> programming editors suggests to me that Recent Files is/would result in
> dis-use of an important feature. IMO, its abysmal that we suggest a
> change that seems to discourage people from using a feature with
> measurable time savings.

You're focused on entirely the wrong thing. This isn't about discouraging
anything.

As Colin said:
     I'm not discouraging it. I'm encouraging a better way of doing it. You
     can fit more items into a submenu.

> > A quick check on google shows that Colin Robertson (who also had recent
> > files as submenu before I rewrote the section) and Adam Elman both
> > concurred that the submenu is preferable. 
> 
> I found some arguments of Colin's which I found unconvincing, and I'm
> not particularly swayed by Colin taking one stance or another. I respect
> Adam as a designer (and would be somewhat swayed by him taking a stance
> on either side, even apart from whether his arguments fully convinced
> me), but I was unable to locate a message where he really took more than
> a wishy-washy stance on this. In general, I found he was arguing
> primarily in favour of not using a submenu. If you could link me to this
> argument that would be helpful. The closest I found was this:
> 
>   http://www.geocrawler.com/archives/3/267/2001/8/0/6475829/
> 
> Which hardly seemed conclusive.

You expect anyone to say something conclusive in GNOME? Ha!
On GNOME lists (and others) weakeners like "I think ..." and "probably"
are common and lack of them is considered flaming; unless it's Havoc talking
about something he maintains or Jeff actually flaming someone.


> > Two advantages mentioned are that by proximity
> > to Open and that having a name for the list makes it is more apparent what
> > it is. (I'll add that it's entirely possible to have a document named Close
> > or Properties.) Also, Matthew Thomas suggested that the main Open command
> > be on the submenu with the recent files list since most people will first
> > go to it to check if a file is recent. (Here would be a questionable use
> > of a conditional cascading menu like OS/2's  or a folder menu like MacOS's,
> > btw.)
> 
> Matthew actually adopts arguments that actually run somewhat contrary to
> arguing for a "recent files" submenu.
>     "Rationale:
>     *   It's not just muscle memory which is affected if some `File'
>         menus have an `Open Recent' item and others do not; it's also
>         the average speed with which users can open a file. If a
>         separate submenu is used, users will habitually go into the
>         `Open Recent' submenu *just in case* the file they want is
>         there, before exiting and moving back up to the `Open...' item.
>         If `Open File...' and the list of recent files are in the same
>         submenu, this problem is avoided."
> 
> In a nutshell, this is actually my primary rationale for not using "Open
> Recent". To summarize this argument in a slightly different order:
> "Open... and the recent files list should be in the same menu". Now
> Matthew thinks this menu should not be File but should be File->Open,

That's not summarizing his argument, that's taking it out of context.
You may as well justify all uses of force by "summarizing" the argument
that "In self-defense, use of force is acceptable" as "Use of force is
acceptable." 


> but that is not a can of worms I'm willing to open again in this release
> cycle (which should be over in less than a week and a half).

Lovely. Everyone should be aware that if you want a change you'll make 
it yourself near release time rather than discussing it and possibly
being shot down.


> If File->Open is not used, I think there's a convincing argument that
> placing Documents in a submenu will result in either that menu *always*
> being opened, adding the extra cost of a submenu access per File->Open,
> or people not using "Recent Files" at all (which given the way our file
> selector currently performs is a *huge* time waste). My own observations
> suggest that the latter would be true, though initially I would have
> guessed an extra submenu open each time.

This is more an argument for putting the list at the top of the file menu
or even in a menu of its own. Only in a UI were you place "Close", the last
thing you'd use, on a toolbar . . . oh, wait, that's GNOME.


> > My own inclination is to exlude recent files completely, but GNOME isn't
> > headed in the direction that makes that feasible. (John Blad agreed with
> > removing recent files from the menu, but to put in the open dialog 
> > instead.)
> 
> I don't understand why you'd want to exclude recent files. It saves
> people a lot of time. I'm guessing you have a better suggestion that
> helps with the same general problem (namely that time freshness is an
> important criteria for people choosing files, and needs to be usable
> with little or no conscious effort)?

I included that information because I'm arguing for what has shown itself
to be better and not for my own personal preference. My own preference
is to have reliable type recognition and handling, to be able to easily
create any kind of object (file, folder, launcher, etc.), to have folder
windows of reasonable size and shape to organize my work, to be able to
make folders based on queries, to be able to take a folder of some kind
of work and turn it into a template for later work of the same kind.
If you're thinking people don't work that way, note that they can't.


> Further compounding this whole issue is "status quo" and my desire to
> have an imminent release of the HIG. The status quo is currently what
> I've changed the HIG to. If we choose to put an item in the HIG that
> requires a change to a number of major GNOME applications, I want to
> have some confidence that its the right thing(tm). Right now I see a
> theoretical advantage (handling a larger than 4/5 item recently used
> list nicely) being played off against real world results that I myself
> have witnessed. The safe approach now is to not put in a guideline that
> I both disagree with, and breaks the status quo in GNOME applications.

Sounds like an argument for OK/Cancel to me. I should never have written
the patch to get that changed. Maybe Yes/No should come back too.

I'm so glad I quit. I wish I'd not even bothered with the first message.
Maybe Palm will make a tablet some day.

Keep reversing changes hashed out a year or more ago. Keep supporting them
with illogic and appeasement. I'll try not to give a damn; at least I don't
have to use it.

Ciao,
Greg