(On the flip side, Windows' select-a-directory dialogue of the same vintage is such an utter piece of garbage that I can't imagine there being any overlap of designers between the two dialogues.)

I hadn't realized that KDE was copied from Windows 95. I'm surprised no one here has mentioned NeXTSTEP. Here's a demo by Steve Jobs from 1992: https://www.youtube.com/watch?v=gveTy4EmNyk

- Click the FILE tab

- Wait two full seconds while it replaces my screen with something else

- Click Save As

- Click Computer (because Microsoft wants you to do everything in the cloud)

- Click Browse

- Finally proceed to saving your document like you would be able to do immediately on any other system

A habit that I've developed from earliest computer classes in elementary school is to save the file in the location you want as soon as it's named, so ever after Ctrl+S saves it with no hassle.

I agree it's very ridiculous.

[1] 'Backstage UI' is the bit that looks like this: https://kiatplayground.files.wordpress.com/2015/06/save-to-o...

I would extend your argument to Windows Explorer in general.

Sometimes I feel like the developers don't want stuff to work similar to Windows. Because that would be admitting that Microsoft actually did something right.

It's not the same vintage. It's a carry over from Win 3.0.

Windows 3.0 didn't have any standard system dialogs, these were introduced in 3.1, but that is not the main point. In Windows 3.1 the directory selection dialog was exactly the same as file open/save dialog (Figure 8 in the article) but didn't let you to choose files (and there are still places in windows where standard open dialog is used for choosing directory).

What is typically used as "standard directory selection dialog" actually isn't even documented standard WinAPI dialog, but originally internal dialog of the explorer shell (and it would not surprise me it it was not present in original Windows 95 RTM but introduced in some slightly later version), also it does not select directories (ie. pathname as string), but shell folders (ie. ITEMIDLIST).

For example: I literally can't know how I can save a file using Gnome's dialogue in the general case, e.g. if the dialogue opens at /foo, and I navigate to /foo/bar using the dialogue, but then go back to /foo ("bar wasn't the right place after all"), I can't save the file there any more. "bar" will be selected. Clicking "Save" while a directory is selected will not save, but navigate instead. Now I'm in "bar" again. I go back to /foo and try to click something else, say a file. This changes the to-be-saved-file's name to the selection.

After I asked someone who uses Gnome as their main desktop they told me "that's easy: you just have to ctrl+click on the selected directory to de-select it, then you can save in the current directory".

That, my dear readers, is indeed unusable garbage.

But, I only realized it now because almost none of the apps I regularly use make use of Gnome's default file open/save dialog. Linux's extreme inconsistency has some benefits ;)

Oh, and talking about Gnome, the only reason anyone uses it is that after configuring a few basic stuff, you can completely ignore it, just run your apps, forget that there's an actual OS with GUI somewhere beneath them. Heck, if even the applications running on it ignore Gnome and its "standard widgets", its biggest strength is that it can be easily ignored!

That's one of the most absurd and glaring usability bugs I've ever heard.

That is the most annoying part to me. Windows does this as well. It's such a rare thing to want to overwrite a file for me, I find it so irritating that if I accidentally click on a file name instead of a folder, suddenly I lose the file name that I wanted to save as. Usually I just cancel and start again. So stupid.

Apple have a tradition of being really bad at this. Many of the (slightly more) advanced features are completely hidden behind undiscoverable key combinations or very hidden features. The slide-to-reveal pattern on iOS (now mostly fixed with augmentations) is a good example. Middle clicking the titlebar in Finder to reveal the directory parents is another.

It's not like the Mac way saves screen real estate or anything. It's like the way Firefox lets me close a tab by middle-clicking on it. Most users don't know it's possible, but it doesn't actively harm them to have the feature there.

I really like the fact that the Windows save dialog is basically Windows Explorer, and I really miss those features when an application uses the older file save API (which gives a more Windows 95 / 3.11 interface).

