15th June 2026

New content types for research

I've been lucky enough to have some time over the last few months to make a lot more progress with Open Research Notebook version 2.

One area I've been focusing on is the basic text editing experience, and supporting the kinds of content which are particularly useful for research.

The editor now supports:

• code blocks with full syntax highlighting and autocompletion for many programming languages;
• table creation and editing; and
• mathematical notation

Under the hood, all text is still saved in the Markdown format. So the features I've added are those supported by the Markdown format, in particular the GitHub flavour of Markdown, which has some useful non-standard features. Some of these features can be quite fussy to work with in raw Markdown format, for example table creation. With that in mind, I have used a text editor which is flexible enough to embed dynamic components, such as a table widget with drag handles for creating new rows and columns. These dynamic widgets make editing and viewing data easier and more intuitive, even though the ultimate output is still the same – plain text.

As the video below shows, a popup menu allows you to insert tables, codeblocks, and so on: but there are also typing shortcuts which will achieve the same thing. For example, typing $$ at the start of a new line, followed by the enter key, will automatically insert a LaTeX mathematical notation block, opened in editing mode.

Improved revisions mode

I've also updated the revisions mode, so that the 'diff' view, which shows the changes between revision snapshots, is more sophisticated: it shows line numbers and highlights lines removed, added or edited, with colour coding.

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

20th April 2026

Revising the Revisions

Working on the basic text editing functionality in Orsn, I found that before I could work on text block features (tables, etc.) I had to update something more fundamental: the Revisions system for keeping track of changes to Cards and Pages.

Part of the philosophy of Orsn as a tool for documenting research is to allow the writer to 'share their workings' if they so desire, in the spirit of open scholarship and transparency; viewing the history and evolution of a document might allow readers to make a more informed judgement of the researcher's process and assumptions.
Of course there is no requirement in Orsn to publish work or share revision drafts, and having access to revision snapshots is also extremely practical for writing of any kind – it allows for freedom in exploring one path in depth, knowing that it is always possible to retrace one's steps if one arrives at a dead end. Sometimes it's necessary to go back and take a different fork in the road.
This is a wonderful feature of branching in git. I have often thought about how this workflow might be translated into non-programming scenarios. That was a fundamental reason why I chose to use Markdown as the text format for Orsn. Plain text allows for this kind of tracking.

Version control and publishing

My conception for Revisions in Orsn is closely tied to git. While Orsn stores its data in a database, rather than flat text files, it will be possible to serialise its data (export them) to a series of Markdown files which will be exportable as a git repository. Conversely, it will also be possible to import Projects from git repos and deserialise them (import them) for viewing and further editing.
In this scenario, the Revisions in Orsn function as git commits, or snapshots, so that key changes can be documented, but without the learning curve and the tooling required for working with git. When a Project is exported and published as a git repository, it becomes available in that format for anyone familiar with version control and its more sophisticated options; and it can become a site for collaboration, if that's useful.

So, in short, every Revision in Orsn becomes a git commit in the exported git repository. (For the moment there is no equivalent of branches in Orsn. This may arrive at some point in future. We walk, or at least toddle, before we can run.)

Out with the old

In Orsn v1, the revision system stored changes as a series of patches: that is, it only stored the parts of a text document which had changed since last time. That is a space-spacing approach, but it introduces a long chain of dependencies.
Picture this: a document is revised 5 times. The original document is stored in full, along with the text changes made in each subsequent revision. To view the document at, say, revision 4, we have to load the original document, apply the patch changes of revision 1, then to the resultant updated document, apply the patch changes of revision 2. And so on. Until we get to the desired revision, number 4.

You can imagine that in a long chain of revisions, this introduces a lot of vulnerability to errors. If there is an issue in applying just one of the patches, the rest in the chain will fail, and it won't be possible to construct the document.

