isambard » design

UI Rule #92 – Don’t sacrifice the useful to fit your design

steven — Mon, 30 Jan 2012 04:15:58 +0000

Everybody needs a lego moleskine. Comparison shopping at the UK Book Depository proved troublesome because they decided to cut the product title short, removing the information that actually differentiated the products being chosen:

Hard to tell which one to choose when everything you want to know about the choices is unavailable. Should I get the “Lego Y..” or, mmmmm, the other “Lego Y..”?

Compare to Amazon, who manage to fit the full name in without issue:

If you’re going to allow a certain number of characters for a value, assume all of those characters may be important at some point. And make sure somewhere on your interface you let them all get their moment in the sun.

Adding a table of contents to your ePUB

steven — Tue, 12 Apr 2011 04:18:30 +0000

With ePUBs it is straightforward to add a table of contents to your book, allowing your readers to quickly navigate within your content. Interestingly how you do it is not a part of the ePUB specification itself, but highlights ePUB’s development from earlier digital book initiatives.

This article assumes you are creating/editing your ePUB source content directly. If generating an ePUB via a development tool (eg Pages, InDesign) then it can automatically generate the TOC for you. However even if doing so this article will help describe what is being built for you.

To help, I’ve included a smorgasbord of sample ePUBs to demonstrate how tables of contents are included. There’s a basic book (single level/standard TOC) as well as books with 2, 3, 4, or 5 level TOCs.
Download the one you want or take the whole pack. Note that because WordPress considers EPUBs a security risk, they’ve all be zipped.

Do I need to do this?

A table of contents is optional (your ePUB is valid and usable without one). What’s more how it actually presents for your readers is dependent on the reader. As such you should decide for each book, and your target market, whether worth the development effort.

How do I do this?

Adding a table of contents to your ePUB has two key steps:

Creating a valid .NCX file
Including the .NCX file in your book

Let’s work through these steps in turn.

Creating a valid .NCX file

The .NCX file defines your table of contents. There’s no rule about what filename to give it, but the default option for most eBooks appears to be TOC.NCX. So we’ll assume we’ve called it that too.

The definition for your TOC.NCX file is not part of the ePUB specification but is instead maintained by the DAISY Consortium and co-opted by IPDF who manage ePUBs for us. Browse the detailed specification and see if you can find out what NCX stands for.

In essence an .NCX file is an XML file. It lists the elements for your table of contents within a simple and standard framework:




	-- insert required metadata

DOCTITLE
DOCAUTHOR

	-- insert required navigation structure

Copy that and use as the basis for your TOC.NCX, while we fill in the missing bits: metadata, title, author, navigation structure.

(1) insert required metadata

Every .NCX file needs to define four metadata elements:

dtb:uid – this is the unique ID for your publication. It needs to match the ID given in content.opf.
dtb:depth – this is the number of levels in your TOC. Normally this would be 1 but you can add more levels – see hierarchical contents below
dtb:totalPageCount – this is not used: set to zero
dtb:maxPageNumber – this is not used: set to zero

For example, here’s the .NCX header for a standard table of contents with only 1 layer of entries.

(2) record title and author

The document title and author should match those recorded in the main metadata within content.opf (DC:Title, DC:Creator respectively). Some readers may reference these values when displaying the contents, although those in my limited test suite all seem to ignore these values and focus on those in content.opf.

In the sample ePUBs included with this article I deliberate added “(NCX)” to the end of the title and author in each .NCX file. Just to see if/where it appeared. Never did. But your mileage may vary.

(3) insert required navigation structure

The navMap is where the entries in your table of contents are defined using special XML elements called navPoints.


     Text to show in the table

The playOrder is numeric, indicating the sequence that the content elements should be traversed in when navigating. Note that this does not need to match the order you list them (and they appear) in the TOC. Nor does it need to match the sequence in the section of content.opf.

My testing (and the OPF specification) indicate that the playOrder is not used to determine the sequence content is browsed. When users move through the content sequentially, this sequence is defined by the element in content.opf. However, even though playOrder is not used, it is recommended that meaningful values are recorded “just-in-case”. It also ensures your ePUB validation, if using epubcheck, will be successful.

The text will present as entered in your TOC; be mindful that not all readers will have a lot of room so don’t make the entries too long.

The URL needs to be the reference to the file/location that is the target of this TOC entry. This will be the filename if you have created separate chapter files. Else you could reference separate sections within a single document via anchor tags.

For example, here are sample entries from the start of one EBook.



  cover
  


  preface
  


  credits
  


  Chapter 1 - Background

Note: If using anchor tabs, the other end of the link needs to be to an ID, not name tag. Read this for the explanation.

Including the .NCX file in your book

Only two small changes are made to your existing eBook to include your .NCX content, both made to content.opf:

add your TOC.NCX file to the ebook manifest. Application type needs to be
application/x-dtbncx+xml
add a reference to the new TOC.NCX to your ebook spine. This is added as an attribute in your tag:


  
  ...



  
  ...

That’s it. Save CONTENT.OPF, build and test.

Next steps

Once you’ve mastered the basic table of contents, you’re ready to investigate some more advanced options:

hierarchical contents

You can create multiple levels in your table of contents simply by nesting your navPoint elements.

...

          Chapter 1
          
Section 1
          
Section 2
...

Don’t forget to work through the playOrder values to retain a logical sequence to your content. Even though not sure who/where these values are used

