Re: [HIG] Recent files

[Seth Nickell <snickell stanford edu>]

<snip>

Card sorts are a tool for understanding how users categorize items, not
something that can always be directly translated into a menu structure.
I do not know of an accepted technique for using card sorts to determine
item prioritization, visibility, or information dependency (all of which
play major factors in this situations). Card sorts also provide only
vague information on category granularity (how fine to make
categorization). It would suprised me if users did *not* card sort
recent documents together into a seperate category. 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.

> 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. Categories simply
aren't that relevant here. My observation(s) are based on watching and
jotting notes on more than 15 users from my dorm on their personal
computers, and several administrative assistants in our computer science
department, is that the majority of people open the menu, bring their
cursor down near open (or directly on it), and then glance to assess
whether their file is in the recent files list. If it is, they click on
it, otherwise they click "Open". Subjects who were asked to talk aloud
(when they actually mentioned this) basically confirmed that this is
what was happening (well, nobody mentioned that they moved their cursor
down near open first, but they mentioned scanning the recent files list
for the document they wanted).

On personal computers and administrative assistant computers I observed
approximately a 50% sucess rate for opening documents from Recent Files
list rather than having to result to File->Open. If you measure the time
it takes to scan the list (including the misses) and then click on the
item if its there, vs. always using File->Open..., you can see that a
lot of time is being saved by the presentation of Recent Files. This
suggests to me that Recent Files is providing a valuable shortcut.

I also conducted smaller scale, but more highly ordered tests on GEdit
(which follows the File->recent files convention), which resulted in
Gedit being closed a number of times, and a number of documents being
worked on. Only one user out of 5 actually used recent files in GEdit
for accessing documents they had already opened; and this in spite of a
number of complaints about the file dialogue (particularly in
post-session debriefing). 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.

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

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

> 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)?

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.

-Seth