In the new v2 revision system, I have accepted the compromise of slightly greater storage requirements in exchange for greater reliability (plain text doesn't use up too much space, so this is reasonable). In the new system, a full snapshot of a given change is captured, making its restoration much more robust. It's still possible to calculate and show the differences between a revision and its predecessor, and I have included that option. With the new snapshots, changes to title and tags are also captured, and we have flexibility to track other properties if they are introduced. This new setup feels much more solid and dependable than the 'cumulative patch' system of Orsn v1.

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

13th April 2026

The Big Clean Up

I had a chance to return to Orsn last week. It's been a while, so I did a Big Clean Up, sorting all methods and import statements alphabetically, and labelling my Vue component sections consistently. Although I've been using IntelliJ for some years I haven't used the Bookmarks feature in the past. It's very useful, in conjunction with the minimap feature ('CodeGlance Pro' plugin), which gives a graphical overview of a given file, and includes text links to bookmarked lines.

This was also a good opportunity, as I was refamiliarising myself with some of the code, to document tricky features where the workings were not immediately obvious, in particular component structures. Bringing a fresh eye also prompted some refactoring of variable and function names for clarity. As a consequence I was able to fix some issues with my implementation of ProseMirror inline menus.

My aim is to include jsdoc documentation in the code base for important functionality, but for my own reference I've also been creating separate descriptive Markdown files where I visualise the component structures of key pages, and detail where the responsibilities for data flow and updates lie. This is the kind of thing certain efficient programmers do at the start of their development cycle. Doing it retrospectively will have to suffice in this case. For me it is now essential as the codebase is large and there is a tendency to solve problems and move on, so the detail of implementation can become muddied without careful write-ups.

I started out hoping to use Mermaid for creating Markdown visualisations, but it turns out that creating simple wireframe diagrams with blocks and nested blocks, is not yet one of its strengths. After wrestling with some buggy rendering of simple panel layouts, I gave up on it and looked for alternatives. I was pleased to find an IntelliJ plugin which opens the drawio editor within the IDE, so I was able to draw and edit my simple diagrams directly as SVG files, and embed them in my MD documentation.

I'm still thinking about supporting Mermaid diagrams in Orsn, however: it does seem effective for other use cases.

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

Orsn version 2 – development diary

12th November 2025

Markdown editor updates

A preview of some of the new text editing features in Orsn v2.
The new default editor is now a WYSIWYG text editor with various keyboard-driven menu options.
Under the hood the editor creates plain text markdown, but it's easy to use if you're not familiar with the markdown format. It's even possible to enter markdown syntax directly into the WYSIWYG editor: elements like headings and checkboxes are rendered automatically.

There is also a markdown mode, with optional splitscreen preview, for editing in markdown format directly.

Still a work in progress and lots more to come!!

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

11th July 2025

Moving. Forwards. Slowly.

As a result of my focusing on work which I actually get paid to do, Orsn development has been slower in recent months: nevertheless it has been edging forwards.

I've been working on inline toolbars and menus in the ProseMirror text editor, which I'm integrating into version 2 of Orsn. I started with a 'mentions' inline menu for creating previewable links to other content in the app. It's triggered by the '@' key:

I then moved on to menus for text formatting and inserting other kinds of content.

Creating inline toolbars and menus for the ProseMirror text editor has been time-consuming, and somewhat complicated, mainly because of the need to integrate ProseMirror into the Javascript Vue framework which I'm using to build Orsn. ProseMirror is designed to interact with the browser's document object model (DOM) directly, adding and removing interface elements as required. Vue, on the other hand, allows for a certain level of abstraction which make it easier to update sections of page content dynamically, keeping visualised content in sync with stored data models. When making popup menu elements for the ProseMirror text editor in Orsn, I had to learn and make sense of the PM way of doing things, and find a way to reconcile that with the Vue way of doing things — hopefully in a way which results in the best of both worlds.

As usual, getting into the details of using these menu features raised questions about usability and best user experience. Much of the time I devoted to this phase of development was spent on implementing the triggering and manipulation of menus using keyboard shortcuts, as I try to support a keyboard-centric workflow for speed and convenience.

A significant question for a web app is whether to offer right-mouse contextual menus. This was not traditionally approved of but is becoming increasingly common in web apps (as opposed to web sites). Orsn will be usable as a desktop app as well as a web resource, which makes the question a vexed one. For now, I have avoided contextual mouse menus and gone for key-triggered contextual menus instead:

• @ key opens 'mentions' menu for linking to other internal resources such as cards, pages, people
• Forward slash key opens main actions menu
• Hash key opens actions menu with header options only
• Selecting any text by mouse or keyboard opens a formatting toolbar

Some wheels had to be reinvented with this approach. For example, if the cursor in the text editor is on the right hand of the screen, the actions menu has to display its dropdowns in a right-to-left direction rather than a left-to-right one, and the left and right arrow key actions need to be swapped, when moving between menu items:

Such details emerge just when you think you're about done. It's true that when making something, the last 20% takes 80% of the development time. More or less. In the end, the functionality is taken for granted by the user, when they have seen similar features in other apps, and they perhaps only notice it when it doesn't work, or is unintuitive. But that's OK. As a developer I still get a kick out of making these things work.

Now that Orsn v2 has the infrastructure in place for text editor menus, additional menu options and menu functionality can be added as required. So it's time to make progress with other features.

Slowly.

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

18th April 2025

Typescript makes you think

Typescript is 'JavaScript with syntax for types. TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.'

I definitely have an ambivalent relationship with Typescript, but I am quite clear on the benefits it brings to my development process.

The ambivalence comes with the desire to be, sometimes, spontaneous, creative in the moment, to extemporise and to follow inspiration wherever it might lead. Or just to be lazy. Typescript to some extent limits those tendencies, in that everything acquires an additional step, either because of the need to define types, or more often, to work around type definitions which have previously been created. It forces the programmer to confront structural questions.
Also, when using Typescript, code loses its clean lines. It becomes more verbose. Keyboard characters jostle for meaning, depending on where they are applied. Abstractions are rife. At times, the whole thing becomes arcane, obscuring the logic of the code, which might previously have been discernable in the code structure, in its sentences, phrases and syllogisms.

However, it is inevitable in a complex app that even after any improvisory moment, a process of careful structuring and organising will be required. The virtue of Typescript is that it forces you to develop a more formal structure and stick to it. It forces you to do 'slow thinking'. Sometimes that feels onerous. But that careful building of structure is, like it or not, what programming really is.

What is normal?

Web applications are often complicated because they have multiple possible points of interaction. A value can be updated in a sidebar, a content panel or a pop-up box. There are numerous points of entry, unlike a game which runs a single process at 30 frames per second in a loop. So it is vital to have a single source of truth and to apply updates consistently, so that the most recent change is universally applied. That means (for me at least) having a centralised 'store' of data values in the application.

I was finding, in spite of adopting this architecture, that in Orsn, my handling of data was leading to inconsistencies and some errors. It turned out that this was because my data store was not really acting as a single 'source of truth'. Why not?

Data normalisation should be a familiar set of principles, even by intuition, to anyone who has worked with relational databases. They are principles which are designed to reduce redundancy and ensure data integrity. They prevent the same data from being saved in more than one place, which can lead to complexity, inconsistencies and errors. While observing such principles carefully in my database (on the server), I was not applying them consistently in my data store (on the user computer–usually called the 'client' but who's to say what this relationship is?).

To take a simple example:

In the database we have a table to store Cards, and a table to store Tags. Card have Tags. Multiple Tags in some cases. Tags belong to Cards. Multiple Cards in some cases. So it's a 'many to many' relationship. In such a scenario we need a third database table to store the relationship between Cards and Tags. But we don't save the whole Tag or Card (name, author, timestamp, etc.) to the third table: instead we store references to entries in the other tables. 'Tag number 1 is related to Card number 3.' etc.

Meanwhile, back at the app, we want to load up some Cards and their Tags. So we download the cards and tags from the database and put them in our data store. Thing is, it's quite easy to download 'whole' cards and their 'whole' tags as a single structured object from the database, and this is a convenient data model to use in the store. This way, every time I fetch a card from the store, I also have access to its tags, with all the tags' properties. That's fine... until I need to have a page in my app for managing all tags. In that case it makes sense to have a dedicated place in the store just for tags, which again I download from the database. Now we are in a bad position because 'complete' tags are stored in two places in my store, and if I update them in one place, I need to remember to update them in the other place too.

This unnormalised store structure is to some extent encouraged by the affordances of some code libraries for querying databases (I use objection.js for Orsn), as they allow for the easy downloading, in a single operation, of data objects and all their related objects as a single entity, even though they may be stored in different database tables. In some contexts, a store structure like this, with duplicate entries, might be manageable, but as complexity increases, so does the potential for errors.

Typescript to the rescue

Typescript is not really the saviour here, but when I adopted a more stringently normalised model for my data store, I was able to use Typescript to clarify the nature of that model and enforce its use throughout the development process.

The fact that Typescript is a superset of javascript, and a structural typing system as opposed to a nominal one, gives it flexibility suited for this use case. Instead of creating a completely new set of normalised data models to use in my store, I was able to selectively adapt the shape of the existing 'full' models, to be normalised ones:

export class Card implements SearchableModel {

  static readonly fieldsToSearch = ['title', 'blocks.body'];

  id: string;
  title: string;
  blocks: Pick<Block, 'id'>[];
  tags: Pick<Tag, 'id'>[];
  projects: Pick<Project, 'id'>[];
  stacks: Pick<Stack, 'id'>[];
  cardsStacks?: CardStacksProperty[];
  isHighlighted?: boolean;
  isNew?: boolean;
  extensionInstances?: Pick<ExtensionInstance, 'id'>[];
  createdById: string;
  createdTime: string;
  formattedCreatedTime?: string;
  modifiedTime: string;
  modifiedById: string;
  accessedTime: string;
  fieldsToSearch: string[];

  constructor(
    title = date.getNowFormattedForCardTitle(),
    tags: Tag[] = [],
    projects: Project[] = [],
    stacks: Stack[] = [],
    blocks: Block[] = [],
    cardsStacks: CardStacksProperty[] = [],
    createdById = '',
    createdTime = '',
    modifiedTime = '',
    modifiedById = '',
    accessedTime = ''
  ) {
    this.title = title;
    this.tags = tags.map((tag) => ({ id: tag.id }));
    this.projects = projects.map((project) => ({ id: project.id }));
    this.stacks = stacks;
    this.cardsStacks = cardsStacks;
    this.blocks = blocks.map((block) => ({ id: block.id }));
    this.createdById = createdById;
    this.createdTime = createdTime;
    this.modifiedTime = modifiedTime;
    this.modifiedById = modifiedById;
    this.accessedTime = accessedTime;
    this.fieldsToSearch = Card.fieldsToSearch;
  }
}

Instead of having an array of full Tag objects in its tags property, each Card now only stores the id value of its Tags, in a direct reflection of the normalised server database structure. This is achieved using the Typescript Pick feature, which allows for declaration of a partial type based on one previously declared. A nominal type system might have required the declaration of entirely new classes.
This means that when the app retrieves Cards from the cards store, it now has to get the related Tags from the tags store too. But this additional step can be incorporated into the Cards getter method in the cards store, so it doesn't lead to additional complexity in everyday use. With this approach data integrity in the store is much improved, and in this example, in spite of my previous complaints about its readability, the use of Typescript in the class definition is helpfully explanatory of how the data is structured.

Contact

Find me on the fediverse (Mastodon) @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

20th March 2025

Truncating a Tab, and other short stories

So you decide how your interface is going to look, and you have a good idea about how to implement it. Then you get into the detail...

It's when you start using a feature yourself that you realise that the detail of the implementation is vital to usability, and to a good working relationship with the software.

A Tabbed Interface

In a main view in my new design, I have a tabbed interface for managing content (see main pane of image below). That's pretty straightforward to implement.

Image: Screenshot of Orsn 2 software prototype

With tabs, a tab can be as wide as the text it contains. In that case you will end up with some very wide tabs and you will be doing a lot of horizontal scrolling to be able to browse through content. So if the overall width of the tabs is wider than the browser window, it makes sense to truncate the text in the tabs, so that you can fit more into the view.

This is where it gets a bit tricky.

My Orsn tabs are not a fixed width, like those in Chrome – they are only as wide as the text in them. And do you know what, I like it like that, so I'm not going to change them to be fixed width. That means that some are narrow, some are wide, and it's not ideal to truncate every tab by the same amount. You only need to truncate the long ones when that is necessary: and when doing that, you have to take into account the extra width afforded you by narrow tabs. Otherwise, you truncate too much and your tabs don't fill all the available width of the browser, which adversely affects legibility of tab titles.

To cut a long story short, here is the logic I (eventually) arrived at for a satisfactory tab truncation process:

4th March 2025

An Idea in Motion

I am making steady progress with Orsn v2.

Non-Technical

With v2 I have redesigned, to varying degrees, the paradigm, the interface and the database structure.

Now we have a simplified paradigm of Cards and Pages. Pages take over from Contexts in v1. They're extensions (plugins) and can provide custom visualisations and interactions. As part of the v2 rewrite, there will be fewer of these at first, with more attention paid to proper execution – v1 was more of a proof of concept. I will also provide templates for those who want to create their own.

A Project has three modes: Edit, Design and Publish. Edit is for creating content. Design is for arranging Pages, and Publish is for the presentation of the selected Pages. For the moment I am focusing solely on Edit mode.

Edit mode: a simple prototype page, with temporary content and design, showing sidebar and tabbed contents

The interface is already cleaner. In edit mode there is now only one main sidebar, instead of two. It has tabs at the top and accordion-type sections at the bottom. (Cards will have their own foldable annotation and revisions sidebars, on the opposite side of the interface, as will Pages...) Not unlike what you would see in VS Code or a similar IDE app. As before, the sidebar position is switchable in settings. This time, though, I have added some basic functionality which was missing in v1, e.g. dragging of sidebars and accordion sections to resize them.

Cards now have Blocks, that is separate sections for different types of Markdown content. This is still in development, but it will bring Orsn up to speed with what other Markdown editors offer. The types of Block supported will be text blocks, code blocks with highlighting, tables with some useful editing options, and LaTeX. (There are some interesting graphing options in Markdown these days but that is not a priority for now. That kind of thing can perhaps be better done in a Page extension.) I think this kind of Block concept should be familiar to anyone who has used Jupyter Notebooks or similar tools.

There is the option to have multiple Stacks now, in a tabbed interface. Before, there was just one Stack. A Stack is a collection of Cards. A bit like a folder, functionally, but it avoids the use of a hierarchical structure in the Cards themselves. Once you have added Cards to a Stack, you can collectively add them to a Page, if you want. You can create 'Live Stacks', e.g. a Stack based on a tag, which shows every Card with that tag. Or a Stack based on a search term. Etc. (Like 'smart folders' in some OSs.) At least you will be able to. For the moment, I am pouring the foundations, not laying the bricks.

A priority on the roadmap is to make it possible to assign properties to Cards. In this way, a Card in a Project will be able to have certain custom fields. As an example, you might have a Project for storing book references, in which each book's Card has ISBN and author properties. Those properties will then be accessible for visualisations or interactions in Pages, if the Card is added to a Page.

I won't say too much more about the database design, as it is ambitious in the features it might support in the future, but my priorities for now are more modest.

Technical

My starting point for updating the software was to migrate everything to Vue3 and rewrite the codebase to use Typescript. That phase is complete apart from a very few utility files which are still in javascript for the moment.
I resisted Typescript to a degree in the past, in part because I like code to be readable and self-explanatory wherever possible. I also want it to look nice! Perhaps not surprising for someone who spends a lot of time building interfaces? Typescript decorates javascript to such a great extent that if you are at all unfamiliar with it, code clarity is much reduced. Also, there are certain procedural aspects about it which I found confusing. Where to put the type declarations? What's the difference between .ts and .d.ts files?

On the other hand... for an application of any complexity, type safety is such a boon. It forces you to think clearly and helps enforce consistency. It makes structural decisions in the code explicit. That is all-important. I don't want to say how often I have found inconsistencies in v1 of Orsn, inconsistencies which Typescript has forced me to confront and fix. Also, once you have a certain level of familiarity with Typescript, the code is still very readable. And for other confusions, such as where to declare types, there is always the option of reading the documentation or looking at other people's code.

So overall I am delighted with Typescript, and I can't see myself going back. It has definitely helped make clearer what is happening under the hood in all the different parts of the new Orsn.

The move to Vue3 is what made it possible to use more Typescript than in v1. I have seen that other javascript frameworks are trending (Svelte?) but I haven't looked into them. Vue seems to be going strong and I really enjoy its usability and the sensible structural guidelines it sets out. I used React in a former job and its language was stated very much in terms of the requirements of the framework and its logic. Vue's language is stated more in terms of the requirements of the app designer. That may make it slightly more high level in some respects, but not significantly. You still have to understand lifecycle events, data binding, all the core stuff that makes it useful.

As part of the move to Vue3 I also upgraded the application's store system from Vuex to Pinia. They are similar to use in a lot of ways, but the move to Pinia has allowed me to remove a lot of code, as data updates are now executed straight away in 'actions' instead of in separate 'mutations'. That is easier to read and make sense of, and more economical to write. Pinia also supports Typescript directly.

The Road Ahead

The path onwards is pretty clear, and I am confident about the technical side of achieving the goals. The big problem is having the time to get there. That's the battle, and of course that is the difference between an imagined app and a 'real' one. It's not properly real until you make it.

It's interesting trying to balance the small details against the bigger picture. You can spend your morning making a sidebar resizable, but then you have to switch perspectives and consider the overall design and purpose.

It would definitely be useful to hear from others with different perspectives. I don't want to spend a long time going down the wrong paths. Find me on the fediverse @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io

The first version of Orsn was to an extent a proof of concept and was not widely released. Now I want to get it to a more 'finished' state, one where I will feel happier about properly sharing the software. Some changes are required to make the software more robust, and I have ideas of how to make it more useful and usable, too. These are sufficiently different from what is there now to warrant a new version number and prompt the sense of a fresh beginning.

He's a man, with a plan...

I have mostly completed making updates to Orsn to use Vue 3, Typescript and a more modern text editor library, Codemirror. However, rather than simply making a reproduction of the existing version, I'm now pausing to redesign the software.

Before I list the proposed updates I want to summarise the overall goals for the software:

1. Document and share research
2. A creative interface for developing, organising and inspiring ideas, and optionally to 'show workings'
3. Easy to use software, ideal for individuals and small teams as well as institutions
4. Geared primarily towards humanities research and writing, but with support for data-based research/digital humanities
5. Encourage open scholarship practices
6. For knowledge in-the-making: allow for rewriting, annotation, multiple perspectives, iterative versioning

Orsn is primarily (though not only, as we will see) a text-wrangling software which uses Markdown for text formatting. Markdown is a plain text format which makes content easily storable, reproducable, editable and versionable, for example in a Git repository. It also supports the attractive and readable formatting of text for human consumption.

Using Markdown is an important part of working towards the goals listed above, in particular, 5) and 6).