RiscOS had it right - the Open dialog didn't exist - you would open the folder and double-click the file. And the Save dialog didn't exist - the document would reduce to an icon which you would then place into the correct folder. (You can sort of do this on the various versions of macOS by dragging the icon from the title bar but it's inconsistent)

https://classicmacfinder.com

What I was interested in back then was the idea that there was a direct correspondence between the folder window and the data structure on the hard disk, and that to the user these concepts should be indistinguishable. One part of the illusion is that a folder always appears in the same place with the same window size, to give the sense that the folder is a tangible thing with permanence.

It's got a loooonnggg way to go (I never realized how many small but vital details are in a file explorer application), but it's strangely exciting to see it draw itself on modern macOS, especially on a retina screen!

And yes, the spatial UX! I'm still working through getting all of that implemented (I just completed persisting window locations/positioning days ago). I have recently been reading theough some of John Siracusa's turn of the Mac OS X era writings and that's been hugely insightful and helpful. The level of detail (both of the original Finder and his writings) is impressive and sirprising.

Very cool UX concepts!

IIRC, you even used to be able to just swap the System folder around and have like a completely new/different install of Mac OS.

This article from 2003 lists the problems with the OSX Finder. Since it was written, it's only got worse.

https://arstechnica.com/gadgets/2003/04/finder/

I love being able to drag a file up one level in the tree without cutting and navigating to the destination to paste, or having 2 windows open to almost the exact same location.

[0]https://en.wikipedia.org/wiki/Miller_columns

While Miller columns certainly support that, so does the tree view in the left panel in the default Windows explorer layout.

I've been using bitCommander, which is a Windows file manager that supports (among other things) Miller columns.

I think RISC OS (?) did this. Open documents in applications had icons representing them which you could drag to the file manager to save. (And perhaps to other applications to open?) Mac OS also has (or had?) this to some extent – many document-based applications show an icon in the title bar, which is for dragging and dropping the document in question.

Even Windows has an example of catering to this way of working, in Explorer, where the folder icon in the location bar represents the current folder and can be dragged and dropped. They even have some custom behavior to prevent the window from being raised when you drag from it, so that it works more like classic Mac OS and lets you drag to an overlapping window.

Be OS did this, too; I got the impression that Windows was inspired by that, both for BeFS (NTFS) and the desktop filesystem UX.

More likely that they were both inspired by a common source.

Never mind that MS have been working on a fully database driven FS (WinFS?) for ages.

How many exploits were just a matter of tricking an extra-fancy OS dialog into popping open something it’s not supposed to, escalating permissions alongside it?

The door swings in both directions, in other words :)

This can't be blamed on UX people. It's an ancient difference between Unix and VMS and not easy to fix.

What really is a joke is a left pane that combines favorites, libraries (die, die, DIE) and disk trees. It was never usable, except for favorites.

++edited to clarify language.++

No web browser, though. Internet Explorer 1.0 shipped with the optional Plus! pack.

I could have sworn that was all in the Plus! package too, but 20+ years of time has eroded my memory on that...

Well, I agree that there was no comparison with System 8, but not in the sense you mean. I think that the Mac back then was head-and-shoulders a better system than Windows. It might still be, but they're both so painful to use now that it's very difficult to pick a winner.

The Macintosh system was very understandable, very clean. Extensions were an easy-to-understand way to extend one's system, and easy-to-disable too. The window system itself was better-thought-out and less-confusing than Windows's was. The Finder was much more straightforward than the Windows equivalent (was it called the File Explorer back then?). The way that the Mac associated programmes to files (with an application code & a file code) was much better than the extension-based naming of Windows. The way that the Mac used its files' resource fork was great.

Programming a Mac back then was very clean & straightforward. I don't think there's anything today as nice, except maybe Cocoa, maybe. Certainly not the Windows 95 API!

Extensions could easily bring down the entire system because there was no memory protection. Full OS crashes (what modern macOS calls kernel panics) were a daily occurrence for the typical Mac-using professional who ran complex software.

The window system was often difficult to understand because apps tended to use a plethora of little panel windows that could overlap even from different apps. Windows preferred large windows that contained the entire app UI, and users typically maximized them. The Windows 95 Task Bar was much better for actually keeping track of your tasks than whatever the MacOS 8 thing was.

File extensions were always a hack, but one that Apple adopted too for Mac OS X. The days of Mac's file-specific associations were numbered when the Internet happened, because Unix servers wouldn't keep track of that metadata, so you needed file extensions anyway.

Besides, the file-specific associations were often super annoying because they were created by the editor app even for exported files. You saved a JPEG file from Photoshop, and it forever insisted on launching the full Photoshop when you double-clicked on it, instead of your preferred lightweight image viewer. This would happen even when you copied the file to someone else because the association was in the file metadata.

Windows NT 4 and its next version Windows 2000 were just heads and shoulders above MacOS 8 and 9 in terms of performance, stability and usability.

(And programming in Mac OS 8... Ugh. No memory protection, no multitasking, APIs originally designed in Pascal.)

Yes, they were quite unstable. I didn't say that they were stable; I said that they were easy-to-understand and easy-to-disable, which they were: each extension had a distinct icon displayed at system boot; disabling one was as easy as dragging it to another folder; disabling all was a matter of, IIRC, holding down Command as you booted.

