Tool Makers Should Help us to Easily Share Workflows
Tools for Thought are complex and could be easier to adopt into our life if it was easier to share workflows between users.
Tools for Thought are known for having steep learning curves, which can overwhelm us as users.
From personal experience and learning the depths of multiple tools, I have found it takes at least two to three months minimum to begin to comprehend a tool's full potential. This doesn't mean I have mastered the tool, but have come to a level of understanding that will help me see and plan how I can maximize the benefits of the tool.
You have likely found for yourself that the investment to learn such tools is significant, requiring time, energy, and often lots of frustration, but in the end, that effort can lead to significant gains over time. As they say, no pain no gain!
What needs to be learned?
Learning a tool is not just about learning the features of a tool, but also how that tool fits into your personal workflows that help you accomplish your goals in life and work.
Just to be on the same page, a workflow is a collection of steps, or actions, that produce a desired result. Common workflows might include morning routines, daily or weekly reviews, processing new notes, repetitive tasks with multiple steps, and other similar multi-step procedures. Larger workflows can even be made up of other smaller workflows.
Workflows and the actions required to complete them are linked directly with a Tool for Thought's features. This means you have to learn the features of the tool and then map them into how they will help you achieve the steps in your workflow. Though it really should be the other way around right? The workflow should help us define the features we need from our Tools for Thought. Form follows function.
Herein lies the often simple-looking challenge for us as users of Tools for Thought: defining our workflows, learning the tool's features, and then combining these two things together. This process can be time-consuming and even overwhelming. There are just so many moving parts, and sometimes we don't even know what we want. For example, can we clearly answer these questions:
Is our problem well-defined?
Is the solution well-defined?
If we don’t know what we want, it’s impossible to know what we need. Therefore, we need a clear picture of the why and the how.
Learning from others
For this reason, many of us like to learn from others who have more experience. This is why it is popular to watch videos or read articles from other users profiling the way they work, how they use the tools, and specifically their workflows.
As we see how they solve problems, using tools we want to use, we begin to shape a mental picture and a more complete understanding of where we can go in our own efforts.
The Tools for Thought community is very generous in this regard, sharing their workflows and techniques. Bravo!
However, the next thing after seeing their approach to using tools is that we want to duplicate their approach in our own environment and then build on that. Yes, we would like to use their approach as a foundation or template to get us started.
Here in lies the problem. While it is easy to watch others show their workflows, it's not easy for us to reproduce their workflows. Why is that? Tools for Thought are complicated pieces of software.
Often workflows require installing plugins, configuring software settings, creating reference data, and even at times installing code like JavaScript. This compounds the complexity.
Frankly, sometimes the installation and configuration of tools are so technically complex that they are beyond the reach of many. For example, why would someone have to learn the basics of JavaScript or an advanced query language to leverage workflows? That is just insane to expect users to have to go to these extremes.
A solution to sharing workflows
What we need is for the makers of Tools for Thought to solve this problem for us. We need them to build into their tools features that will allow users to share their workflows, with other users.
In other words, a way to bundle up a workflow that can be shared with other users without all the complexity and pain during the installation and configuration.
Just a note: I am not speaking of sharing workflows between different tools, rather sharing a workflow between users of the same tool.
This might seem too difficult, but some companies have succeeded in this. Tana is such an example.
Tana is a company that is spearheading this concept of user workflow sharing in the beta phase of its product development. They recently released a templating feature that allows a person to bundle up their workflow and then "publish" it for other users to "install" into their own personal workspace. They have even set up a catalog of reusable workflows.
You can find detailed instructions about creating and using Tana Templates at this link, but let me outline the overall process of sharing a workflow in Tana:
Imagine in Tana I develop a morning routine workflow that has three or four morning activities that I like to do, each procedure with a few steps. I want to share this with others.
I can put all this workflow (or workflows) under one node in my graph and then using a Tana command, I can publish this workflow (the parent node and all its child nodes).
Tana gives me a URL for that workflow that can be shared with others.
The other user who wants to use my workflow can then import the workflow into their workspace using a command Tana provides.
The user gets all the configuration information and instructions on how to use the workflow along with sample data or reference data.
Once in the other user’s workspace, they can start using it right away and then adapt it over time for my unique needs.
If you want to learn more about Tana and its template sharing system, check out this great video by Ev Chapman:
Tana Templates can save users hours to days of effort because they won’t have to reinvent the wheel and create the mapping of a needed workflow to Tana features, as someone else has already done all the hard work for us.
Examples
Let me provide a few examples that illustrate how this could simplify our lives if we could easily share workflows.
Language learning: Imagine you are learning Spanish and someone has created in Obsidian a collection of 3,000 vocabulary cards that use the Spaced Repetition plugin for flashcard testing. If Obsidian had a sharing feature, it could bundle up all the flashcards, and the plugin needed for this solution into one file for sharing. As users, we would get this file, and put it into our personal Obsidian vault. Obsidian would then install the needed plugin, configure it, and also put all the supported markdown files into an organized place. While we would still have to learn how to use the flashcard system, we would not be bogged down in getting it to work.
Habit Tracking: Imagine a personal trainer has created a set of best practices in Logseq to help track important daily habits, such as drinking enough water and getting your walking steps in, amongst other things. This tracking solution might be a set of Logseq templates for quickly recording your daily habit activities and predefined queries for reviewing your progress. If Logseq had the ability for the trainer to bundle up these templates and queries into a package file, that could be forwarded to their clients for installation into their Logseq graph, it would greatly simplify the adoption of that trainer’s better habit-forming methods.
Progressive Summarization: Imagine your friend has been using Tiago’s Progressive Summarization technique and has developed a number of SmartBlocks in Roam Research for walking you through 5 layers of summarization. If Roam had a feature to bundle up these SmartBlocks and supporting documentation into a package file, you could install it in just a few minutes and start using the SmartBlocks.
These are some very basic examples, but what I have seen from personal experience in helping many users install such workflows into their Tools for Thought can take hours and often doesn’t work because the user misses one tiny little step in the process. It just shouldn’t be this difficult.
What am I proposing?
This is a call to all makers of Tools for Thought to give consideration to how they can help users share workflows. Their tools can be complicated, and users must invest time into learning them, but it's a big help to build on the work of others and duplicate their efforts as starting points.
Makers of Tools for Thought need to build into their tools sharing features, not just for collaboration, but for sharing workflows between users.
Tana is off to a great start with their Templates feature. This is the way!
Another benefit for makers of Tools for Thought if they provide “workflow sharing features” is helping creators easily share and even monetize their work. There is a thriving market in the community for templates, how-tos, and best practices. Additionally, when people build workflows that their life depends on, well, they become more dependent on the tool, which reduces user attrition. The point is: features are not enough, and users need solutions to problems. If your tool doesn’t solve a problem, users will move on, regardless of the hundreds of features you have.
What do you need to do?
Dear friend, reach out to the makers of your tools and ask them about their plans for workflow sharing between users. Help them see this as important and useful. Help them see this is a feature that will help users see that a tool’s community isn’t just some discussion forum or YouTube channel, but something built into the product.
I love this concept! Several threads here:
- we learn to use a tool by watching other humans use the tool as well as trying to use it ourselves. this is why I love pair programming with other developers. I learn far more by watching the way they interact with their machine and structure their work and think through problems in a whole-life way. see the apprentice/journeyman trades system in history, etc.
- digital spaces make it difficult to learn from others by watching. we have our own private glowing rectangles, isolated in our own rooms. even youtube videos of people working are highly edited / curated, not truly useful for learning how to use the tool.
- this is similar to ethnographic research. sitting with users while they live their lives and the tool usage takes place in context. there are some good works on this sort of thing in anthropology / sociology.
- basically, every product team that actually does their job well inherently does this. they enter into the WORLD of their user and place their software in context. unfortunately, this excellent research is trapped inside of companies in their internal wikis, their private video archives. for example, the Muse team did extend user research before building the first version of Muse. if only this research could be shared!
- We started experimenting with "workflow walkthroughs" during Tools for Thought Rocks sessions, where someone spends 5-7 minutes showing off how they execute a specific workflow, such as "taking notes in a meeting" or whatever. It's not feature focused or tool focused, it's the workflow, which usually consists of one or more tools used in tandem. It was enlightening to see what people actually did! But the default was to slide into describing "features" of the tool - which is not that helpful. "Let me watch while you do it."
I would love to somehow see this idea of a shared repository of workflows come to light! I think we could all stand to learn from it, whether you're a tool user, a toolsmith, or a researcher.
I love this idea of shareable workflows.
Even though you mentioned it wasn't what you were suggesting, there's absolutelly also something to be said for shareable workflows for users between tools (portability and discovery)!