Re: [HIG] Recent files

[Seth Nickell <snickell stanford edu>]

On Sat, 2002-08-10 at 01:38, Gregory Merchan wrote:
> 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.

You asked them questions. *buzzer* Sorry, play again. As Nielsen,
Norman, and Cooper say at different points, you cannot effectively
understand a problem by asking users questions. You need to watch what
they're doing, and *THEN* ask them the questions. The questions you
cited before were asking people to list things they didn't like about MS
Word, which is fine, but not necessarily a useful tool for directly
making a design decision.

> 
> > > 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.
> 

Huh? Recent files experienced a lack of of use ONLY IN GEDIT WHICH WAS
FOLLOWING YOUR RECOMMENDATION. Dude, people used Recent Files like crazy
in Microsoft Word, and Excel. At the time I didn't notice people weren't
using the feature in GEdit because its not what I was looking into that
day.

> > 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.

The problem is that the net effect of putting it by itself in a submenu
is to discourage it. I'm not saying you're intentionally discouraging
it, but that's what I would guess would happen, and that's what I've
seen happening in very small samples. Which is better:

1) A 4 item recent used list that gets used 90% of the time

or

2) A 15 item recent used list that gets looked through 10% of the time?

I don't have a big enough sample to pull up real reliable numbers like
"90%" and "10%", so those are bullshit. But that's the effect I both
theoretically expect to see, and the effect actually observed in a small
usability test.

> > > 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." 

"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."

I'm not caring too much what Matthew would actually comment on this
issue, so I'm not caring what context he put this argument in. What I
care about is that this argument has no outside dependencies. It doesn't
*need* context to be valid. If a seperate 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.
I want to avoid this problem. I think its more important than listing a
lot of items, because what I'm seeing is even worse than what Matthew
predicted. I'm seeing people not *using* recent files at all.

> 
> > 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.

Right, that's what happened. I've been itching to make this change for
months and I'm waiting until near release to avoid being shot down.
(FWIW, what happened is that I've been avoiding working on the Menus
section because picking up whole sections isn't so much fun, but I
finally realized it needs to be finished before HIG release (it has the
highest FIXME density right now)).

> I included that information because I'm arguing for what has shown itself
> to be better and not for my own personal preference. 

Very weak argumentation technique. "I'm not arguing for my own opinion,
I'm just arguing for what is known to be right"

> 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.

I also like this idea(s), at least some variant of it. We were pushing
to make things like folders based on queries for Nautilus (using Medusa)
but didn't have time for 1.0. I'm slowly working on pushing a generic
templating mechanism into GNOME. Etc.

> 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.

Yup, that's me. Glad to see you're still melodramatic and petty. Its just like old times.

-Seth