3 ms·

It’s an odd way of thinking about working on a computer—it’s task-based rather than app-based or document-based. If I've one frustration with computer interfac

It’s an odd way of thinking about working on a computer—it’s task-based rather than app-based or document-based. If I've one frustration with computer interfaces, dating back to the 1990s, it's this. If anything it's become worse with time as apps, both desktop and mobile though especially the latter, become more self-centric, to the point of having their own, non-filesystem-based, data silos. I understand some of the security reasons for this (apps are themselves increasingly untrusted and untrustworthy, and data-sharing is a significant risk). But it is extraordinarily frustrating when trying to work with multiple tools. Modern MacOS is particularly pernicious in that I'm often working between multiple applications, but on the same project, and the friction of raising and lowering all app-associated windows as I cycle between these, often navigating to a workspace I'd not meant to go to, is quietly maddening. The Linux / X-Windows notion of focus-follows-mouse addresses this somewhat. Your current app is whatever the mouse happens to be on top of. On MacOS this simply isn't available, though there are some ... hints of this. E.g., if I happen to have the mouse over a browser window I can scroll that window with the mouse. But if I then, say, hit Cmd-W to close that tab ... suddenly the actually focused app which I'd forgetten about gets a kick in its nethers. This happens to me several times a week, if not per day. I don't know that Stapler is the true solution to this, but it does seem to track in that direction.

msephton 2y ago
Check out my comment about Xerox Star & Smalltalk and what Apple missed from their visit to PARC: https://news.ycombinator.com/item?id=41215350 https://news.ycombinator.com/item?id=41215350
- dredmorbius 2y ago
  I saw that, appreciate it, and agree ;-)
bane 2y ago
The history of Operating System development is really interesting in that the decisions of what the atomic element of the system are (files, documents, or applications) lock all future development into a certain path, but all the choices not made then have to be somewhat retrofit into the design. For decades systems have dwelled in a kind of morass where they seem to focus on trying to implement different variants of the other two, with one of these atomic elements as the core concept. For example, the dominant atomic concept in Xerox Star was the document [1]. Documents are an abstraction just above files. A webpage is a document, but is made up of numerous files like the graphics, fonts, executable scripts, etc. Document oriented systems like Star also deemphasize applications. The system is supposed to open up the correct application(s) when you choose to interact with a document. But even with this as the core abstraction, the system still had to provide methods to work directly with files and applications. Other systems, like Plan 9, nixes, MS-DOS, CP/M, etc. focus on the file as the atomic primitive and try to build around that. But when things moved to GUIs, many of the development teams focused on the Applications. Windows 3.x famously only showed users organized collections of applications, with file management as just another application. But Windows 3.x was sitting on top of DOS which oriented itself around files. The nixes in the meanwhile forgot about documents almost entirely. Where I think they've failed to evolve is not in reimplementing these three things over and over, but in assembling them into useful, higher-level, abstractions. What I really think is missing is a way to assemble two higher-levels: workplaces which implement workflows. Pipes and scripts sort of mimic workflows, and desktops sort of mimic workplaces, but these concepts have really stalled and there's almost no real system-level tooling for building these things, especially in a GUI. For example, scripts are really used as a kind of a way to assemble pipes into pseudo applications + automation, but it's hard to turn them into real workflow tools, and desktops just allow you to dump a bunch of application windows and files into one place, but there isn't any real scoping to it. 1 - https://youtu.be/xJzYRgmnJrE https://youtu.be/xJzYRgmnJrE
- dredmorbius 2y ago
  The Star's document seems similar to me to a project folder or perhaps a composite archival format: tar, WARC, EPub, etc. The latter are useful for keeping various assets together, though at the cost of complexity when working with them. Makefile management ties together a set of resources and independent tools in a different way.

msephton 2y ago

Check out my comment about Xerox Star & Smalltalk and what Apple missed from their visit to PARC: https://news.ycombinator.com/item?id=41215350 https://news.ycombinator.com/item?id=41215350

dredmorbius 2y ago
I saw that, appreciate it, and agree ;-)

bane 2y ago

The history of Operating System development is really interesting in that the decisions of what the atomic element of the system are (files, documents, or applications) lock all future development into a certain path, but all the choices not made then have to be somewhat retrofit into the design. For decades systems have dwelled in a kind of morass where they seem to focus on trying to implement different variants of the other two, with one of these atomic elements as the core concept. For example, the dominant atomic concept in Xerox Star was the document [1]. Documents are an abstraction just above files. A webpage is a document, but is made up of numerous files like the graphics, fonts, executable scripts, etc. Document oriented systems like Star also deemphasize applications. The system is supposed to open up the correct application(s) when you choose to interact with a document. But even with this as the core abstraction, the system still had to provide methods to work directly with files and applications. Other systems, like Plan 9, nixes, MS-DOS, CP/M, etc. focus on the file as the atomic primitive and try to build around that. But when things moved to GUIs, many of the development teams focused on the Applications. Windows 3.x famously only showed users organized collections of applications, with file management as just another application. But Windows 3.x was sitting on top of DOS which oriented itself around files. The nixes in the meanwhile forgot about documents almost entirely. Where I think they've failed to evolve is not in reimplementing these three things over and over, but in assembling them into useful, higher-level, abstractions. What I really think is missing is a way to assemble two higher-levels: workplaces which implement workflows. Pipes and scripts sort of mimic workflows, and desktops sort of mimic workplaces, but these concepts have really stalled and there's almost no real system-level tooling for building these things, especially in a GUI. For example, scripts are really used as a kind of a way to assemble pipes into pseudo applications + automation, but it's hard to turn them into real workflow tools, and desktops just allow you to dump a bunch of application windows and files into one place, but there isn't any real scoping to it. 1 - https://youtu.be/xJzYRgmnJrE https://youtu.be/xJzYRgmnJrE

dredmorbius 2y ago
The Star's document seems similar to me to a project folder or perhaps a composite archival format: tar, WARC, EPub, etc. The latter are useful for keeping various assets together, though at the cost of complexity when working with them. Makefile management ties together a set of resources and independent tools in a different way.