I’ve uploaded a series of conversations with Doug Engelbart which was originally part of our Invisible Revolution documentary.
The Association of College & Research Libraries (ACRL) provides a basic definition of scholarly communication as “the system through which research and other scholarly writings are created, evaluated for quality, disseminated to the scholarly community, and preserved for future use. The system includes both formal means of communication, such as publication in peer-reviewed journals, and informal channels, such as electronic listservs.” (2003, http://www.ala.org)
The subject for my work is augmenting scholarly document discourse to increase clarity and credibility in the following document lifecycle:
• discovering document of relevant and of high quality to read,
• reading to critically understand,
• write/enter text to get thoughts cleanly and quickly out of head onto a substrate
• construct argument to more deeply understand your text
• cite external & internal material to tie into the web of scholarly discourse and to increase credibility
• copy-edit document to present a clear and coherent argument
• review of the work (primarily by supervisors/teachers but also by peers and editors) to increase quality and chance of publication/pass grade
• publishing credibly (logically presented and correctly cited) and clearly (in a readable and clear format) & archiving to augment the first spoke in the cyclical wheel
• archive document for future access, also to augment the first spoke in the cyclical wheel
Approaching Ideal Academic Discourse
The subject of my work is not to simply replicate the early generations of digital work where a serious focus was on replicating the capabilities (and, more importantly,) the limitations of the previous media of paper (WYSIWYG to WYSIAYG). The subject of my work is to explore and develop new digital capabilities far above what the previous capabilities of paper publishing would allow.
This will not be linear process. With new technologies come new opportunities, which are often spent on flashy demos which simply aims to sell the technology itself. To find out what truly useful utility the new opportunities offer is an exploration of the new capability space – we can not know how to map the opportunities fully until we explore the territory.
I am therefore a proponent of the facilitated evolution (Engelbart, 2009) model where the human system and the tool system co-evolves through trial and error towards a continuously re-defined and refined future of ever deeper literacies (my term, I did not get a chance to discuss that term with Doug but I have a feeling he would have appreciated it).
This is why I have engaged in dialog with academics to work to uncover how to provide augmentations to remove impediments to the scholarly communications process, to make tasks smoother and thus more likely to be carried out, and by providing advanced functions to go beyond anything we have been able to do before.
Here is the above mapped onto potential future work/features for Author:
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 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.