> Windows preferred large windows that contained the entire app UI, and users typically maximized them.

As a Mac user at the time, I much preferred the multi-window mode: it meant that I could customise my desktop as I liked. The Windows single-window mode was terrible, as it meant that I couldn't layer windows properly.

> You saved a JPEG file from Photoshop, and it forever insisted on launching the full Photoshop when you double-clicked on it, instead of your preferred lightweight image viewer.

We considered that a plus at the time: it meant that different files of the same type could be opened up by different apps by default. One could always, IIRC, Save As if one wanted to change the file type — or use ResEdit.

> Windows NT 4 and its next version Windows 2000 were just heads and shoulders above MacOS 8 and 9 in terms of performance, stability and usability.

Stability, probably. Performance, maybe. But usability? Never! That was back when Apple cared about UX.

Windows 9x and maybe OS/2 were far and away the dominant OSes on actual workstations. Macs and even aging Amigas at some creative shops, some more Unix workstations at places where most people could recognize and identify the purpose of (if not actually use) a slide rule. But what I essentially never saw on any desktops was Windows NT. Lack of driver support and inability to run many business applications kept it out of that space.

But NT was the first winOS which supported multi-proc, correct?

NT4 was the first OS I could have my dual 266 intel procs run softimage IIRC

NT4, Adaptec 2940u2w, and mirrored segate cheetah drives.

You had to space them out because a stack of two cheetahs would cook the upper one to death ...

I actually recall that Cheetah problem. :-)

The original Mac released in 1984 and was produced through 2000, sixteen years. OSX released in 2000 and is now in its eighteenth year. Whilst each system has seen some evolution over time, the general metaphores and interfaces have remained consistent.

Apple have realised and internalised a core concept of GUIs: change is bad. There is a far higher cost to changing interfaces than can be gained through efficiency, and the retraining and unlearning costs are exceedingly high relative to benefits.

This is a message apparently lost on Microsoft and most of the leading Linux desktops.

Mind: I write this as someone who whilst using a Mac presently doesn't much care for the interface. My preferred desktop remains WindowMaker (itself based on Aqua's predecessor, NextStep), which has a key advantage of having changed almost not at all in the 20+ years that I've been using it. It's also configurable in ways I find useful, and I schlep around a configuration directory to new systems as needed.

That and a terminal window.

* MS-DOS/Windows 3.1-like * Windows 95-like * Windows 8-like

Windows 8 basically was born and died in a couple of years, to be replaced with Windows 10, which is very much the same basic set of metaphors as Windows 95. There's a start menu, a little dock of pinned icons next to it, a taskbar, a clock and some little icons for what are basically background processes. There's a maximize and minimize and close button on windows. There's a File/Edit/Whatever set of menus. You can right click for context items, many of which are consistent with Windows 95 20+ years ago. That basic system is now something like 21 years old now.

You can maybe argue that Microsoft forgot your message five or so years ago, but they obviously rediscovered it.

Windows 3, 95, NT, and 2K each saw significant changes in where and how major system functionality was presented.

During the same period I was using numerous Unix and Linux platforms (and still do). Those have largely seen far less substantive change at the shell and system level, with a few notable exceptions.

I'm not discussing Linux GUIs, which have been all over the goddamned map. I've used twm, fvwm, fvwm2, VUE, CDE, WindowMaker (my preferred option), GNOME and KDE through multiple generations, Enlightenment, various of the 'boxes (black, open, flux, ...), ion, xfce4, ... And those are the ones I've trialed to some significant extent. I've at least fired up and looked at virtually all the options mentioned on the XWinMan page: http://www.xwinman.org/

There are several fairly central components which have changed fairly markedly. The shift from telnet to ssh, multiple iterations of firewalling, various scripting languages of preference (bash, perl, python, an oddment of others), mailers (sendmail, qmail, anything reasonably sane, mostly exim and/or postfix now), and of course, the whole init replacement clusterfuck.

But the notional concepts of files, filesystem, shell, utilities, pipes, etc., has remained consistent, and even across several utility / server replacements (particularly ssh and mailers), command-level compatibility has been preserved to a remarkable extent with previous options (e.g., rsh and sendmail syntax).

If Microsoft can only be relied on for five-year stints of "having learnt this lesson" then they have not learnt this lesson.

This includes a hell of a lot of systems configuration tools. The corrective force on failure to adhere to this norm is strong.

Hell, you can today configure Windows 10 to behave much like 8.1. The one thing i see some people miss with the 8.1 to 10 transition is the charm bar. In particular that it gave easy access to printing and such.

While Apple may retain the UI across time, they are more than willing to change APIs etc on a whim.

