Text
> I can’t see how it’s any more part of “the OS” in MacOS than in Windows?
Think of “the OS” as the whole package, not just “system components and software other than user-installed applications”.
Because it’s implemented at the system framework level, and there’s basically only three system frameworks for developing macOS apps — Cocoa, UIKit for Mac, and SwiftUI — and two of them call into the other.
That means practically every application (well, maybe not every; the number of UIKit for Mac apps is on the rise) shipped with macOS is a good macOS citizen, compared to Windows which is a mish-mash of apps built with all the many various application frameworks that have shipped with Windows.
Some parts of Windows are UWP. Some are Win32. Some are WPF. None of them can be expected to behave identically. Many of them don’t behave the same way as basic system apps. Explorer behaves nothing like Settings.
> Every app on both Windows and MacOS have to implement most drag & drop handling themselves.
On macOS, only custom handling is required. When an app is built from standard components, Cocoa does it for them. These are not rare edge cases — these are buttons, text fields, text areas, image wells, and all the other basic components that make up the majority of apps.
> If you are the audacity developer you’ll be notified that someone dropped an mp3 on the surface of your window. You’ll have to take it from there. That’s 100% the same thing in windows.
I’m aware of that. Actually, I mentioned Audacity in a section where I illustrated three examples of where one would expect an application to accept something that has been dragged in. That wasn’t an example of anything exceptional to macOS.
> File drag events work like that on windows.
Again, you’re on a section where I’m illustrating standard, expected behaviour for drag-and-drop.
I don’t start really talking about anything macOS-specific until the section where I mention proxy icons, so I’ll respond to the next section.
> First of all, there is no proxy icon!
I explained proxy icons as an illustration of why a Mac user might want to drag-and-drop into open/save panels as a means to directly answer your question on that very point.
> the missing capability is the proxy icon
You got a bit hung up on the proxy icon. It was just one way that a Mac user might want to drag and drop. I mention a couple of other ways that a person might want to drag and drop something into an open/save panel.
The lack of proxy icons in Windows is orthogonal to the point of open/save panels being needlessly destructive.
> I want to repeat - and this is important. The windows save panel isn’t special.
That’s a technical detail. That has nothing to do with the merit of whether or not it should be that way.
> One can argue that this is a poor choice
Yes.
> but that’s what it is
Yes. That doesn’t make it good.
Microsoft has demonstrated an affinity for reinventing their own user interface elements with breaking changes in each iteration. There was nothing stopping them fixing this behaviour then, there’s nothing stopping them doing it now — there is absolutely no reason an application should depend on destructive behaviour.
> It’s absolutely not a clear cut case of “Well that dialog should be non-destructive so dropping should do navigation! Case closed!”
That slightly misrepresents my argument. I don’t believe it’s necessary that Windows open/save panels should behave as on macOS.
I just believe user interfaces whose purposes only cover two of four letters in CRUD (specifically [C]reate for saving a file and [R]ead for opening one) should avoid being destructive.
That could even be fixed with a simple confirmation dialogue.
> there are several types of file dialogs in windows, and some are more like what you describe
Why are there non-destructive and destructive file dialogs? Why are destructive ones the most common?
> Perhaps if windows had proxy icons
Irrelevant. Protecting user data doesn’t necessitate proxy icons. Microsoft simply chose to reuse a control with zero affordances for use-case; they made the choice not to protect user data.
> because proxy icons would have made drag to navigate work?
You’re stuck on the proxy icons. They were just one thing you could drag.
> It sounds to me you have a few such discoveries to make on windows which would make the experience less frustrating
I’ve been using Windows for the past 25 years. I still use it today, every day.
I don’t have any sudden discoveries to make, I know it back to front. With every release, it deviates worse from its own standards than any UIKit for Mac app ever could from regular Cocoa.
Fundamentally, Windows is composed of several incompatible technologies that all work completely differently from each other because of historical internal competitiveness from a fractured company. That legacy lives on today — and worsens with each release as Microsoft continues to pour efforts into other application frameworks (WPF is deprecated; UWP is unloved; WinUI is supposed to unify them; but React Native is more likely to have an impact), creating massive schisms in the consistency of the user experience.
When Windows’ absolute basic components, the user interface elements you encounter in every app, are clearly the product of some technical desire for standardisation on a single control rather than any real desire to protect user data, I’m inclined to think the user experience is not at the forefront of Microsoft’s design philosophy.
But that’s not because of a lack of proxy icons.