Skip to content

Category: Interactive Text Space Diagram

Liquid | View Application (layout tests)

Layout tests for a citation layout application.

Full Meta-Jacket

The user drags a PDF icon onto the workspace and the application checks whether it has full metainformation attached for citation. If not, it asks the user to select the name of the document and gives the user a list of a few places it can search for metainformation, including the ACM Digital Library or by the user pasting a Bibtex text or manually entering the data.


I experimented a bit with how to represent documents (as icons to make them take the same space or as text), people (bold), headings (san serif, same as Author headings) and comments (italic) and how ctrl-clicking could bring up different dialogs for options:

I also changed the canvas to a light grey and did some experiments with real documents, shown as two line serif type and headings in san-serif to see clustering:

I also looked at some different ways of showing active/selected documents, highlights and connection lines etc.:

Structure: Columns

I moved onto columns since we have tried that before in early Author dynamic Views and it seems to make sense to be able to anchor items to headings.

Here is a test where more annotations are shown (in yellow, as they would appear in the document) and there is green text above one of the columns (it seemed easier to skim when I used columns) designed to indicate an unread document:

However, based on how well the columns seemed to work, I then had the notion of having a column to the left for un-read and therefore un-categorized papers and the idea of having a column on the right for used or refused documents took too much space so refused documents now appear under the un-read column and used documents (copied for citation) are grey but this can be toggled).

I am really quite pleased with this layout, in it’s Trello like column style but I honestly don’t think it really adds much functionality beyond what normal citation managers do so I’ll pause this direction.

1 Comment

Showing relationships based on glossary

Direction Problem and Thoughts (for flow of thought)

These are my notes and how I worked through this. For the conclusion skip to below or read the clean implementation post

To define for the graph view we have the problem of arrows, of direction. If one entry has, for example, that Liquid | Flow was inspired by Doug Engelbart, it should ideally also have in the Doug Engelbart entry that he inspired Liquid | Flow.

When a node is in the centre of the view it should be able to link out to entries which are not listed in its WordPress entry, but in the other entries.

There are two ways to tackle this: The other entry could automatically have this new relationship appended but that would require semantic analysis to change ‘inspired’ to ‘inspired by’ or ‘works for’ to ‘is the boss of’ etc. Therefore I think the solution needs to be something where the user enters relationships in one node for both directions and then enters it in reverse for the other node. In this interface the user will enter ‘was developed by’ and then choose ‘Frode Hegland’ from the previous Glossary Entry popup:

glossary term for graph view. Hegland, 2019.

When the user clicks OK the dialog below is presented, asking the user to enter the reverse, which will then be appended to the other term’s WordPress entry:

reverse. Hegland, 2019.

This should then be able to support graph views. However, the problem in the graph view then is which version to choose? Incoming or outgoing? Maybe let the user choose based on the two options, by clicking on the arrow and have it reverse polarity and description?

By default the entry in the central node’s relationship will be used first.

Hegland, 2019.

As is shown in the previous image with the comments in italic, there are core issues to be dealt with. How can the user indicate that something is a part of something else?

‘Liquid | Flow is a part of The Liquid Information Environment’ is an easy way to put it but visually this is tricky since, as can be seen in the image above, ‘Frode Hegland’ is followed by ‘developed’ and that links to ‘Liquid | Flow’ and that reads well. To have ‘is part of’ is not elegant or grammatically good since the ‘is part of’ then needs to be on top/before ‘Liquid Information Environment’ and then it should be below ‘Liquid | Flow’ but logically it is the container so should be on top…

is part of. Hegland, 2019.

Liquid | Flow is a part of The Liquid Information Environment so this makes more sense visually. However, the connecting term ‘contains’ may work for some network diagrams but not for this:

contains. Hegland, 2019.

The problem is that both of these need to be correct: When ‘Liquid | Flow’ is the centre (here in bold on the left) and when ‘Liquid Information ‘ is the centre. Do we really need to have the user indicate both? MAYBE

both. Hegland, 2019.

Direction To Implement

I have decided the way forward has to be to use the intellect of the user. Therefore, this will be the first screen when adding a glossary term:


first part. Hegland, 2019.

Once the user chooses a Glossary Entry, additional request appears below, asking the user to add a further relationship with the same two terms, but the other way around. This additional relationship will be posted to the other term. Also, the little [+] only appears now, in case the user wants to add further relationships.

second part. Hegland, 2019.

This way the dynamic graph view can support showing both Liquid | Flow and Liquid Information in the centre:

flow in the centre. Hegland, 2019.

And once the user clicks on ‘Liquid Information’ it moves to the centre, showing relationships from its perspective:

liquid information in the centre. Hegland, 2019.

OK, that’s been a few days of thinking and Starbucks in Singapore and too much coffee and walking but this an approach I can live with. It takes some time for the user to create this but it is the user who is in control.


What can you do with it?

Someone I know who is a very positive person but not at all very technical asked me a while ago about my Apple Watch: “What can you do with it?” And my first thought was “well, probably not very much for you because you don’t like to learn how to do things with tools”. I didn’t say this of course, I just mentioned a few of the main features. However, this got me thinking about something fundamental:

