Highlighting linked text

[Doitsu]

Originally Posted by Hitch

The only alternative to this is to make the target ITSELF a link. This means--and many publishers are not enamored of this idea--making the linked target a blue, linked piece of text. OR, inserting something akin to a footnote, but now remember--you're working backwards. The reader would see the link location, but not know what it's for; if they click it, they'd go to the index.

On a related note, Sigil has an Index Editor that will automatically generate hyperlinked index entries.

[Julanna]

Hitch, you sound so worked up! I suspect this issue isn't worth that much angst.

I already know how an index will work in paper and the differences with ebooks. I also know how html works.

Your reply is actually full of good information that will come in handy for newbies who don't understand the mechanics of it. Should have been written up with a more helpful tone.

Making the target itself a blue underlinded piece of text is not appropriate, of course publishers are not enamored of it. Doing that only makes the target look like a link because that's what everyone is use to seeing after using the net ever since forever. And if it's only a target (and not a link back to the index) it's only blue underlined pieces of text. You'd have to put in a separate link back to the index. Possible, at this stage I haven't done that. On some browsers using the back button will take you back to the index, but not on all browsers. It's easy to make the target invisible by using different coding (thank you helpful mobileread people on a different thread).

Just to clarify, I'm only looking at a simply name index, but I suspect if my problems were solved it could be upscaled for large books with a complex index as well.

And when I say it's an overlooked opportunity I'm talking about the programmers who haven't yet worked out a solution. This isn't my area, I actually don't know how much work would be involved, but I suspect it hasn't been done because of the idea that search is enough rather that it not being possible.

The target text does not land at the top of the page in an ebook in any reader or software reader I've tested on, only on a html page.

The problem with the target not being blue underlined is that then the target can't be seen easily when the link is activated. It's somewhere on the page. (Which is how a paper index displays).

A solution to that could have been to have a temporary highlight on the target in an ebook when the link it activated, and that's what I've realised, on this thread, isn't possible with current html/css and ebook conversions.

And, actually, having multiple targets is easily displayed in the index using a, b, c etc. Looks good that way. The code part of the targets in mine also have letters that match. I use find so I don't miss an instance of a name and paste code down the page, just changing the letter difference as I go. I don't have trouble knowing where I'm up to and then I can create the correct number of links in the index just changing the letter on each.

And yes it is semi-painstaking. I've only done a small family history book. Working out a system helps (shrugs).

We could number paragraphs, and I've seen small ebooks that do that, but it is so clunky, especially so in a larger book, even if you use chapter no. and paragraph number. Clunky. And I don't like seeing chapter numbers in the text so they'd have to be invisible to satisfy me too. I may try this sometime.

As I said further up the target will not be on the top of the screen on an ebook reader or software (except by coincidence). This could be different in a .mobi or whatever ibooks use. I haven't tested those formats. It *will not* in an epub.

Ok, and saying again, I know it's the creation process. The creation process is what needs to change.

At this stage I don't care what publishers will pay for. Search is not as good as an index, an index is a structured finding tool that facilitates learning. Of course publishers are going to not pay for it unless they find dollar motivation. Publishers motivations have always involved money. On the other hand if some use proper indexes, others will be pressurred into using them.

Just because it's currently difficult doesn't mean it isn't a problem that shouldn't be solved. Talking about it will help push in that direction. Sitting back and ignoring it, or accepting half assed work arounds will only mean it's never solved.

[Julanna]

oooh, Doitsu, another avenue to explore. Thank you

[Hitch]

Originally Posted by Julanna

Hitch, you sound so worked up! I suspect this issue isn't worth that much angst.

Well, several thousand books into my ebook-making career, it might be that I've answered this question, about indices, a few times, and had to think about and deal with it, more than once.

I already know how an index will work in paper and the differences with ebooks. I also know how html works.

Your reply is actually full of good information that will come in handy for newbies who don't understand the mechanics of it. Should have been written up with a more helpful tone.

Excuse me? You're annoyed because my TONE wasn't what you wanted? I wasn't telling you how an index works in paper; I was explaining the mechanics of using the existing coding to make indices.

