Zettelkasten Forum


Sharing and working in group in a zettelkasten? (your opinions, your solutions)

Hello fellow Zettelnauts,
I'm starting working on a long art exhibition project with another researcher. We will operate as a collective of researcher/curators. At this point it make sense for me to have a system of sharing our work in a collective archive.
Have you ever try this?
I have try to work with someone with Obsidian on Dropbox, (mainly because the links to images in the archive is local, and we had to share images)
I have see that https://hackmd.io/ is proposing a solution with Github in markdown, so it could be integrate in the archive or obsidian…
Also, a point of concern for me, I have my own archive, and do not wish to create duplicate notes for the common archive. Is there an approach for this or even a solution?
Thanks a lot for your help

Comments

  • edited August 2022

    @KrsBee I work for an engineering company and have introduced the use of a ZK for several large projects requiring research, compilation, documentation and application of design principles and standards (sorry; a mouthful). Due to people using both Macs and Windows-based computers, our software of choice was Zettlr and the files were stored on a company file server to which everyone had access. Personally, I use The Archive and Dropbox - there is no reason that couldn't be used by a group of people if everyone was working on Macs. The fact that both the text and image files are on Dropbox makes them accessible to anyone in the group.

    Most of the people were not that familiar with ZK concepts, so I did some training (with exercises) to get them informed and up to speed. This included:

    • How to write a zettel (practise, practise, practise - it was like an English class for engineers).
    • How to do the next most important task - linking zettels - immediately and then over time.
    • The wise use of tags and structure notes (my opinion, of course, but then I was the senior advisor on the project).
    • Creation of references within Zettels (we used Zotero for our reference database).
    • A common format for zettels, including the use of accurate titles and the placement of metadata.
    • Strategic use of images - how to select them, and then how to include them in the ZK.

    It proved extremely helpful to find the brightest, keenest person and give them further training on maintenance of a ZK (with special tags to empower that process).

    In addition to all that, I held regular (at first weekly and then bi-weekly) meetings to review our progress and check consistency of the ZK efforts. This was very important as the end product ZK was going to be used extensively in writing a report and needed to be organized in a consistent manner. Zettel quality was a high priority.

    While a ZK is a rather "organic" creature when one person works on it, that multiplies exponentially the more people are working on it. It could get totally out of control if some consistency isn't imposed on the items listed above.

    We learned as we went along, fortunately quickly enough that the ZK took shape really well. The deliverable to our client was a report, with normal engineering plots, flow charts and event trees. However, we did not release the ZK to our client - our team considered that a proprietary creation that gave us strategic advantage on other similar projects on which we might compete and did not want to release it publicly. Not sure that is relevant to your application, but I thought I'd mention it.

    If you have any questions on the above, I'd be happy to respond further.

    Oh - just re-read your post. It is extremely easy to copy and paste individual zettel files from one ZK folder to another. So - copying some of your own zettels from your personal ZK folder to a separate folder containing the group/project ZK should be a cinch. If everyone follows the same set of rules regarding titles, naming of files, and generation of UUIDs, there shouldn't be a problem.

    Note for clarity on the above material: I use the abbreviation ZK for "Zettelkasten" and always spell out the word "zettle".

  • P.S. to the above - I didn't make it clear that I was working with a project team of 10 people, 6 of whom were doing the research work and actively writing zettels. One extra person was keeping an eye on what was entered and "maintaining" the ZK (checking for consistency in format, rationalizing tags, spot checking zettel quality, etc.).

  • Thank you @GeoEng51 for this sharing. I will continue to experiment with Obsidian and see how it work with github for the cloud.
    I like best The Archive, but the way it implement the images in the file is not efficient for collective sharing of notes.
    My burden is that my notes use links with the UID only, and those are not directly recognize by Obsidian…

  • Yes, @ctietze and me tried to use our ZKs for cooperative book writing. It failed back then (8-10 years ago).

    I never developed my ideas on how to make this work since there was never a need to.

    My main line of thought is to imagine the shared ZK as the main text which anybody can edit. The personal notes are commentary which can just be edited by the individual note owner. That would allow for separating the private notes while also creating a shared text body that can be accessed by everybody.

    But I don't think that the burden of dublicating and doing some work by hand instead of automating is so much of a burden that it would slow down the whole project too much.

    I am a Zettler

  • @KrsBee, a few thoughts come to mind that may be relevant:

    1. Online collaborative editing of a knowledge base is the purpose for which wikis were invented in the 1990s.
    2. GitHub, which you mentioned, is now popular for collaborative work, mostly related to software development: e.g., Yu Wu, Na Wang, Jessica Kropczynski, & John M. Carroll (2017). "The appropriation of GitHub for curation". PeerJ Computer Science, 3, e134.
    3. Combine (1) and (2) above, and you get: GitHub wikis, which can be either edited through the browser like any other wiki or cloned to your local computer like any other git repository and managed using git and, since you can use Markdown as the format for text, should be editable as an Obsidian vault (I haven't tested this: see, e.g., a discussion about Obsidian and GitHub wiki).

    However, depending on your requirements, some other kind of software may be more suitable for your purposes, especially if you are working with many digital assets related to the exhibition. There are many different content management systems and digital asset management systems. If you are not a professional exhibit developer or don't have one on your team, you may want to consult one about this issue to learn what is most popular in the field.

  • A quick comment on wiki's - a wiki is just an app that allows multiple people to make and revise text entries, with a clear linking system - in other words, it's software that is eminently suited to creating a ZK. There has been discussion on using several different wiki apps for just such a purpose on this forum in the past.

    My point is that a "wiki" is not a different beast - you should make a distinction between the different types of software floating around (including wikis) and the concept of a ZK, which can be implemented with a variety of software and paperware solutions.

  • Thank you @Andy. I will try to work with github. I've seen that it allows to connect multiple repositories. I imagine each participant can have is own ZK in a separate repository and a shared ZK for the collective work. I will experiment with the wiki and my idea and see how it could work.

  • @GeoEng51 said:

    you should make a distinction between the different types of software floating around (including wikis) and the concept of a ZK, which can be implemented with a variety of software and paperware solutions.

    I think you meant that one should make a distinction between "the" Zettelkasten method, as it is defined on zettelkasten.de, and the ways the method can be implemented. But one should also make a distinction between that method and a Zettelkasten, which just means a "slip box". Any application of that term to software is metaphorical.

    Wikipedia defines a wiki as a kind of web app, and that's the definition I meant in my point 1 above, where I linked to the Wikipedia definition. The interesting thing about my point 3 above is that it combines the strengths of a wiki (as a kind of web app) with distributed version control of local files that can be created and edited with a variety of apps. I should have mentioned that GitHub is not the only company that offers this: for example, its competitor GitLab has equivalent functionality, and there are other git-based wikis, although many of them would require setting up your own git server, which would probably be too much technical complexity for a researcher/curator without sysadmin experience—better just use a service such as GitHub if a git-based wiki is the right solution.

  • edited September 2022

    @GeoEng51 said:
    A quick comment on wiki's - a wiki is just an app that allows multiple people to make and revise text entries, with a clear linking system - in other words, it's software that is eminently suited to creating a ZK.

    I disagree. A wiki can be made to work, but its suitability is awkward. Wikis tend to run out of gas for this reason: out of sight, out of mind. My own wikis have been eminent failures. I'm picking up pieces from my last wiki to import into Zettlr. Having grown up in a family of artists, a wiki could be a recipe for disaster in an art project.

    Why bother with more specialized Zettelkasten software if wikis were so well suited to the task? If I were to switch from Zettlr to a wiki, I would lose pandoc integration, which includes pandoc citations, I would lose the ability to import Zotero citation databases; I could forget about LaTeX integration, ID generation, the file listing that includes IDs and titles, and the related files pane, which in a wiki I would need to access by clicking "what links here" instead of having it available on the right-hand side of the screen.

    As I yammered in my pompous inaugural Zettelkasten.de introductory post:

    Over the years I've tried to organize and improve my note-taking, writing, drawing and research with index cards, blogs, Kanban boards, journals, mind maps, structured procrastination, spaced-repetition algorithms for long-term memory, dual-N-back for short-term memory, bookmarking sites like delicio.us and pinboard.in, flash cards, incremental reading in SuperMemo, Microsoft One Note, Scrivener, Markup, Markdown, YAML, emails to myself, wikis and straw grasping.
    Of these, wikis seem to have been the most effective, until they too ran out of gas. Still, the siren song of brain prosthetics, ringing like the tinnitus in my ears, has somehow led me to the Zettelkasten Method.

    The last thing that an art project needs is argument among programmers.

    GitHub. Erdős #2. CC BY-SA 4.0. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Armchair theorists unite, you have nothing to lose but your meetings! --Phil Edwards

  • Good points by @ZettelDistraction! One thing I said that's compatible with his warnings is: "depending on your requirements, some other kind of software may be more suitable for your purposes". It seems advisable to make your exhibit development plan and software requirements checklist first and see what checks the most boxes, while consulting with an expert in your domain if possible. The original post says that the output is an exhibition project, and the rest of us are in the dark about exactly what that entails: an outline? a database of objects? exhibit labels? graphic layouts? an interpretive brochure? a book? all of the above? It's hard to give precise advice when this details aren't clear.

  • @Andy @ZettelDistraction Good points; I agree. I didn't mean to say that a wiki is the perfect app for creating a ZK, but many have used it for such and discussed it in this forum. I had a look at a couple of wiki apps when I first got started on the ZK method and discarded them for the reasons you stated. I've used The Archive (for a personal ZK) and Zettlr for a work/project ZK, and both are well suited to my engineering and personal needs.

    My only intent in an earlier post was to make a distinction between the software one uses to create a ZK and the ZK itself (and I meant the ZK "product", not the method). The product does not have to be limited to pieces of paper in a slip box; it can also be a collection of electronic notes, accessed and maintained using your favourite software app. In a perfect world, I guess a ZK would be software-independent and even medium-independent, but of course that is rarely the case. So each of us searches for software and/or media that best suit our purposes, our systems and our way of thinking.

    @KrsBee I want to reiterate the importance of keeping your personal ZK independent of any collaborative or project ZKs. This is a simple matter, because you can copy and paste zettels from one ZK into another with ease (if you are working in an electronic ZK). This is a matter of personal style, I guess, because I only have one personal ZK and it contains whatever I believe should go into it. So creating a separate work/project ZK is simply a matter of style - for me, mostly because I don't want other people mucking around in "my" ZK :smile:

  • Thank you for your ideas and comments. I have just try to use HackMd.io because it presents as a collaborative note taking tool. It can link files together but the interface doesn't work for me, because each page as to be open in a new tab and it's painful as I have already lots of tab open… We decide to use Figma FigJams to brainstorm, it is more organic and fun, and give us some time to find the right way to share our notes on this particular project. I believe that each note taking and thinking/memory work approaches are very intimate, and that collaboration take time to manage a safe space to think together.

Sign In or Register to comment.