Still thinking about Jason Yuan's 'Mercury OS" concept - or rather his rationale for it, preventing cognitive overload due to context switches and interruptions.

uxdesign.cc/introducing-mercur

I think what I want from a "desktop environment" is something that will let me *reify my threads of attention*.

Maybe that explains why I feel so cramped and claustrophic at a deep level in so many apps.

My threads of attention stretch between apps. I want those threads to be *objects in the system*.

Similarly, if the objects in my desktop are "threads of attention", it's maybe more easy to understand why I want them to have a bunch of very odd-seeming qualities:

* they're my thoughts, so they need to stay secure: local to my machine if possible

* they need to be safe from data loss: readable in the future across multiple OSes, so something like plain text

* they must be simple yet extensible

* they can't be a priori restricted in content (because thoughts), so static typing is not great

@natecull

Don't want to quash anyone's creativity, but in the vein of "keep it simple" and "don't reinvent the wheel":

Major environments (KDE, Gnome, XFCE,...) already support virtual desktops, whose features can be set individually to create "workspaces".

This allows me to arrange windows for different tasks, making it relatively easy to task-switch and recover my own state. I don't know what the limit is, but I use 10-20, easily.

I use different wallpaper on each as a mnemonic aid.

@TerryHancock

Yeah, virtual desktops aren't at all what I'm thinking about here.

It's nice that they exist, and I have tried them years ago (they didn't work for me but browser tabs perform a somewhat similar function) but they're just not anywhere in the vicinity of being this concept.

A key part of the concept is *not having applications at all*, because the context-switch occurs when going between applications.

A second key part is that the "desktop" treats views as *processable data*.

Follow

@natecull "Not having applications at all" goes a long way toward conveying my intent in relying strongly on shell / console / command-line tools principally. I've never liked monolithic applications, and for a long time the only one I really used was a GUI web browser (and if possible, I'll still gravitate to a terminal-based one).

I'd also started off mostly working with remote access to my real computer, whether that was running Unix, VMS, MVS, or whatever. The idea of a local interactive client (text or GUI) and some remote box, or set of boxen, on which Heavy Shit ran, seemed sensible. Local side remained responsive. Any given remote box might get saturated, but there were usually others.

Shared resources might be disk, comms channels to common storage, and external networking. Mostly those didn't matter much (we're talking 1990s-era here).

The workstation age was ... in some ways a step back. I mean, it's nice having a bunch of power on my desktop, but that also means that when I want it to get busy it's absolutely pigged out.

And no, I'm not a gamer, so local low-latency high-graphics performance wasn't really a need.

@TerryHancock

@dredmorbius @TerryHancock

Yep, I feel like something important from the Unix command-line piping model was lost when we moved to windowed GUIs, and while I don't like to blame Smalltalk... it was kinda Smalltalk that pushed that shift.

We went from "data piped through small tools" to "big opaque stateful silos".

I don't understand what went wrong because both Unix and Smalltalk seemed to have coherent visions of separable components... but together, I feel like they made the opposite.

@dredmorbius @TerryHancock

But I've never really made friends with an actual Smalltalk. Booted up Squeak once, got lost within seconds, never really felt welcome. Maybe I should try again, but... dunno.

If I had a Smalltalk, I think a big thing I'd want is to put arbitrary chunks of the image / object soup inside some kind of transparent box... sort of a Docker thing, but extremely lightweight? And use that for all sorts of things, from revision control to data import/export to app shipping.

@natecull What Mercury seems to be describing with a visual metaphor is what old-school Unix was doing through the shell.

Grab a copy of Peek et al's Unix Power Tools and flip to the Productivity section. It's a bunch of hacks for managing to-dos, email, chat, reminders, etc., as flows. But textually rather than graphically.

The GUI mocks that the Mercury article show would be great visualisations for how a Unix-oriented flow works.

It's just that instead of, say, 8 items on a screen, I could see 25 on a standard 8x25 terminal display. Without scrolling.

Bump up the terminal size or scroll, and I'm dealing with 10s, or 100s, or 1,000s, or 1,000,000s of elements and entities. But I don't have to attend individually to each, since it's the shell tools that are doing that job.

@TerryHancock

@dredmorbius @TerryHancock

Yeah, like you I'm really not a fan of that very Apple-like UI interaction workflow as shown in the video. I've used systems with much more information density, including text, and I want that. Those little "cards" make me feel cramped.

It's more the cognitive justification for the need for such a UI (he says "OS", but he means "UI") that I'm interested in. That's a part that was missing for me - *why* I feel like I need a system object which isn't an "app".

@natecull There's a strong element of the ideas that I'm playing with in which is oriented around this.

The principle interfaces would be the filesystem and shell. (The filesystem would be strongly document-oriented: & .)

And utilities would act on those documents through workflows, projects, groups, tasks, etc.

Whether or not that fits what anyone actually wants to do is ... another matter.

@TerryHancock

@natecull Now, if someone could figure out how to make both you & me and the metaphorical Cory Doctorow's Technoilliterate Boss happy, through an interface that's both textual and graphical ...

... I wouldn't comlain.

@TerryHancock

@natecull And yes, I'm aware of many reasons why My Vision Is Not Today's Reality:

  • Most people aren't literate. Not computer literate, but literate literate. High-functioning literacy is about 15% of the adult US population (nces.ed.gov/pubs2019/2019179/i)

  • Proprietary software markets reward monopoly, winner-takes-all, and monolithic design.

  • There are tasks which simply don't decompose well to text. Including a lot that goes beyond somple 7-bit ASCII.

  • If attention is the limiting factor in workstation / PC usage, then that's where a competitive marketwill wage its wars. Computers are so cognitively draining because that is how companies defend their castles. Your attention is literally their defensive moat. No, a bunch of emotionally drained computer peons isn't a profit centre directly (this isn't the Matrix), but it does keep new entrants from hiving off marketshare.

  • There's still competition for which specific motifs and protocols will win out. And there's been contention for these. (Playing in the environment defined in the preceding points.)

@TerryHancock

Sign in to participate in the conversation
Toot.Cat

On the internet, everyone knows you're a cat — and that's totally okay.