A few Bear 2.0 simple feature requests for better support of thinking and creating with links

Beta Panda Feedback
1

Hi,

First of all, let me say how much I love Bear and the direction Panda is going – I’ve tried and used in depth all major notes apps under the sun, followed the development of many (Craft, Obsidian, DEVONthink…) and even chatted with their devs on occasion. The Bear team’s care to detail and UX is stellar. The obsessive care to minutiae makes Bear a joy to use, and I understand some features will never be implemented in there, because it detracts from the vision of an “easy to use, deep to master” app.

That being said, many new features have appeared in linked notes apps, some of which have appeared in Bear (wiki links, linking to headers), and make the app even more powerful to help and support thinking. (I’m a professional fiction writer, and using heavily those tools in my daily work, especially the emergence supported by linking notes.) This post aims at requesting some of the major features that have appeared through the last few years, and which I think could be implemented very easily in Bear 2.0, without adding any kind of complexity and detracting from the vision of the app.

Backlinks will be implemented

Mentioning those as they are a staple of the product space, but it has already been confirmed that they will be implemented. Move along!

Remember uncreated notes titles when suggesting wiki links

Here is the use case: you write a note, deep in flow, and add a wiki link to an uncreated note, for instance [[Character A could do something]], in order to flesh it out later. But later in another note, you think again of that idea and write [[Character A could do some thing]].
Problem: if you have not created the first note by clicking on its link, that link won’t be suggested to you in the second note. You then run the risk of creating two different, diverging notes. And remembering to create the note immediately when adding the link breaks flow and adds clunkiness.

Solution: either

  1. remember uncreated note links and offer them in the suggestions when creating a wiki link. That way, I could see I already had my first idea when linking it again in the second note, and avoid a duplicate. (Obsidian does this.) Unobtrusive and easy!
  2. create all notes automatically when creating a new wiki link in the “Untagged” category. (Craft does this.) Much less elegant, favor solution 1 (which should be reasonably easy to achieve since Bear uses a database)

Auto tag new notes created through wiki links when working in a tag space

Currently, when a tag is selected in the left column, all new notes share that tag, allowing you to keep working in a given tag (and mental space). This is not the case, though, when you create a note by clicking on a new wiki link; it will then be untagged. For consistency, it stands to reason that the new notes created in that manner would share the first behavior and be auto-tagged as well.

Quick opener

A quick opener, a la Spotlight, would be a boon to quickly search and access content, offering to

  • Search for a given note or heading (just as the app does when suggesting wiki links)
  • Access tags directly, and especially subtags, saving clicks

Bonus: if the app remembers links to uncreated notes via wiki links as per my second proposition, it could also suggest those in that quick opener, possibly with a different color or marker, showing that they are “pending”. They could be then created directly from there, very easily. Almost all current notes apps offer this (Obsidian, Craft…)

All these features seem to me to be both simple, consistent with Bear’s mission and easy to implement. They would go a very long way to position Bear 2.0 favorably for integrated thinking environments / PKM against the competition, while remaining true to the app’s slick UI / UX.

Moonshots (other features for thinking)

For the sake of completeness, I am listing below other major features that have appeared in the space these last few years, but which I honestly feel would require a lot of work on the team to make work while remaining consistent with the app’s philosophy. I would love to see them, but I’m not holding my breath, as I realize this is probably more complexity that the devs want for Bear. Still, here they are, sorted from (in my opinion) “closest to the app’s vision” to “farther away”. These are not requests on my part, just food for long-term thought.

  • Unlinked mentions (stil pretty close to the vision). Along with its backlinks, a note could show where it is mentioned elsewhere but unlinked, deepening possible cross-references throughout notes.
  • Aliases (more complicated to achieve elegantly). Notes could carry alternate titles for easier cross-reference (works best when paired with an unlinked mentions feature). Use cases include: people working in multiple languages; scientists where commercial products may have scientific names (think medicine), where species have vernacular and scientific names; the humanities where the same historical figures may have gone through different aliases and identities; etc.
  • Block references (that would also remain in line with Bear). We have links to headings, we could have links to paragraphs and blocks of text. Goes along and works best with…
  • Transclusion (very powerful, but that is farther from classic Bear): embed a block of content inside another note, allowing cross-referencing and live editing. Needs block references, obviously.
  • A graph of links (possibly the farthest away from the original vision). The graph can be a very powerful tool for visualizing unlinked notes, for homing it onto a given subject, for seeing a structure emerge from various areas of interest. Of all these, that’s the tool I expect to see less, but I’m mentioning it.

