We also have monolithic application ecosystems because there are 10,000 ways to do information handoff between sub-problems and every developer will choose to do something subtly different making interoperability a nightmare.
Conversation
But those are all criticisms at a metalevel. There are two major things that jumped out at me while I read through the entire presentation.
1
1
Firstly, the example was given of "why does Photoshop ask you for both the name of the file and the place to save it?" In the context of interfaces being too overwhelming in the number of questions they present.
1
1
It asks you both because it needs to do both. It asks you both because both of those pieces of information are important to doing the job you're asking it to do. That's the task. The tool already exists.
2
2
And yes, I know, the whole deal is to somehow magically question whether or not the entire abstraction of files and file spaces is somehow inherently inferior to implicit clustering by temporal and task attachment.
1
4
Remember how I said there was decades of user interface design that were hand-waved by the writer? This is part of it. It's not like this is a new line of questioning.
2
2
Yeah, and the old answer is wrong :)
1
The old answer is twenty years of semantic file systems and GNOME Shell where it's one of the first things people turn off once installed. So you're right, but not about what you expect to be.
1
1
My own feeling is that the previous attempts AND Mercury both try to usurp too much. They try to replace and not adjunct, which provides no on-ramp. They forget people already have jobs to do.
1
1
Agree here too
iPads arent computers
iOS isn't an empoweding OS
MercuryOS is a good conceptual framework for **something** related to (programmable attention)TM-
2
1
2
My broad sense is that the desired end-state is an inversion, a dual of the current structure: instead of apps-as-nodes, we have apps-as-edges. Roam and LiquidText are nouns/places; I think their ideal form is as verb. Roam/etc-as-OS is roughly what’s necessary for this, I think.
Though please n.b. that this is almost certainly the wrong path for your business (unfortunately).
Related:
Quote Tweet
Replying to @LiquidTextCorp and @spiralstairs
I'm very excited to try!
I worry about the opacity of the app container model. Conceptually speaking, I want the LiquidText canvas at the level of the OS! Across not just some PDFs, but also web pages, mail messages, etc. The model pushes towards little app silos—it's a bummer.
3
We've tinkered with "apps as service providers" (not in those terms, of course) before. Plan9 took it pretty far down into the Mach kernel, even. It has some useful bits but the multiplicity of desired ways to touch ANYTHING means things get unpredictable fast.
1
2
3
Indeed. I don’t know a workable model for this.
It’s interesting to see TimBL try it again with Solid.
The “no-code”/“Zapier-driven” trend is interesting to watch, too, since there’s a greater emphasis on end-user-usability. But I’m not optimistic here.
1
3
Show replies