I understand the complaint but a lot of these suggested improvements aren't great either, especially the ones that are close to the name of the app and so would be right next to the app name which is itself a menu header. "Password" right next to "1Password" and "Automation" right next to "Automator" would drive me batty.

Maybe the real fix is to consider if you need a File menu at all, and whether most of what has been shoved in there should go under the app name menu bar item instead.

It feels like "File" became a de-facto "Start" or "Main" menu.

I always appreciated the rare times when an application would use something other then "File", such as "Game" or "Room" for chat apps.

While I don't agree with some of the suggestions I appreciate the author took the time to at least propose solutions.

But I thought everything is a file in *nix OSs?

It's an interesting point, but I think the benefit of having actions related to the main object(s) that each application deals with in a standardized place that people expect ("File") outweighs the cognitive load of needing to figure out where those actions might be in every single program.

It's a real Chesterton's fence situation. There's a lot of latent information contained in a tradition of calling the first menu item "File" including expectations around what can be found there.

You could also say it pierced the metaphor and no longer refers to files on a computer, but to the concept of filing that computer files were named after.

That's how language works. Eavesdropping once referred to water dropping off the eaves of a roof. There is mostly no "log" that "logging in" writes to. The menu itself has nothing to do with food or eating. Is the meaning clear to contemporary readers or listeners? Yes.

It’s more of a throwback to an age where the majority of the apps are creators and editors of documents embodied as files on disk, giving users the freedom to move, rename, copy, and otherwise organize files. As soon as apps began to manage their own data storage through a SQLite database or even the cloud, the File menu stopped making sense. We still keep it because we are romantically attached to it and it harkens back to an age where users had more control over data storage on their computers.

File is File not exclusively because it has to do with files (though file-related actions should also be there) but because of relative significance versus the other menus

In the "File" menu you are doing something that has the potential to fundamentally alter the app you are using, by tampering with (typically a large portion or even all of) the data files it contains, or by resetting the state of a running session (file > new window in browsers)

"Edit," semantically, is the same but for a subset of that data, often only a single piece of data. Here I'll sustain that the "create a singular new password/event" button could be under Edit, not File, since those are not actions scoped to the whole app or to the filesystem, instead only to individual records in a database.

"View" is read-only and actions under here should not write anything anywhere. And so on.

Please do not abandon decades of UX tradition in favor of inserting tautologies into your programs.

(1Password/Passwords, Automator/Automations, really? might as well put a pictogram there rather than duplicate the word - I already know what the app does, I want the UI to signal what scope my actions are applying to)

"Project" for DaVinci Resolve makes sense, probably because it's a synonym lol

- Notes: note

- Messages: message

- Passwords: password

- Reminders: reminder

[...]

Most of propositions are restatement of the app name or theme thereof, and thus do not seem to be very helpful (everything in a notes app has to do with "notes" one way or another). Plus, having naming conventions change per app is confusing. The "file" menu is usually about "(primary) actions" and "I/O", so I would rename all of this as "actions". However, "file menu" has been associated with these kind of actions, and it is fair to consider a liberal interpretation of the word broadly referring to organisation of data (wherever this lies) and creation of new data structures within the app (not just filesystem level).

The nomenclature is largely derived from history. We called it that, so we continue to call it that. While I think changing it is possible, changing it to something new across many applications does more harm than good. We all understand that a floppy disk means save, a camera shutter sound means a picture has been taken, etc. The brain is good at associations based on past experience. Especially for those that are less tech-savvy, this is a god-sent. I like the core concept the writer here has in mind, but I think it fights against built-in brain conventions too much.

and this is why you don't want tech people designing user interfaces...