Skip to content

Author: Frode Hegland

Response 1 to Sam’s Response to Liquid Space

This is in response to Sam’s Post:

Here are my comments to Sam’s response to my post on Liquid | Space:



Multiple Layouts – created by author

Multiple layouts – selected / controlled by user

Thinking about (all multiples)

relationships (peer-level associations), as well as

drilling into detail (drilling down), as well as

understanding context (drilling up)1


I agree that we need to have and key multiple layouts, what I refer to as ‘Views’. Sam, do you agree it’s the same thing? I’m not sure about the mechanism for this yet though, something to think about hard.

As far as drilling down and up is concerned, my current thinking is to keep it simple and allow the user to link to other .space documents which are rendered in the linking document as a live preview, for all intents and purposes acting like a transclusion, like a portal. The opposite issue, showing how the current document/canvas fits in a ‘higher’ level, is a hard one, since multiple other documents can refer to it and therefore be ‘above’. We therefore need some mechanism to show ‘backlinks’ in this world.

For these issues I hope we can be more inventive than simply adding buttons.

Changes to original document, in new version

Add these as issues to be worked on.


Visual Design

For diagrams, it is useful to use visual indicators (colors, line style, line width, icons, size, etc) to bring out intended message or meme to be conveyed in that presentation instance (message)

Diagram operations can be a separate discussion, as it can be quite an extensive set of actions / use cases


in AUTHOR mode, PRESENTATION is for the AUTHOR, and assists in the creation / authoring / editing / reorganizing / etc. of the object

in READING / VIEWING / NAVIGATING modes, PRESENTATION is for the READER / / and provides ways that ENHANCE the reader’s comprehension of the material2


The question of visual indicators is difficult and important. This can really help communicate, but it can also quickly become a language only the author understands, so needs real work to design.

As for presentation issue, yes, having different modes for author thinking and presentation and reader access is important.

Changes to original document, in new version

Add issue of visual indicators as a point to work on.

Look into modes for Read and Edit.



on keyboards, keyboard shortcuts are faster than mouse operations, and ought be available, at least until keyboards are obsoleted

Rather than having multiple actions create different TYPES of an object class, a SINGLE action ought create an object instance, with easy EDIT-PROPERTIES that allow tweaking it or changing its type, attributes, etc.

HIGHLIGHT NODE – the idea of FOCUS is introduced here – very important. FOCUS can be invoked by click (mouse enabled), keyboard shortcut, glare (eye-sensitive devices)

FIELDS – ought be:

STANDARD / DEFAULT – system-supplied, always available

CUSTOM – user-defined

VISUAL – user / reader CAN choose this, as well as experiencing the AUTHOR’s specified visual behavior


key discussion is CATEGORY TAXONOMY vs TAGS

The LAZY way is tags

most likely to be used / adopted

The intellectually cleaner / elegant way is CATEGORY TAXONOMY

less likely to be used / adopted


adding by drag/drop -> leaves a TODO item to review HOW to integrated it into the FOCUS DOCUMENT3


Keyboard shortcuts are important but this should also take good use of gestures and direct manipulation as via a tablets and laptop with multi-touch trackpad.

The importance of instances and inheritance is crucial.

We could have a very cool way where user types a tag and immediately, visually, a web grows above it, linking it to what is in the taxonomy, letting the user tap on which connections are correct for this tag.

Changes to original document, in new version

Consider keyboard issues as part of the interaction method design, nothing to add right now.

Put down section for inheritance and instances.

We should have a meeting to define the fields as well.


Invention based on this post

Instead of adding tags being plain text or auto-complete, show a visual web/hierarchy connected to the tag based on the document’s world.



1. Sam’s response to Frode’s “Liquid | Space (thoughts for spec)” | Knowledge Federation – The Journal. (2015)

2. Sam’s response to Frode’s “Liquid | Space (thoughts for spec)” | Knowledge Federation – The Journal. (2015)

3. Sam’s response to Frode’s “Liquid | Space (thoughts for spec)” | Knowledge Federation – The Journal. (2015)

1 Comment