Making the target itself a blue underlinded piece of text is not appropriate, of course publishers are not enamored of it. Doing that only makes the target look like a link because that's what everyone is use to seeing after using the net ever since forever. And if it's only a target (and not a link back to the index) it's only blue underlined pieces of text. You'd have to put in a separate link back to the index. Possible, at this stage I haven't done that.

Yes.That's exactly what you do: make a link BACK to the Index item. Stay tuned...

On some browsers using the back button will take you back to the index, but not on all browsers. It's easy to make the target invisible by using different coding (thank you helpful mobileread people on a different thread).

On a browser? eBooks and browsers aren't the same thing. They're not even close. Half the readers out there don't have "back" buttons. Half the damn Kindles out there don't have them.

Just to clarify, I'm only looking at a simply name index, but I suspect if my problems were solved it could be upscaled for large books with a complex index as well.

And when I say it's an overlooked opportunity I'm talking about the programmers who haven't yet worked out a solution. This isn't my area, I actually don't know how much work would be involved, but I suspect it hasn't been done because of the idea that search is enough rather that it not being possible.

No. You misunderstand entirely. The aspect of indices has been worked on for years. It's not ignored because "search si good enough." The problems--which I don't believe you understand, at all--with multiple "back" jumps, have created the 'search is quite good' response.

The target text does not land at the top of the page in an ebook in any reader or software reader I've tested on, only on a html page.

You're right. It only highlights it. Boy, that would be HORRIBLE.

The problem with the target not being blue underlined is that then the target can't be seen easily when the link is activated. It's somewhere on the page. (Which is how a paper index displays).

A solution to that could have been to have a temporary highlight on the target in an ebook when the link it activated, and that's what I've realised, on this thread, isn't possible with current html/css and ebook conversions.

That's right. it cannot be done with current HTML/CSS and ebook conversions. Period. It requires something like javascript. Which only iBooks has, which is a tiny fraction of devices.

And, actually, having multiple targets is easily displayed in the index using a, b, c etc. Looks good that way. The code part of the targets in mine also have letters that match. I use find so I don't miss an instance of a name and paste code down the page, just changing the letter difference as I go. I don't have trouble knowing where I'm up to and then I can create the correct number of links in the index just changing the letter on each.

As I endeavored to explain, having "a, b, c" in the INDEX, isn't the problem. It's the other way around. Are you going to put this: (Text borrowed from wikipedia, hope nobody gets their panties in a twist about this):

The coat is moderately long, silky, and of a red or chestnut color. It requires frequent brushing to maintain its condition and keep it mat-free. The undercoat is abundant in winter weather, and the top coat is fine. Their coats should also feather in places such as the tail, ears, chest, legs, and body. [Jump back to Index Setters, Irish] [Jump back to Index Setters] [Jump back to Index Hunting Dogs] Irish Setters range in height from 25 to 27 inches (64 to 69 cm), males weigh 60 to 70 lb (27 to 32 kg) and females 53 to 64 lb (24 to 29 kg). The FCI Breed Standard for the Irish Setter stipulates males: 23 to 26.5 inches (58 to 67 cm), females: 21.5 to 24.5 inches (55 to 62 cm). Irish Setters are deep chested dogs with small waists. Irish Setters life expectancy tends to be around 11 to 12 years.

...for all the entries that have multiple Indices linking TO THEM? This is the part I endeavored to explain. it's not that the INDEX has multiple pages for an ENTRY, it's that the ENTRY has multiple links TO IT. Now, in your case, with "last names" or whatever it is you're doing, maybe that won't happen, in which case, you'll just NOT do the blue links, and your users will have to search the next page, or 4, to find the entry. But the point I tried to make was, when you have multiple links BACK, you can't put something like this:

Irish Setters get along well with children, other dogs, and any household pets, and will enthusiastically greet visitors. Even though they do well with household pets, small animals may pose a problem for this breed, as they are a hunting breed. Some Irish setters may have problems with cats in the house, and may be too rambunctious with small children. As the FCI, ANKC and UK Standards state, the breed should be "Demonstrably affectionate." As a result, Irish Setters make excellent companion animals and family pets.

