The "File" menu isn't about files

Contrapoint: your application isn't special enough to break patterns.

Opening a calendar application, clicking on the "Event" menu, and being given options to make a new calendar makes as much sense as opening the "File" menu and seeing the same options.

If you split it up so any menu item that verbs a noun, had a top level menu named by that noun, you'd end up with New/Delete/etc actions being split into many menus, which feels just as wrong.

"File" works because of inertia, and people have a feeling of what should be in there:

    - new thing
    - save thing
    - copy thing
    - open another thing
    - rename thing
    - send this thing somewhere
    - import a thing in another format/export thing in another format
    - close thing, but don't quit, send me to some start screen please

It's vaguely related to the file/container you're looking at, but I wouldn't even say that's hugely important to most people's use of the file menu. It just has to have those things in it because honestly, it's pretty consistent. Other than a few examples in the article (Find My with it's always-disabled options, Reeder clearly having already moved all of it's menus into Account/Subscription/Item nouns) the file menu lines up with what I expect to be in it. Maybe that's me stuck inside my own bubble?

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.

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

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.

Any imports and exports are going to involve external files in almost every case. This is an attention grabbing headline that ignores the value of semantic consistency across applications. Everyone understands that the File menu is about doing things that will entail interactions with the underlying file system and that it's not real until you save it. We're not better off by putting these more or less similar functions under menus titled 'Picture', 'Document', 'Project', 'Song' etc.

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.

Great satire, but how are you going to prevent some UX person at Apple from thinking this is good idea?

Check the HIG. It says to use 'File'. I'm sure the goal here is consistency. It's a Human Computer Interaction (HCI) fundamental principle.

https://developer.apple.com/design/human-interface-guideline...

> "File" – You could argue that Items are files, but are they? You import and export files, ok, but what am I actually importing and exporting? Right, passwords!

This seems really weak. What's the benefit to the user of changing "the menu for saving and editing items" on a per app basis?

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.

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

The "File" menu is about CRUD operations on file-level objects.

I think eventually (~decades) the concept of the menu bar will go away, but until it does, File is a fine name for the first menu on the bar. I don't know what it will get replaced with, but it will go the same way as the Save icon—a relic that was a good design at some point, but no longer has much basis other than inertia, and will slowly get forgotten as it becomes obsolete.

Export and import don't have to do with files? Glad they started with that one so I knew I didn't need to read the rest of it.

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.

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

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

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’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" menu is about "Filing".

Back in the days all the things you would create using the File-menu would be files, because what else would it be???

A benefit of that system was that all documents and data could be easily treated as files - and moved organized as you pleased.

Somewhere along the line someone clearly decided that this was too simple and made storage opaque - and now you never know where anything is stored - and how or where to organize it.

I'm not sure I consider that an improvement.

For all comments saying that it is a standard and shouldn't be changed, I think the standard is that the first "menu" is the important one, no matter how it's called, so for this reason it should really be changed.

Imagine if you move the file menu to the middle. Will you still be quickly able to find it "because it's a standard" or instead click the new first menu (and then spend several minutes trying to find where the "New window" option is)?

OK, let's do this:

It isn't a hard drive. What's being driven, your mom? It definitely isn't a hard disk in most cases, either, because SSDs are so common.

It isn't a screen. What's being screened out? Is it a monitor? I don't know, is it? Are you monitoring things? If not, then it isn't.

It isn't a mouse. Mice have tails, and also are small living mammals with respiration and without buttons.

It isn't a touch pad. It is touched, but it's also stroked and tapped, so calling it merely a touch pad is inaccurate.

My point, of course, is that language is purely convention, and trying to nitpick all of those conventions quickly leaves us with nothing. There's polysemy and semantic drift and as long as there isn't confusion there also isn't a problem.

Main