Re: [xml-dev] undermining hierarchies in books (was Re: [xml-dev] How to do XML design, per Jackson Structured Design)

On 11/27/2013 11:48 AM, Simon St.Laurent wrote:
> [Dare I open a multiple-Balisage-paper-length topic the day before a 
> holiday?  I guess so.  And alas, I'll be in Germany for next year's 
> Balisage, so... and again disclaimer that these are my opinions, and 
> my employer would be surprised to hear at least some of them.]
>
> On 11/27/13 10:31 AM, Michael Sokolov wrote:
>> In my view for text (hypertext, whatever), hierarchies + some light
>> linking seems to be a pretty good model.
>
> Kind of.  Or, perhaps, wouldn't it be pretty to think so?
>

> We've known for years that readers are less interested in our 
> hierarchies than we are.  There are some readers who use the Table of 
> Contents, the purest hierarchical guide to the book, as their primary 
> approach.  There are some readers who plow through the text as a 
> linear stream.  There are many many readers who use either the index 
> or search tools to navigate, throwing off the guidance of hierarchy as 
> they quest for particular nuggets of information.

The beauty of a well-structured book is that a reader benefits from the 
structure without being directly aware of it. We're all taught to to 
structure a book using an outline form as an aid to planning and 
thinking.  Once the book is complete, the table of contents may never be 
used, but its influence remains.  The sequence of the chapters, and the 
development of ideas in a well-written book forms a logical succession 
that had its genesis in that outline form.  I don't know how deep a 
hierarchy of sections is required for this, not having actually written 
any books, but I suspect that creating outlines is still a valuable 
process for organizing thoughts?  I certainly use it for the software I 
write.

Of course books with chapters and sections are not the only kind. Some 
books, as you point out, are not intended to be read cover to cover.  
This is why such books have always had indexes.  For reference books and 
how-to books and cookbooks, the index (or entry list) is often the most 
useful, or only guide. In the online era, traditional book indexes are 
largely obsolete due to search (yes an indexer can add value, but 
marginally, and indexes don't translate well online, except as 
augmentation for search).  Cookbooks and technical books occupy a 
strange middle ground between narrative and reference though.  People do 
*read* them, not simply *use* them.

In safariflow.com, we've been experimenting with deconstructing the 
traditional book structure by presenting a chapter-primary user 
interface; the books themselves are de-emphasized.  But users missed the 
signposts.  We had to add back the book covers, and provide more obvious 
access to book-level metadata (author, title). I think the book covers, 
and the authors, help to situate the work in a textual landscape.  One 
thing we always try to do in a big-text website is to give the user a 
sense of scale. If we decompose our books into chapters and present a 
site as an undifferentiated mass, we lose the middle-ground. The table 
of contents is of course part of that.  I find the TOC to be an 
invaluable guide to a technical book - a good one lets me know at a 
glance what topics will be covered, and at what level, so I can evaluate 
the suitability of an entire book.

And we are still producing books, not just atomized articles, or posts, 
or Q&A lists. Books explore a single topic in depth, in much greater 
depth than can be achieved in a blog post, and I would argue that 
readers need that, and will always need that. Even if they don't read an 
entire book or appreciate all the subtleties of the hierarchical 
arrangement of chapters and sections, the fact that the writer (and 
editor) have plumbed those depths and arranged their thoughts according 
to a grand plan informs the character of every part of the work.  It 
would not be possible to just write the best chapter of a book leaving 
out the rest.

So I think that book production, at least, still requires at least some 
degree of hierarchy.

When we publish and disseminate the book, we deconstruct that hierarchy. 
To the brutal search engine machine, the documents of interest are the 
web pages, more or less.  We choose some proper granularity like 
chapters, break the books up there, index them. (Thus a random-access 
reader can jump in anywhere, read as much or as little as she chooses, 
navigate forwards or back in the same book-stream, or sideways into 
another, via recommendations or hyperlinks, etc.). But in the database, 
we don't really need hierarchy any more in the markup.  Of course we 
need textual markup like lists and tables and bibliographies, and inline 
markup for text styling, but the grand hierarchy of the book persists 
only in an elaborate system of hyperlinks, and in the TOC.

So do we need the hierarchical markup then, if we are just going to 
eventually throw it out?  I think so.  Primarily for the concept-forming 
process, but it also provides a convenient mechanism for delivering the 
content.  EPUBs get delivered as essentially a list of chapters plus a 
TOC, and publishers use anchors to reference anything below the chapter 
level.  It's messy and error-prone; I tend to think a single 
hierarchical document would be better, but then rendering engines would 
have to know how to deal with that. Really I see this loss of hierarchy 
as a triumph of machine concerns (ease of indexing and optimization for 
presentation) over human concerns (conveying concepts in a clear and 
fluid manner to a reader).

In brief: good books are written from a point of view. The point of view 
forms a hierarchy, naturally. Readers and publishers and websites and 
search indexes and recommendation systems and so on bring other points 
of view to bear, but these do not abnegate the writer's perspective, 
they complement it, are layered underneath, on top of, and alongside it.

-Mike