MS Windows applications usually implement these by having the four most recent documents with a sequential number in front as a mnemonic in the lower part of the File menu. macOS and some applications have a “Open Recent” submenu in the File menu right below the “Open…” command. Those usually have more than four items listed.
That is also the solution currently proposed in the section “Common Menus and their Contents” under “File Menu” in the Haiku HIG. It says to limit the number of entries to no more than 5, which I’d say would still be acceptable directly in the File menu if the File menu is as empty as in this example. On the other hand, I see little reason to limit the number of items to just 5 if a dedicated “Open Recent” submenu is used. For reference, Affinity Designer uses such a submenu and shows 10 items, Adobe InDesign shows 20.
What’s currently missing in the HIG is a policy that specifies what happens when a file is offline and can’t be opened. Some applications (eg. many Adobe programs) just give an error and remove the item when it is clicked. Some even use the error as a trigger to check all items and remove all offline ones in one go. Others just ask whether that item should be removed from the list, which I personally prefer since it doesn’t cause the application to lose valuable MRU items if the user just forgets to connect a USB drive or to mount a network volume. Another option would be to check file availability when popping the menu open and graying out the offline ones. That way the user wouldn’t have to click the item only to then find out it’s not available, but I have not seen this implemented anywhere.
Another point that could be standardized is how to deal with duplicate file names in different locations (eg. two different files named “letter.doc” in two different directories). InDesign for example shows the full path for only those duplicate file names and only the file name for others. It might also make sense to ellipsize the path in this case for very long paths using a suitable algorithm to avoid giant menus. Other applications just display the file name twice and rely on the user to know which one of them they edited more recently.
“Open Recent” submenus also sometimes have a “Clear…” command, the presence or absence of which could also be standardized.
Maybe amending the HIG in this area could be done as part of the GSoC project. A fairly consistent user experience has always been one of the big strong points of Haiku.
I split this to a new topic, as it deserves a separate discussion.
While out-of-scope for the Find-panel-GSoC-project, it’s something we can collect opinions here before amending the HIG. You’ve already made many good points.
IMO:
Keep 5 items in the history when directly under “File”, more items should get their own submenu “Recent files”
Check availability when creating the “File” menu, disable (“ghost”) currently not available files.
In case of identical file names, show the complete path only for those identical items. Middle-truncate paths longer than x chars.
A “Clear history” item under a separator should be added when there’s a separate “Recent files” submenu. When there are only 5 recent items directly under “File”, a “Clear history” item may be confusing. And with only 5 items, entries tend to quickly drop from the list.
Yeah, that sounds good. Though IMO 4 items directly under File would be more consistent with other systems and we could avoid the length of the item group getting out of balance compared to the other command groups in there (usually between 1 and 4 items, see for example MS Word).
As far as “Recent Files” goes, I’d suggest the title “Open Recent” instead since it makes it even more obvious what action will take place when clicking the item, while at the same time being consistently named with the “Open…” command.
I’d also suggest to place “Open Recent >” right under the “Open…” command like Apple and others do, whereas individual MRU items directly in the File menu conventionally go above “Exit” or “Quit” to reduce the amount of mouse travel necessary for the more frequently used New/Save/Export/Print commands.
Graying out items might cause a bit of coding overhead for running the check in a separate thread to avoid lags when popping up the menu since the file system needs to be accessed every time the list is shown, which could take up to a few seconds in the worst case. So maybe having some ready-made and well-tested utility code for this as part of the OS API might be nice.
This would better be done by supporting separate user accounts with different logins.
Someone who wants others not to see their recently used files would likely also prefer other users to not have access to their home/documents folders, browser history, email and banking programs etc. They would likely also have their own preferences, desktop background, etc.
There should be a “Privacy” or “History and search” preflet to be in charge of that kind of things, such as clearing recent apps/docs/places, the search queries, cleaning bash history, taking care of Web+ history, etc., some of which can be done by FilWip (3rd party app).
We already have recent files in the deskbar. I’m a bit confused what this is about? Do you want to add application-spefic recent files to the menu of each application?
This is not realistic advice. It is very common in a family setting to just use one account, or you simply forget to log out while you are doing something else.
Then how about a central storage, disabled by default ? Then, applications would submit the filenames to it for storing, and would ask if there are filenames for them. When disabled, the system would simply return “0 files” .
Not only in the DeskBar, but also in every instance of BFilePanel in the favorites menu. So are we talking about adding something that’s already been there for 25 years?
Depending on the application, this may however not be persistent if you restart the app, so there is room for improvement still
The discussion started as part of the Find Panel UI enhancement project, where there is a feature now that allows the user to load previously saved search queries using such an MRU list. My initial point was that if we add an MRU list, the implementation should conform with the Haiku HIG, but that the HIG is not very specific in a few points and that amending it in this aspect could ensure a more consistent experience across the system and our native apps in general.
Currently, the HIG explicitly mentions MRU lists in the File menu. Whether the DeskBar/BFilePanel list satisfies the same requirements for all use cases is certainly something that can be discussed. If so, the HIG could be updated to specify that no application specific MRU lists should be provided. Or it could be left up to the app developer, in which case it would still make sense to standardize the look and behavior for those developers who choose to offer one in their software.
I’m not in front of a Haiku system right now, but isn’t the Deskbar/BFilePanel one not one that lists all filles of all types used in all applications? If I’m using, say, something like a music notation software like MuseScore once a month, my last document would be extremely far down the list in a general system wide MRU list. But when I launch the application, having the last documents that were opened in that application available as a quick choice would certainly be beneficial, even if that was two months ago.
At least Windows and macOS have both system-wide “Recent Files” menus and application-specific “Open Recent” menus, so there seems to be a case to be made for having both.
Anyway, I’m neither overly passionate about this, nor do I suggest immediate action. I merely saw an oppurtunity to set guidelines for a more consistent user experience across the system, which I already consider one of the strengths of Haiku. A lot of great UI/UX is just getting the small details right.
It is my understanding that application in Haiku generally already have this based on a querry. (Or should have this based on a querry). So in my understanding the initial problem of “showing deleted files” should never occur in the first place.
Before adapting the guidelines we should investigate what the problems are with the current design.
It’s true that we had a kind of MRU list with the recent apps/docs in the Deskbar and also in the file dialog. However, the are not persistent, but just work for the current session. On reboot it’s gone.
I also doubt it makes sense to change that at those locations. You just cannot keep a persistent MRU for every one of your dozens of applications and all the files those apps opened.
This is a feature the app should provide. It’s useful to present to the users a list ofthe last opened files, even if they haven’t launched the app for 6 months.
Also, having a short MRU directly in the File menu beats having it e.g. in the file panel. Just count the clicks needed to load a recent file.
True. The app could add a “last opened date” as attribute and query for that to pick the last 10 or something. Of course this would only work with files on BFS volumes. Is that a caveat we could live with?
That “last opened date” attribute should be standardized, so we don’t end up with everyone adding their own attribute to the index. META:last_opened maybe?
That querries only work on BeFS is true, but that is a bit of “eh, that is the way it is” for me. Can’t do much about other filesystems not supporting querries
I’d be OK with it working on BFS files only.
OTOH, this topic is about the HIG, i.e. the implementation isn’t prescribed, it’s just suggesting that “good Haiku app-citizens” should offer a MRU list, and suggest where to put it and name it (“File | Open recent…” or a short (4?) list directly in the “File” menu. BTW, I’m not totally sold on putting the MRU above About and Quit…)
That said, can Haiku provide some assistence here? Does the Registrar register ( ) what application open which files when? It would be nice if there were an API to ask the system, “Give me a list of the last 10 files opened/saved with {application-signature}.”, and have the system take care of setting attributes, querying them etc.
Hmm. After some more thought…
Not sure adding a “last opened date” attribute makes much sense. The app still needs to keep a list of recent files. Sure, you should check with a query if the file is still available and not show it in the list if it’s not found.
But querying for anything else makes no sense. The app could just as well save the “last opened date” with the file paths. Plus many apps can open that file, so using any queryable attribute won’t work either. Imagine opening an image with ArtPaint, then later with another app…
Anyway… Let’s keep this thing on track and discuss only the GUI part. Implementation is left to the app, though it would be nice if the bundled Haiku apps gave good examples how to do it right.
Keeping offline files in the list could still be useful as a cue. If there is a disabled item, the user is faced with the situation “That file I want isn’t available, I guess I should mount the network volume”. If it’s not listed, it may be more of a “huh that file I edited yesterday isn’t there any more! Maybe it didn’t get saved? Or did I maybe use another app to edit it?”.
On the other hand it’s also a tradeoff because it takes away spots in the list.
You’d end up with a dozen LastOpenedWithXXX attributes hanging off the file. Doable, but I think we keep getting back to the point that this is an issue for app developers, not for the OS.
Would it make sense if apps were always showing last five files opened and a query would make names appear greyed if not available?
The app would take care of the list. If there’s one, there would be a clear list entry after it. All apps lists would be stored in the same dedicated config directory to allow an user to wipe the folder and clean all apps in one move.
) what application open which files when? It would be nice if there were an API to ask the system, “Give me a list of the last 10 files opened/saved with {application-signature}.”, and have the system take care of setting attributes, querying them etc.