Hope this can be of use to the team. Once again, I perfectly understand – and appreciate – that the team is very picky about what features to put in Bear. I believe, however, that the requests in the first part of this post are minimal additions in terms of features that would go a very long way to better support deep thinking, while keeping the app streamlined.

Thanks for reading :slight_smile:

7 Likes
2

d’accord! Very little feature but extremely useful

That is the only point in your post i heavily disagree. In rare cases i want the new note (created by crosslink) to have exactly that tag which is selected in left sided pane

Yes, useful, i just don’t know if i would use it frequently :wink:

Generally the most tools use a "|” inside the crosslink to specify an aliases. Isn’t that elegant enough? :smiley: I desire that feature highly.

Especially in combination with block references but also with whole shorter notes this is a killer feature that offers so many possibilities.

3

I agree that the ´|´ syntax is currently used in many apps and that’s a reflex we often have, but it remains to see if the devs agree it’s light weight enough. There is also the issue of defining default aliases for notes: a note called ´orca´ can be defined to be aliased to ´killer whale´ in the whole of the notes, something that would be defined in an inspector pane. Which is why I believe it adds complexity the devs may not desire. (Even though I’d very much like it to happen)

4

That definitely would add complexity that would not fit into bears approach as the aliases would be defined in another part of the ui. The straight slash inside of the link itself is light weight in my eyes: how much weighs a slash? :smiley:

5

That would be only half the story and a really limited feature. The real power of aliases lies in conjunction with an unlinked mentions feature, necessitating the ability to add specific aliases to given notes so that they are recognized throughout the whole database. Which is why I don’t think it fits Bear as it stands very well.

The first part of the post, on the other hand, would bring huge QoL improvements without bloating the app. :slightly_smiling_face:

6

Hello and thanks for your precious feedback!

I can tell you backlinks and a quick opener are projects we want to tackle after 2.0 release.
I do have some questions/considerations about the other proposals

Uncreated notes
I have some problem with the concept of uncreated note and way more with creating notes without an explicit user intention. The first creates a new note state (linked but not created) and this has to be communicated in the completion panel. I can’t think of a good way to achieve this without writing “Note not created” somewhere near the title (not a good solution). On the other hand creating notes while writing wiki links makes we wonder what should happen when a link is edited: Should Bear create another note with the fixed title, delete the previously created, so keep track of the created but not used notes somehow. Also, might be me but, triggering app actions while editing the text feels like possibly going against user expectations and intentions.

I do wonder if this can be mitigated by a better way to move back and forth notes in a way creating a new note with a click is friction less.

Auto tag notes created with wiki links
This seems very functional to the way you use tags and wiki links but feels unexpected. New notes created with a tag selected in the sidebar do report the tag, but the same wiki link can be clicked in different context (Notes, Trash, Archive, detached windows, …) and users might not see the selected tag in the sidebar.

Unlinked mentions
I can see obsidian have those but I wonder what they are used for, can you give your use case? Also, are they always meaningful? As far as I can see they are just text matches of the current note title, but if the title is something simple (e.g. “hello”) don’t you get a lot of unwanted/unuseful results?

Block references and transclusion
I don’t think these features will come to Bear. I understand and like it’s power but transclusion makes sense if the whole app is built around it and we want to stick to the “just text” idea. This unfortunately makes also very hard to make block references because we lack of identifiers for each paragraph in the text.

A graph of links
This too feels a little out of place for an app like Bear but luckly some third party developers managed the created those graph from Bear’s database.

7

From a standpoint of an user i can say that i would not expect that a note is created without my interaction. If i like to create a note from a wiki link i just click the link.

I am not sure why this has to be communicated. When writing a wiki link from completion panel why is it important to know if the note already was created?

I couldn’t see the real benefit of graph views. I thought it just fun to travel through the milky way of notes. In the meantime due to some tutorials in youtube i can see some serious usage. Maybe it is a good idea to collect the purposes people hope to achive with graph view and then to see if that couldn’t be achieved in a different way (f.e. a statistics window about notes and their links)

I am aware of the power of transclusion and blockreferences in roam research. But that is not what i want in the first degree. I would be happy to have a scrollable preview in a pop up when hovering the mouse over a wiki link. Ideally a click into that pop up could transform that pop up into a note window where you could continuing writing

1 Like
8

I might be wrong but In the scenario KillerWhale illustrated, I think you want to easily identify the note [[Character A could do something]] against similar titled notes (e.g. [[Character A could go somewhere]]).

9

I think you misunderstood him. Let me describe the scenario in my words:

I write several notes and it happens that in these notes i write often the same wiki link without creating it f.e. by clicking on the link. To avoid that writing of the same link name again and again it would be nice to have it in the completion panel. Actually there is no other reason for the name of uncreated notes to appear in completion list than for link names of already created notes.

I think KillerWhale wanted to say following: it can happen that without the appearance of the wiki link name in the completion panel you run the risk to write a wiki link name that is just similar to the one you meant because you are writing it from your memory. The unwanted result is then that you have two notes with similar names

1 Like
10

Hi @trix180 and thanks for your reply and for examining all these suggestions. Happy to know the quick opener is planned, thanks! For the other subjects, allow me to reply in sequence:

ncreated notes
I have some problem with the concept of uncreated note and way more with creating notes without an explicit user intention. The first creates a new note state (linked but not created) and this has to be communicated in the completion panel. I can’t think of a good way to achieve this without writing “Note not created” somewhere near the title (not a good solution). On the other hand creating notes while writing wiki links makes we wonder what should happen when a link is edited: Should Bear create another note with the fixed title, delete the previously created, so keep track of the created but not used notes somehow. Also, might be me but, triggering app actions while editing the text feels like possibly going against user expectations and intentions.

Which is why I do not think creating the note automatically is the best solution. I believe however that Bear should remember that an uncreated note with a title has been linked from somewhere, so as to offer that link in autocompletion to avoid duplicates (as @krssno points out).

If you forget to create manually a note that does not exist despite clearly identifying it in a wiki link, that link will completely be lost. You might create a note later with a slightly varying title, and the first link will be useless – even worse, you might stumble upon it later, remember you have a note on that subject, then click the link, creating the note, and think “hmm, guess I had created that note all right, but it’s empty”.

It’s a nightmare for managing knowledge.

What I suggest in that situation is

  • Have Bear remember wiki links that point to uncreated notes
  • Offer that link in autocomplete suggestions (and the potential quick opener), maybe with a paler color to show that it’s uncreated yet, or with a symbol

This is how Obsidian signals such links, for instance, in its quick opener

Capture d’écran 2022-05-31 à 20.13.27

But it could be even argued that signaling it is not even mandatory. It’s a link that exists, it can be autocompleted, the note may be created in its own time.

Auto tag notes created with wiki links
This seems very functional to the way you use tags and wiki links but feels unexpected. New notes created with a tag selected in the sidebar do report the tag, but the same wiki link can be clicked in different context (Notes, Trash, Archive, detached windows, …) and users might not see the selected tag in the sidebar.

This argument only holds if you do indeed create note automatically with wiki links, which is not the best solution, as argued just now. (Bear should rather remember those links and offer them unobtrusively.) On the other hand, if you are clicking on that link with a tag selected to create the note (current behavior), I am arguing the tag should be added to the newly created note, because it’s very much deliberate on the user.

However, this is not a major pain point. Not remembering uncreated note links is, much more.

Unlinked mentions
I can see obsidian have those but I wonder what they are used for, can you give your use case? Also, are they always meaningful? As far as I can see they are just text matches of the current note title, but if the title is something simple (e.g. “hello”) don’t you get a lot of unwanted/unuseful results?

It’s up to you to use meaningful note titles, of course.
This feature gives its full power when combined with aliases. There are countless examples where that can be helpful:

  • You start working on a notion, which is not heavily linked yet because you start working on it. Later, it’s helpful to see where it can be referenced. For instance: a character in a story; a historical figure; an event; a species…
  • This is incredibly powerful when mixed with aliasing. I could be a zoologist working on “orcas” also called “killer whales” and “Orcinus orca”. I could see any reference (including clipped content!) of those words in the “orca” note. I could be a historian, studying provinces that have changed names during time. I could be a linguist or a religious scholar, looking at the evolution of words, and working in several languages (think the transcription of Asian or ancient languages). I could be a doctor or chemist looking at “Aspirin” which is also “acetylsalycilic acid” and “ASA”. I could be an epidemiologist looking at “Covid”, “Covid-19”, “Coronavirus”, and so on.

