← Back to context

Comment by flaburgan

2 hours ago

In the end, using any device is all about doing actions (the simplest being reading/viewing, but also editing etc.) on data. Now the biggest difference between desktop and mobile is that the first one is (was?) file oriented while the second one is software (application) oriented. Edit a document, listen to a music, on desktop you would historically navigate to where the file is, then open it with the program of your choice. On mobile, you would almost never do that, you would first open the app and from it select the file you want to interact with. This is changing a lot how you are organizing the way you work. On desktop, it is easy to put related files of different types in the same folder, for example you organize your birthday, you can have the list of the invited people in a excel file with their number, a subfolder with the songs you want to play, some pictures of the venue, a text files with notes and etc. It is not natural at all to organize things like that on mobile. Android and iOS are hiding the files as much as they can. (This is not the case on Ubuntu Touch for example). And it becomes the responsibility of the app to organize the files it can open. This has a big impact on what you expect your desktop manager to done or not. I would personally be very happy if I could organize applications how we can organize files, and simply reopen a work session where I left it (some PDF open, some terminals open, my IDE, my browser...) even weeks after. To complexify the topic even more, the same thinking can be done in the browser, which is basically an OS now...

"Android and iOS are hiding the files as much as they can."

This is the number one thing that bugs me about all the mobile OS platforms. The most important thing to me is my data not the programs that I use to operate on them.

Anyone can have a copy of the programs I use, but only I have my data.

Leaving the organisation of something so important to some XYZ app doing who knows what is just madness to me.

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 ...

Win 3.11 program manager was application oriented. Win 95 was a mix, you could work document-oriented in Explorer (and most people did) but the start menu was still application oriented, with the exception of the "recent files" part (I forgen when exactly that was introduced). 'Libraries' pushes you from the files-and-folders back into a more application based model, to the point where I have an empty 'music library' and a folder music2 next to it where I can organize things the way I want.

  • I had a friend that stored her docs in a folder in the start menu back in win 95

    It was odd at first, but it made a lot of sense from a document first mindset.

    I eventually adopted a similar strategy myself.