Skip to content

Flexible Table of Contents / Overview (Thoughts)

This note is a discussion on how we can use Visual-Meta to give the user useful interactions for navigation. The software can only create an overview based on what is in the document, this is important.


An overview of a document can be a navigational aid and an introductory aid. The current Reader software is focused around a document by a single author but with The Future of Text we are also looking into how we can help the user grasp the content and decide what to read based on multiple contributing authors.


In Reader currently, in addition to whatever is in the PDF document itself, the user can cmd- (minus) to fold the document to show only headings, repeating to show increasingly less levels and cmd+ to fold back out or clicking on a heading to ‘jump’ to that section. This happens if the headings are encoded in Visual-Meta.

Easy to build or currently possible views which the user can invoke with a keyboard shortcut: The user can also hit ’n’ to see headings (if there are any) and all the Names in the document or ‘g’ to see headings with glossary terms. Some sort of keyword lists can also be employed.

Introductory aids are both the first thing a user sees and where they will go back to unless they are reading the document linearly and are therefore different from views, as discussed above. I imagine a document being opened and user going into full screen (it helps me think about this cleanly). Here are some options which can be shown but quesitons have to be asked if this is what they will see when going to top level/first page again of it the chosen list will appear. A major question is what the user should see on going to the ‘first page’ or over view again; the options such as below or the previous option, with an option to change the option?

• Author Name (first/last)

• Title Alphabetical/Bound Order (following the headings in the PDF)

• Geographical (if coded for this by author birth/residence)

• Length or article

• Keywords Clouds/Lists


What we are aiming to do with these interactions is to help the user decide what to read next.

Changing the document

One function should be for the reader to be easily able to have the system mark what they have read (in a way that can be easily toggled back), and for the user to mark articles they don’t find interesting and those they do find interesting. A menu item for ‘Annotate’ at the top of the screen could give easily (Fitts’ Law) access to ‘Like’ (keyboard shortcut ‘l’) and ‘Dislike’ (‘d’) which will be applied to the section shown on screen (based on headings, so no text needs to be selected). The Disliked articles could then be moved to the end of the table of contents, and slightly greyed out, also in the document itself. Why not? This could be stored in a Visual-Meta appendix.

Changing view (based on what’s on screen)

A command ‘Find Similar’ (’s’) could be used when reading a section and the system looks at the keywords in that section and shows, table of contents style, what other articles are similar, including showing the relevant keywords.

Conclusion for today : See more Views, make Views more accessible

Thinking about the table of contents as being introductory may not be useful, since changing it would require the system to know where the ‘printed’ table of contents is (since these books/documents should be readable in any PDF reader) and deleting those pages in order to show other options.

I therefore think we should continue the focus on navigation view actions for the user and annotations which are not just on the surface, but which change how the document is presented, such as the Like/Dislike approach.

How can we make the interactions pleasant? How can we take them out of the menubar? People just don’t go there much, me included, I think partly since it’s a bit hidden and partly that it contains a lot of boring, seldom used options. When working in something like Photoshop though, it is used, since there are so many commands keyword shortcuts can’t really use used for all of them.

The interactions we have, which people are used to, are spacebar to advance ctrl-click for tools. We can easily build a contextual menu on selection, but what about full page or full document interactions?

Of course, select heading could show like and dislike commands. But who would consider selecting menu text?

Maybe move cursor to the bottom of the screen to reveal a toolbar, which clearly shows keyboard shortcuts, in the style of Author maybe? How about if this also shows on selection (instead of a toolbar close to the selection), so that the user is encouraged to learn the keyboard shortcuts?

Published inReaderThoughtsUpdates

Be First to Comment

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.