Bug 329546 - [UX] Usability: Provide a "File > Recently Opened Files" menu
Summary: [UX] Usability: Provide a "File > Recently Opened Files" menu
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-05 09:31 EDT by Martin Oberhuber CLA
Modified: 2019-09-06 16:07 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2010-11-05 09:31:11 EDT
Build ID: Eclipse SDK 3.6.1

The Eclipse History (Navigate > Back) provide some means of navigating to files previously opened, but for many first-time users it's not intuitive. Most users of other Editors or IDE's expect having a "File > Recently Opened Files" menu for navigating to files they had previously visited but closed.

For improved usability, I'd suggest adding this since it's perceived as common functionality across applications.
Comment 1 Remy Suen CLA 2010-11-05 09:45:13 EDT
(In reply to comment #0)
> Most users
> of other Editors or IDE's expect having a "File > Recently Opened Files" menu
> for navigating to files they had previously visited but closed.

We have a dynamic menu at the bottom between 'Properties' and 'Exit' that shows the last N recently opened files (where N can be tweaked in the 'General > Editors' preferences).

How does this enhancement request exactly differ from this list?
Comment 2 Dani Megert CLA 2010-11-05 11:32:45 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > Most users
> > of other Editors or IDE's expect having a "File > Recently Opened Files" menu
> > for navigating to files they had previously visited but closed.
> 
> We have a dynamic menu at the bottom between 'Properties' and 'Exit' that shows
> the last N recently opened files (where N can be tweaked in the 'General >
> Editors' preferences).
> 
> How does this enhancement request exactly differ from this list?

Correct. That gives faster access than another nested menu.
Comment 3 Martin Oberhuber CLA 2010-11-05 16:50:37 EDT
I have the following usability problems with the current approach:

1. The approach without menu nesting doesn't scale well to lots of files.
   The Preference is limited to 15 entries.

2. The current list shows the _recently opened_ files, but I am more 
   interested in _recently closed_ files. Because those that I recently
   opened are typically available as editor tabs anyways.

   Example: Create new file foo.txt and close the editor --> The file is
   not in the recent list, how to find it again for continued editing?

   Example: dbl click on about.html in a Java/PDE workspace. You will get
   2 new entries in the "recent" list (one for about.html, the other for 
   the web browser). 2 older, likely more interesting entries are thrown 
   out of the list.

I know that apps like MS Office 2000 also have a list of recent files directly in the file menu. But these apps do not have editor tabs. Most editors that I know of have a sub-menu for recent files such that the submenu can hold lots of recent files. 

I do not buy the "faster access since no submenu" argument because I do not need access to the recent list so frequently. For those default 4 items I have there, I can use the editor tabs. I'd be interested in 20 items and would thus prefer a submenu.
Comment 4 Remy Suen CLA 2010-11-05 16:54:33 EDT
(In reply to comment #3)
> 2. The current list shows the _recently opened_ files, but I am more 
>    interested in _recently closed_ files.

Recently opened but actually recently closed. This could be confusing to the user. I certainly was confused by the original bug summary.
Comment 5 Eclipse Webmaster CLA 2019-09-06 16:07:45 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.