Tag Archives: design

Quote of the Week (28 November)

From Antoine de Saint-Exupery. An oldie but a goodie:

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away

Brought to mind recently after working on a website for a client. Against my advice they loaded up the homepage with lots of distracting content. Only for us then to spend the next several rounds of editing slowly removing each of the extra pieces.

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

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.

Shipping is part of the product cost

When shopping online, while comparing product costs is important, often what I need to compare is the total ‘cost-to-the-door’. This is particularly the case when shopping at overseas sites – something those of us in Australia do most of the time.

Different sites/vendors have different rules about shipping. And the variations in shipping options can easily negate any variation in original price.

So as a general request to web store developers and vendors, please allow visitors to determine the shipping cost prior to checkout and/or prior to registration. Don’t make me sign up and complete all my mailing details before I can determine the actual price.

How to do it

Really have two options if wanting to be upfront about shipping costs.

(1) Include shipping in the initial cost

This is the UK Book Depository model. One price is quoted for any item. And that price includes delivery.

Quoted cost = final cost to my door. Simple.

Note technically the site states delivery is free worldwide. But we all know that really means they just include it in the initial price. That’s why they’re not the cheapest on first quote. But the convenience of knowing the final price up front far outweighs any interest in comparing with other stores. I’m not going to search for the same book in Amazon (for example), add to basket, check out, log in, enter shipping details, etc, just to get a price to compare with the first number offered by UK Book Depository.

Another consequence of including delivery in the initial cost is it removes any order friction around postage optimisation and bundling. For example, Amazon postage appears to get cheaper the more books I order, with the consequence that if I want a book I’ll add to my basket but not actually order until a few more items in there to lessen the postage overhead. But then what actually happens is they sit there long enough for me to lose interest and remove them. With UK Book Depository there is no benefit in bundling orders together. Which means all orders get submitted immediately. Before I’ve had time to reconsider.

(2) Provide a mechanism to quickly determine shipping costs

Simple tool to estimate shipping. Close enough is good enough at this stage of the purchasing process.

If shipping cannot be bundled, then allow me to calculate (or at least estimate) the shipping before entering any personal information. How much do you need to estimate shipping? Nothing more than a zip/post code and/or country. And I won’t be upset if I have to enter that twice; once to estimate and once to actually checkout.

For example, look at how Think Geek does it. As soon as I add an item to my basket, I get a simple shipping calculator. This gives me a figure close enough to the final value that I can immediately determine whether to progress with the order or not.

How not to do it

Already stated what not to do: don’t make me complete all my order details before I get a figure for shipping.

Don’t make me sign my life away before quoting postage.

To that essential rule, I’ll add an extension particular to us overseas buyers. Don’t make me complete all my order details before you tell me that you cannot ship the requested item to me. Too often some protectionist racket prevents requested items being sent overseas. Nothing more annoying than completing your forms before being told “sorry, not available in your country”.

Adding a table of contents to your ePUB

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:

  1. Creating a valid .NCX file
  2. 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:

<?xml version="1.0" encoding="UTF-8"?>
  PUBLIC "-//NISO//DTD ncx 2005-1//EN" 
	-- insert required metadata
	-- 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.

	<meta name="dtb:uid" content="a897sad23fd23ds" />
	<meta name="dtb:depth" content="1" />
	<meta name="dtb:totalPageCount" content="0" />
	<meta name="dtb:maxPageNumber" content="0" />


(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.

<navPoint playOrder="x">
     <navLabel>Text to show in the table</navLabel>
     <content src="url" />

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 <spine> 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 <spine> 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.

<navPoint playOrder="1">
  <content src="00-cover.xhtml" />
<navPoint playOrder="2">
  <content src="10-frontis.xhtml#preface" />
<navPoint playOrder="3">
  <content src="10-frontis.xhtml#credits" />
<navPoint playOrder="4">
  <navLabel><text>Chapter 1 - Background</text></navLabel>
  <content src="chapter1.xhtml" />

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
  • add a reference to the new TOC.NCX to your ebook spine. This is added as an attribute in your <spine> tag:
  <item href="toc.ncx" id="ncx" media-type="application/x-dtbncx+xml"/>

<spine toc="ncx">
  <itemref idref="chapter1" />

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.

<navPoint id="navpoint" playOrder="1">
          <navLabel>Chapter 1
          <navPoint playOrder="2">Section 1</navPoint>
          <navPoint playOrder="3">Section 2</navPoint>

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


  • 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.


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.

E-Learning as coffee break

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)

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 (19 July)

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.