"At one particularly frustrating moment, I offered the following: “Bill, a shower, a toilet, and a water fountain all have mechanisms to control water flow, places where the water comes out, some sort of porcelain basin to hold the water, and a drain, but we don’t combine them into one thing to reduce their learning curve. We don’t merge them into one object because each of them are in use in fundamentally different ways at different times.”
Then the pause.
Then Bill’s verdict. ["That's just rude."]
Ouch.
As I saw my career disintegrate before me, I started to question just how “beautiful” my analogy really was. To his credit, Bill was forgiving, and met with me many times after that, giving me numerous opportunities to get him on board with all manner of ideas coming from my team (with varying degrees of success on my part). Ultimately, I never did succeed in making Bill really comfortable with a more emotional approach to software design. But the real lesson of the day was learned. In the software industry, as long as the engineering-minded run the show, the notion of subtle and textured user experience design that balances the emotional and functional aspects of a software experience will always struggle to take root."
There was a paragraph in that article that made me think of something
>”But engineers (like everyone) see the world through their lens. Engineers look at code all day. And when they see two pieces of code doing roughly the same thing, they immediately think about ways they could eliminate the wasted effort by combining them into one piece of code that performs both functions”.
I shudder when thinking of all the times I have wasted time trying to generalize something only to end up with code that is harder to understand, awkward to use, more complex, more prone to bugs, or all of the aforementioned, just because there is a stupid voice in my head going “do not repeat yourself”.
With maturity comes the insight that not repeating yourself is good. But sometimes avoiding it makes things worse and costs a lot more.
> I shudder when thinking of all the times I have wasted time trying to generalize something
My programming life has improved for the better when my threshold to generalise and DRY is not when I need to use some piece of code in two different places, but when I need to use it in three different places.
I am not joking, that was life changing advice for me.
In software there is the distinction between visually DRY and functionally DRY.
The latter should be collapsed, but might not be duplicate code at all. Automated code analyzers will often not even see these.
And the former must be kept duplicate. Unless you can make it functionally duplicate too. Automated code analyzers will often flag these wrong.
Don't get me wrong: I love automated analysis in a CI or my workflow. But it is not binary like a linter: pass or fail. It requires context and interpretation; I see e.g. CodeClimate as suggestions, not laws.
I think we talk about slightly different abstraction levels.
I wasn't thinking of the things a compiler will tend to optimize. It was more the times when I have tried to do too much with some higher level abstraction and suddenly you find that the abstraction isn't a good fit for everything you need to do inside it and that you may even be writing code that becomes very awkward (hard to understand, "abuses" the abstraction, or just very slow).
These things tend to hit in the "oh shit" phase when you have enthusiastically convinced yourself (and your team members) that this is the way to do it, you have written a lot of code where the abstraction still fits and then you stumble upon the cases where it doesn't fit and things get awkward.
DRY is a good principle, but duplication of code that does nearly the same thing may have significantly lower cognitive overhead, be easier to maintain and easier to evolve in some cases. (The trick is to silence that little OCD voice in your head when you come across those cases).
Funny you'd post that in here because MacOS sucks at this and Windows does a great job. In fact arguably the engineering mind worked great there. The file open dialog in Windows is just a repurposed Windows Explorer view which means you can access all the things you can from explorer when opening and saving including things like unzipping a zip file, renaming some existing file that's in the way (like file.txt -> file-old.txt and then saving the current file as file.txt), moving files (create a folder "old", drag file.txt info old, save the new file as file.txt where the old file.txt was.
Basically you can actually do the things you often need to do. Conversely on MacOS if you need to do any of those things your only option is to use Finder which really sucks because you then have navigate to wherever you were in the app
And of course you can set the icon size in Windows file dialogs, something you can't do in MacOS file open/save dialog
So in this case, thank god the engineering mindset won out in Windows, at least for this particular feature. Whatever UX designer on MacOS decided to neuter the file dialogs failed UX class apparently and chose based on some random airfairy idea then users actually getting work done.
- Re: file open dialog - repurposing Windows Explorer means that every time I want to open a file in an app in windows, I have to look for it, rather than just drag/drop from a window I likely already have open into the file open dialog (or from a quick-find launcher tool).
- "Basically you can actually do the things you often need to do. Conversely on MacOS if you need to do any of those things your only option is to use Finder which really sucks because you then have navigate to wherever you were in the app" - I'm having trouble understanding what you mean here.
- Don't get me started on sizes for accessibility reasons, that was partly why I had to switch elder friends to a mac after watching them suffer on windows. Things may have improved over the past few years though.
- I really want to see Microsoft or the FOSS community figure these things out, I dip my toe in once in a while but I think there's an evolution in cultural/governance/funding needed. Maybe the popularity of videoconferencing may help the FOSS world actually see how people work rather than just posting pictures of 'screenshots' and battlestations.
Have you tried? A properly written Win32 app is supposed to handle drag-and-drop of files onto its window, and treat it as "Open". Try this in Notepad, for example.
That said, I'm not sure what this has to do with repurposing Windows Explorer? It uses the same widget to browse files, but the File Open window is not actually an Explorer window.
GP is talking about drag-and-drop of a folder into the file picker view, which results in the file picker navigating to that folder. Or drag-and-drop a file into the file picker view, which results in the file picker navigating to the enclosing folder and then selecting the file being dragged.
This is even more useful when saving files than opening files.
I see. I have to say, though, as described, this sounds as a rather inconsistent behavior to me. Does the macOS file picker not provide file management functionality at all (e.g. creating folders or moving them around)? If it does, it's kinda strange that it would behave differently from the standard file manager.
> Conversely on MacOS if you need to do any of those things your only option is to use Finder which really sucks because you then have navigate to wherever you were in the app
While I don't disagree that it would be nice to be able to do more of the same things in file picker as in finder, there is the possibility to right-click -> open in Finder
Filepicker also supposrt Finders "go to" (cmd+shift+g) that let's you type paths, with autocomplete and support for ~, which is a super nice feature.
An amazing feature of the windows file picker that i hardly ever see mentioned is that you can simply paste in a url into the name field and it will automatically download it to tmp and refer to the file.
Reading this story from 2012 now, it aged... interestingly. It's basically complaining that this mentality:
> Concept reduction, consistency, skill portability, were all core to how to make a great UI. Why have 17 different ways to pop up (or drop down) a menu? Why have 17 different graphical treatments? With “one menu to rule them all,” users could learn how to use the menu once and then apply this knowledge anywhere they saw this affordance. That way, developers don’t have to reinvent the wheel, and users don’t need to relearn the wheel.
was taken too far, and argues for dialing it down a notch or two. But the industry did exactly that, and the resulting UX is worse than what we had in early 00s - and keeps getting worse every year.
If software engineers wrote novels, most of them would just add new pages to a million page choose your own adventure novel, and then laugh at all the authors who write a novel from scratch each time.
If it's any comfort, had it been me, you'd have gotten a promotion on the spot. Toolmaking requires a delicate balance between realism, and sytemic abstraction. You have to simultaneously keep the view of system-as-world and end-tool-in-the-world firmly in mind simultaneously. Sadly, with programming, it can be very difficult to keep oneself from getting bewitched by overall system complexity in ways that end up having an adverse effect on the usability of the tool itself.
Great analogy, though. I posted about how macOS’ file picker behaves compared to Windows’ one; this analogy would’ve helped.
When I want to use the bog, I’ll use the bog. When I want to clean my bum, I’ll use a bidet. When I want to wish my hands, I’ll use a hand basin.
The way Windows does it feels like crapping in the bath tub, at least to me. Wrong tool for the job. “If all you have in a hammer” kind of deal.
On the other hand, I’m sure Windows users who defend the mini-Explorer think of it more like using one of those fancy Japanese toilets with a bidet and music player to hide the sound of your ablutions.
"At one particularly frustrating moment, I offered the following: “Bill, a shower, a toilet, and a water fountain all have mechanisms to control water flow, places where the water comes out, some sort of porcelain basin to hold the water, and a drain, but we don’t combine them into one thing to reduce their learning curve. We don’t merge them into one object because each of them are in use in fundamentally different ways at different times.”
Then the pause.
Then Bill’s verdict. ["That's just rude."]
Ouch.
As I saw my career disintegrate before me, I started to question just how “beautiful” my analogy really was. To his credit, Bill was forgiving, and met with me many times after that, giving me numerous opportunities to get him on board with all manner of ideas coming from my team (with varying degrees of success on my part). Ultimately, I never did succeed in making Bill really comfortable with a more emotional approach to software design. But the real lesson of the day was learned. In the software industry, as long as the engineering-minded run the show, the notion of subtle and textured user experience design that balances the emotional and functional aspects of a software experience will always struggle to take root."
--
I keep a running list of little workflows and experiences I generally love on macOS and see if alternatives exist here: https://docs.google.com/spreadsheets/d/148zTJUwfVv9xfDcpSoH3...