Pop-up notes for iPad

[theducks]

@psymon
my 2 cents:
Consider the Performance hit on low horsepower devices.

Foot Notes: Jumps within the same file

End Notes: Needs to load/replace and render the current file (then do it in reverse to return) the bigger the file, the longer.
who says the endnote file needs to be 1 monolithic file? KIS (Keep it smallish ), make the break at a logically appearing point
If your per-chapter notes are long. notes01, notes02...


If Hitches opinion differs, listen to her. She makes a living doing this

[mrmikel]

It can work faster in lower power devices to put them as endnotes, at the end of each chapter and put links above it allowing you to skip over the endnotes. Some of the works I have done offer go to next chapter, go to previous chapter and go to Table of Contents.

You can download the Sony reader library which will display epubs as they will appear in smaller format readers, which might give you an idea of things.

[Psymon]

Originally Posted by theducks

End Notes: Needs to load/replace and render the current file (then do it in reverse to return) the bigger the file, the longer.

Um, I don't know about other devices, but on the iPad it loads/renders the whole, entire book all at once -- you can see it happening at the bottom of the screen -- and if/when I change the font size or orientation, you can see it do it all over again. So I can't understand why that would be an issue -- I'm not jumping to an entirely different "book", just to a different location within the same book that has already loaded completely.

who says the endnote file needs to be 1 monolithic file? KIS (Keep it smallish )

Well, that's easier said than done, if the book is meant to have 500 or 1000 footnotes (or endnotes or whatever). I guess what I'm trying to avoid by putting all the notes in a separate file is having TONS of pages of notes in-between each chapter -- people might want to just actually read the book, and not all the notes. And yeah, I know that it's easy enough to just go to the ToC and jump over the notes to the next chapter -- but if ALL the notes can be put in a separate file (at the end of the book), then wouldn't that be nicer?

EDIT: Oops, I just read mrmikel's reply, and see how it actually addresses some of what I just wrote.

Originally Posted by mrmikel

It can work faster in lower power devices to put them as endnotes, at the end of each chapter and put links above it allowing you to skip over the endnotes.

Just how "low power" are these "lower power devices"? I mean, in this case we're talking about a book that isn't full of illustrations or all kinds of fancy formatting that needs to be rendered over and over (with each "load"), but basically just a bunch of text files -- which, as I said, have already loaded/rendered when you open the book. All you're doing when you jump to/from a note is move to a different place in something that's already loaded/rendered.

Some of the works I have done offer go to next chapter, go to previous chapter and go to Table of Contents.

Oh, that's a good idea, if I did end up putting the notes at the end of each chapter -- seems so obvious, I should have thought of that, too! I still think it would be nice(r) if all the notes were at the end of the book instead, though.

You can download the Sony reader library which will display epubs as they will appear in smaller format readers, which might give you an idea of things.

Oh, cool -- I'll go look for that! It's exasperating, though, having to download/install so many different programs just to test books in -- never mind having to test one's books in so many different programs. :/

[theducks]

There are many 'Low horsepower' (dedicated reader) devices are still in use.

Sony, Hanlin ... using old versions of MRSDK (the common reason for 260K file size. Maxing that size is really slow to render and a good reason for chapter/file)

Emulating on a PC only shows visual problems (and sometimes misses on those ). There is no substitute for the Target device.

[Psymon]

Originally Posted by theducks

There are many 'Low horsepower' (dedicated reader) devices are still in use.