...in which, 3 or 4 different INDEX items are all "jumped back to," obviously, from the ONE link (the underlined text is representing a single target.)

There's no reasonable way, to get the multiple index links TO, to work, with ONE target. I mean, sure, you can have them all jump there--but you can't get them BACK. So, if Jane is looking up, in Hunting Dogs, 24 different breeds, and, god forbid, she wants to go back to "Hunting Dogs," in the spot in the list she'd gotten to..how does she do that, if "Irish Setter" is linked to from 3 or 5 or 10 other places?

And yes it is semi-painstaking. I've only done a small family history book. Working out a system helps (shrugs).

We could number paragraphs, and I've seen small ebooks that do that, but it is so clunky, especially so in a larger book, even if you use chapter no. and paragraph number. Clunky. And I don't like seeing chapter numbers in the text so they'd have to be invisible to satisfy me too. I may try this sometime.

As I said further up the target will not be on the top of the screen on an ebook reader or software (except by coincidence). This could be different in a .mobi or whatever ibooks use. I haven't tested those formats. It *will not* in an epub.

Ok, and saying again, I know it's the creation process. The creation process is what needs to change.

At this stage I don't care what publishers will pay for. Search is not as good as an index, an index is a structured finding tool that facilitates learning. Of course publishers are going to not pay for it unless they find dollar motivation. Publishers motivations have always involved money. On the other hand if some use proper indexes, others will be pressurred into using them.

Just because it's currently difficult doesn't mean it isn't a problem that shouldn't be solved. Talking about it will help push in that direction. Sitting back and ignoring it, or accepting half assed work arounds will only mean it's never solved.

If you think that paragraph numbering is clunky, wait until you try to create multiple back-jumps to an index, or a concordance, from within a single target. As my "tone" isn't helpful, and, hey--what would I know about it, anyway--I'll withdraw. Good luck.

Oh, BTW: Sigil has an index creation aspect, yes; but he indices work as LINKS.

Hitch

[Tex2002ans]

Originally Posted by Hitch

Creating competent indexes is not simple. It's not easy. It's not an "overlooked opportunity." It's a lot--a LOT--of work to do well; it's easy to do badly [...]

Oh yeah, if we are talking building an Index from scratch, it is absolutely BRUTAL to create an Index. If you already have the print Index though, AND you have your EPUBs marked up with page ids, it wouldn't be TOO bad.

This is the way I have seen it done (this is a real sample from an actual ebook with a linked Index):

<p>[...] The study of history makes a man wise <a id="page31"></a>and judicious. But it does not by itself provide any knowledge and skill which could be utilized for handling concrete tasks.</p>

[...]

<p>[...] Where there is something to explain, the human mind has never been at a loss to <a id="page32"></a>invent ad hoc some imaginary theories, lacking any logical justification.</p>

As you can see in RED, throughout the book is a <a id="page###"> that matches the page number in the physical book.

Then, in the Index, you just map every single page number to its equivalent link. So you change this:

Dialectical materialism, 79–84
Deflation, 419–421, 428, 564–567, 779 see also, Cycle theory; Depression; Money

into this:

Spoiler:

<p class="index1">Dialectical materialism, <a href="../Text/11-lnk34.html#page79">79</a>–<a href="../Text/11-lnk34.html#page84">84</a></p>

<p class="index1">Deflation, <a href="../Text/28-lnk155.html#page419">419</a>–<a href="../Text/28-lnk155.html#page421">421</a>, <a href="../Text/28-lnk155.html#page428">428</a>, <a href="../Text/31-lnk198.html#page564">564</a>–<a href="../Text/31-lnk198.html#page567">567</a>, <a href="../Text/44-lnk283.html#page779">779</a> <i>see also</i>, Cycle theory; Depression; Money</p>

As you can see, the code can get real hairy real fast. And there is currently no automated tool that I know of, that can do this (you COULD probably come up with some regex to help speed up the process).

Side Note: Perhaps it would be fastest to merge the entire book into one mother XHTML file, create some explicit links to convert those page numbers into "page###" links, and THEN split the book into its respective chapters. That would let Sigil deal with the bulk of the spaghetti link renaming.

I don't see a linked Index using this method, as being any worse than reading the physical version of the book.

