Why does the New menu even exist for creating new empty files?
What’s the point of having a New menu anyway? “Why would anybody create a new BMP file by right-clicking an empty space in a folder? You still need a BMP editor to put anything meaningful in there. The same is true for a PowerPoint presentation, and an Access database. Although, creating an empty Access database and then opening it will presumably get you the Access program. But if I want to create a new PowerPoint presentation, I will… um… open PowerPoint.”
Sure, maybe that’s what you do, but that’s not what everybody does.
Not everybody knows that the way to create a new BMP file is to open this program called Paint that is hidden in the Accessories folder of your Start menu. User research shows that for many users, the way they create a new file is to find an existing file of the same type, copy it, then open the copy and delete everything in it.¹
In fact, in the Xerox Star (the precursor to our modern GUI interfaces), creating a new document is done by copying an existing one.
For people with a document-centric view of the world, programs aren’t really things that you think about. What you really work on are documents.
It’s like making a telephone call in the United States. You don’t think about which telecommunications company serves that number. You just dial the number and let the telephone network figure out which telecommunications company is responsible for that number. You don’t really care which company gets used, as long as you get connected.
As other people noted in the comments, having a New menu is handy because it lets you create the file directly where you want it, saving you the trouble of having to navigate through the Save As dialog just to get back to where you started.
¹ And who among us can say they never created a new class or project by copying an existing one, and then deleting everything inside?
Even Unix follows this pattern for process creation! To create a new process, you clone an existing one (fork) and then delete everything inside it (exec).
Light
Dark
29 comments
While the use case and justification seem reasonable, the solution leaves some strange gaps, like if I use the New -> BMP File, I get a zero byte file, which will not open in Photos (and Photos reports that it doesn’t support the format). This seems like a solution that worked well for plain text files, but probably not much else. A better option would probably be for applications to register themselves during installation as an application that can create a particular file type, and then could at least create a valid file of that type, like a fully transparent image file, or an empty PPT, word document, etc… I’m not sure how you’d deal with multiple applications supporting the same file type, like having both Gimp and Photoshop installed, but there’s options there.
The New menu shouldn’t open the app in question (except for Access for whatever reason), so it doesn’t matter if multiple apps can open a file type. You make the file, then click to open it at which point it’s a normal file that will get opened by your default app. That’s why you get the Photos weirdness, it’s typically the default app that opens picture formats. Your “better” seems it would just cause confusion.
I use the New menu all the time for text files (which I then often change the file extension, Word files, and Excel files. I wouldn’t want the New menu to force open Notepad just because I made a text file as I’m often going to change its extension.
You wouldn’t. This would be an option set up per handler, not global.
In fact, it already exists. You can register new “new item” handlers, and you can specify to Windows how you want the new file to be created: a null file(zero-byte data file), or with a set of default contents you provide, or a copy of an existing template file, or even to run a program to generate a new file.
Note in that last case you aren’t supposed to run a whole UI program; you’re supposed to invoke some sort of batch command that causes the program to generate the new file you need.
In the case of text files, you can just leave it as the null handler. For images, you could invoke an image editing program that just spits out a blank, but valid, image file, and then immediately exits, instead of opening the full editing UI.
I’m sure back in the Windows 9x days at least there was a way of supplying template files for the New context menu. I suspect that functionality still exists – whether any applications use it may be another matter of course.
There are actually several ways to define the contents of a “New” file, including copying from a template file, having the template data directly in the registry, or even running an application.
https://docs.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#extending-a-new-submenu
Though I don’t know if the problem with the 0-byte bmp file is whether the new file handler is wrong (that is, a 0-byte bmp isn’t spec compliant and thus there should be a template for it) or whether the Photos application is wrong (that is, a 0-byte bmp file is valid and thus it should handle it).
Really it seems like there should be an easier-to-use connection between the folders as seen through the file viewer and the open/save/etc. dialogs within applications. Windows treats the file dialog as a complete file-folder window, where you can rename, move, drag-and-drop, and otherwise manipulate everything while saving on opening a file. Macs, on the other hand (at least when I last used one regularly) have this interesting trick where you can drag a file from a folder into a save/open dialog, in order to change the directory of the dialog and select a file. I find that I kind of want both behaviors, where sometimes I want to drag-and-drop to mean “move/copy a file” and sometimes I would want it to mean “look here at the same thing that I’m looking at in this other window”.
It’s just really awkward a lot of times how I have a window where I want it, but then (to save a download in a web browser or whatever) I need to like copy-and-paste the address bar into the save dialog box’s address bar to get it to the same point.
Rereading my comment here, it might not be as clear what the connection is to the article as it originally was in my mind, but I think I’m trying to get at that the system (both Mac and Windows, though with different tradeoffs) tries to support both a “document-centric” mindset and an “application-centric” mindset and doesn’t make it easy at all to switch between the two (much as the article’s example demonstrates).
The RISC OS save dialogue goes the other way – it contains only an edit control for the filename, and an icon which you drag to the folder window where you want to save it.
What increases the aggravation when saving files under Windows is that a lot of applications re-implement the file dialog and do it badly (no names, no packdrill).
mspaint… and then you have to remember that ctrl^s will overwrite an existing file haha meh.
What else might you expect it to do? This is what every other application does.
Not exactly *every* other application:
The Photo Viewer Applications I know will default to save a copy if you do edits in a photo.
I’m not faulting mspaint, being the simple bmp editor it is, to just overwrite the current image file on save.
Seeing as other concurrent programs that display (and edit) images do not necessarily do this, this can be annoying.
Indeed, while Ctrl+S might usually be Save, sometimes it’s Save-As, and sometimes it’s something completely different, especially in programs that don’t even create files.
Apparently, things have changed. Windows 11 has gotten rid of the New menu. A Microsoft blog post says the Windows development team is disposing of the unused context menu items based on telemetry.
Windows 11 still has the New menu, and it was migrated to the new context menu. I don’t think things migrated to the new context menu would be going away! It’s still early though.
“As other people noted in the comments, having a New menu is handy because it lets you create the file directly where you want it, saving you the trouble of having to navigate through the Save As dialog just to get back to where you started.” That may work for a document-centric view of the world, but for other viewpoints, that process doesn’t make sense. Personall,y I don’t see the point in navigating to the place where I want to store the file, then creating a new one, and then filling in the content; I start the program first, to get my ideas down on “paper” so to speak, and then save it in a folder of my choosing. So there’s no “just to get back to where you started” in this viewpoint because I started with the editor program, not the destination folder.
You’re assuming that you’re navigating to the folder in order to make a new file. In most cases, you’d already have the folder open for other reasons like organizing or processing files and then create a new one in there while you already have it open. Moreover, it’s much easier to navigate to a folder in the File Explorer than it is to navigate to a folder in the Save As dialog (even though they’re—usually—essentially the same thing, the Save As dialog is smaller and has pitfalls like accelerator keys that can trip things up).
“You’re assuming that you’re navigating to the folder in order to make a new file.” I was replying to Raymond’s assertion about users’ workflows and “getting back to where you started” when using save-as in an app. Maybe you do have your target folder open in a window when working in an editor app. I personally don’t, but I’m not here to advocate my own way or working as the One True Way. There are more workflows than users (when you consider that user workflows evolve over time as users learn new shortcuts, new UI elements, new software, etc), all of which are valid.
If you have your target folder open, and you dislike browsing folders in the Save As dialog, then you can simply copy the address from the open window into the dialog box. That’ll circumvent those pitfalls that you’ve mention and is nearly as quick as the New menu.
As a programmer I use this constantly. VS code handles making new files OK… But making a new file in VS proper is so easy to get wrong that I never use it to make new files.
I’ve worked at a few places where there is a strong guideline to never create files with VS due to the bad default locations and poor handling of additions to the project and filter files.
I like the “that’s not what everybody does” thinking.
By that logic, why not restore the beloved Recent Items entry in the Start menu? You could even fix it, by allowing Open File location to work even if the file was renamed (after all, it is the location you want to access). Sure, you now have something similar on a per-app basis. But that’s not what everybody does 🙂
And the beloved Quick Launch Toolbar also had one good thing that was lost with all the recent innovation: you could put many small “launcher” icons at predictable, immutable locations which would not jump around, and which you could access by muscle memory alone. Why not restore something similar, perhaps blending in the more powerful right-click taskbar menu options?
While I enjoy always using the latest, I so very badly miss both features of older systems.
Tangential, but germane—I wonder at least weekly why WinOS lacks a native touch command. (as a native cmd command, system32 exe or even something in PowerShell or pwsh). Just something easy to call on from a shell.
I’ve used copy con file.txt. Not as easy as touch and not scriptable since it requires ctrl+z to save the empty file.
Use
Interestingly this didn’t work with COMMAND.COM which would just say “0 file(s) copied.”; instead I believe you could use
rem > file.txt(note that this doesn’t work for CMD.EXE).REM doesn’t work, it comments out the redirection, but REN will work.
I have touch.bat in my path containing:
which handles both creating an empty file and updating the timestamp on an existing file.
You can mimic touch by just setting LastWriteTime on a file in PowerShell. Would be fairly easy to alias it if you do it often enough I suspect.
I always thought of this as:
Notepad is an app for viewing and editing text files, which contain characters. It lets you delete, change, and move/copy existing characters, and also add (type) new characters.
Explorer is an app for viewing and editing folders, which contain files. So it makes sense that besides deleting, changing, and moving/copying existing files, it also lets you add (create) new files. 😊
Maybe not literally true, but a nice mental model to entertain for a few moments’ entertainment!
This was probably a good justification 15-20 years ago, but for a very long time now this method pretty much only works for your office suit documents. For the most common files, your standard program to open images is not an image editor, the standard program to open PDFs is not a PDF editor, and the standard program to open multimedia files is not your DAW or video editor. And so on.
This explains though why when I open up the New menu today, I only see entries for Office documents, Text files, and Photoshop. For these types of files, yes the menu choices make sense. But now there’s a discrepancy how to create new files. “For these types of files you can do ‘this’ [use the New menu], and for other types you have to do ‘that’ [start the correct app and go from there].”
Frankly, while I do understand that you shouldn’t need to know the name of the program to open files, this does not reflect reality when creating or editing new files. You might not care or know what your standard viewer is, but people who create and edit files do know what their editor is.
Eg. if sharing stuff on eg. Android I will get the choice of what app i want to share with. With same logic it would make sense that New gave a choice of what app I want to use to create and open the new and empty file? I assume in most cases the user will open the new and empty file immediately after, not being happy with just having created an empty file?
I for one hope this function isn’t removed because it is MUCH more convenient to create a file in a folder that’s already open than to run the program (and wait for it to open if it’s a big, bulky, bloated monster), create a new document, then slog through the Save-As dialog to re-navigate to the folder that I already had open (while trying to accidentally save in the wrong folder or accidentally close it and have to start over again) and then save the file.
This is especially true since I don’t always intend to actually create the file right there and then, often I want to create a file, give a descriptive name about what it will be, then work on it LATER.
The Xerox thing is weird. To make a new document, you have to copy an existing one, but where did the original -chicken- -egg- document come from? If a compiler is written in itself, where did its original compiler come from? Did God create himself? 🤔 Who knew computers could be so existentially philosophical? 🤷