OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS