Skip to content

Category: Liquid | View

Liquid View Presentations Tests

I have been using Scapple to map out how Doug Engelbart’s process fits the academic document process, which turned out to be quite useful to see where there was a mismatch (Doug was not concerned with the career of the academic, only the work, at least in his formal models). The process was also useful exercise in testing out how a real-world project would use a Liquid View, in that I could not simply freeform layout everything and anything, it needed to have a means through which it would be done in a Liquid View.

This is the full size screenshot:

I took the screenshot and annotated it in Keynote:

Jacob has cleanly separated the word processing view and the TOC outline view in Author so I can’t wait for Author to ship so we can start to experiment with these views…

Another exercise from today highlights the need to allow the user to add borders:

Comment from Mark Bernstein (email 6 August 2017):

“Perhaps it does, but the illustration doesn’t make the argument, at least not to me, at first glance. The right-hand slide, which I suppose is a Engelbart creation from relatively late (1990s?), is not a distinguished slide.
The left-hand slide, which I think is yours, is significantly clearer.  It’s got two borders. The lozenge around “external environment” does not appear to have a purpose at all, and is also oddly placed; why not center the text? Why, for that matter, is the environment, which by definition encompasses everything, enclosed?  The second border is better, but it prevents a confusion which would not in fact occur; there is already sufficient white space to distinguish this list from other lists in the view.”
My thought in reply to this is that he is right but we may need to figure out a way to add labels to arrows, which is only a related issue.
1 Comment

Some of the issues

Some of the issues with the Liquid View come up when I use Scapple to simulate some of the aspects, for the work on my PhD.

Here I have created a column for the lifecycle or process to augment, which is linked vertically top down with arrows to indicate the general flow. To the right of this is a brief description of the point/goal of each process and there is then a divider/quit a bit of space before I get onto the invention/innovation/idea/development columns, the first one which is a list of specifically desired functionality which should be useful in make one or more processes reach the potential of the goal. This is followed by a column of what needs to be implemented for such functionality to be realised:

Issues which arise from this is that it’s clear that it would be useful for the nodes to be interactable to jump to specific sections of the main document, or external documents, but this is clearly not all the headings of a document, this is a subset of a document which means that it can be thought of as an inserted graph.

How this could be handled is if it is its own document and then embedded into the main document but this could become confusing, especially when the author want to link to a section in the main document from this view, which is not in this view…

This leads me to think the we should be stricture with hierarchy, not simply allowing the user to do everything arbitrarily. Maybe we make level 1 headings a special thing, which can only be viewed in a specific way? My friend Tom is an author and he showed me how he writes a chapter per word processing document and then collates them all at the end. This is a perspective to consider.

Having a look at this specific example above, let’s say that the four bold headings are level 1 headings and that what is shown below them are then level two and that’s all we have in this view, where the level 2 headings are ‘stuck’ under the level 1 headings in columns and the user connects any headings arbitrarily and can move them around. How would the user designate only these four level 1 headings for a Liquid View?

I must think of some way to allow the author to create multiple Liquid Views with different sets of headings – maybe there is a default one for the whole document and then a ‘process’ for creating a sub-set like this, with maybe a slightly different background colour and appearance in the main document?

A Solution?

A solution to this could be to have two completely different kinds of Liquid Views, maybe with two completely different designs and names:

  • Document Liquid View
  • Embedded Liquid View

The document Liquid View would work as previously discussed but the embedded Liquid View would be embedded in the same way as you might add a picture but the Liquid View created through embedding will only exist inside the host document, so it’s not so much embedded as created, but the term seems right.

Embedded / Liquid Diagram

There will be no headings in this Embedded Liquid View on creation but the user can ctrl-click on the screen to choose ‘Insert’ and a hierarchy of all the headings in the host document will appear, allowing the user to insert one heading as a node or a series, if there are any below the level chosen. This lets the headings be linked from the Liquid View into the main document. The user can also create headings from scratch and ctrl-click on them to link them to headings in the document.

The embedded Liquid View is not a Liquid ‘View’ then, it becomes a Liquid Diagram, since the user can click on a heading/node to jump to it in the document if it’s connected, but cannot ‘expand’ the view back into a word processing view since there is no such underlying structure. I will change the name of this in the future but for now I’ll leave it as it is here since this was the flow of thought as I went through it, writing this text.

