Mapping Tools4Thought using collective intelligence tools
Help us map the Tools4Thought landscape and pilot decentralised collective intelligence tools in the process.
This post is based on the Tools for Thought Map pilot project, and is also part of an interconnected series of posts exploring how a decentralised ecosystem for collective intelligence could be bootstrapped into existence.
The Fellowship of the Link’s first pilot project aims to explore and demonstrate decentralised solutions to collective intelligence. It needs your knowledge, contibuted using the decentralised collective intelligence tool we’re piloting in the project.
Our focus is a knowledge domain loved by its inhabitants and confusing as hell to everyone else: Tools4Thought.
So what are Tools4Thought?
If your first reaction is “What the hell are Tools4Thought?”, the map we are developing will be for you.
So what are they? Tools4Thought promise to help you take and organise your notes to get the most out of them. Most claim to mimic how the mind works, with every note linked to many others without hierarchy, woven together into a personal knowledge graph using tags, bidirectional links and other tricks.
many people using Tools4Thought seem to spend more time tweaking their system than actually using it to think
While Tools4Thought play a central role in many thinkers’ productivity, they are rarely enough: most people using Tools4Thought are also productivity geeks, and spend a lot of time integrating their Tools4Thought with tools for bookmarking, writing, ToDo and calendar apps, bullet journals and many more. It gets complicated fast, so while I see Tools4Thought as a key element of decentralised collective intelligence, I don’t feel today’s products are easy enough for most users off the shelf.
Early adopters
This is unsurprising: it’s a new field, so these tools are aimed at early adopters, and so are generally highly customisable and often open-source, allowing early adopters to experiment and extend the tool.
As in many sectors, these early adopters are technology-oriented. In the thinking tool space, moreover, many seem to spend more time tweaking their productivity system than actually using it to think.
Inevitably, some of them fine-tuned their personal system so well that they managed to monetise it in the form of books and courses.
Forbidding landscape
That’s no bad thing, but the resulting landscape is forbidding to newcomers, with software still aimed at early adopters, and the subculture buzzing with competing visions advanced by people vying for clicks.
Moreover, those books and courses describe systems which have been obsessively fine-tuned to one particular user’s needs and tastes over several years. Newcomers are not only asked to learn new software, they are asked to change the way they work and think.
Newcomers are to change the way they work and think
This is unlikely to be “off the shelf useful” to them, as to reach mass adoption productivity software must obey the Pareto Principle: the first 20% of the effort should yield 80% of the benefits. Pareto-friendly software allows all users to reach a lot of low-hanging fruit fast, with only some users choosing to spend the remaining 80% effort to customise the tool and gain the last 20% of the benefit.
A pre-cooked system developed over years by a single early adopter, by contrast, has reached the 100/100 point… but only for that user.
And that’s why we need a map
A map of this landscape would help newcomers identify which combination of tools and practices would help them reach 80% of the benefits with only 20% of the effort. They can then customise to their heart’s content if they wish.
How the map will look
If the map was an iceberg, the tip showing above water would be a spidergraph (top in the figure, below) mapping various tools’ strengths and weaknesses along axes such as user-friendliness, openness, etc. Users can then simply define the strengths most important to them to identify a shortlist of tools best matching their needs.
Numbers on a spidergraph are great, but even better are the stories behind them. Users will therefore be able to dive under the waterline to explore a knowledge graph, composed of three sorts of file:
Personal profiles (bottom)
This is what we need current Tool4Thought users to submit, following the template. It includes an About Me section, the author’s scores for the tools they use (automatically added to the spidergraph) and short bulletpoints describing how they combine their thinking tools and productivity practices. Each tool and practice mentioned is a wikilink, and so links to the dedicated Tool and Practice pages (next).
Tool page (right)
A brief description of a thinking tool, with relevant bullet points automatically pulled from all Personal profiles, thus linking to all the people who both contributed to the map and use that particular tool.
Practice page (left)
A brief description of a productivity practice, such as inbox curation or zettelkasten. Again, the template automatically pulls in relevant bullet points from the Personal profiles of people using the technique.
explore a map of how different people use and combine thinking tools and techniques
A user starting with the spidergraph’s shortlist of thinking tools can thus discover not just the tools themselves, but explore a map of how different people use and combine it with other tools and practices.
How do we do this?
We’re building the map with massive.wiki: pilot projects, after all, are designed to explore.
Why massive.wiki?
The above architecture would be pretty easy to pull together using any modern content management system on a centralised server. But in addition to helping people navigate the world of thinking tools and practices, we are exploring how collective intelligence can be created using decentralised tools.
That means people creating and submitting the above knowledge (stories, tools, practices) using the tools they want to use, while also allowing the collective knowledge to be knitted together - in this case, into a map.
With massive.wiki, a network of editors can work on local copies of the wiki’s contents using any markup file editor, and submit them via GitHub. Git therefore provides version control, while GitHub provides collaboration tools that allow users to discuss and moderate changes at the word-by-word level if required (other ways of discussing the content are available).
I immediately loved the idea driving massive.wiki, as it’s a concrete example of one of the collective intelligence building blocks I’m looking for — an approach to Tools4Thought which simultaneously provides:
- home base for your social knowledge graph, where you can share selected ‘private’ notes with your friends: simply set a note’s visibility to “Friends”, or even a named group of selected Friends, and it will appear in their thinking tool.
- seamlessly integrated with your public web presence: simply set a note’s visibility to “Public”, and it’s live.
- anyone can integrate the knowledge into their own personal library of notes, pulling updates whenever they want, without being obliged to submit their own.
- users can collaborate on both private and public notes, opening up features such as forking and wiki-ising your notes with friends.
- the whole thing is opensource and non-proprietary: editors can use any markup editor and manager they want, from notepad to Obsidian.
Ready for primetime?
My first massive.wiki experience, however, illustrated how unready decentralised collective intelligence tools are for prime-time, and why.
The “standard approach” for using massive.wiki is to use Obsidian (a popular, reasonably open Tool4Thought) to edit your files, as Obsidian integrates with GitHub via a plugin. But I couldn’t get the plugin to work. I’m not alone with this problem, but the plugin developer simply refers people to Obsidian’s Discord channel, where I hunted in vain for help. It took three hours of coaching from massive.wiki co-creators Peter Kaminski and Bill Anderson before I was underway.
new users must not only master multiple tools, but also get them talking to each other
This illustrates a problem with my wishlist, above: it relies on different tools interoperating with each other, rather than trying to build monolithic software which tries to do everything. But that means new users must not only master multiple tools, but also get them talking to each other. And as these tools are usually open-source, technical support is limited.
Hence this pilot. It will simultaneously provide a massive.wiki test case, demonstrate a collective intelligence tool, and develop a map which will make it easier for new users to find their way in the Tools4Thought space, indirectly enlarging the user base.
Get involved
The https://tftmap.massive.wiki/ website is being developed iteratively, so this section will be irregularly updated as the site develops.
(January 2023): The site is currently version 1 — essentially a mockup to stimulate discussions with early adopters as they submit their personal profiles while Peter and Bill get the basic code working.
So if you want to get involved, check out the site and please:
- tell us what you think about the way we’re measuring thinking tools (there are several ways of commenting on the site’s content)
- if you use thinking tools, Contribute
- get help and join the conversation via the thinking tools map Mattermost channel, and the more general massive.wiki channel.
Bigger picture
Alongside this post I also just published a series exploring how a decentralised ecosystem for collective intelligence could be bootstrapped into existence. Start with the executive summary, or jump straight to the three posts it summarises:
- Thinking and writing in a decentralised collective intelligence ecosystem
- Social knowledge graphs for collective intelligence
- How Artificial Intelligence will finance collective intelligence
You can also:
- subscribe to my newsletter,
- browse everything I #LikeThinkDo tagged “Collective Intelligence” (or grab its RSS feed)
- follow me on Mastodon, here on Medium or on Twitter (although I’m quiet quitting the latter).
