Comment by ch_sm
5 hours ago
Yes! You’re describing a fundamental dichotomy in approaches to GUIs in general! Historically, we can see the difference and some oscillation very clearly:
The Xerox Star, the Canon Cat and Apple Lisa’s OSes were largely document oriented, and placed no emphasis on the application at all. The Operating System owned the creation and editing aspects of the document. Developers could only add "tools" that slotted into the existing interfaces the OS provided. You’d never launch an App on any of those OSes, you’d "tear off" a new doc from the stationary pad on a Lisa (that sounds ridiculous as I type it).
That paradigm really goes against the idea of "Software as a separate product", which is an older idea, starting in the 1960s at IBM (they unbundled HW and SW, partly under anti-trust pressure). The document-centric GUIs/Shells don’t really allow for a separate software market.
The 1984 Mac was kind of a middle ground, in my mind. It was a platform for discrete Applications (sold separately) but it also had the Finder which let you organise, open and delete documents separately from the Application that edited them.
Apple and later MS tried to bring the document-first concept back with OpenDoc and OLE respectively. OpenDoc never went anywhere then Jobs killed it, and OLE turned out much smaller in ambition and scope (and I think was never very popular with devs).
I think ultimately the intuition and perceived benefit behind document centric GUIs is pretty clear: the OS knows what kinds of artefacts it can handle, and presents a consistent and controlled interface to the user. File interoperability problems are minimised. Devs are allowed to extend functionality to an extent, but they can never take over the system or invent a new kind of interaction.
The App-first paradigm OTOH places more power in the Application developers hands, gives them the means to innovate, and allows for a larger, more diverse, more self-important software market to exist (see iOS).
Mixing the two, as the Mac does, comes with some confusion and complication for the end user, but I think is ultimately the right balance for everyone.
There are two things the document-oriented approach struggles with, though in many ways it's still the best we have.
The first is creating new documents: Lisa's attempt was understandable, Windows' File/New menu tends to miss out all non-Microsoft file types. Sometimes you just need to open the app, like inkscape, to get started off.
The second problem is with things inherently app-based like games. Sure, one could have 'File/New/Factorio game' in the Explorer menu (although that just copies a template file, it doesn't allow for customization) and one could make it so that double-clicking a save game opens Factorio (assuming .fac or something is associated with the correct program), but the usual way is start -> steam -> factorio -> load game (or, more likely, 'continue game' which the document-based approach also can't handle well).
I like my documents and my music organized into folders, most of the time I'm not fussed where my savegames are stored (steam cloud backups, after all). A sensibly done hybrid approach is best.
How to organize my Factorio blueprints is another question ...
Games making their save files front and center might be an improvement. The old days of them being in the install directory were good. Then some started putting them in "My Documents" reasonable for alleged security reasons. Then they vanished under "%APPDATA%". Now some don't even have the name in the path thanks to the dumb idea of "cloud saves".