Obsidian has released a Webclipper for a variety of browsers. Making it easy to get stuff into your notes from your browser is a key thing to make as frictionless as possible. So this is a laudable step.

I’ve been using the Markdownload webclipper for 4 years.

Both allow you to precisely template what gets saved and in which way when you save a page or a selection on a page. That way I can ensure it ends up in my Obsidian notes tool in a shape that is immediately useful inside that environment.

A key difference is that Markdownload saves to the file system, it simply puts a text file with an .md file extension in a folder I designated, and that is the same folder Obsidian looks for my notes. It can also save through Obsidian though. It’s independent and useful regardless of Obsidian, because of it.

The Obsidian webclipper saves through Obsidian, I suspect so you can leverage whatever you have set up in Obsidian for incoming material. It brings Obsidian to the front and does the saving, and if you want opens the note to continue there. In my case it meant the default template for new notes got applied by the templater plugin, overwriting the material I tried to save. The settings of the Obsidian webclipper does not have the option to save to a folder, bypassing Obsidian.
This to me introduces an unneeded dependency (and the need to figure out suppressing my default template inside Obsidian so it doesn’t overwrite incoming webclippings). To me the fact that Obsidian is a viewer on top of regular text notes on my hard drive is valuable because I can use the files and manipulate them in other tools. I daily read and write those notes outside of Obsidian. It seems many others don’t realise this fully as there is the strong tendency to want and expect Obsidian to do everything (even though the dev team handily shifted that urge to the developers of plugins).

I will stick with the Markdownload webclipper for now.

During the September Dutch PKM Obsidian meet-up the topic of discussion was journaling. An interesting thing that stood out was how a participant demonstrated their use of named block references in Obsidian.

In Obsidian any phrase surrounded by double brackets is a link to another note. Adding an circumflex (accent circonflexe, ^) behind such a link allows you to reference a specific paragraph inside a note. On occasion I’ve used those, though not often.
If you add the circumflex and select a paragraph, Obsidian will add a random alphanumeric code behind the selected paragraph in the original note, and to the end of your link. Removing or altering either will break the link.

What I hadn’t seen before was that you can add your own block references. At the meet-up someone did that using templates so he new the block references in specific types of notes, and could always refer to them elsewhere, in this case establishing links between day notes and week notes in a predictable manner. These block references can then be human readable, and re-used (as long they’re unique within a single note).

In the past days I found myself using them to references reading / literature notes from my own notes. Especially I noticed that I use the block reference to point to the part inside a paragraph I’m mostly referring to.

Below is an example from this week.
First a reference link in one of my notes, with the block reference ‘sortboxes’. Then the original annotation. The reference ‘sortboxes’ points exactly to my words in the annotation I am referencing.

It’s interesting that after learning this possibility a month ago, I now see myself doing that in a different manner than I saw it, yet as emergent behaviour, as a new earned structure. A useful thing perhaps to also adopt in Latticework, as during sensemaking it is common that new thoughts or associations latch on to steadily shorter phrases or even single words of annotated material rather than full paragraphs, as you progress in thinking things through.

I am trying out the Books Search plugin for Obsidian. I keep notes on all books I’ve read, own or have come across. I add meta data to those notes manually. The Books Search plugin helps make that easier by picking up that meta data from Google Books through their API. You install the plugin through the Community Plugin list, and can then add an API key. Without that key, after a few tries you will get an error message.

The plugin documentation does however not state how to connect the plugin to that Google API.

These are the steps I took after a bit of searching:

  • In the Google cloud console first create a project. (A Google account is needed)
  • In the same console, under credentials, click create credentials and create an API key. Copy that key and save it in the settings of the Obsidian Books Search plugin.
  • In the same console, under Enable APIs & Services, enable the Google Books API.
  • Go back to Credentials, edit your API key, select Restrict Key under API restrictions, and select from drop down list the Google Books API you’ve just enabled. (If it doesn’t show any APIs to choose, you have not enabled any APIs yet.) Now the key works only for the Google Books API.
  • Ignore the warning in the console about OAuth consent, as this is not needed (the books API is accessible without authorisation, and you’re also not building an app for others to use.)