Physical: You look up page number, you turn the ancient stone tablet over to that page, you scan page looking for where this word/person was mentioned.
Digital: You click and jump to the "page", you scan the page looking for where this word/person was mentioned, AND/OR you just search for the word yourself.

Originally Posted by Julanna

A solution to that could have been to have a temporary highlight on the target in an ebook when the link it activated, and that's what I've realised, on this thread, isn't possible with current html/css and ebook conversions.

I don't know, I think this would be better handled at the READER level itself... Perhaps something like Chrome's Ctrl+F search, where the scrollbar turns into yellow highlights showing off the portions of the page where the search term occurs:

http://cdn.raizlabs.com/gregshead/wp..._scrollbar.png

Perhaps one of the non-mainstream devices/readers like Marvin, or the multitude of Android EPUB readers could implement something like this? Could be a nice selling point over the competition! :P

I believe AZARDI just implemented entire library search. Where you are able to search the text of every single ebook added to the program... I would believe this to be infinitely more helpful than a stinkin' Index. Sort of like a Google (Searching) compared to that ancient Dewey Decimal System (Index).

Originally Posted by Julanna

And, actually, having multiple targets is easily displayed in the index using a, b, c etc. Looks good that way. The code part of the targets in mine also have letters that match. I use find so I don't miss an instance of a name and paste code down the page, just changing the letter difference as I go. I don't have trouble knowing where I'm up to and then I can create the correct number of links in the index just changing the letter on each.

Oh boy... I don't know what sorts of Indexes you are looking at, but there is just no possible way that would fly in books that I have seen. Perhaps that might work in the simplest of books, but it could get quickly WAY out of hand.

For example, this text in the physical book:

Dialectical materialism, 79–84
Deflation, 419–421, 428, 564–567, 779 see also, Cycle theory; Depression; Money

Converted to this with the "page number" equivalent:

Spoiler:

<p class="index1">Dialectical materialism, <a href="../Text/11-lnk34.html#page79">79</a>–<a href="../Text/11-lnk34.html#page84">84</a></p>

<p class="poem1">Deflation, <a href="../Text/28-lnk155.html#page419">419</a>–<a href="../Text/28-lnk155.html#page421">421</a>, <a href="../Text/28-lnk155.html#page428">428</a>, <a href="../Text/31-lnk198.html#page564">564</a>–<a href="../Text/31-lnk198.html#page567">567</a>, <a href="../Text/44-lnk283.html#page779">779</a> <i>see also</i>, Cycle theory; Depression; Money</p>

Compare this to what Sigil's Index Tool created:

Spoiler:

<div class="sgc-index-entry">
Deflation <a href="../Text/3-introscholars.html#sigil_index_id_1">1</a>, <a href="../Text/6-TOC.html#sigil_index_id_7">2</a>, <a href="../Text/6-TOC.html#sigil_index_id_16">3</a>, <a href="../Text/28-lnk155.html#lnk163">4</a>, <a href="../Text/28-lnk155.html#sigil_index_id_17">5</a>, <a href="../Text/31-lnk198.html#lnk206">6</a>, <a href="../Text/31-lnk198.html#sigil_index_id_3">7</a>, <a href="../Text/31-lnk198.html#sigil_index_id_4">8</a>, <a href="../Text/31-lnk198.html#ft313">9</a>, <a href="../Text/56-indexC.html#sigil_index_id_3">10</a>, <a href="../Text/56-indexC.html#sigil_index_id_6">11</a>, <a href="../Text/57-indexD.html#sigil_index_id_5">12</a>, <a href="../Text/57-indexD.html#sigil_index_id_6">13</a>, <a href="../Text/66-indexM.html#sigil_index_id_3">14</a>
</div>

<div class="sgc-index-entry">
dialectical materialism <a href="../Text/52-lnk322.html#sigil_index_id_1">1</a>, <a href="../Text/52-lnk322.html#sigil_index_id_2">2</a>
</div>

Now I have to go through, and check all 14 usages of "Deflation" and all 2 usages of "dialectical materialism". Now I have to compare this to the physical book's Index.