How to respond to documents/posts?…

This was orignally written in reposnse to Sam’s post in response to my post on Liquid | Space.

This was written in Author, with citations and headings and pasted into a WordPress posting app (the official one, on iOS) where most of this went missing. The original .author document is available from

Diary Entry of Sorts

I’m sitting at Starbucks in Putney, London, drinking my old favourite, a con-panna, which is two shots of espresso, whipped cream, some sugar and coffee beans on top, mixed, then iced. No healthy for the body but sometimes necessary for the mind.

Of course I am writing this using Author, on my iPad Air 2, propped up on a 12 South Stand (it’s nice, but too heavy and not tall enough really), typing away on my normal Apple keyboard. The promo video for Author for reading is done, with a quote from Vint to start it off. It’s on Facebook and I hope to be able to promote it there when version 1.6 of Author is approved, which should be any day now. It fixes the crash on start bug which only journalist early users have experienced. Yup. Murphy was involved.

Note after writing this document: It would seem that I came to a useful concision of the last issue discussed, ‘threading’ and I would very much welcome comments, while I did not really get to dive into the document space, something I look forward to discussing with my esteemed Amigos.
Document Dialogue

David Price suggested that the third video should be about how documents relate to each other (the first was Reading and the second was Editing). Now that I have put together a proposal for a basic concept map application (tentatively called Liquid | Space) and Sam has blogged (and emailed) a response, I have to figure out a model for how best to respond to him.

The prime objective is to write my reply in such a way that Sam and anyone else can easily follow the thread of the conversation.

Should I publish on WordPress as a comment or a new post? Should I publish an Author document by emailing it or posting it on the web? Should I maybe design a new discussion forum system?…
As Author Document

Ideally I want to write the reply here in Author but I cannot expect the whole world to read documents using Author and a free-floating document (not published onto the web using a URL to find it or academically using a reference number to find it) will be an issue. If I publish it to a server it would have a URL, but would not be readable by a web browser.

As WordPress Post

Publishing my reply via WordPress would keep things nicely in one place to make it easy to follow the thread, if posted as a new post but is linked from the Sam’s post with a link in the comments. I am however tempted to add a link to the original Author document, since I’ll be writing it in Author.
In New Discussion Forum

Too much work. Stop it now.
Results of Reply

I’ll be replying with basically three types of replies for the issues he highlights: Yes, great idea, I’ll add it to the main spec, No, I dont’ agree and here are reasons.

The point is that my responses will be twofold; comments on Sam’s post and a new Spec document, which should also refer back to the original spec, Sam’s comments and my comments + more of the same in the future.
Free-form vs Meta

There is a temptation to add meta information to the Author document saying what it is in response to. An alternative is to simply write it in the document, as I have here, first sentence all the way up top there.

The Document Space

This leads to questions of the document space. How should documents connect?

Links point to a document but they are ‘dumb’ and not stable.

Citations point with more knowledge of what the point to and point to data rather than location (author name, title and publisher etc.).

Doug had powerful arguments for a back-link database so that all documents knew what documents were pointing to them. Today we have Google searches.

I propose that we develop routines and best practices to give documents in points and out points that are easily searched and letting the reader applications find the thread. A design problem for me is that I don’t like having visual interaction elements in documents and users would not necessarily know how to add this met-to the document.

Let’s play with one idea: On creating a document there is a field, right under the ‘Name of Document’ field, which is ‘Document is in response to’ field for a URL or other document information. This is nice and will be part of the new documents meta-information. Then we get onto the issue of threading:

How to refer to each of Sam’s items is also an interesting challenge. Should they all appear in a spreadsheet format? Or should they appear as citations, each with Sam’s name etc. under them? Or something else?
The thing is, it should be possible to comment on Sam’s issues one by one, or in blocks, while making it clear what he wrote and what I wrote. Furthermore, this should be done in a way that the document ‘understands’ which is which, so that we can build further interactions in the future to help people read through document dialogues. I’ll start here and see how it looks, using Author’s Paste As Citation command on the first section I copied from his post:
The text that follows is from Sam:


