Skip to content

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)

Published inThoughts

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.