I can understand that, but just how god-awfully "slow" are these devices in question that they can't even render what amounts to a simple text file, with little or no graphics or fancy formatting or anything? And wouldn't those people using those devices be used to so, so many ebooks, web pages, etc. taking time to load/render anyway (i.e. it's just par for the course for them)?

Emulating on a PC only shows visual problems (and sometimes misses on those ). There is no substitute for the Target device.

I understand -- that's nice, if you can afford it, and don't mind having a ton of devices lying around for nothing else than testing purposes. The former is more of an impediment to me than the latter, of course. :/

[theducks]

Originally Posted by Psymon

I can understand that, but just how god-awfully "slow" are these devices in question that they can't even render what amounts to a simple text file, with little or no graphics or fancy formatting or anything? And wouldn't those people using those devices be used to so, so many ebooks, web pages, etc. taking time to load/render anyway (i.e. it's just par for the course for them)?



I understand -- that's nice, if you can afford it, and don't mind having a ton of devices lying around for nothing else than testing purposes. The former is more of an impediment to me than the latter, of course. :/

a Maxed out TEXT file 30seconds to over a minute. This repeats if I change (zoom) the font. Once the file is rendered*, in-file page flips are decent.

*render is pre-parsing the whole file in these cases, not just what is displayed on the screen

You need lots of devices to provide odd lumps for cats to sleep on Laptop keyboards are only so-so

[Psymon]

Originally Posted by theducks

a Maxed out TEXT file 30seconds to over a minute. This repeats if I change (zoom) the font. Once the file is rendered*, in-file page flips are decent.

I know, but like I said, if you have a "slow" device, then aren't you used to having to wait for things to render all the time? Why sacrifice user-friendliness for the vast majority of people out there for those few that have older, slower devices?

Don't get me wrong, I do understand the whole concept and motivation surrounding that -- I started doing web design in the mid-1990s, when MANY people were still on dial-up connections, with smaller monitors, etc. -- but at some point in the development of things there has to be a tipping point where you stop going to such extremes to appease those few (and increasingly fewer) people with comparatively "ancient" machines/devices.

You need lots of devices to provide odd lumps for cats to sleep on Laptop keyboards are only so-so

Ha ha -- I don't have a cat, so that's not really additional motivation for me (never mind I can't afford it), but I can certainly see that they do have other practical uses, when they're not being used for testing.

[Tex2002ans]

Originally Posted by Psymon

[...] that is, a person clicks the little superscript footnote number (or however it's done) and then they get a little "popup note".

I just wanted to toss in a comment here on the "superscript footnote". A long time ago I settled on the slightly more ugly, but much more functional [##] footnote. This is more functional ESPECIALLY on touch devices, because the superscript numbers can get very tiny, and can get very hard to push with your fat finger on smaller font sizes.

Did you ever run into those websites where a damn popup ad comes up, and has that dastardly small little "x" in the corner that is impossible to click?

Giving it some extra space around it with the brackets makes it much easier to push.

For example, this:

In fact, firms were able to hire increased quantities of labor at the frozen wage scales and employment grew at the rapid rate of 4.2 percent per annum from August to November 1971.<a href="#fn1" id="ft1">[1]</a></p>

[...]

<p><a href="#ft1" id="fn1">[1]</a> Michael R. Darby, “The U. S. Economic Stabilization Program of 1971–1974,” in Michael Walker (ed.), <i>The Illusion of Wage and Price Control</i> (Vancouver, Canada: The Fraser Institute, 1976) pp. 136–37.</p>

Is easier to click than this:

In fact, firms were able to hire increased quantities of labor at the frozen wage scales and employment grew at the rapid rate of 4.2 percent per annum from August to November 1971.<a href="#fn1" id="ft1">¹</a></p>

[...]

<p><a href="#ft1" id="fn1">¹</a> Michael R. Darby, “The U. S. Economic Stabilization Program of 1971–1974,” in Michael Walker (ed.), <i>The Illusion of Wage and Price Control</i> (Vancouver, Canada: The Fraser Institute, 1976) pp. 136–37.</p>

If you still want a superscript, at least settle on the mix of both:

In fact, firms were able to hire increased quantities of labor at the frozen wage scales and employment grew at the rapid rate of 4.2 percent per annum from August to November 1971.<a href="#fn1" id="ft1">^[1]</a></p>

[...]

<p><a href="#ft1" id="fn1">^[1]</a> Michael R. Darby, “The U. S. Economic Stabilization Program of 1971–1974,” in Michael Walker (ed.), <i>The Illusion of Wage and Price Control</i> (Vancouver, Canada: The Fraser Institute, 1976) pp. 136–37.</p>

Also, avoiding superscript footnotes is generally a good idea for certain typographical reasons in HTML/ebooks (not messing with the line-height, the footnote can be rendered at the normal font size (think accessibility reasons)).

Anyway, this is one of those things that typographers/style guides will debate over, and it is a balance between the beauty/functionality of the text..... I tend to favor the side of functionality/readability over "beauty" any day of the week.

The most important thing is to actually get the information in the book ACROSS to the reader.

[Psymon]

Originally Posted by Tex2002ans

Giving it some extra space around it with the brackets makes it much easier to push.

<big snip>

That's not a bad suggestion, actually -- and I have seen books done with footnote markers done up like that, too (although generally they're done with superscript). I can see that that's more "clickable", though, for ebooks. I might consider doing that.

Also, avoiding superscript footnotes is generally a good idea for certain typographical reasons in HTML/ebooks (not messing with the line-height, the footnote can be rendered at the normal font size (think accessibility reasons)).

I don't know if this'll help anybody, but I ran into issues re line height, etc. when I was doing web design, and finally came up with some styling that seems to work great and not interfere -- and on top of that, the percentages are all perfectly conforming to/with the "golden section", and thus look good, visually, too.

If you do need to use superscript -- whether for footnote markers or for any other reason (perhaps you might want to have, say, the abbreviations for "Dr", "Sr", etc. written with the "r" in superscript, just to get fancy-schmancy) -- then maybe what I came up with will help others, too...

sup {
font-size: 76%;
line-height: 100%;
vertical-align : 38%;
}

62% for the font size would be more "perfectly" in line with the golden section, of course, but I found that a bit too small for readability in some cases/contexts, and thus went the next step up (still within those "golden" parameters).

[Hitch]

Originally Posted by Psymon

<big snip>

That's not a bad suggestion, actually -- and I have seen books done with footnote markers done up like that, too (although generally they're done with superscript). I can see that that's more "clickable", though, for ebooks. I might consider doing that.

If you're doing your own books, then I recommend it. Most of our clients want the superscripted numbers. But I personally like the more-clickable links.

I don't know if this'll help anybody, but I ran into issues re line height, etc. when I was doing web design, and finally came up with some styling that seems to work great and not interfere -- and on top of that, the percentages are all perfectly conforming to/with the "golden section", and thus look good, visually, too.

If you do need to use superscript -- whether for footnote markers or for any other reason (perhaps you might want to have, say, the abbreviations for "Dr", "Sr", etc. written with the "r" in superscript, just to get fancy-schmancy) -- then maybe what I came up with will help others, too...

sup {
font-size: 76%;
line-height: 100%;
vertical-align : 38%;
}

62% for the font size would be more "perfectly" in line with the golden section, of course, but I found that a bit too small for readability in some cases/contexts, and thus went the next step up (still within those "golden" parameters).

The line-height and the vertical align won't really work for Amazon (yes, I know that this is the ePUB sub-forum). and I think v-align is dicey at best. We've tried various solutions like that, with varying degrees of success.

Vis-a-vis the endnote, chapter-note issue. There are millions of low-power devices out there. Millions of them. In fact, "more serious" readers, as far as I can tell, seem to be more likely to have the low-powers, as well as also having tablets or tablet-like devices for other purposes. So it behooves you to keep those in mind at all times.

For a massive book, you might consider different endnote sections, to ameliorate the "load one giant endnote file" issue, as someone else suggested, Ch1 endnotes, Ch2 endnotes, or do the footnotes as, I think, mrmikel suggested, with jump-past links.

Vis-a-vis the other question, which isn't a bad one (I've asked it myself)..."how do it know?" That's an interesting question, isn't it? How does the device (say, a PPW) distinguish between the links in the TOC, versus footnote lines? My answer is, PFM, which means Pure Freaking Magic. Whatever the distinction is, it certainly seems to work. TOC items don't "pop up" as footnotes do.

Hitch

[Tex2002ans]

Originally Posted by Hitch

The line-height and the vertical align won't really work for Amazon (yes, I know that this is the ePUB sub-forum). and I think v-align is dicey at best. We've tried various solutions like that, with varying degrees of success.

Yep, I was going to comment the same thing. That solution won't work across many devices. At best, it would degrade into a small font footnote on the same line, at worst, it would cause some wonky madness with the line. I just settle on hideous in-line bracketed footnotes. Those won't break anywhere and are easy to read/click.

Originally Posted by Hitch

Vis-a-vis the other question, which isn't a bad one (I've asked it myself)..."how do it know?" That's an interesting question, isn't it? How does the device (say, a PPW) distinguish between the links in the TOC, versus footnote lines? My answer is, PFM, which means Pure Freaking Magic. Whatever the distinction is, it certainly seems to work. TOC items don't "pop up" as footnotes do.

Probably taking into account the Metadata (nearly everyone marks the TOC as "Table of Contents", it can probably know that links in there ARE NOT footnotes).

Then lets say it is NOT marked as a "Table of Contents" via metadata, but the thing is about >90% text inside of <a> tags due to heuristics... you probably know it should be treated a little differently.

I don't have a device that has this "pop-up footnote" functionality, but it would be interesting what it does on some of these books with linked Indexes.

Then for the actual footnotes, I am assuming some sort of heuristics approach which takes into account the length of the text in the footnote + the look of where the link leads to.

For example:

<p><a href="../Text/Chapter01.xhtml#fn1">[1]</a></p>

RED is likely not going to be very long at all (maybe 6 characters MAX) (Perhaps they also take into account superscript within a link as HIGHLY LIKELY it is a footnote?)

Since BLUE is also pointing to some sort of id, they will probably make an ok assumption that it is a footnote? Perhaps they might discount if the id uses the word "page" in there (so maybe an index might be excluded if it is pointing to #page123").

On the receiving end, it might use heuristics to tell

<p><a href="../Text/Chapter01.xhtml#fn1">[1]</a> Text Text Text.</p>

<p><a href="../Text/Chapter01.xhtml#fn2">[2]</a> Text Text Text.</p>

Or:

<p><a href="../Text/Chapter01.xhtml#fn1">[1]</a></p>

<p>Text Text Text.</p>

<p><a href="../Text/Chapter01.xhtml#fn2">[2]</a></p>

<p>Text Text Text.</p>

They could look at where the links are located (towards the very bottom of the HTML file? In its own separate HTML file?)

Anyway, Amazon has a fracking MASSIVE amount of books to sample. So they have A TON more data on what is footnotes and what isn't footnotes. Above is just how I would tackle it if I was coding it, and it would probably work pretty decently from the books I have seen.

[mrmikel]

I have a tablet, which I love and I have a Sony PRS-300. The Sony only needs to be charged every week or so. The tablet needs to be charged just about every day.

I prefer the 300 for reading, since the background is not glowing it is easier on my eyes. When we go camping, it is the 300 that goes with us, since it has about 300 books in it, which is way beyond what I read on any camping trip. Its cover has a little LED light built in, so I can use it at night much as one would use a book. If it died, I would want to replace it, not rely on a tablet for reading.

I think there are a lot of people like me. It does not work fast, but I do not read for speed, I read to relax. And I would be not pleased that someone says everybody has tablets, heck with old dedicated readers, making it take 5 minutes to load footnotes, some because of file change and the rest because of the very long file all at the back.

Revert to old rant: It is impossible to design a book for big tablets and e-readers and phones that makes any sense. If you design for the small ones, you skip the pull quotes, full page bio. inserts, etc that one expects in the large format, like a magazine. If you go for the big ones, you completely lose the thread of the story in a smaller device as your single page becomes 5 or more in a smaller device. This is not something which is readily or easily solved. Rant off.

Being the ornery cuss I am, I design for my little 300, since I am getting paid exactly $0 for anything I do with the readers. I kinda figure if I do a decent job of correcting mistakes, etc, then since it is public domain, anyone of a different opinion is free to download and turn it into the epub to serve as the example of the perfect epub for all time.

[Hitch]

Originally Posted by theducks

a

You need lots of devices to provide odd lumps for cats to sleep on Laptop keyboards are only so-so

For my One Twoo Wuv, Ducky:



(Now you guys can see how ancient my desk is. I had to move the 4th monitor from that end of the desk, because the two of them would NOT move from "their" corner.)

Hitch

[Hitch]

Tex:

I don't think it's the id. We have a lot of books that have internally linked items, for which each has an id, and they don't open up in pop-up. It's not the superscript, as near as I can tell. I concur, they have a crapload of material to sample. It's not the metadata, either. (See: I know what it ISN'T, but damn if I know what it IS.)

I suspect some type of quasi-interrogatory parsing. That's my best bet.

Hitch

[theducks]

OT
Why I have more than 1 computer (and keyboard)

Sebastian has to help