How hierachical contents are displayed or navigated depends very much on the reader. It also appears to vary how many levels of content are supported. The standard itself sets no limits (or tells you what to call them: chapter, part, section, ..). However mileage may vary with different readers so don’t go overboard. The following table shows results with the two readers I spend most of my time with: Adobe Digital Editions (ADE) and iBooks (on the iPad). The two columns for ADE show the default view (when first opening your book) and the expanded view.

single level (basic book)
two levels
three levels
four levels
five levels

Notice:

for iBooks, it gives up after 2 levels of contents. Unable to find anything official that states that’s a limit, but if aiming for that platform I’d stop at 2.
for Adobe Digital Editions, the menu gets a little confused at the deeper levels – notice at 5 levels of contents the first level does not appear. Not sure if anything can be done to fix that, but also reason to avoid going that deep.

The above images are taken from the sample ebooks included with this article. Feel free to use to test how well supported in your chosen reader.

multiple tables (pageLists and navLists)

The standard table of contents is defined within a navMap. This is the complete, logical structure of your book. However the .NCX specification also allows you add two additional types of references to your TOC:

pageList – use if needing to offer navigation by page (rather than topic/section). Your ePUB can only include one pageList, and it cannot be hierarchical – one layer only.
navList – use if wanting to offer other any other arbitrary collection of topics, for example a list of illustrations or a collection of chocolate recipes taken from your complete recipe book. You can have as many navLists as you want, although they too can only be single level. An additional element, navLabel, can be added to give a title to your collection.

The steps involved in defining and including these tables is complex enough to warrant their own article, coming soon.

Conclusion

A table of contents is a valuable addition to most books, particularly non-fiction or reference titles. Adding one is reasonably simple, and thus worth the effort. However keep to the basics if wanting to be functional in the widest range of readers.

Quote of the week (20 December)

steven — Tue, 21 Dec 2010 01:02:17 +0000

From William Morris (Beauty of Life, 1980):

If you want a golden rule that will fit everybody, this is it. Have nothing in your houses that you do not know to be useful, or believe to be beautiful.

Quoted by Donald Norman in Emotional Design, 2004.

E-Learning as coffee break

steven — Fri, 08 Oct 2010 04:27:16 +0000

Since you cannot have a decent idea without a manifesto, here’s one I prepared earlier for a suggested initiative for e-learning for a current client.

Concept is to develop and offer a library of short-n-sweet e-learning lessons on topics that may be of value. The shortness comes from enforcing a 5-min time limit, being the time needed to sit down and drink a cup of coffee (hence the coffee lessons name). But that shortness also comes from enforcing a time-limit on production. These should not be epic productions, more as labours of love from those of us wanting to share our knowledge but only being able to find occasional moments between projects to work on them.

What that means for the producer is firstly that anyone can do it, and secondly that we can afford to be smarter about the tools we use to make our content quickly. For example:

use a rapid e-learning tool and a simple template to plug in content
use your computer’s built in webcam to capture an introduction video or content describing key points
use Captivate or other screen capture tools to demonstrate a process
use audio recording to easily add a voiceover to content, etc

In this I’m inspired in part by the dogma school of film-making that deliberately enforced constraints over the film production process. Putting similar limits on producers encourages us all to produce (you don’t need the fancy tools or skills, because you don’t have time to use them). Which can help produce a wide variety of simple skills. Having our coffee lessons available is a growth exercise for both the learners (any of us) and the teachers (again, any of us).

Having helped assess a few people’s presentation/training skills where they have to pick a topic to present, obviously the key to a coffee lesson is picking a topic suitable for the 5 min limit. You’re not going to run a coffee lesson on “InDesign” for example. But you could run 5 mins on publishing an InDesign book as an ePUB compatible with your internal environment, for example.

As a follow-up a colleague has just noted that for a lot of general skills these coffee lessons already exist. Just search Youtube and you’ll find short-n-sweet videos on a plethora of skills. However what BYO provides is the ability to provide content specific to your organisation, the option to track usage (by offering via your LMS), and of course the experience in developing for yourself.

Quote of the week (27 September)

steven — Wed, 29 Sep 2010 02:50:29 +0000

From Joel Spolsky, quoted on UX Myths, found via Barbarian Blog:

Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

Quote of the week (6 September)

steven — Mon, 06 Sep 2010 04:19:47 +0000

An intriguing comment in metafilter surfaced by Simon Willison.

If you are not paying for it, you’re not the customer; you’re the product..

Quote of the week (19 July)

steven — Mon, 19 Jul 2010 02:45:02 +0000

From Henry Ford:

If I had asked people what they wanted, they would have said faster horses.

Interesting take on the need to not be too blinded by the status quo when looking to be innovative (although read Luke Hohmann’s clarification that this not should be taken to mean “ignore your customers”). More to get beyond what the customer says they want (framed in what they’re used to, or aware of) to what the real need is.

Quote of the week (30 November)

steven — Sun, 29 Nov 2009 11:08:12 +0000

From Seth Godwin:

If you’re getting feedback, realize that the person must care a lot to have sent it.

Quote of the week (19 October)

steven — Sun, 18 Oct 2009 20:48:53 +0000

From Antoine de Saint-Exupéry.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Quote of the week (12 October)

steven — Sun, 11 Oct 2009 20:47:27 +0000

From Dare Obasanjo:

The bottom line is that a lot of the time it’s OK to create a solution that solves 80% of the problem. Always remember that shipping is a feature.

Quote from an article: Duct Tape Programmers and the Culture of Complexity in Software Projects