MS on the other hand may change the UI (though outside of 8.x, the core layout and behavior has remained much the same, and even 8.x could to a large degree behave like the older UI) but they bend over backwards to maintain APIs across time.

Microsoft was always more vendor / ISV / VAR oriented, and stable APIs matter there.

Being able to get a new computer but install from the same software library (i can hear the _sec people getting hissy already) as was used on the old one makes people more likely to pick the same "platform" over time.

The counter is that Apple caters to a smaller software development community, though several of the tools also see extensive use and support (particularly photoshop). But there's a heck of a lot fundamental functionality on Apple's platforms that you can get without relying on third-party software, or at least, third-party proprietary software. Given the dynamics of proprietary software markets, particularly toward adware, nagware, and malware, this seems a possibly positive development.

(I've made much the same observation in recent years about the Android marketplace, which I see as a growing cesspit, and of the Windows application space, particularly at the peak of its crapware / spyware / adware period in the decade of the 2000s.)

Linux solves the software compatibility problem by allowing for recompiling of software for which the source is freely available, for the most part. This isn't a perfect solution, and there are complex systems which tend to not be particularly forward-compatible. One possible argument is that such complex systems are themselves inherently problematic and ought perhaps be avoided. You may not agree with the argument, but I'd expect you'd admit to its existence.

Microsoft was addressing a different space, and one in which there was a massive focus on desktop-distributed client software, much of it aimed at very specific business applications. This is a major application area for computers, though it's also one that's shifted significantly toward client-server Web-based solutions (or app-based, now). Which presents its own set of features and limitations.

And again, all this is what I was hinting at earlier with noting that you'd presented a very interesting point. I'll be thinking about this for a while.

I agree with you that keeping the file metadata in a separate fork is far superior to keeping the file metadata in a three character extension, but sadly the world zagged on this one when Apple zigged. I especially like that you could have two files of the same type associated with different applications, so if you created a text file in your IDE it would open back up in that IDE instead of launching the word processor. And you could change it (somewhat clunkily) at will.

Win95 did have some advantages though. The Start Menu was a better organization system than Apple's Application folder for example. Macs of that era were also slow and badly overpriced.

These were not actually that different. The original Start Menu was just a menuized view of a folder hierarchy (which mostly contained shortcuts but could contain any document).

Or if you're going to Very Deliberately Ignore the Other OSes and go do things your own way. VDIing like that seems to be a very Apple trait.

My point is, I'm not sure how well the resource fork model could have ever survived prolonged and sustained contact with the Internet and modern pervasive networking.

Since we're talking about Win95, then the 3 characters limit doesn't apply (long filenames was a major new feature of this OS after all). .jpeg and .html were relatively common for example at the time, and worked fine.

I find the extension system still kludgy, but arguing than it was worse in part because of the limited pool, is incorrect starting from Win95.

The metadata that Macs kept in the resource fork go way beyond file type and creator too. It included things like the file's Icon, creation/modification information (so it would survive a trip over the Internet!), loads of stuff for applications (menus, graphics, sounds, etc...), formatting for plain text documents (so they fall back to plain text on unsupported systems), and so much more.

Fun fact: NTFS supports the concept of a resource fork on files, but almost nothing in Windows uses it. I think I've seen more malware hiding stuff in there than legitimate uses in the wild. Worse, even the obvious case of loading a Mac file on a Windows machine it usually fails and falls back to creating the clunky separate directory instead.

One thing I loved about old MacOS apps is opening them up in ResEdit and so much of how the thing was built.

Sort of. It would be more accurate to say that each filename was a 4-letter type code and a 16-bit ID. Each resource could also have a name, but that was less frequently used (and didn't have to be present, let alone unique).

More importantly, resource forks didn't exist in isolation. They were loaded into a chain of active resource files -- for instance, while working with a Hypercard stack, the resource chain would include the active stack, the Home stack, the Hypercard application, and the System suitcase. A stack could use resources (like icons or sounds) from any of those sources.

Also, that Windows feature you mention is called ADS - alternate data stream.

.jpeg.photoshop.ro.creat127339292....

The filename extension is the bare minimum of metadata for a file and not easy to extend.

Even then Unix systems will skip even that minimal metadata and force you to messily search for magic numbers at the start of the file and make a guess.

I completely disagree.

First of all, Windows 95 had preemptive multitasking (the Amiga was the only computer that had this at the time), Mac OS was single task and used a terrible scheduling and it would be years before Mac OS gained preemptive multitasking because of terrible architecture choices that made this extremely challenging.

From a GUI standpoint, Windows 95 was a total revolution and made Mac OS look completely antiquated: rendering, scrolling speed, font types, menu items and dialogs, etc...

The Amiga was exotic hardware, like the BeBox. If you want to include those, you might as well include SGI and Sun hardware. Preemptive multitasking was common on non-PC hardware.

We're talking about consumer facing computers, and at the time, the market was pretty much only Windows, Mac, OS/2, Amiga and Atari.

I miss window shades so much.

Windows user here. Honest curiosity: does anyone know why the minimize / maximize works on the Mac the way it does? I mean, what's the rationale to design it like this?

I rarely, if ever, use Minimize on the Mac. Minimize comes from Windows (and other windowing systems) where the window minimizes to an icon or button on the task bar.

"Maximize" also comes from Windows (and other windowing systems.) As others have noted, in newer macos (which I don't use,) I think it oddly makes the window go full screen. Full screen is a recent macos feature -- I once asked about making my Application go full screen and Apple developer support said that going full screen did not follow their Human Interface guidelines. Something seems to have changed at Apple since I asked about that decades ago.

There was no Maximize on the Mac, it is called "Zoom." The idea is that the window has two sizes and you zoom between the two sizes: One size is the size the user has resized the window to (often with much difficulty) and the other size is an ideal compact size ("optimally fit content") without hiding anything and hopefully where scroll bars do not appear -- it is a UI feature that is/was rarely, if ever, done very well by applications other than the Finder.

By the way, Command-Tab to switch tasks was once an add-on from Microsoft for Mac OS. Go Microsoft! (Mac fanboy here :)

The the MacOS scheme of doing this leads a sort of organic, emergent window layout - I always end up with windows staggered to display relevant bits. With Windows (and with most window managers, X), things always end up either strict tiled or stacked.

I'm very used to the Mac way and prefer it, but that could just be the result of long use. It doesn't waste space (Windows apps always seem to have lots of dead space to me and makes me work to be able to see parts of other windows) and forces me to switch windows far less. But it is a fiarly subtle thing.

My WM of choice is now Xfwm, which allows to rearrange windows easily without gaps, make windows fill available space (vertical and horizontal separately), or tile them by dragging to corners.

On OSX, things like Spectacle and Magnet sort of help.

For me, the goal is not to maximize available space to the frontmost windows; it is to maximize the use of the monitor to display what's currently relevant. It allows me to do things like keep a Finder window open with just a bit peeking through to drag things to, keep an eye on a few lines of a terminal tail -f, see the mailbox pane and room pane in Mail/Slack so I can see if anything new happened I should respond to, etc. all while working on whatever I'm working on.

With the Windows-ish "maximize the window", that is replaced, almost invariably, by useless window background.

Again, I expect this is mostly what one is accustomed to, and the Macish approach is more idiosyncratic to the user. Works for me.

Also, you can maximize a window for a moment, look at it, and then unmaximize it back to its previous size.

I use xfwm4, and turn all of the window snapping off -- unlike Mac and Windows we can customize. ;)

You will pry the Command-key from my cold dead hands:

  /usr/bin/setxkbmap -option ctrl:swap_lalt_lctl

Also, if you hit the up arrow in the command-tab switcher, you can use the arrow keys to select a minimized window and hit enter to restore it.

Tiling window manager: https://github.com/ianyh/Amethyst

Programmable window manager: https://github.com/kasper/phoenix

Either that or I've gotten very much better at doing this.

I absolutely agree with your guess as to why this is.

in Maximized state the window is set to maximal available size (so you are not wasting any part of the screen) while you are still provided with fast and easy access to relevant OS UI elements

in full screen you explicitly tell the system that you don't want to be distracted by OS UI elemtents (typically in situation when you know that you won't need them for extended period of time, or if you REALLY need every single pixel of the screen)

I'm came from ~18 of Windows & Linux usage and everyone always told me macOS is THE OS with the best usability.

But I can't confirm this.

Minimization of windows is shitty and maximization even more.

When I maximize, often just the height is changed, when I go back to "normal" the height and the width is changed, so I always have to adjust the width manually.

When I minimize a few windows, it's impossible to get back the right one without luck.

and if you have many windows open (in win 10 at least) you don't have to press alt+tab 10 times in a row to choose your desired program, you can hold alt+tab and use arrows.

Some days I still really miss dwm, but having Photoshop, Ableton, and several other things Just Work™ makes it worth it.

System Preferences > Mission Control > Automatically rearrange Spaces based on most recent use

Perhaps it's a setting or was the behavior in an older version of macOS?

Motherfucking maddening as hell.

[1] https://en.wikipedia.org/wiki/VirtuaWin

And there is no proper UI element for checking if you have anything open in a different workspace without opening the switcher.

I mean it's perfectly usable once I got the basic gestures down and installed the app that let me independently set the track pad and mouse wheel scroll directions, but will go so far as to say that both xfce and MATE are objectively better at window management.

Partly I think their hands were tied by the too late to change decision for the always there contextual top menu bar. Or this is just 25 years of using win95 clones talking and I'm set in my ways.

You wouldnt judge i3 or other completely different approaches after only a few minutes.

absolutely :)