Users should be able to publish an Orsn research notebook to a Git repository, where it can be accessed, annotated and further developed by others – or at least it should be downloadable for others to explore it in detail in their own Orsn application. This shouldn't be something which is technically difficult for users to do. Orsn should offer simple controls for publishing research notebooks to Github or equivalent public repositories, and for cloning projects from repos to their desktops.

Operating at a small scale like this is vital to my aspiration for Orsn to support open scholarship and inclusive research. Orsn should be an alternative to research platforms which require an institutional team to maintain, and research projects which require large funding investments and therefore do not have the option of failing. Research should be capable of being a low-stakes activity which allows for experimentation, playfulness, and learning from mistakes. And it should potentially be open to many participants, not just those sanctioned by academic institutions.

Orsn is built using web technologies, so Orsn projects can be published as websites. However, Orsn can also be used as a cross-platform desktop app, in offline mode. This maximises its potential for inclusive use. One of the goals of the software is to provide a digital-first format for research outputs, one which properly exploits the potentials of digital media and networks, and avoids the syndrome of presenting research via 'website with downloadable PDFs'. Having a web-based format of exchange for Orsn projects allows users to exchange projects for offline desktop exploration, while retaining the benefits provided by digital interactions.

Proposed features in v2:

Simpler structure

• Instead of Cards, Contexts and Pages, Orsn v2 has Cards and Pages.

