An example interaction to provide server-side specified options for text interactions. Options can include in-blog search, user name recognition and links and more. You can try it live at http://wordpress.liquid.info/a-theoretical-model-for-knowledge-work-symbol-manipulation-4-aug/ It looks like this: This is currently implemented at wordpress.liquid.info under the original name of ‘hyperwords’ in 2006: A Level, B Level & C Level of Activity
-
-
Visual Syntactic Text Formatting
Visual Syntactic Text Formatting is one of the ViewSpec we are considering. As originally developed by Mark Warschauer, University of California, Irvine markw@uci.edu, Youngmin Park, University of California, Irvine and Randall Walker, Mayo Clinic: Visual-Syntactic Text Formatting – Live Ink I have implemented is a simplified version in Liquid | Flow, as can be seen in these two different lengths, taking a paragraph from Doug Engelbart’s 1962 paper, some tweaking as to what rules should be used can be useful, both live and pre-set:
-
Authoring Version Control, Comments & Layout
Taking the layout of this blog as the starting point, I have looked at how to indicate that an article has been superseded. In this design the text ‘This Article has been superseded’ is appended after the date, with a reveal triangle. The reader can click on this to get options to simply acknowledge this (OK), and the red text becomes light grey, to view the latest version or to view the version history. Design Other design thoughts in this mock-up are having next and previous post buttons be on the right side of the screen so as to follow the logic of scrolling back and forth. There are no…
-
Thoughts on a ‘Publish’ Dialogue Box
The act of publishing to the web, through WordPress, can be more useful for the reader if the process includes explicit steps for adding meta-information, such as the Category of the post and appropriate Tags. In this dialogue, mocked up for possible inclusion in Liquid | Author, the user has a large, clear screen for assigning Categories and adding Tags:
-
Status
The wordpress ‘status’ Format is quite interesting. It behaves like a non-headed tweet or social media post. It could be useful for future work. https://codex.wordpress.org/Post_Formats
-
Implicit Linking
Let users select any arbitrary text and perform searches based on the text, such as we have experimented with for Liquid | Flow and in wordpress here wordpress.liquid.info both of which are already developed and owned by us. A blog post with illustration of the blue dot. This is a Doug Engelbart Term. https://www.theguardian.com/technology/2004/nov/18/onlinesupplement jrnl post Category: Implicit Linking
-
Document ViewSpec
A flexible view where the user can control the presentation of the article, including collapsing into outline modes, expanding into Flow mode, colour coding of key text and more. This is a Doug Engelbart term. Cited from Authorship Provisions in Augment jrnl post Category: ViewSpecs
-
High Resolution Addressability
The ability for a link to be created which does not just link to the document but to a specific section within the document, such as a paragraph or a sentence, so that the reader can instantly jump to the cited section. This is a high-resolution version of pages in physical documents and can be used for further interaction. Related to the issue of pointing and addressing: http://wordpress.liquid.info/the-fine-art-of-addressing/ This is a Doug Engelbart term. jrnl post Category: High Resolution Addressability
-
Timeline
The Timeline in jrnl is the view of all the blog posts. We aim to augment this view through two mechanisms: Query/Search In the Timeline view the user should be able to search/query the server for which blog articles to view and the user should further be able to search within the search result. ViewSpec Timeline ViewSpec system which provides flexible ways for the user to choose how the list of document should appear. This is conceptually the same as the Dynamic Views.
-
Meeting with Chris Gutteridge 5th of Sept 2018
Christopher Gutteridge and I had a half day work and discussion session on the project. Decisions We decided that we should work on published documents, not live documents as in Google Docs. We further affirmed what may be obvious; that we want to make any additions modular so that anyone can plug any component into their wordpress install without needing the rest. Major components of work will a fast query engine and a view engine for a list/timeline view and text interactions when reading a document. Actions We plan to hire an external wordpress developer for a reality check before moving further. I have noted down our priorities as…