Liquid | Glossary : Implementation
There needs to be ways to store the entries and retrieve them over a network. Where the entries are stored should be flexible however, and the user should be able to set this, whether it's on a blog or in a database or something else.
Workflow in Author
Liquid | Author is a prime candidate to be an initial interface to the system and this is how it would be implemented initially:
Creating & Tagging
The author selects text to add a glossary entry to and cmd-y to open the Glossary Entry dialogue.
Here the user fills in a brief note about the text, a longer note and, optionally, further information.
The author then clicks 'OK' and saves the entry to a database within Liquid | Author, similar to how the user information (name, institution etc.) is stored. This system will need to be able to synch via APIs to a server repository, when such is developed.
Publish to Rich PDF
When the author chooses to publish the document, the any entries in the author's Glossary which are also in the document will be included at the end of the document, under the heading 'Glossary', same as any citations will be listed under the heading 'References'. The entries will be uniformly presented, for easy parsing by the reading application.
The concept for the Rich PDF format is discussed in this blog post:
Publish as .liquid
If the document is published as a .liquid (Author native format) then the glossary will be visible at the end of the document, same as with other format. This is a 'View' which can be turned on and off in the Author 'View' menu.
When someone opens the document in a Liquid|Author application the following will be possible. Other systems will of course vary in their reading implementation.
The reader can choose to:
Workflow as Plugin
The system should be available as plugins for Google Docs and Microsoft Word.
The system should allow for multi-user systems, such as in a research team.