Using the Book Search plugin I notice it is by default restricted to English books, not finding titles in other languages that Google Books does have in its lists. The locale settings in the plugin allow me to switch language before a search in the search form through a very long drop down menu, but doing that (or doing the same search for each of three or four languages) quickly negates the effectivity gain the plugin provides.

It is unclear from the Google API documentation if locale can be set to multiple languages.

Probably not, given Google’s long history of interpreting multilingual as serial monolingual (see this 2007 presentation at Google by Stephanie Booth pointing this same stuff out), ignoring that multilingual people tend to change languages throughout their activities even for just a single word or short phrase. (I don’t have Dutch, English or German days or topics, in the case of books I may want to find the German original of an English translation, or want to search for a specific thing in French because I know it exists, while also interested in any Dutch translation that might be available or the Italian original. My notes are always in multiple languages.)

Working on a visual representation of the European data strategy landscape, integrated as well as alongside a textual representation this morning. It makes for a pleasant experience. The experience comes from what Zsolt Viczián’s Excalidraw plugin for Obsidian allows me to do, something I mentioned here earlier after the PKM Summit last March where Zsolt showed this.

Excalidraw drawings are basically text files describing the drawing, which are then rendered in the viewer. What the plugin supports is putting other text elements outside the drawing elements, and exclude them from the visual view. This creates two representations of the same file: one the drawing presented visually, one the text content outside the visual. Zsolt calls it the ‘flip side’ of a drawing, being a note accompanying the drawing. I see it more like two different views on the same thing. I have a hotkey (cmd arrow down) enabled to flip a note between both views.

Putting both views next to each other, and working in both at the same time, allows me a seamless mode of working, switching between visual material and text writing. As shown in the screenshot below.

Here you see the same note twice, opened in two tabs. The left side is the textual representation. It also contains an embedded auto-generated image from the visual representation but that is something I choose to do. Underneath that image you see some notes I wrote.
The right hand side shows the visual representation, a drawing of how I perceive the context of the European single market for data (at least, part of it).
I use the visual side as a Systems Convening landscape, to think about barriers, possible interventions, visibility etc. I use the text side to turn those thoughts into notes, potential actions, and links to other relevant material, or to write down things I think might be added to the visual.

Over the years my main problem with working more visually has been the lack of fluidity between the visual and the textual. Basically rendering them into two separate silos. Few tools solve that issue (Tinderbox is one). This means I usually favor the textual side of things. Where I use images, they are ‘frozen’ moments of the ever evolving textual side. The set-up this morning is not silo’d and here the creation of visual elements aids the text creation and vice versa, while I work on both in parallel in a single note. Both text and visual evolve together. Very nice.

Gisteravond was de 6e meet-up van Nederlandstalige Obsidian gebruikers. Net als de editie van afgelopen december vond deze meet-up plaats onder de vlag van de Digitale Fitheid community en de KNVI (Koninklijke Nederlandse Vereniging van Informatieprofessionals).
De vorige keer was ik een van de facilitators, dit keer was de begeleiding in handen van Martijn Aslander en Lykle de Vries. Dat gaf mij gelegenheid meer inhoudelijk mee te doen, en dat was prettig.

Het recept was hetzelfde als wat Marieke van Vliet en ik de vorige keer improviseerden: aanwezigen droegen aan het begin een onderwerp aan, en vervolgens mocht iemand telkens iets kiezen uit de lijst (maar niet het eigen onderwerp). Zo komt een divers lijstje onderwerpen tot stand, en zorg je ervoor dat een bredere groep aan het woord komt.

Iemand vroeg of je Obsidian ook op een USB stick kunt draaien. Dat je je vault op een stick hebt, en dan op systemen waar Obsidian staat die kunt openen inclusief alle plugins etc. Ik stelde voor dat ter plekke te proberen, en het antwoord lijkt ja te zijn. Deed me denken aan de wiki-on-a-stick experimenten die ik lang geleden deed rondom het ‘patchwork portal‘, waarbij wiki’s met een lokale kleine webserver op een stick werden uitgedeeld waar anno 2005 nog geen of heel weinig internet verbinding was.