The pencil and paper, what does it do? This is a question more about the users skill level and use case. The properties of the pencil and paper medium are not that hard to describe. The power comes from a skilled interaction.

The smart phone, what does it do? This depends very much on the users ability and interest in using the available apps so the answer would be anything from just making calls to running your full digital life.

The point is that the capability = the tool + the user.

Personally I have to try to answer the question of what does a graph view of text do for an author? It’s not a simple question since there are specific ‘affordances’ which need to be be built into the system for certain things to be possible. When making a CGI movie it is often remarked on how everything in the world has to be thought about and designed–there is no background or set they can put the actors into. Similar things with games–in Battlefield I can easily blow up a building but I can’t tie my shoelaces.

I read once (and cannot for the life of me remember where, but I suspect it was in Edge) that a lead developer of the successful Crysis game once remarked that making the AI for the players adversaries work well was a matter of making sure that everything in the game knows what it is and what its characteristics are: A piece of wood needs to know what force is required to shatter it and so on. This matters greatly since a digital environment may look like a flat screen with colours but this is only a two dimensional slice of a multidimensional space of interactions. Even a paint program does not simply add colour to the screen based on the users mouse, trackpad or digital pen–it adds the marks based on the pen and virtual paper’s characteristics.

In the graph view what is being around is text and lines but the text represents specific text, since I have already taken it as a starting point that simply letting the user take any words from their document and move them around is not as useful as having different text have semantically interactive characteristics.

The basic way to do this is to have some sort of a list of what words are ’special’ and a way for the user to visually state which other text is also special. By assigning text as a heading you are saying it has a special role–and I am referring to roles within the work of authoring a document, particularly an academic document–that of indicating a high-level view of the organisation of the document. Headings have been referred to as structural links since they do not have a semantic meaning but they do have a semantic meaning, there is a reason why one chapter or section comes before another in the flow of a linearised argument. This is the very essence of headings: Showing sections of a linear flow. To me, at this point that should be respected and therefore headings shown by themselves, collapsed into a table of contents or outline should be editable in sequence through a drag and drop function but not be in a graph view since that defeats the function of headings. This can be disputed but there it is for me for now. They can have value in as markers in other views, but not for themselves.

Other text in a list. This refers to what I am working on with what was originally called the hyperGlossary and then Liquid Glossary but which I think I will just call it a glossary though Chris might not agree. Anyway, it’s a list but a list where each item has attributes (as in Crysis) to create an environment for useful interactions. Each ‘glossary’ term can easily be linked to other terms to create an explicit connections allowing for construction:

And there we have it. I wrote the above sentence using the word ‘structure’ instead of the final ‘construction’ since I thought that structure seemed a bit too final so I used Liquid Flow to look up construction in wikipedia–not useful, then the etymology and then it became clear that what I wanted to do was to say this allows for construction, it is not a structure and this is the key.

The glossary as I am designing it now for Liquid Author’s dynamic view has these types:

  • Document for anything the user cites
  • Authors/people in general
  • Institutions of people
  • Concepts for anything else

This is for the use-case of a student of course, the last item ‘concepts’ is quite general but users will be able to type in anything they choose. Likely ‘document’ will be auto-assigned when the user downloads an academic document with the Liquid Browser:

There is probably room for improving this list, particularly outside of the initial use case but categorising is useful for filtering views, for doing basic citation analysis for example. Naming things is a big issue. Confucius is said to have said: “If I was the ruler, the first thing I would do would be to make sure everything is named correctly”: “If names be not correct, language is not in accordance with the truth of things.”


Walking in the early, dark morning of Singapore to find a toilet, this Starbucks does not have one and it’s the only 24 hour one. Lots of police cars outside Orchard Towers. I hope they are only there for the unruly. Anyway, to ION and back and with a new perspective.


Human language does not allow for one correct label for one thing. For the case of this work though, I will remove ‘institutions’ from the basic list and have buttons for ‘Document’ and ‘Person’ and freeform for anything else, which will automatically be put under the meta-tag of ‘Concept’. This should serve literature reviews well since documents are a core unit and are addressable items and persons are out-of system but the reason for the documents. Anything else can be labeled should the user want to, from idea to building, but they willl… Stop, this does not really make sense. Let’s start again:

Buttons for Documents (they have citation information) and Person. Anything else will be text entered but recent items will stay available for clicking on, to use recollection to encourage the use of same tags. Here it is mocked up:

basic types. Hegland, 2019.

This means that we can support nice citation flows through documents, their authors and any associated concepts as well as let the user add any terms they know.

So what can you do with it? Anything you like in terms of visualisation we hope, over time. Initially though, we are focused on supporting citation views and concept views to help the student ‘map out’ their understanding of a knowledge space and communicate this understanding to other readers, particularly examiners of their thesis.


Headings are for linearising. Glossary terms are for enabling constructions of relationships. And this is how we will focus the development of the Liquid Views.

Leave a Comment