This means that we can design different types of Embedded diagrams and visualisations.

Note also that the embedded is live, not an image.

Note to Jacob: We should probably develop a plugin architecture for the Embeds so that they can be developed and tested while integrated into he main document through links but built by different people for time saving.

Other documents can also be called into a link from an embedded diagram through relative or name addressing.

Leave a Comment

Interactions In Liquid Views

 

Liquid view is designed to help an author think in order to produce a document, it is not a general purpose system for analysing information. In light that framing, it will be important to be very clear about the purpose of the system, as starts here. The purpose of the liquid view is to help the author better understand how the sections in their document, as indicated by headings, relate to each other and thus to organise the sections better and integrate information which appears to be missing. 

It should be possible to interact with the liquid views in different ways for different reasons, depending on where the user is in the process:

Creating Nodes 

The user should be able to create a new node/heading by double clicking on the screen and start typing. By default any new heading is shown as being level 1. The user can then drag the heading onto any current heading and the new heading will then slot in user the current heading (same level or one level below, depending on how the user drops it, a gesture we will have to study)/

Type heading on screen. Defaults level one. Appears at end of WP. Floating in liquid. Changes heading if snapped to different level. How to order as level one? Move to head then maybe be away. Cmd f searches on it.

•  Choosing what Elements to show

•  Choosing How Many Levels Deep to Reveal Headings

•  Manual Layout in 2D and 3D

•  Criteria Layout 

– Using ‘magnets’ to pull Elements in specific directions 

– Search to show only Elements with specific keywords or hide, as well as to show connections to such Elements  

•  Manual Connection view

•  Criteria Based Connections view 

•  Connections visual change depending on criteria, such s amount of keywords linked, age etc.

•  Navigation by moving the user’s view within the document, primarily horizontally and vertically as well as ‘zooming’

•  Attracting Further Information in order for the author to best understand the information as well as 

•  Hiding Information away for use later – such as by putting Elements into the Cuttings area from the liquid view 

•  Quick find on screen through allowing the user to type in the first characters of a Heading and have the Heading(s) which include the search text to be highlighted.  

•  Create Heading/Node. Headings are usually created in the word processor view but should also be possible to add to the liquid view, either as sections under current headings or free-floating (where they will then be appended to the end of the word word processing view unless moved elsewhere).

 

View Controls

Control mechanisms need to be present to allow the user to alter:

•  Global view attributes, such as a toolbar.

•  View attributes of specific link types.

•  View attributes of specific headings. It needs to be possible to:

  – Move section

  – Choose how many levels to see: open/collapse. If collapsed, the Heading is underlined to indicate more under it.

  – Show/Hide connections

  – Indicate wether the section is Done (green dot/colour text maybe), In Progress, Paused or Empty (grey maybe, and auto-assigned?)

  – More… To be determined during user consultations, as with all potential features

•  Mouse over sections to see structure, in other words what other Headings are part of the same column

Layout Considerations

The user will be able to manually move elements around the screen and summon automatic layouts based on criteria:

 

•  The basic layout unit scheme is a column, where headings show up as in the word processing view’s collapsed ‘Table of Contents’. The author can easily snap apart headings from columns and create new columns.

•  Clusters of near or overlapping headings will show similarities and and those headings not near each other will imply distance in meaning through distance in layout.

•  Relative positions of top/bottom and left/right can be used to show meaning.

Stored Views

The author should be able to save views (maybe in a tabbed format) and possibly to go back through a timeline. 

Toggle Views

How can the user best transition between the word processor view and the liquid view, in a way that feels natural and makes it feel like two different views of the same information is shown? Currently, logically, the view fights with the collapsed/Table of Contents view. How should the liquid view look on first entering it; the same as TOC?

 

Context:

•  Toggle TOC view: Pinch in with two fingers to enter and and pinch out with two fingers to exit 

•  Toggle liquid view: Pinch out with three fingers maybe?

•  Toggle flow view: pinch out with two fingers when in regular view and pinch in with two fingers to go back to regular view

Annotations

The liquid view should be annotatable, just like the word processor view should be. 

Sharing

On publishing the .liquid document the author should be able to choose what liquid views related information should be included. 

Leave a Comment