8 ms·
Yes, a save panel is a save dialogue. It’s just Apple terminology. > I don’t quite get the point of dragging a file to a save dialog at all though? On macOS (
by zapzupnz 6y ago
Yes, a save panel is a save dialogue. It’s just Apple terminology.
> I don’t quite get the point of dragging a file to a save dialog at all though?
On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen.
This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling behaviour out of the box) and can be further enhanced by an app’s developer.
That begins with behaviour you might ordinarily expect from most apps: drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.
On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.
On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms.
For example, proxy icons: on any given document window (a window for an open document, like a Word document, Photoshop document, Final Cut project, etc), the name of the document is preceded by an icon that represents the document. You can actually drag that icon off the window’s title bar to any other on-screen element that supports receiving dragged objects — an open document, a Finder window, an email, a text field, etc.
I say all of this to cement one point: dragging and dropping is a key interface metaphor on macOS and iOS/iPadOS.
So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.
Or perhaps I’ve just downloaded an image from the web that I want to share with my friend. Again, I can open up my favourite messaging program, click on the Add Attachment button, and drag the image in from my Dock’s Downloads stack.
(Although, that’s a slightly odd example; I wouldn’t bother with the Add Attachment button, I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do)
For save panels, I might already have a folder open in Finder where I want my document to be saved. When I save the document for the first time and the save panel appears, I can either drag that folder or its proxy icon from Finder straight into the save panel — bam, the save panel is pointing to the correct place.
Or perhaps I want to save a file into the same place as an open document. Again, I would just drag the proxy icon of an already-open document into the save panel, bam, we’re looking at the right folder.
Notice: these actions are non-destructive. Non-destructive actions follow the principle of least surprise. All I’m doing is telling an open/save panel where I want to be.
> That to me as a Windows user seems alien. I expect it to work as an Explorer window!
Ask yourself what the basic function of an open/save panel is: to select a location for a file (and in the case of a save panel, give it a name). Of the four CRUD operations, only C and R are directly relevant.
Something shouldn’t act as something else, especially if it’s destructive. That, in my opinion, violates the principle of least surprise — an interface to C or R should not U or D.
The only thing I expect to act as an Explorer window is … an Explorer window.
- baxuz 6y agoI love this comment. One of the reasons I prefer using MacOS as my daily driver even though I have a lot of complaints. Sadly, due to the ever-increasing number of non-Cocoa apps (primarily Electron ones), these features are getting the boot.
- zapzupnz 6y agoIndeed. Little things like Apple’s implementation of drag-and-drop being lost in this sea of ugly, slow Electron apps is something that you just can’t explain to Electron developers — they make for Windows first, they have no idea what Mac users complain about, and even when we tell them they think we’re being silly. As per the comment to which I replied asked (although I believe GP asked in good faith): “why would you want to do that anyway?” Because that’s how we do it on macOS. That could be why we use macOS. If you care so much about letting macOS users access your app that you went with Electron rather than writing something Windows-only, it shouldn’t be hard to learn to respect the Mac platform and, more importantly, its users.
- kergonath 6y agoEntirely agree with et dry thing you said. I just wanted to say, re > For example, proxy icons The way they are buried in Big Sur, and often invisible unless you mouse over where they are by accident is my biggest gripe with the update. This is fundamental in how we interact with documents on that platform, and one of its great features. What were they thinking?
- zapzupnz 6y agoI suppose it comes down to the fact that sidebars can now inhabit the space usually reserved for title bars. It’s not a design decision against which I have any opposition so long as draggable space remains (and there usually is; I complained to Apple during the Big Sur beta period and they made some spacing adjustments). But I agree, those icons coming and going can make using them something of a pain. It also makes less clear what apps actually have them. An option in System Preferences to make proxy icons show all the time would be lovely.
- 6y ago