What i like the most is you are just a super key tab away from basically everything so focus on a single thing feels natural and right. There is no way to lose anything either, its all there. Always.

The last time I tried it, I got frustrated when working with a lot of pdf sources - hitting the super key just presented me with a myriad of white rectangles where open windows would frequently rearrange requiring a slow manual search to find the file I was looking for. This can be less of a problem with a taskbar, as the filename is the main identifier, and being 1 dimensional it is easier to scan and preserves its position better.

Another frustration is trying to view two apps together on the screen at the same time, if one of the apps itself contains multiple windows. I'm not at my desk to try this but let's say you have multiple chrome windows open, all with their own tabs, and you want to view your current chrome window overlayed on a window from another app. To do this you have to manually minimise all of your chrome windows one by one so they will all move of the way, to allow you to switch between apps and view them both at the same time.

Four fingers up, expose. Drag the windows you need up top into a new desktop. Command (or control? Or option? Or a combination?) Plus the right arrow to switch desktops. Try all the combinations until I get to the right desktop or throw the damn thing out a window.

Somehow it is able to open up the device manager and THEN give the window in the background focus when I switch to my editor and back to Xcode with cmd+tab.

So I have to move the Xcode window down, to grab that backgrund thing what seems to be part of Xcode.

There was no task bar or dock or anything else really to minimise to. IIRC there were addons for 7.1 that added "window shading": a button on the window title bar that reduces the window to just the title bar.[1]