Now I have to double-check every link to make sure that where it points to is actually RELEVANT, AND falls in the text that the physical Index referenced (for example, I have to find that Sigil's new "dialectical materialism" links (1, 2, 3, 4,...) actually FALL in between the text on pages 79-84. Now I have to make sure that all 14 entries of "deflation" falls into the page numbers referenced in the Physical book's Index.

Each one of these comparisons takes AT LEAST 20 seconds (probably much longer) to double-check and read the sentence/paragraph to see if that spot is relevant. Let's say I can get 3 done in a minute (being generous), with an Index of hundreds/thousands of links, this adds up to HOURS and HOURS of work.

As you can see, the work that actually has to be done, to create a PROPER linked Index, goes exponentially THROUGH THE ROOF. As Hitch said, it is very easy to create a crappy Index, but to DO IT RIGHT, it is absolutely brutal. And what is the entire point of wasting all the manpower on that crap, when you have a full SEARCH at your fingertips.

Edit: Actually, the way I did Sigil above only found the capital "D"eflation, if I added in the lowercase variant, the amount of links in Sigil's Index jumped from 14 to 40. So that would be, on the extremely low end, at least 13 minutes of work just for one word.

Side Note: This isn't even covering all the other work/manpower that has to go into creating a great Index (it really is an art, and I don't feel like writing another tome ). For example, you have to handle multiple variations of the same word. In the physical Index, it might just say, "Speculating", but you have to cover the words "Speculate," "Speculates", "Speculation", "Speculative", .... Now that "13 minutes for one word" estimate? Yeah, that goes much higher.

How do you handle when the name/word is referenced multiple times within a short span? Do you just point to every single line/paragraph the word is mentioned? What if "Deflation" was mentioned in 10 paragraphs between pages 419-421? Are you going to have 10 links that jump you to "the same" general location?

Originally Posted by Julanna

Ok, and saying again, I know it's the creation process. The creation process is what needs to change.

[...]

At this stage I don't care what publishers will pay for.

Most of the publishers that I have seen, are now just completely chopping out Indexes in their ebook versions, because they are obsolete and make zero sense in an digital book. (Similar with this preposterous idea of "page numbers", they make about zero sense in ebooks + websites.)

These are relics of the physical age, and must go the way of the dodo!

Originally Posted by Julanna

Search is not as good as an index, an index is a structured finding tool that facilitates learning.

How do people learn things on the internet? There is no Index there to help guide you! You just SEARCH for all the info you need.

Anyway, my personal philosophy is, I do not waste my time on creating those insane page links + linked Indexes (it is just not worth the time/effort). Although I personally DO leave the actual text of the Index in the book. Why throw it away if someone already painstakingly categorized the book?

Leaving the text of the Index in the EPUB, allows a person like you to still take a look (as you would in the physical book), and then you can easily SEARCH for those words yourself if you really wanted to. But all this linking back/forth/every which way? Nah, no thanks.

Originally Posted by Julanna

[...] Should have been written up with a more helpful tone.

Hard to convey emotions through text, typically you interpret the words with whatever your current mood is (if you are angry, you might feel that the posts on MobileRead are especially infuriating/mean)... maybe that is why I sprinkle smileys all over (ok ok, I lied, I use them excessively ) ... I don't think you could interpret a smiley face wrong!

So what have we learned today. In order to teach everyone about how horribly labor-intensive Indexes are, we channel "happy thoughts"!

[Hitch]

Yes, indeedy, Tex;

And here are the horrible, horrible results of using search:

https://www.dropbox.com/s/wzuwc3us11..._List.png?dl=0

And,

https://www.dropbox.com/s/2gw7dz3slv..._page.png?dl=0

..the results on the page. It's the way the bulk of ePUB e-readers work. Apple makes it look "snazzier," but the functionality is the same.

Done now. Tex has demonstrated, with his speedy fingers, better than I, why the whole idea of creating massive indices is a huge waste of time, for anything more complex than "See Spot Run."

