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?
The example you're giving is for an application that operates on files. In that case, naming the menu "Files" obviously makes sense.
But the obvious example of what op is talking about is Pidgin, an instant messenger. The first menu is called "Conversations". It has actions for operating on conversations. The application can't open files, or save files. At least not in the same sense as Notepad, Paint, Audacity, etc.
The calendar example is from the article, their suggestion is "Event"! But also, yeah that's a weak choice for me to pull from.
I guess my point is "File" is just consistent, not that it accurately represents the way the application functions. A lot of UX conversations come down to the naive-user experience, but truth be told, you're only a naive user for a short amount of time. Maybe a week into using macOS for example, I think you'll just mentally map "File" to that list of actions I have in my comment, and you're golden.
Yeah maybe conceptually it's weird that "New Tab" in safari is a File action... but also that's where every application puts its "New Thing" actions. If I want the application to give me a blank slate, I will look for File > New *. "File" is just a word.
If every application had it's own place for those actions that were named for the noun they act on, sure, the naive user touching a desktop OS for the first time is going to breeze through tasks a tiny bit faster, at the expense of the location/name/grouping of menu items now requiring relearning on an app-by-app basis.
There's an alternate history where the file menu is actually labled "Do" or something, and I would make the same argument. "I know what's in the Do menu."
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.
This use of "logging" comes from the "logbook", a book recording what happened on a ship, which was called that because a literal log (i.e. part of a tree) attached to a rope was used to measure the ship's speed.
> There is mostly no "log" that "logging in" writes to.
Um, there is, actually.
On the etymological front, "log" was originally an actual wooden log, dragged behind a ship. It then became the book in which measurements of the log's speed were entered.
The UCLA Computer Club had a log -- a book with dated entries. Someone augmented that with a wooden log ... an intricate culture developed around this pairing. Traces of this are preserved: https://americanhistory.si.edu/collections/object/nmah_69051...
(That drawing is a pretty good representation of the actual log. And there's another memorialized pun: MUS stood for machine unit second, which was the computing center measurement unit -- the Computer Club had a quota for submitted jobs [card decks].)
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.
Yes. It’s all about consistency and user expectations.
Apple guidelines for example, which have been in place for 40ish years:
> Best practices:
Support the default system-defined menus and their ordering. People expect to find menus and menu items in an order they’re familiar with. In many cases, the system implements the functionality of standard menu items so you don’t have to. For example, when people select text in a standard text field, the system makes the Edit > Copy menu item available.
Applications that don’t use the “File, Edit, View, [App Specific Menus], Window, Help” structure are really weird to use.
Example: a bunch of JRE apps on OS X. Circa mid-2010s, many didn’t follow the standard menu layout and were a little jarring (pun intended) and unsettling to use when you tried to navigate features.
> "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?
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.
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.
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.
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.
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
>Please do not abandon decades of UX tradition in favor of inserting tautologies into your programs.
Not just the File menu, but also MVC is one of many examples of decades-old UX tradition that should not be treated as sacred merely because generations of programmers have copied it.
The irony with MVC is especially rich: people are still cargo-culting terminology from Smalltalk-80 decades after the Smalltalk world itself moved on from that original UI architecture.
"Things seem to hang on in computing just because they work a little bit." -Alan Kay
That was his reply when I asked him about his thoughts on MVC:
>nobody can agree on what a controller is, anyway, except that it's the dumping ground for all the brittle junk and dependencies that none of the other well defined classes wanted.
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.
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.
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)?
Why would you add a new first menu? And what about the first one being important motivates changing the name?
There should be a positive case for any change. Some reason the new name is better, more useful, more intuitive. But I haven't seen anyone describe this yet, here or in the blog.
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.
Careful, you're going to trigger all the Kiwi Farms trolls, who will insist on "Master", then they'll demonstrate their commitment to free speech by downvoting and flag brigading us.
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:
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?The example you're giving is for an application that operates on files. In that case, naming the menu "Files" obviously makes sense.
But the obvious example of what op is talking about is Pidgin, an instant messenger. The first menu is called "Conversations". It has actions for operating on conversations. The application can't open files, or save files. At least not in the same sense as Notepad, Paint, Audacity, etc.
The calendar example is from the article, their suggestion is "Event"! But also, yeah that's a weak choice for me to pull from.
I guess my point is "File" is just consistent, not that it accurately represents the way the application functions. A lot of UX conversations come down to the naive-user experience, but truth be told, you're only a naive user for a short amount of time. Maybe a week into using macOS for example, I think you'll just mentally map "File" to that list of actions I have in my comment, and you're golden.
Yeah maybe conceptually it's weird that "New Tab" in safari is a File action... but also that's where every application puts its "New Thing" actions. If I want the application to give me a blank slate, I will look for File > New *. "File" is just a word.
If every application had it's own place for those actions that were named for the noun they act on, sure, the naive user touching a desktop OS for the first time is going to breeze through tasks a tiny bit faster, at the expense of the location/name/grouping of menu items now requiring relearning on an app-by-app basis.
There's an alternate history where the file menu is actually labled "Do" or something, and I would make the same argument. "I know what's in the Do menu."
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.
This use of "logging" comes from the "logbook", a book recording what happened on a ship, which was called that because a literal log (i.e. part of a tree) attached to a rope was used to measure the ship's speed.
See:
https://en.wikipedia.org/wiki/Chip_log
https://en.wikipedia.org/wiki/Logbook_(nautical)
In the modern computing context, "logging in" does involve adding entries to a kind of (digital) record-keeping tool.
Etymological fallacy: https://www.logicalfallacies.org/etymological-fallacy.html
I'm not applying this to your response but I immediately wondered if this exists on the site and it does:
https://www.logicalfallacies.org/fallacy-fallacy.html
I once heard a non-english speaker say "logining", and that made so much more sense than "logging in".
Noun versus verb.
Did you log in (space: split verb)? What is your login (no space: noun)?
Do you have a backup (noun)? Did you back up (verb)?
Very succinct Calvin & Hobbes quote: "Verbing weirds language"
Did you do a backup :-)
> There is mostly no "log" that "logging in" writes to.
Um, there is, actually.
On the etymological front, "log" was originally an actual wooden log, dragged behind a ship. It then became the book in which measurements of the log's speed were entered.
The UCLA Computer Club had a log -- a book with dated entries. Someone augmented that with a wooden log ... an intricate culture developed around this pairing. Traces of this are preserved: https://americanhistory.si.edu/collections/object/nmah_69051...
(That drawing is a pretty good representation of the actual log. And there's another memorialized pun: MUS stood for machine unit second, which was the computing center measurement unit -- the Computer Club had a quota for submitted jobs [card decks].)
- 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.
Yes. It’s all about consistency and user expectations.
Apple guidelines for example, which have been in place for 40ish years:
> Best practices: Support the default system-defined menus and their ordering. People expect to find menus and menu items in an order they’re familiar with. In many cases, the system implements the functionality of standard menu items so you don’t have to. For example, when people select text in a standard text field, the system makes the Edit > Copy menu item available.
https://developer.apple.com/design/human-interface-guideline...
Applications that don’t use the “File, Edit, View, [App Specific Menus], Window, Help” structure are really weird to use.
Example: a bunch of JRE apps on OS X. Circa mid-2010s, many didn’t follow the standard menu layout and were a little jarring (pun intended) and unsettling to use when you tried to navigate features.
> "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?
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.
Pierced the metaphor - elegant.
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.
Great satire, but how are you going to prevent some UX person at Apple from thinking this is good idea?
I don't think it's satire, and I'm not sure it's not a good idea
whoosh
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.
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.
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.
But I thought everything is a file in *nix OSs?
The true file was you, the user, all along.
And the links you made while browsing.
Which will be deprecated next version. Please log in with your cloud account.
That's not true; most of them don't represent network interfaces as files for instance. Plan-9 gets closest i think, and it's an outlier
Maybe 40 years ago.
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.
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
>Please do not abandon decades of UX tradition in favor of inserting tautologies into your programs.
Not just the File menu, but also MVC is one of many examples of decades-old UX tradition that should not be treated as sacred merely because generations of programmers have copied it.
The irony with MVC is especially rich: people are still cargo-culting terminology from Smalltalk-80 decades after the Smalltalk world itself moved on from that original UI architecture.
"Things seem to hang on in computing just because they work a little bit." -Alan Kay
That was his reply when I asked him about his thoughts on MVC:
https://news.ycombinator.com/item?id=8841428
>nobody can agree on what a controller is, anyway, except that it's the dumping ground for all the brittle junk and dependencies that none of the other well defined classes wanted.
https://wiki.c2.com/?WhatsaControllerAnyway
Mostly Very Confusing
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.
and this is why you don't want tech people designing user interfaces...
"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)?
Why would you add a new first menu? And what about the first one being important motivates changing the name?
There should be a positive case for any change. Some reason the new name is better, more useful, more intuitive. But I haven't seen anyone describe this yet, here or in the blog.
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
Careful, you're going to trigger all the Kiwi Farms trolls, who will insist on "Master", then they'll demonstrate their commitment to free speech by downvoting and flag brigading us.