Multiple Layouts – created by author

Multiple layouts – selected / controlled by user

Thinking about (all multiples)

relationships (peer-level associations), as well as

drilling into detail (drilling down), as well as

understanding context (drilling up)*
You can see that it is a quote, from the * at the end, but since I used the ‘paraphrased’ category rather than ‘quote’ that’s all you can see. I proposed we add a category called ‘Minimalist Quote’, ‘Quick Quote’, or something like that, and show the text as slightly greyed out to indented. Or both.

1 Comment

Liquid | Space (thoughts for spec)



A tool to think with, allowing the user to easily map out their space. Therefore the layout must be user controlled.

This is seen as as tool for thinking about relationships, first and foremost.



Visual Design

  • Initially inspired by Scapple
  • Typeface Helvetica.
  • Light grey bgr. #f8f8f8
  • Black text and lines.



Different from Scapula (visual and interaction)

  • The grey, not beige background.
  • Dragging a node should be in real time, with real time update of lines.
  • No bar at the bottom of the screen.
  • Pinch or cmd- cmd+ should not zoom screen but scale any selected nodes text.




Create Node

  • Double click/tap to add a new node. A dialog appears, as is shown in the About section below. On creating a new node all others fads into 10% opacity.

Edit Node

  • Double-click node and all others fads into 10% opacity and box with drop shadow appears, same as when creating a new node.

Create Connection 

  • Click and drag onto other node to add grey line.
  • Click and alt-drag onto other node to add black line with arrow.

Highlight Node

  • Click/Tap to grey all other connections and nodes to 10% opacity, as shown here. Tap outside to revert to normal mode.




When click/tap and move, make all other connections and nodes 40% opacity. This happens whether the node was first clicked on/tapped or user goes straight to click and move:




This might be the most important part – what we can assign each node as being all about.

Each node is created with a set of fields which are shown in a dialog box when the node is double clicked/tapped.


Note, this illustration is for general design. For the actual fields refer to the lists below, since they will change as the project develops.


  • Title (once node is created, this shows as heading, not editable, however double click to edit)
  • Comment
  • Tags

External Resource 

This section is about whether the node should be presented as an icon/screenshot or picture, or if it should be simply the heading text. Therefore any one chosen below will grey out the others (user can still use any other, thereby greying out the previously chosen one).

  • No. Keeps this as a simple text heading. Default.
  • URL to web resource. If used, a screenshot of that web page will be generated and used as the image.
  • Link to other Liquid | Space document: (this can be searched for or dragged onto this field. If so, the screenshot of the other document canvas will be used in the picture field below, to give a sense of seeing through).
  • Picture: (allows user to drag a picture here which will then be the node, with the heading below it. user can also drag a picture from desktop onto canvas and spawn this dialog with the picture in this field automatically shown.


This node is a: [pop-up list of types which all have icons, such as lightbulb, + sign, – and so on] If this is chosen AND an external resource (which all have screenshots or pictures), then this will show as a small badge, lower right in the screenshot or picture. If not then this will be used above the node title, same as a picture or screenshot.



I have not thought this section through yet. I am not sure if we should let the user choose this or let it be chosen through choosing a type of node.

  • Shape of this node: (none, box, circle, rounded box, triangle, hexagon, pentagon)
  • Colour of Outline:



Each connection to and from the node can be tagged, giving the user a way to categorise them.

I am not sure how we should decide on categories and how they should be illustrated.






Author Integration

User can drag and drop text from Author to Liquid | Space and headings will turn into nodes which are connected by normal (grey lines). Saving the .space document will be linked to the original .author document and if the user adds nodes in Liquid | Space, the .author document will add the nodes as headings int he original .author document

Any .space document can be inserted into a .author document and the a preview .png will show the canvas, while the full .space document is saved inside the .author document. If double-clicked, the .space document will open in Liquid | Space for editing/interaction.





  • Compatible with OS X El Capitain
  • Modern architecture including continual auto-save.
  • Full screen support.
  • Save as a .space which includes an image preview which is a full size screenshot.
  • Export as transparent .png
  • Multiple undo.