And really, if anyone is still wanting to do "something," but just doesn't want the apparently-loathed blue link, the obvious solution is simply to switch up a CSS class for the indices links, and make the linked element something OTHER THAN BLUE. Like, say, a grey background, aka, a highlight. Or PINK. Anything other than a simple blue link. (n.b.: obviously, don't make it something that disappears when night mode is on). I fail, utterly, to see the difference between "a highlighted phrase," and a link, in the usage. The target IS. A. LINK. Yes, it will display this way in the normal reading mode, but: so what? If it's attractive, nobody will care. (For that matter, even making them plain blue links doesn't seem to upset the apple cart). Of course, that doesn't solve the dreaded multi-link and multi-page issue, naturally.

Hitch

[Julanna]

geez, if you are wanting to convince me of something going off at me is not the way to do it.

[Hitch]

Originally Posted by Julanna

geez, if you are wanting to convince me of something going off at me is not the way to do it.

I think you completely and utterly misunderstand what I've said thus far; I haven't remotely "gone off at you." I've simply told you precisely what the myriad issues are with what you perceive as something ignored by the eBook-making world, apparently out of laziness.

The fact that you've never even coded a back-link for an index item jump tells me the precise extent of what you know about the topic, but you apparently feel free to opine away as to what's been overlooked or neglected. Both I and Tex have now endeavored to show you the issues. Period.

Hitch

[Tex2002ans]

Originally Posted by Hitch

And here are the horrible, horrible results of using search:

https://www.dropbox.com/s/wzuwc3us11..._List.png?dl=0

And,

https://www.dropbox.com/s/2gw7dz3slv..._page.png?dl=0

Hmm, that does look nice, that probably would work better than the Chrome highlighted scroll bar like I mentioned. This is how Mantano does it on my phone:



Definitely better at the Reader level, than trying to come up with some convoluted highlighting via CSS.

Originally Posted by Hitch

Done now. Tex has demonstrated, with his speedy fingers, better than I, why the whole idea of creating massive indices is a huge waste of time, for anything more complex than "See Spot Run."

And yeah, as was mentioned, a crappy/easy Index (which mentions EVERY SINGLE USAGE of the word) will only ever able to be "as good" as the search. It would be infinitely worse to use though, because you have to remember "oh wait, did I click the [15] or the [16]? Did I click on the [f] or [g]?").

I could maybe see a usage for an Index that has a more BROAD Chapter-based coverage though. "Deflation, Chap. 1.2, Chap. 3.4, Chap. 4.5.1"... although that TOO takes a ton of extra work above the typical Print Page Index you get.... (And again, no easy way to automate this).

Although a Chapter-type Index WOULD be better suited for the digital book era. :P

Side Note: One of my big pet peeves is referencing pages in books, there could be a multitude of different formats for the same exact book, (6"x9" Print Edition, 5.5"x8.5" Mobile Edition, 8.5"x11" Large Print Edition, EPUB, MOBI, HTML version on a website). It is best to toss page numbers in the garbage, and go with a more general/broad location based system if you are referencing something:

"As Bastiat mentioned in Chapter 3 on Deflation" would be superior to "As Bastiat mentioned on page 53 on Deflation". Chapter 3 works as a reference in ANY of those multitude of formats, but "page 53" only works in THAT specific edition/page size/publication date/whatever.

Now, most books have multiple formats, and people will be choosing whichever one suits them best.

Originally Posted by Julanna

geez, if you are wanting to convince me of something going off at me is not the way to do it.

Happy Thoughts! Happy Thoughts! Let the positivity fairy flow through you!

[Julanna]

Thank you everyone who attempted to help me here, as I said it's been an interesting trip. I also apologise wholeheartedly for engaging with the angry poster. I do know better and it won't happen again.

[Toxaris]

Originally Posted by Julanna

I also apologise wholeheartedly for engaging with the angry poster. I do know better and it won't happen again.

That is utterly unfair and harsh namecalling. You can agree or disagree, but this is undeserved.

[Hitch]

Originally Posted by Toxaris

That is utterly unfair and harsh namecalling. You can agree or disagree, but this is undeserved.

Tox:

Fret not. I appreciate your post, but...give it what it's due, which is nothing. It fazes me not in the slightest. S/he obviously wants to bait me. Leave it alone, and just bear the behavior in mind the next time s/he has a question or wants unpaid help.

Hitch