Month: May 2017

Interactions In Liquid Views

Published by Frode Hegland on May 28, 2017

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.

Elements in Liquid Views

Published by Frode Hegland on May 28, 2017

The elements of what will be available visually on the screen to interact with will include:

Nodes

• Columns which are Headings which are connected vertically and are the basic layout.

• Headings which are the things which are primarily interacted with. These will have typographic attributes which will initially be the same as in the word processing view, with the same user-specified font attributes. These can be modified to convey meaning by altering any of the properties, including type family, weight, colour, size, kerning and so on.

• Sub-Heads which show up always connected to the/snapped to headings are designed, to let the author explain headings. They appear in the word processing view as sub-headings. They can be created in the liquid view or in the word processor view. The reason for them is that they act as Notes on the Headings to explain more about them.

• Glossary Items should be interactable in this view, visually distinct and possible to toggle on/off and to create and edit in this view.

• Web Items. It should be possible to drag and drop or summon via links any text which has a URL, or a part of a book marks list, to enable Vannevar Bush style trails.

Connections

• Manual Connections are visible lines between the Headings which can be modified by colour, thickness, texture, shape and whether there are arrows at the extremities or names or icons in the centre. For simplicity and logical consistency these links should be simple whereas the next category, where there can be value in having different types of links look different, should have the variation. Therefore the initial suggestion is for thin black lines.

• Criteria Based Connections are visible lines between the Headings which can need to look different from the manually created links.

• Internet Links are links to URLs, which need to be indictable somehow, as elements and/or connections.

Summoned Information

• Body Text. The view should support showing some or all of the body text depending on user choice, such as the first sentence of the paragraph under the heading, presented similar to the sub-head, or all body text to appear through a mouse-over or click interaction.

• Persistent Badges to show further meaning such as indicating that a heading is actually a link to another .liquid document or the web.

• Mouse-Over/Interaction Badges/Controls which appear when required, to allow the user to get further information from an element or to move it or further interact with it.

• Body Text Elements of specific categories should be possible to draw forth when desired, such as showing all links under a heading, names or other keywords – anything which can be defined. These should be possible to draw forth and to define connections with.

• Means to enter a keyword which will result in connecting lines to all the headings where the keyword is present, or only showing headings where the keyword is present.

• Overlays or Backgrounds can help convey the meaning of relationships through labeled/un-labeled box shapes or labelled/un-labelled divider lines. These would not show up in the word processor view.

Annotations

• Annotations will be an important aspect for someone who is not the author to add at some point. This is not being dealt with in this project.

The Space

• Colour/texture/image background, useful to help differentiate different liquid views or aspects of the views.

Definitions

Addressing the issue of the vocabulary of elements in a document. The items listed below can exist alone in a document or as a part of a document with others. These elements can be text, scribbles, tags, applet bits of code and other means of marking intention.

• External Notes : Notes to be used in document later or not

Notes used where needed.

• Knowledge Container/Frame : Document

Any self-contained addressable or portable framing of any of the components listed above, including composite and single items.

• Main Document Text : Text in document without additional, tagged information.

This refers to the plain text of the main body text

• Thoughts : Notes, Writings

Our thoughts are simply notes created by us without primarily referencing something else in the world.

• Something in the World : Citations

Something in the world which can be addressed and cited somehow. This can be a clipping/cutting or a URL or just the data itself which a system can search for and locate in an origin document/location. Includes text, Pictures, Video, Audio and Graphs.

• Thoughts about Something in the World : Annotations

Something which exists in the world, such as an article and we add a note to it, we annotate it with our thoughts. This can be through adding meta-information in a digital environment with explicit ‘tags’ but it can also mean simple highlights, strokes and shapes around text or other information.

• Thoughts about Something in Our Work : Comments

We comment on our own documents for ourselves and/or for others.

Liquid Glossaries

Published by Frode Hegland on May 27, 2017

The Liquid Glossaries are an ancillary issue to the process of writing academic documents and as such is being looked into. The web page for this project is http://www.liquid.info/glossary.html and the blog posts relating to it are on http://wordpress.liquid.info/category/liquid-glossaries/ The relevance of glossaries for Liquid View is that the Liquid View needs to be able to show glossaries where required, in an visually efficient way.

You may have noticed the large amount of links to blog posts in this article. This is not only because I wrote too much, it is also an exercise in learning how to write re-usable chunks, which is where the Liquid Glossaries will come in.

Create a Glossary Entry

User selects text does keyboard shortcut cmd-l and the Glossary Dialogue opens with the selected text copied into the ‘Heading’ field.

If the user did not select text but does cmd-l the Glossary Dialogue opens and the user can type in a Heading.

There is a visual mock-up here: http://wordpress.liquid.info/glossaries-over-coffee/

The Glossary Dialogue

The Glossary Dialogue contains various fields, all of which can support rich text. They include:

• The ‘Heading’, or the subject for the entry. Name to be decided.

• Brief Definition (max 140 characters, indicated in [hard brackets for use in the Visible Glossary View])

• Full Definition (long. This field can contain external links as well as in-document links

• Option to save to Personal Glossary or only use in this document

On clicking ‘OK’/Enter, the Glossary Definition is saved to a database in the Author application (or in the document, depending on preference, as above). This database is connected to online versions (to be developed and discussed).

Interacting with Glossary Entries in Edit Mode

Wether the author has created an entry while working on the current document or created it earlier, the author can interact with the glossary entry in much the same was as interacting with a citation in Author. The Glossary Definitions are not visibly indicated (by default) so that to interact with the selected text’s glossary entry the author would need to do the cmd-l keyboard shortcut (or ctrl-click and choose). If there was a document entry it comes up for editing, if there was none, a new dialogue, as above, is presented.

Glossary Logic

If the glossary entry is two or more words long, even though it can also be spawned on one (as shown in the screenshot in the blog entry referred to above), then if the single word spawn is followed by a capitalised word, it will not spawn. This is so that an entry can be for a name and if the author refers to another name where the first name is the same as what’s in a glossary entry, but has a different last name, it will not interfere.

Interacting with Glossary Entries in Read Mode

• In Read mode the reader can click on text with a glossary definition to see the Glossary Dialogue in Read Mode (similar to the Citation Dialogue in Read mode).

Visible Glossaries

• The reader can choose to turn on [Visible Glossaries] where all the Brief Definitions are automatically shown in-line in the text, either the first time they appear or every time then appear, in [Hard Brackets, in grey]. This mode can be turned on in a Glossary Dialogue button in Read Mode or through cmd-[ or cmd-] (’tab’ will have to be used if the user wants to indent).

– If the [Brief Definition] is clicked on in Read or Edit mode, it will open the Glossary Dialogue in Read or Edit mode. This text cannot be further interacted with on the page.

Publishing A Document with Glossary

When the author chooses to Publish the document the document will be presented with all the ‘Brief Definitions’ inline, [inside hard brackets, in grey] for the author to review. The author can click on any of these definitions to turn them off (and the text goes red) and back on again with another click if mistakenly clicked on. The document is then published with a list of all the Glossary Entries at the end of the document (same as Citations are listed at the end of the document under ‘References’). How the glossary entries are embedded is up for discussion.