The closest thing to a maximise button in classic Mac OS was more like a size-to-fit button: the application gave the window manager a hint which was the appropriate size for the document displayed, be it a file folder, a word processor document or whatever. Having a single window fill the entire screen wasn't as common as it was on Windows.

None of this was particularly strange to me back then.

[1] https://en.wikipedia.org/wiki/WindowShade apparently a standard feature later on

System 7 was WAY earlier than Windows 95, it was 1991, a little more than 4 years earler (like an eternity):

https://en.wikipedia.org/wiki/System_7

"It was introduced on May 13, 1991 ..."

And even 7.1 was almost exactly 3 years earlier: System 7.1

"In August 1992, the 7.1 update was released."

https://en.wikipedia.org/wiki/Windows_95

"It was released on August 24, 1995"

Not even Windows 3.1 had been released at the time System 7 came out, it's competitor on MS side was DOS (version 5.00):

https://en.wikipedia.org/wiki/Timeline_of_DOS_operating_syst...

https://en.wikipedia.org/wiki/Windows_3.1x

or some of the various semi-graphical third party shells for DOS.

Sure it did, namely Windows 1.0, 2.10/2.11 (actually Windows/286 and Windows/386), but very few people used them.

Windows 3.0 was the first one to have some diffusion, but it had very limited capabilities, and it's adoption was slow because of the increased specifications for the PC, and in any case not comparable with the later wide adoption of 3.1.

Yup! For the longest time I liked to work with a half-width browser window to match my half-width editor & word processor windows. It drove me crazy the number of websites which set their body text to some fraction of the window width, which looked good with a fullscreen window but terrible with a halfscreen one.

Eventually I just gave up. The whole point of the web was device-independent information transfer, but somehow we allowed device-dependence to sneak it.

You can play around with it on archive.org. https://archive.org/details/mac_MacOS_7.0.1_compilation

IMO there's a whole generation of people who did their early computing on MS Windows (including myself) and so internalised that that is how GUIs are "supposed to work". When moving to something else later in life there's a feeling that it is "wrong", but it (e.g macOS)'s way of doing things is also correct and is just a divergent evolution to MS Windows. Research, open-mindedness and experimentation are necessary when using something different.

http://osxdaily.com/2010/06/22/make-hidden-application-icons...

It wasn't designed to 'make this window fit the screen'. It was designed to 'make this window fit this A4 document.

Maximize on Mac was NOT designed for the window to fill the whole screen, but rather to resize the window to optimally display its contents. E.g. maximizing a Preview window with a PDF document changes the width of the window to the PDF page width. (Good tip for getting along with your Mac: stop trying to maximize everything.)

