Liquid Glossaries

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 and the blog posts relating to it are on 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: 

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.