With a setting, a conflict between two options becomes a choice (or compromise) for the user, instead of a situation to be solved by the designer. The conflict itself has not been evaporated.

The checkbox to show or hide brackets in Logseq is an example of this. I use Logseq as an example, because it is the software that I use daily and like a lot.

The conflict

When the setting enabled this improves the editing experience. The brackets are already in the text and so the text doesn’t move as much when you click the text to edit. This fills the need for a better editing experience.

When disabled the text looks better when reading, because you don’t have formatting syntax interspersed between your text. This fills the need for a better reading experience.

The two settings are in conflict with each other. When the setting is enabled, it makes the reading experience worse. When disabled, the editing experience becomes worse.

Both needs, a great editing experience and a great reading experience, need to be fulfilled, to reach the goal of making the Logseq experience as a whole a great experience.

When conflict is evaporated, you fullfil both needs and come closer to the goal. So the question now is, how can you evaporate this conflict?

Before we can do this, we need to find the underlying assumptions for the five arrows between the blocks. One or more of these assumptions are wrong and this can lead us to a solution.

An aside about conflicts

You can notice a conflict in your life when you are toggling between the actions depending on the mode you’re in (a compromise). The other way is that the conflict is something that you hide from yourself, you don’t think about it (willful blindness).

Another way to feel the conflict is that when someone asks you to do something, you feel like you can’t do it, because you feel pressure to do something else. Or when you feel you should do something, but feel pressure to do it another way.

Specifying the conflict as concretely as this helps to find the points where you make your assumptions clearer. It can then help to find the core conflict of the problem and find a solution.

The assumption

Logseq uses a method to write a document that depends on Markdown. This method uses formatted HTML when reading and a <textarea> when editing. In the editing mode the Markdown is shown and when reading this Markdown is formatted. This allows you to use Markdown formatting when writing and have a nice reading experience. The problem becomes more visible when more formatting is used. When there are more invisible characters in the reading view, the jump to editing becomes wilder. The biggest jump I think is when using markdown links, because the whole URL is hidden.

The assumption is that, because Markdown is plain text we need a separate editing and reading experience, which cannot be combined.

The need for Markdown creates a conflict between the editing and reading experience.

A solution?

I see two solutions at the moment. This does not mean that Logseq should make these same choices or use any of these solutions.

One way to solve this conflict is to use a rich text editor, or an editor that combines Markdown syntax with the formatting. There are apps that already provide this experience, like Obsidian and Typora.

Another solution would be to use a full rich-text editor.

Both of these solutions create their own conflicts, which I did not look at yet.

Conclusion

The result of looking at this example is that something as simple as a switch between two options, can show that a larger conflict exists, because of a unrelated choice for a file format.