In a recent macOS version, Apple changed the green "maximize" button to full-screen, which is very different from maximize. Now double-clicking on most window chromes will execute the old maximize behavior.

The problem with this approach is I definitely do not need someone else making the decision of what is "optimal" for me. I've been using macOS for about as long as I used to use Windows now, and at this point, macOS seems to have largely abandoned the concept, which is great. Applications get either a full screen in their own isolated context, or option-click for a full-screen in a regular windowed context. The options now are a very windows-95/98 like: "either go completely full screen, or resize to whatever you like," which gives me full control of what I find optimal for any given application.

Macs used drag and drop for file management between windows representing separate locations on disk. Windows users tended to select files and choose cut or copy then navigate to the second location and paste.

The same held true for moving content between documents in an application or moving content between applications. Mac users preferred to use drag and drop, while Windows users relied on copy and paste.

The problem with keeping every window maximized is that you're giving up system wide drag and drop as the primary user interaction method.

Personally, I find drag-and-drop handy sometimes but it's very constraining. You have to go through non-standard motions to complete any more that is more than trivial, always holding down the primary mouse button and thereby losing your primary way of interacting with the interface. In other words, sure, if you have a clear view of your destination, then yeah, drag and drop is fine, but in all other instances, it becomes clunky.

Cut/paste is incredibly quick and doesn't sacrifice usability of your interface or input methods between the two ends of the transaction. Windows seemed to balance this out well, where you could drag and drop most of the time, but you could also ALWAYS cut/paste. I despise that I can't cut/paste in finder. Which is why I use PathFinder instead.

The danger cut/paste DOES pose is it fundamentally unlinks the start of the transaction and the end. In between, you can do literally anything, which may mean losing track of what's in your paste. Still, I'd call this a fair trade-off, specifically because it is non-destructive for files. You won't lose a file to to paste. It just stays put.

On Windows Ditto, and on Linux CopyQ (among others, and there has to be something like that for Mac) solve this problem, by giving you a preview of what's in the clipboard as well as the history copies you made.

Then they are shocked later when they paste those files into some random location and can't figure out where they went.

Dragging and dropping does not have that issue. Users find it much easier to learn.

Open the source window. Open the destination window. Drag.

And that's the crux. The whole feature (in its original incarnation) rested on the false assumption that there's a singular "optimal" state at any given time.

The Apple Human Interface Guidelines have been a state-of-the-art reference for good UI for a long time, but the part about the zoom button always baffled me, as it directly contradicted several Core Principles laid out in Part I of the book.

The reason this is done is of course that most applications don't have content that fill the entire screen, so maximizing, in most cases, is meaningless - and hinders the usability of the system.

It makes more sense to leave some space over for other apps than have a big empty area on both sides of the screen.

Interestingly, I noticed that it's only Windows-switchers who complain about this. People who've used Mac for a long time don't give this any thought.

It's a matter of where you place responsibility. It's like saying, "most websites aren't responsive, so naturally it makes sense to restrict the size of your browser window and leave space for other apps." But most would laugh at this and say it's the responsibility of the website/webapp to build a responsive layout. Why should we hold desktop applications to a different standard?

I completely that it is probably almost entirely windows-switchers who complain about it. I'd, obviously, self-aggrandizingly suggest it's because we've tasted something better. People don't complain about the taste of food they've never tasted ;)

I think that's a misrepresentation. It's not a static size. It's not an artificial limit. If the document that's open has content to fill the entire screen, the window will fill the entire screen.

The macOS interface is based around floating and overlapping windows. If you put a window over the whole screen then it could be as well maximized. This gets a bit hairy on smaller screens but really shines on huge monitors. In general macOS is more optimized around having one big screen rather than a multi-monitor setup.

But seriously, minimising windows is a reflex learnt from Windows. In Windows you often need to minimise one thing to find something else. Especially the desktop. On a Mac you can usually find something more quickly in the dock. In Windows you’re far more likely to have an app maximised by default, and minimising is a natural way to switch tasks. On a Mac, minimising is not a natural way of task switching.

I use ShiftIt, a neat little Open Source tool that help me manage windows sizes and positions (including minimizing and maximizing): https://github.com/fikovnik/ShiftIt

I've recommend it to pretty much any Mac user I've met.

I'm actually willing to bet good money that it's the other way around and it's you who is in the minority.

