The Reader’s Experience

There are many ways to access the glossary data for the user and we will need to both experiment to find an optimal solution for the general user as a default option and provide naturally accessible options for any user with specific needs or preferences. We will be building a WordPress plugin to provide this functionality.

 

The design of what happens when a document with glossary terms attached is published to WordPress is difficult since there are so many ways it could be handled and there should be degrees of reveal for the reader without the reader being confused: It should be possible to not have any glossary text visible, to have the short definition visible and to access the full definition and then the full graph connected kahuna.

Visual tests

There should be a way to indicate that certain text has a glossary term available for reading but which is not opened up (in brackets to show the short definition). See are some tests using () ( • ∫  ‡ + ⋮ which should not stand out when scanning the page but be clear when reading a sentence. This is the same logic as Boldbeing designed to see when scanning a page but italicshould only call attention to itself when reading a sentence, it should not be eye-catching at page view level:

Experiments In-Situ

However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland() However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland( However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland• However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets

However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland∫  However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland‡ However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland+ However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets Frode Hegland⋮ However, the issue comes up that if the term is used at the end of a sentence it would be and that would be ugly, so therefore it seems best to make it fit inside brackets

Solution

One solution is to have the short definition in brackets but by default the view is with an icon after the glossary term which, when clicked, open (all of) the short definitions as shown below, with spaces either side of the brackets and a vertical ellipsisat the end⋮ to indicate click for options.

  • some text and then the term which in this case is fish⋮ with other text to follow to better show context

So the user clicks on ⋮ which then instantly in-line expands to show the short definition in brackets:

  • some text and then the term which in this case is fish ( a marine animal that swims⋮ ) with other text to follow to better show context

If the user clicks on the vertical ellipsis it opens to show options:

  • some text and then the term which in this case is fish ( a marine animal that swims⋮ [Hide] [Show Full Definition] ) with other text to follow to better show context

Here the user can click to Hide all the short definitions in the document or to open the web page which contains the definition in a new window/tab. This definition page will further have a link to show in a graph database or Liquid Space.

 

Other solutions considered for the future

 

Blue Dot

User can select text and if there is no glossary text selected or partially selected, a blue dot appears for the user to optionally mouse over:

If the user chooses to, options are revealed, including: To Copy as Citation, Copy High Resolution Link, perform searches, including of the current blog and choose to ‘highlight first occurrence of all glossary entries’:

If the user selects text and it includes text that matches a glossary entry, show the first sentence of the glossary entry in a pop-up box. The user can click on the entry itself to open the full blog post for this entry or click outside to close. The user can also click on the dot which is still there, to perform any normal dot interactions.

The user can furthermore mouse over the heading ‘Glossary’ for it to expand and show options. Further display options can include showing the first sentence of any glossary definition in the document in [hard brackets] which can be clicked on, with some icon* or through colours etc.

The very clear formatting of the glossary entries allows the system to feed any knowledge graph including the liquid space graph, where relationships are retained and can be shown and interacted with visually.

This approach is very simple and experimental, it could very well be characterised as a hack, but the reason for the work is to provide something useful in daily work which can then be improved upon in collaboration with users. Issues for the future include:

The question of whether the reader wants to access a glossary entry made when the document was authored or later, if the document was read much later. A solution to this can be to allow the built-in versioning system in WordPress to be surfaced to give access to earlier versions, if any are available or to lock the entries into the document on publishing, not to keep them separate.

Leave a Reply

Your email address will not be published. Required fields are marked *