[Tfug] OT: E-Book position representation

[Bexley Hall]

Hi, John,

> I got a lot of good feedback from my previous ebook reader
> question concerning useful features.  And, as my former userbase
> continues to be as silent as the night, I was hoping to bug you
> all once more.

<grin>  Fear not!  They will regain their voices once you have
a finished product -- in an intensity directly proportional to
the immutability of your implementation!  :-(

(always amazing how little people know about what they WANT;
yet how *much* they know about what they DON'T want!  :<  )

> As I begin to plan more on what the next Weasel Reader
> application will be like, I am again facing the question
> of how to address the reader's position inside the text.

A big, blinking sign:  "You are here"  (lavatories are on the
lower level adjacent to the food court...)
 
> In the current Palm OS incarnation, I went with a strict
> percentage indicator.  Your current position in the text might
> be 42.67% and the list of bookmarks might contain "Chapter 1"
> at 0.35%, for example.

Short answer:  use UTF-16 instead of UTF-8 at *some* level in
your data representation!  :>

<frown>  I wonder at the utility of reporting (and accepting as
input!?) fractional percentages.  As documents get larger, those
fractions lose precision (so, why are they better than just "XX%"?)

> Personally, I thought this was a good way of doing things. 
> Internally, all
> position information is stored as a character/byte offset
> into the book and
> these are easily converted into percentages.  And on Palm
> OS, users have a
> stylus so entering in "5.72" (percent) is a
> relatively simple matter.  Also,
> most users move around in a book via bookmarks so the
> dialog where a location
> is entered and moved to is (I believe) not so frequently
> used.

Probably true.  I suspect that is more useful in *your* API
(as an implementaion detail)
 
> Looking forward, though, the next version will use Unicode
> for book texts.  I
> can still use character offset, though seeking might be a
> bit more
> problematic.  Even a byte offset should still be okay.  The
> percentage numbers
> will still work and deliver the user to the same location
> each time, though
> they may be somewhat less accurate in that 5% of bytes
> doesn't necessarily
> equal 5% of the characters.

Since *you* initially reported the position in these terms,
you can also store the corresponding "character count" at
which that "percentage" (offset_t) was achieved.

Of course, the first time you see a book, this is a simple
calculation:  0% bytes *or* characters!

I recognize seeking to a percentage *byte* offset is considerably
easier than "walking" to that same *character* offset.  But, you
can do both:  spawn a task that starts counting characters while
you, meanwhile, "jump" to the "byte offset" and begin formatting
the page.  When the other task finishes, it can reposition
the "cursor" more accurately (I realize this could result in
a large shift, potentially.  But, if you already have the
"character offset" metric *stored*, the problem goes away).

This allows a user a moment to look at the page and refresh his
memory as to why this place is (?) significant.  Since this API
("UPI"??) would be shared with the bookmark feature -- i.e.,
not just the "last position stored" -- it is possible that the
user will decide that this is NOT where he wanted to be.  So,
he returns to the bookmark menu and makes another choice, etc.
(you then have to decide the most efficient way of redirecting
that background task's execution in light of this new goal).

[frankly, I think if you also store a "character offset"
associated with each "position indication", you don't need this
extra complexity to be able to give the user a character
oriented position indication.   <shrug> ]

> But, it could be an acceptable tradeoff.
> 
> I had always thought that "page" numbers made no sense in an
> electronic format unless that format specifically contains pages
> (PostScript/PDF for example).  But most other reader programs 
> continue to use that paradigm and users occasionally ask for it
> or wonder why it is not present.

Agreed.  But, I suspect it gives users an easier way to
relate to their position than your "more precise" percentage
indicator.

For example, if I am 123 pages into a 240 page book, I know I
am "about halfway".  Or, "less than half remains".  Or, "Only
about 120 pages left", etc.  For those of us who grew up with
paper, I think this is more in tune with how we *think* of
reading a book.  "I've only got 6 more pages to go" vs.
"I've only got 14.57% remaining".  The latter is meaningless
to me *except8 as a pure "relative position indicator".  It
doesn't reflect the size of the document so I can't use it
to gauge my investment, commitment, etc.

We have our own concept of what a "page" is.  Even if the
document redefines it for us!

E.g., if I read a technical journal with lots of multicolumn
fine print, my page size notion is much larger than when
reading a paperback novel.  Reading that same novel in a
hard cover edition gives me yet another notion of page size.
Yet, since I know how many pages there are in *this* particular
document, I can quickly form a gut feel for my progress through
the document.  "I read about a page per minute", etc.

[N.B. For some types of documents, this might be a valuable
metric to compute and convey (in some form) to the user.  E.g.,
"expected time remaining"  <grin> ]

> Now, on a finger-touch interface, entering in percentages
> might be slightly
> less convenient, I suppose.  I can image providing the user
> with a slider to
> rapidly move through the text which will greatly lessen the
> number of times a
> user needs to directly type in a location.

Such a slider needs to have a "transmission" associated with it;
the user needs to be able to downshift to get more precise
control as well as upshift to get coarser, more rapid movement.
With each movement, if you could (ideally) repaint the screen
so he/she could "get their (relative) bearings"...

[You could use speed of gesture to determine which "gear"
you are in]

> So... any thoughts about this?  Percentages or page
> numbers?  Maybe some
> altogether different representation?  Which method is best?
>  Maybe it should
> be a user option on how to display position?  Keep in mind
> that "book" layout
> is secondary.  Chapters/sections are an *optional* feature
> of a book and are,
> I think, best delivered to the user as bookmarks.

You always need to have available (to yourself?) some scheme
that operates in the absence of any "document structure".
E.g., your position in a "pure text" file. 

I would argue for a character based metric instead of the
"byte offset" approach.  I (personally) think the added
cost to the developer is far outweighed by the intuitive
nature of that metric.  I believe you are also far less
likely to "surprise" (Principle of Least Surprise) users
if they *see* 10 characters on the screen, the cursor on
the 3rd character and the position reported as "30%"
REGARDLESS OF THE PARTICULAR CHARACTERS PRECEDING AND 
FOLLOWING THE CURSOR.

For example, the sequence:
   \u006E \uFE22 \u0067 \uFE23 \u0021
would appear as three glyphs.  If the cursor was positioned
after the second of these, the user would consider it "67%"
yet a byte offset approach would report 80% (!).  (I haven;t
looked at the UTF-8 representation but imagine it is even
more skewed  :-/ )

Of course, this is a degenerate example.  But, intended to
illustrate that some languages would have inherent biases
in their "reporting accuracy" based on the relative frequencies
of one-byte, two-byte, three-byte and four-byte UTF-8
representations.

[I'm sure you've thought about this.  Just consider that
you can't control the material that is being *read*.  Are
you willing to penalize a user who happens to read lots
of technical documentation with fancy mathematical symbols
(which don't fit neatly in single bytes) just for the
sake of implementation ease?  <shrug>]

Given some "core" position representation, I think you should
also take advantage of whatever *other* structural information
is present in the document to convey to the user his/her
position *relative* to this framework.

E.g., if you have page numbers, then report that alongside
the "core position" information:
      78%    Page 9 of 43   (hey, it's possible!!  :> )
Or, "subsection" information:
      78%    Page 9 of 43
             Section 5.3.0.1
Or, any other "scale" that you have available.

I.e., if the creator of the document went to the trouble of
including this structural information, assume there is some
significance to it and try to use it to give the user a
framework in which to judge his "true position".

Since you have a GUI available, you could opt for some
abstract representation of the document (i.e., one that fits
on a single "screen") that outlines the structure and shows
the user's position -- along with those of any additional
bookmarks? -- using some legend.

This could also serve as a means for letting the user
position himself in the document -- give him some sort of
"zoom" control so he can see regions in greater detail
(this allows the structure of the document to be as
fine-grained as the author intended without compromising
the presentation based on the characteristics of the 
GUI hardware)

<shrug>  Just my $0.03

> Thanks for your time!

Holly Hapidays!
--don