So many concepts have different official denominations, and so many people work in different languages. There are literally hundreds of use cases, and you could cross-reference those against your clipped content for instance, as well as against other notes which may have been written at different times, when you did not think of expanding on those concepts. It’s a very straightforward concept that allows tremendous connections and serendipity.

As for graphs and transclusion, I was indeed not hoping for them, I perfectly understand these are not in the realm of simplicity Bear looks to live in, and I’m perfectly fine with that. Remember links with uncreated notes could be unobtrusive on the other hand, as well as aliasing.

Hope I made myself clearer :slightly_smiling_face:

11

In my eyes it is not necessary to signal the status of the uncreated note. I just want to have that wiki link in the autocomplete panel to avoid writing the name again and again. That actually is the origin idea of the completion panel

Yes and not, transclusion does not fit into bears approach if you regard them as what they mean in obsidian or especially in roam research where block references are an important part of the concept. When on the other hand i talk about transclusion and how useful they are, then i mean a more simple and less geeky usage that in my opinion fit into bear. Let me give two meaningful scenarios:

  1. I have a collection of recipes. Now i plan to add to each recipe a checklist for the ingredients to buy. I generally plan the meals for a whole week. I would like to add 7 Headers, each for a weekday. Under each heading i could the add a recipe note as transclusion. That results in ONE note that serves as shopping lis and also as recipe collection for the current week. I don’t have to switch between 7 different notes but have them collected in a single note

For sure: I am talking about short notes and not about blocks of a note. Adding a large note as transclusion doesn’t make sense.

  1. Here a more serious scenario: I have collection of shorter atomic notes, quotes and thoughts to special topics. When i write a larger text to that topic i fall back on that collection of notes. I would like to make a rough copy of that text by planning it. And i could plan it by not only transcluding the required notes but also organizing them in an outline created by headers. Under first heading i could collect definitions in regard to the topic, in a second chapter i could organize collected thoughts and so on. That ends in a first draft and guideline how to write the larger text. Opening a new window with that note with all the transcluded files and copy/pasting relevant parts of it into the larger text would be a great way to write texts.

I just want to say that apart from geeky roam research stuff transclusions could be an useful tool for normal writing and note taking. Actually i am speaking from a position of someone who regards bear as a tool for note taking AND writing larger texts. For the latter apart from TOC and typewriter mode (which are going to come in furure updates) i indeed highly desire what i described in scenario 2. It reminds a little bit of auraticum and citavi where the collected knwowledge in form of notes is structured in a way that helps you writing larger text

1 Like
12

Thanks for the clarifications.

Obsidian autocomplete UI solution is interesting. I think this is a little easier for the quick opener because, as the icon suggests, the note will be created and not just linked in the case of our autocomplete, but we can consider this for our opener.

2 Likes
13

Yup, I think that’s the best solution; it should be unobtrusive - which I think is important for Bear (and the simplicity we all like) - while being a major quality of life improvement. Hope this can be implemented at some point!

14

I would kill for a quick opener on all platforms, but especially on iOS. Consider looking to Drafts for inspiration — there, the pull-down gesture is overloaded virtually everywhere in the app to bring up quick search/quick open. This is extremely fast and productive and I sorely miss having this kind of functionality in Bear on my phone. (Ironically I sometimes find old notes in their ancestral form in Drafts before finding the current, refined version in Bear, just because Drafts quick search is so much faster and easier.)

Of note, a quick opener should also allow opening tags/views, not just notes.

2 Likes
15

Strong support also for autosuggest of notes implied by wiki links but which haven’t yet been created. This works well even if notes are not auto-created.

FWIW, the Roam approach to handling auto-created pages is relatively straightforward and handles the case @trix180 raised as a concern better than I would have expected before I used it heavily:

  • New pages are created automatically for all links
  • If you change the link that created that page, it just creates another new page
  • Any pages which were auto-created and are otherwise empty (no content and not linked from anywhere anymore) are automatically garbage collected periodically (I think after a day)

The key is that the auto-deletion only occurs in cases where it wouldn’t actually destroy any information. It’s only for empty pages which never had any content other than the implied backlinks which have since disappeared.

I don’t think it’s critical for Bear to try to adopt a model like this — just autocompletion for non-existent pages already covers the most critical issue, which is making it easy to use concept links consistently before a page has been explicitly created — but it’s worth knowing that model exists and works well in practice in a related setting (Roam).

3 Likes