Ik was zelf benieuwd of mensen n.a.v. de PKM Summit in maart meer zijn gaan doen met de visuele technieken die Zsolt Viczián met zijn Excalidraw plugin toen liet zien. Met name was ik geïnteresseerd in of mensen bestanden tegelijkertijd als tekst en als visueel element gebruiken (hier uitgelegd door Nicole van der Hoeven). Twee deelnemers lieten het e.e.a. zien. Zelf heb ik een sneltoets voor het schakelen tussen tekst en visueel ingesteld, maar dat zag ik hen niet doen. Dat zegt me dat ze die switch weinig maken. Ik zal er zelf eens iets over schrijven in meer detail, met twee recente voorbeelden hoe dat waardevol voor me was en heel prettig en wrijvingsloos voelde.

Maarten den Braber was een van de aanwezigen die liet zien hoe hij bepaalde zaken in zijn workflow automatiseert, vanuit hetzelfde principe dat ik hanteer: geen dingen doen die uniek zijn voor Obsidian, je moet altijd ook met je platte tekst bestanden uit de voeten kunnen. Hij liet de PDF++ plugin zien, en die moet ik zeker eens onderzoeken en vergelijken met hoe ik momenteel Zotero gebruik.

Muhammed Kilic liet zien hoe hij over meerdere apps heen dezelfde tags, links en indexes gebruikt. Hij noemde daarbij hoe ik dat ook doe in mijn hypothes.is annotaties (links naar bestaande notes, taken, tags opnemen waardoor het in Obsidian meteen in context staat), maar liet zien dat hij dat ook in Zotero doet. Dat doe ik niet in mijn annotaties daar, en toen hij het liet zien vroeg ik me af waarom eigenlijk. Ik link wel vanuit Obsidian naar Zotero, maar in mijn annotaties verweef ik in Zotero mijn notes en tags veel minder. Eens over nadenken, en uitproberen.

Tot slot merkte ik dat het in een groepsgesprek als dit lastig is om min of meer standaard ook te laten zien wat je beschrijft. Je moet je dan maar voorstellen wat iemand daadwerkelijk doet, ipv het te zien. Voelen we ons kwetsbaar in het tonen van onze tools en werkwijzen? Het aantal malen dat ‘tell’ ook met ‘show’ werd ondersteund was daardoor beperkt, en dat is jammer vind ik. Voor een volgende keer zou het ook leuk zijn om in plaats van over aspecten te praten eens iets van ieders gehele implementatie te zien, en daar vragen over te stellen.

Bookmarked Why te database version and how it’s going (by Tienson Qin)

Long time blog buddy Jörg Kantel, aka der Schockwellenreiter, points to the discussion above, on how Logseq is moving away from running on top of you file system towards a database tool. I understand how that may help solve the issues they indicate w.r.t. collaboration and synchronisation, but like Jörg I don’t like it when my stuff is locked away in some database structure I don’t have ready acces to from inside other apps and scripts. It’s why e.g. Joplin is out of bounds for me. For Jörg it’s even more key I think, as he seems to be blogging directly from his markdown files. (I write my blogposts in markdown in Obsidian, but have a micropub script to push it one time / one-way to my website.)

There’s an intriguing remark further down that page that they will maintain both the markdown files and add a database on top, to provide other tools access. I wonder how that will work in practice, and how it impacts the things they intend to solve with the database. I use the closed source Obsidian, and it too has some data stored outside the files that keeps track of graphs etc., and I wonder if this is what they mean or not.

Jörg is looking at Foam as a result. When I started using Obsidian a few months after its launch in March 2020, Foam was more like an idea on top of VS Code editor than an application. I could be tempted to look at Foam again, but using VS Code as its base is something that doesn’t appeal to me.

We’ll continue to support both file-based and database-based graphs, with a long-term goal of achieving seamless two-way sync between the database and markdown files. This will allow you to leverage the benefits of the database version while still being able to use other tools

Tienson Qin