This is a really interesting point to consider. Makes me think about how Typeform needed to make UX flows for every part of this, whereas a domain-specific language only requires you develop the logic for how things work. You can make the "flows" after, like we did w/ the toolbar
Also makes me think about how much less flexible GUI first tools are. Here I'm trying to:
Ask the user's goal (multiselect)
Ask what they were doing prior for each user goal
GuidedTrack doesn't have a prebuilt UX flow to generate this, but it works emergently and I can just type
On the other hand, Tripetto has a prebuilt functionality and user flow for iterating on each multiple choice response, it ended up taking me 3.5 minutes to write (when I already knew how to do it!), and still requires me to understand conditional logic. cln.sh/axtKCe
I should really just post more of my threads as notes on my website instead of tweets huh? It’s like... 15-20 more minutes of refinement robhaisfield.com
Part of why I keep it on Twitter is specifically because of everything else I have on Twitter... there’s a lot of information density that comes from QTing other threads. So on my blog, would it be better to replicate more content into its format, or to reference my tweets there?
I joke to myself sometimes about how I’m apparently incapable of sending out a stand-alone tweet without it becoming a thread. Maybe that’s just a signal that Twitter is the wrong format 🤷♂️
What I like about this is that it makes it easier to start thinking about problem understanding in terms of more dimensions: an edge is about how two vertexes connect. A face is the synthesis of 4 faces and vertexes. A cube is the connection of 6 faces. A tesseract is the conn...
Reminds me of @JoelChan86's knowledge compression - you get more expressivity and remixability when you compress your knowledge. A cube could be expressed as the connections between 6 faces, 10 edges, or 8 vertices oasislab.pubpub.org/pub/54t0y9mk/r…
.@al_malecha "Wait but what about the things outside of the cube? You're literally putting your thinking into a box."
One challenge with explainers is that, no matter how clear they are, many people just skip them.
Something I love about feedback loops is that, as long as people are using the product, they'll learn how to use it. Skipping feedback loops means nonusage.
Explainers feel appropriate for more complicated concepts... but does that really teach the nuance better than trial and error that clearly shows the outcomes of your behavior?
An explainer might help people feel more comfortable getting started and triggering the loops.
If you’re great at queries and can constrain yourself to having certain canonical blocks for a concept, you technically could use block references instead of page references. The trade off is that filters would be harder to use since you can only filter by page refs @RoamResearch
If I were to do that, then all of my most important notes would just come with certain text in the block to make it easy to autocomplete. For example, all of my open questions have “open question” in the text of the block so that ((autocomplete is searchable.
What’s nice about this approach is that it gives you autocomplete but for whole thoughts, whereas it’s cumbersome to put more than a sentence into a page name. Actually, I might do this with my “evergreen note titles” too... use them as block refs for more robust autocomplete
It would totally be possible to use @figmadesign (albeit hacky) as a personal knowledge management system given certain user behaviors & maybe a few new plugins 🤔 It wouldn't be nearly as powerful as say @RoamResearch or @kosmik_app but it would outperform traditional note apps
It has a lot of the same limitations of text vs. GUI I describe in this thread. Ultimately, if an idea doesn’t need to be expressed with visuals, it’s just really hard to beat the speed of typing. That being said, doing it visually leads to me thinking through it differently.
An alternative view on what a visually created PKM system could look like in this thread, as well as musings on the limitations of Figma that could perhaps be addressed via plugins