• Cards are like index cards in a filing system, with text and images. Cards now have rearrangeable blocks for specialised content, such as formatted computer code, LaTeX, or tables – anything that can be rendered as Markdown.

• Cards can be arranged on multiple 'stacks' or 'shelfs', presented as tabs

• Pages are for aggregating cards, and for long-form text (and images). But they can also be rendered by extensions (plugins) for different kinds of visualisations, as Contexts were in orsn v1: Map page, Timeline page, Graph page, etc.

• Each Project has a contents page for organising and presenting Pages.

• All types of content have an optional annotation column.

Extensions ecosystem
Page extensions will be npm packages, hosted on a public repository. There will be a template for creating your own plugins in javascript or typescript. Authors will be encouraged to share their extensions with the community.

Card properties
All cards already have basic properties, such as title, body, author, date of creation. In v2, Cards can be assigned additional project-wide properties, e.g. latitude and longitude, height, weight, start-date, end-date, geoJSON, etc. Such properties can then be made use of in Page views which depict those Cards and their properties, for example as graphs, maps or interactive visualisations. One use case would be that Card properties are drawn from an imported standardised vocabulary.

Versioning
A more robust version of the current revisions system for cards, with an improved visual interface. To be decided whether to extend versioning support to Card Properties.

Semantic support
Orsn does not aim to be a fully-fledged platform for semantic structuring of data, as this approach is not a good fit with its overall philosophy. However, there is potential to use semantics to create relationships between entities, using established ontologies if desired. This is facilitated by the introduction of Card Properties. These relationships can then be represented using custom Page extensions. (Semantic relationships would be stored in a relational database format, to maintain the emphasis on ease of access to Orsn, with minimal setup or technical skill requirements.)

