4 ms·

> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. I can't see how it's any more part of "the OS" in MacOS

> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. I can't see how it's any more part of "the OS" in MacOS than in Windows? > 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. Every app on both Windows and MacOS have to implement most drag & drop handling themselves. You get notified that the user has dropped some data, and you implement it. Some controls are basically miniature apps and can handle some of it (e.g. a text control could as default accept dropping text into it) but that's a rare edge case and in most situtaions you are obviously going to have to implement it yourself. 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. > 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. File drag events work like that on windows. Text selections aren't objects in that sense (dragging just changes the selection) so that's typically not a draggable entity. A picture is, and behaves like you expect (e.g. insert into a word document). > 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 Of course, a chat app has drag and drop for pictures into chat messages on both windows and mac. Otherwise it would be a pretty terrible chat app. Any cat app could of course be terrible, and there is every chance that more chat apps are terrible on windows - but that doesn't change the point. If you launch Teams or Slack or whatever and drag a picture from a word document into it, it will add it to your chat message. On both windows and mac. > 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. As a windows desktop developer myself (who struggle a LOT with drag & drop) I can see myself implementing something like this. But it's always a question of user expectation. First of all, there is no proxy icon! I'd love to see those in windows, but it's not currently part of the UX. As such, you don't have a "drag source" for open documents. To get anywhere to drag from for an open document you'd need to open explorer and browse to the location. But that's the exact same effort as doing it in the file dialog, so what's the point? As you can see, the mistake wasn't "poor handling of drag & drop" here, the missing capability I think is the proxy icon. > All I’m doing is telling an open/save panel where I want to be. I want to repeat - and this is important. The windows save panel isn't special. It's a full explorer file list, plus a file name textbox. One can argue that this is a poor choice - but that's what it is. It has different areas (a filename textbox, a file listing view etc). The file listing view is just like any file listing view in any explorer window. As such it has all the capabilities you expect. If you select a file and hit delete, it's deleted. If you want to create a new folder - perhaps the most common operation for a SaveAs dialog, it does that. So here microsoft had a choice: if you drag a file onto this area of the dialog, should it work like all the other explorer file listing areas in the OS, or should the Open/Save dialogs have special treatment? I think you could argue both ways there, but there are definite drawbacks to both. It's absolutely not a clear cut case of "Well that dialog should be non-destructive so dropping should do navigation! case closed!". This doesn't mean you can't have that functionality anyway. You could just make a drop of any file elsewhere on the dialog (such as on the path-section of the dialog) initiate a navigation, for example. > The only thing I expect to act as an Explorer window is … an Explorer window. I think this is merely a UX choice not a clear case of "well this way is better". As I said there are several types of file dialogs in windows, and some are more like what you describe and not "Just an explorer window". Perhaps if windows had proxy icons, there would never had been a thought to make the latest gen file dialogs be full explorer views, because then the proxy icons would have made drag to navigate work? I use both windows and mac today, but growing up on windows, I use MacOS less and I use it like I would use windows. Which means it's extremely frustrating. For example, I had no idea whatsoever that the little icons in menubars (I just learned they were called proxy icons) were draggable. I always launch finder like I would launch explorer and drag things around, even documents I already had open... It sounds to me you have a few such discoveries to make on windows which would make the experience less frustrating.

zapzupnz 6y ago
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.

zapzupnz 6y ago

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.