> He talked about the desktop building blocks, basically the familiar WIMP model plus the desktop clipboard, as the way that users move data around. Expert users can move data around quickly, he said, but there's a problem: the desktop is stateless. He called this the curse of direct manipulation; there is no working memory to the desktop. ""If you copy a few too many things to the clipboard, oh sorry, it's gone"".
>
> Jenson theorized that the reason there are so many desktop environments, window managers, and Wayland compositors for Linux—as well as alternative clipboard managers—is because the desktop isn't quite working right for users. He thought it was really about working memory: ""How do I manage my data in such a way that I can remember it across all of these things and actually use it."" His perspective shifted to asking ""what would we do to working memory to improve the desktop UX?""
I feel this so much.
I think that there's a "better" windowing system where all of your stuff sticks around way more than it used to. Clipboard history, but also just "oh you have these windows open while working on this task".
People have really leaned into coding harnesses + chat windows as a way of grouping together work. I think there's a more general idea in this space. Don't make me explicitly keep track of things, just hold onto it all for me!
There's some universe where my desktop is basically a Notion-like thing, and I can just throw things into semi-persistent workspaces (that I close out when I'm done). Desktop Environments that make this work nicely will be quite cool IMO
(A simple and dumb version of this is the BeOS "group various windows together, even though they aren't from the same application" stuff. Very cool stuff IMO
Stateless desktop is a feature. Application state is something I have to mirror in my head to prevent applications from doing unwanted and surprising things.
IMO, even the clipboard metaphor is too much state. We already have the selection highlight, which has the nice benefit of being directly visible. This should be reduced to a single global selection highlight. Then copy and paste can be replaced by "duplicate highlighted selection here", eliminating the possibility of forgetting what's in the paste buffer.
Yeah I definitely understand the value of the stateless desktop.
I do think that, for example, the fact that browsers hold history is generally a useful thing, though, right? For me it's less about persisting the application state itself as it is about holding onto metadata for later inspection.
Browser history is state done right because it's not hidden. There's a top-level "History" menu with lots of tools for managing the history.
rtpg · · focus · HN ↗
I feel this so much.
I think that there's a "better" windowing system where all of your stuff sticks around way more than it used to. Clipboard history, but also just "oh you have these windows open while working on this task".
People have really leaned into coding harnesses + chat windows as a way of grouping together work. I think there's a more general idea in this space. Don't make me explicitly keep track of things, just hold onto it all for me!
There's some universe where my desktop is basically a Notion-like thing, and I can just throw things into semi-persistent workspaces (that I close out when I'm done). Desktop Environments that make this work nicely will be quite cool IMO
(A simple and dumb version of this is the BeOS "group various windows together, even though they aren't from the same application" stuff. Very cool stuff IMO
mrob · · focus · HN ↗
IMO, even the clipboard metaphor is too much state. We already have the selection highlight, which has the nice benefit of being directly visible. This should be reduced to a single global selection highlight. Then copy and paste can be replaced by "duplicate highlighted selection here", eliminating the possibility of forgetting what's in the paste buffer.
rtpg · · focus · HN ↗
I do think that, for example, the fact that browsers hold history is generally a useful thing, though, right? For me it's less about persisting the application state itself as it is about holding onto metadata for later inspection.
mrob · · focus · HN ↗