I think that Apple thought that many regular users would switch to full screen apps on the Mac, combined with Launchpad (it's just like an iPad/iPhone). But virtually all non-tech-savvy Mac users that I know do not use Launchpad, nor fullscreen apps.

I think the problem with Launchpad as with Spotlight search [1] is that they are not very discoverable on the Mac. Having search in an application menu (like recent Windows versions and some Linux desktops) is far more discoverable.

I guess people don't use fullscreen apps because they equate desktops/laptops to the 'WIMP' interface paradigm.

[1] If I received a penny every time I see even experienced Mac users launch applications by clicking on a Dock icon or by navigating to the Applications folder in Finder, rather than using Spotlight, I would be rich.

(Yes, yes. It is a lame joke. But who uses only one Window at a time? What is the point of that? Though I remember when I used OS X you could swipe left (or right) to switch back to all other apps. So I think that was good enough.)

In the olden days, Mac users would tend to have lots of overlapping windows. Dragging anywhere on the window edges would move the window, so it was easy to arrange them as you wanted - almost like shuffling bits of paper on your desktop (strangely enough) and if you wanted to move something out of the way, you could fold it up (window shade). There was no need for maximising or minimising and "zooming" just meant "make this as large as makes sense for this particular document", not "expand to take up all the space on my desktop"

As OSX/macOS has developed, all that document/desktop-style behaviour has been lost.

You're talking about the "fullscreen" feature which I always found very weird. For example, ever forget your video was "fullscreen"ed as you try to alt-tab to it only to realize it's a 4-finger swipe to pull it back up. Making the user have to differentiate will always be bizarre to me.

Eh? They still do, as of MacOS 10.13.

I recently sold several windows 95 shrink wrapped original copies on eBay which was the OS on 32 3.5” floppy disks. As an original piece of computer history.

Win 95 was monumental and great. Aside from outlook, and excel, the greatest product MS ever made.

What are the use cases that bother you?

Really, the only place case-insensitive filenames makes sense is when you are searching. It makes no sense for any other reason.

I also like when an IDE detects and provides a warning when I have two variables with the same letters better different capitalization.

Different case is often a bug.

I can think of a lot of reasons to abandon Mac OS X, but this seems like a really odd one to me.

You lost me. HFS+ is arguably one of the worst file systems around (yes I know that Apple finally switched to APFS but that was fairly recent).

I'm really curious what you actually liked about Mac's file system vs. Windows?

NTFS/Windows actually has all of that stuff you want, too. NTFS's permission system, for example, is extremely feature-full and integrates nicely with the user system (ACL support by default rather than an add-on, for example). The octal user-group-all permission you're probably used to is pretty crude by comparison.

It's more likely just you're unfamiliar with it rather than it's actually missing anything.

But if you want you can just pretend C:\ is equivalent to / and mount all your other drives at C:\mnt\whatever, that's completely doable (with a GUI to configure it if you want, even)

I’m still annoyed that APFS doesn’t have file level checksums.

OT but have you tried Witch[1] as a task switcher? It switches between windows, which made my life SO much easier

[1] https://manytricks.com/witch

OSX took the NextStep/OpenStep interface and dumbed it down to great detriment, then added new things back (spaces, zooming) which were inferior logically but required less 'thinking' of how one works and more 'shiny looking' to potential customers..

IMHO hands down the best mouse-oriented window management paradigm to exist to date is the NextStep/OpenStep style over and above windows and osx, though I will admit windows has improved things with their sort of hybrid 'classic' windows+'macish' updates, and some of the newer ui things (e.g. window thumbnails) haven't made it into the current flagship of that lineage which is the open source WindowMaker..

Since the 'official' lineages are dead, am hoping the WindowMaker people continue to innovate/move this paradigm forward as they have been doing subsequently for the last N years...

I remember these times well. It was considered a huge break. People were whining about how stupid the Start menu was compared to just seeing your apps in front of you all the time :-D I love that we eventually came full circle to a Windows 3.1 Program Manager-esque approach with iOS nowadays!

I don't remember anyone using this setup ever though. Maybe this was too obscure and technical for the users complaining.

That would not have been my first pick for an example of Win95's failures. Perhaps the daily system crashes.

I remember when unified USB support came out in Win95 2.5, it was big damn news at the time.

I remember Windows 95 as a complete disaster of crashes, data loss, failing installations, incompatible applications, missing drivers and countless other problems which were only fixed with the release of Windows 98 (maybe even SE), which was much much better. I have memories of people sticking with DOS and 3.x, only having 95 as a nondefault boot option in case they wanted to watch the Buddy Holly video or launch the new Encarta cd-rom.

Learn to use the dock? The taskbar on Win 95 was evolutionary rather than revolutionary, and the Dock from NeXT was one of the influences. Which is the same dock was have today in macOS.

You can still have personal preference, of course. But if you have trouble using macOS to find minimized windows, that's because you haven't learned to use it not because it's not possible.