Publishing support
An option to publish project as a set of Markdown files, and export these to an online Git repository. Also, the option to load in a project from an online Git repository.
Note. Cards can be fully represented as Markdown text and are therefore easily subject to versioning. Pages may be a mixture of Markdown text blocks and other visual elements, e.g. a Leaflet map. In a Git repository, such content would need to be represented as a JSON config file, specifying the extensions to load into Orsn, and their version numbers, in order to reproduce the content described. (Just as a package.json file does in a node project.) The installation of the necessary extensions could be automated as part of the project import process in Orsn. To be decided: how Card Properties should be handled in this scenario. Properties data could potentially be exported in JSON or yaml format, which could be used for repository storage, but then imported into the Orsn database for more user-friendly use via Page extensions.

Easier Markdown experience
New WYSIWYG editor for markdown text, for those unfamiliar or uncomfortable with editing Markdown directly, as well as 'source view' markdown editing and split-screen with preview.

Decisions and Priorities

What I need most to make v2 is time, which is a costly commodity, unfortunately. If you think a go-fund-me type project to develop the software over a fixed time-span is a feasible idea, let me know.

My philosophical approach to Orsn and open scholarship prompts me to propose versioning and annotation, as well as easy online publishing and sharing, as important features. However, features like versioning add programming complexity – which is fine, but detracts somewhat from the aesthetic pleasure of a simple codebase, and its accessibility. However, I have concluded that the best way to engage other developers in this project is by allowing them to create custom extensions, so this may not be so significant...

Should versioning of text blocks be integrated into the proposed 'export to Git' feature, so that each recorded text update is written as a commit in the exported repository? Should non-textual data (Card Properties) be versioned?

Are other features, such as semantics, or something else I've failed to mention, more important?

I am strongly conscious of the potential gap between the ideals of this project and the practicalities of how people might actually use it. Do they really want to have versioning for data, for example? Do researchers really want to 'show their workings', and is it better to just focus on allowing them to share their final draft effectively?

I also want to support the user who uses Orsn for purely personal documentation of ideas and research, and for creating documents. That is how I have been using Orsn myself for many years now.

In short I need advice on priorities! If you have thoughts, find me on the fediverse @Lemmy@post.lurk.org, or send an email to: info [at] orsn.io