underline links removed i sigil but showing in kindle previewer

[Hitch]

Originally Posted by Jellby

People who don't click/tap asterisks (or whatever other minimally inviting content) to check if they are hyperlinked to a (foot)note, don't want to see the footnote anyway. People who don't want to see footnotes are better served with uncolored, un-underlined, unobtrusive text.

Really? So if, like me, you knew from making thousands of Kindle eBooks and reading thousands more, that 99.99% of all eBook builders have NO idea how to suppress the link indicators, you'd click on it anyway?

I cannot tell a lie. I wouldn't bother. Why would I? In Amazon, in Kindle? You know damned well that if it ain't underlined, ain't gray, (or blue) you have a nearly 100% chance that it's NOT linked, don't you? But you'd click it anyway, Jellby?

Or are you really thinking about ePUB, here?

Hitch

[ghmerrill]

Originally Posted by Hitch

Really? So if, like me, you knew from making thousands of Kindle eBooks and reading thousands more, that 99.99% of all eBook builders have NO idea how to suppress the link indicators, you'd click on it anyway?

Though not explicitly asked, I'll venture an answer purely from my own perspective ...

Experience of that sort cannot be disputed, but the relevance of that for prediction is somewhat up for grabs.

I cannot tell a lie. I wouldn't bother. Why would I? In Amazon, in Kindle? You know damned well that if it ain't underlined, ain't gray, (or blue) you have a nearly 100% chance that it's NOT linked, don't you? But you'd click it anyway, Jellby?

I would. I've got to THINK that a lot of people would (but we're really only throwing around opinions, hunches, and at best anecdotal impressions here). WHY would I click on it? Because I'm reading a hypertext document. Here's this symbol that is not standard punctuation in its context. It seems to serve no function other than being (possibly) something to click. It also, in a print book, would be an indicator to a footnote or endnote. It's in a position where one might expect something to click to get to more information. And I've certainly seen other hypertext documents in which there are such links. I don't try to convince myself that it ISN'T a link, and I don't do that by thinking about my knowledge of the technical capabilities of 99.99% of Kindle authors. I'm just reading the book and see this distinctive character in a suggestive place.

It's there. I click it. Of course I do. Et voila!

Or are you really thinking about ePUB, here?

Um ... not me, at least. It's also difficult for me to see either clicking the asterisk or creating documents in which it is thus employed as a threat to civilization as we know it. Would I do it on contract or for hire in the case of a book for a client? Maybe (even probably in most cases) not. But maybe so. I also think the advisability of such a technique is dependent on the type of book in question and the intended demographic of readers.

[Hitch]

Originally Posted by ghmerrill

Though not explicitly asked, I'll venture an answer purely from my own perspective ...

Experience of that sort cannot be disputed, but the relevance of that for prediction is somewhat up for grabs.

Sez you.

I would. I've got to THINK that a lot of people would (but we're really only throwing around opinions, hunches, and at best anecdotal impressions here). WHY would I click on it? Because I'm reading a hypertext document.

Yes, which YOU know because you're trying to make an eBook. Would you like to make a WAG (wild ass guess) at how many "Kindle" customers have the remotest idea that an eBook is HTML? I mean, come on, I get to answer this and discuss it with prospective clients--authors, mind you, who buy Kindle and Nook books like they are popcorn--nearly daily. Out of nearly 4K regular, retail customers? (By which I mean your typical author/self-publisher, not commercial pros.)

ZERO. ZEEEEERO. I have YET, since 2009, to have a regular self-publisher come to me and not be amazed and astounded that, "OMG!, eBooks are HTML, like WEBPAGES?"

So, why would those folks think to themselves, "oh, hey, I'll bet that unlinked asterisk IS a link, cuz this is a hypertext document!"

Hell, would you like my lecture on how many "regular people" know what "download" means, or how to do that from a browser? Or where to find the aforementioned "downloaded" file, if they didn't direct it? Hell, go ask ten regular everyday Kindle/Nook readers, on the street--not UI experts, etc.--how to get an eBook and sideload it to their devices. I'll wait.....

Phllbbbbfffftttttttttttttttttttttttttttttttt.

Here's this symbol that is not standard punctuation in its context. It seems to serve no function other than being (possibly) something to click. It also, in a print book, would be an indicator to a footnote or endnote. It's in a position where one might expect something to click to get to more information. And I've certainly seen other hypertext documents in which there are such links. I don't try to convince myself that it ISN'T a link, and I don't do that by thinking about my knowledge of the technical capabilities of 99.99% of Kindle authors. I'm just reading the book and see this distinctive character in a suggestive place.

It's there. I click it. Of course I do. Et voila!

Brother, you do you.

Um ... not me, at least. It's also difficult for me to see either clicking the asterisk or creating documents in which it is thus employed as a threat to civilization as we know it. Would I do it on contract or for hire in the case of a book for a client? Maybe (even probably in most cases) not. But maybe so. I also think the advisability of such a technique is dependent on the type of book in question and the intended demographic of readers.

I never said it ws the end of civilization as we know it. Nor is it, despite your deprecation "oh, how we've ALWAYS done it"-ism. It's something that's come about due to customer use, use-cases, the IDPF, and habit.

It would be--truly--hard for me to say just how much I truly don't care what YOU do, as you've clearly stated you're going to be a One Book Wonder, but I do think that those of us who do this professionally and commercially (the two aren't always the same) do have SOME obligation to point out the downsides for the wee authors and self-publishers that will come along and read this later--people who will care if they get Kindle Quality Notices, or bad reviews from cranky Amazon readers.

If and when the use changes, when the IDPF changes their minds, when Amazon no longer penalizes authors that don't have it, boy howdy, I'll be right there with ya, but until then...for my customers, to keep them out of the Amazon Kindle Quality Notice Ghetto, I'll keep my customers' underscores there.

Hitch

[ghmerrill]

Originally Posted by Hitch

Sez you.
Yes, which YOU know because you're trying to make an eBook. Would you like to make a WAG (wild ass guess) at how many "Kindle" customers have the remotest idea that an eBook is HTML? I mean, come on, I get to answer this and discuss it with prospective clients--authors, mind you, who buy Kindle and Nook books like they are popcorn--nearly daily. Out of nearly 4K regular, retail customers? (By which I mean your typical author/self-publisher, not commercial pros.)

Etc.

I see in these kinds of arguments of yours a striking similarity with the inclination of developers to conflate goals, design, and implementation.

I don't care what Kindle customers know or don't know about HTML -- or XML or Javascript, or Unicode , or any number of other technical areas. That's all irrelevant from the design perspective and goal of producing a readable book (given constraints on what CAN be done at the implementation level to achieve the goals and design criteria). Repeating claims about the technical knowledge or ignorance of the customer group is totally irrelevant to considerations of how they will/do/might interact with the finished product in which none of that is visible. Surely you must see this.

I don't dispute any of your claims or beliefs about the general technical understanding of Kindle readers -- in part because I don't doubt them, but in part because this doesn't matter to what this discussion is really about. If you want to use it as an opportunity to warn potential customers off from asking for certain features, then to me that's perfectly okay and I won't dispute that either.

But by your own argument, that level of ignorance strongly suggests that the very people you worry about aren't reading this thread, or this forum -- and so neither you nor they will be endangered by it. However, by the same token, you MUST recognize that a failure to understand what "sideload" means doesn't disqualify a potential customer from asking about a variety of features (at the purely perceptual or functional level) in the final product that may or may not be achievable or advisable. And of course you have to be prepared to answer those questions. And I do understand that you have a strong interest in protecting yourself against what you regard as unreasonable requests from customers and having to take time to explain to them why the request is unreasonable. Of course you have such an obligation. That's the nature of a service business. No one is disputing that.

But that's all completely irrelevant to the questions of feasible design and feasible implementation raised in this thread. If you see those questions or the possibility of those designs and implementations -- or even the discussions of them -- as threatening to you or your potential customers and your business, then you absolutely should point that out. But veering off into irrelevancies of how technically knowledgeable those customers are about a plethora of issues in the process of publishing doesn't further that goal. Now those very customers, if they in fact were to read such threads as this, would see mostly a lot of complaining about their ignorance. I guess that's one approach to warning them.

In short, you're not really disputing what's been discussed concerning those design and implementation issues. And suggesting that such discussions are in some way out of place, inappropriate, irresponsible, or dangerous in a forum that's devoted specifically to technical aspects of E-Book Formats and ePub seems at best quite odd -- though you're certainly free to do it.

[phillipgessert]

I think you made a point that you would know to click because you know it's an HTML/hypertext doc. In that context I do think end-user knowledge of what's going on under the hood does factor in to design decisions. Especially in a case like this where the push seems to be to land nearer to an analog with print, where things are definitely not clickable.

I think it's kinda reasonable to say, given a reader that doesn't know these things, and presenting them something that looks like a printed book, some may just glance to the bottom of the screen; and, finding nothing there, just think something's wrong. I don't know whether that's a significant segment of readers, but it's what's meant to be avoided entirely by using common visual language like underlines.

[Jellby]

Originally Posted by Hitch

Really? So if, like me, you knew from making thousands of Kindle eBooks and reading thousands more, that 99.99% of all eBook builders have NO idea how to suppress the link indicators, you'd click on it anyway?

I can't tell what I'd do if I were a different person. But I bet 99.99% of Kindle users have NO idea about what 99.99% of ebook builders know or do not know (let alone of what can or cannot be done).

If I see something that might look like an interactive element, that might link to something I'd like to see, sure, I'd click. What do I have to lose? It's not like I have to get out of bet, get dressed and climb a tree to try, it's just touching the screen, and I'll have to touch it anyway to turn the page... why not try? If it works, nice; if it doesn't, I can rant about 99.99% of ebook builders

Now, there may be hidden links. Maybe the asterism used for scene breaks links to an extra "chapter", and I'd probably not try to click on it. The closing quote mark could be a link to a footnote, and I'd miss it. But an asterisk in the middle of the text? A superscript number or dagger? You'd have me clicking before I reach that sentence, underline or not (and if there's an underline I'd be cursing the ebook builder for not removing it, I don't need and it looks ugly).

Or are you really thinking about ePUB, here?

This being the ePub forum, and I reading only ePub books... yes, I'm thinking of ePub.

[Jellby]

Originally Posted by phillipgessert

I think you made a point that you would know to click because you know it's an HTML/hypertext doc.

As far as I'm concerned, it's not because I know it's HTML, but because I know it's a device where can click/touch on things to do stuff. I can swipe to turn the page, why shouldn't I be able to touch what looks like a footnote mark to see the footnoe? Why shouldn't I be able to touch the titles in TOC to go to the stories/chapters, even if they're not underlined?

It's like right-clicking on GUI programs to get a context menu. Once I learnt that's a thing, I try it whenever I think it might be useful, I don't need an indicator that I can do it. Sometimes I'm disappointed I don't get anything or not what I'm looking for, but quite often it works as expected.

(Of course, there's an initial barrier. The first time I got in contact with Windows it was around version 3.0. I spent about a week opening the desktop, dragging the icons around, and closing it in confusion. Until someone told me that I had to double-click to open the programs... Now I use KDE on linux and have double-click disabled But my point: someone using a touch-screen e-reader has already passed that barrier.)

[ghmerrill]

Originally Posted by phillipgessert

I think you made a point that you would know to click because you know it's an HTML/hypertext doc.

But here again lies a possible conflation that leads down a path to problems of one's own making. What is meant by a "HTML/hypertext doc". I can be guilty of informally using such ambiguous/incoherent terms myself when not being careful.

Hypertext is an abstract conceptual description of documents. I won't get any more detailed than that admittedly vague description, but it will suffice for our purposes here. Formally, hypertext is really a kind of algebra (or "general relational system" if you prefer).

Hypertext can be implemented (and has been) in any number of ways -- only one of which is via HTML. For example, before there was HTML there was (even yuckier than HTML) SGML. And as another example, for decades SAS institute used it's own markup language (called, if I remember correctly) SAS Markup Languag (SML). And IBM had several markup languages floating around in the pre-Bookmanager and book manager era. You young-uns don't know what it was like. There were range wars. Check the old usenet archives. It was nasty.

And creating and using a hypertext document/system doesn't even require a markup language. It can be (and has been) done purely programmatically, or via a DB. The world, in fact, is fairly overrun with actual and potential IMPLEMENTATIONS of hypertext.

HTML is ONE of those implementation mechanisms.

So what does the reader of a hypertext document need to know about HTML in order to understand or suspect how to navigate such a document? Well, NOTHING -- and often they don't. Believe me, my sister has NO idea of HTML, NO idea of the theoretical framework of hypertext, and NO idea of how the hypertext she uses on a daily basis is IMPLEMENTED. Yet she uses it and has expectations and anticipations (about thinks like links and what they do, etc.) because of that. I know people in their 90s who have probably never heard the word "hypertext", but they know how to use a hypertext system when one is put in front of them. They don't know and don't care, and don't make use of any knowledge of, the underlying implementation technology (including its foibles and constraints).

I'm not saying that what you've said here is wrong, but it does speak to the danger of inferring what readers know, what they believe, and what they look for -- based on what AUTHORS or DEVELOPERS believe. And I guess another way of trying to put my point would be to say: Go back over the postings in this thread and scrub them of any mention of HTML and see what's left. You still have fundamental questions regarding design and UX that deserve serious consideration.

To talk about a link is to talk about a hypertext concept. To talk about a blue line is to talk about an artifact of implementation. To talk about HTML is to talk about part of the technology of a particular implementation of hypertext (well, it can be -- since HTML can implement things other than hypertext). One needs to hold these at bay from one another or crappy applications confused conceptualizations, and bad designs will result.

(Hence, again, my comments about talk about HTML and users' knowledge of it and other details of technology being irrelevant to the discussion.)

[ghmerrill]

Originally Posted by Jellby

As far as I'm concerned, it's not because I know it's HTML, but because I know it's a device where can ... to do stuff.

Yes, this is a reference to HYPERTEXT -- devoid of any implementation (or even design) details.

[phillipgessert]

Well, it's kinda semantics (badum-tish) but I think by saying you knew you could click because it was a hypertext doc you probably basically meant that you knew you could interact/navigate because you were within a system that allowed for that, right? My point just being not everyone will know that. Jellby's point above is sound in general, but e.g. my preferred device has no touch at all, and I could see a less savvy user being less inclined to think "I can swipe therefore I can tap" on a device that allows neither. In any case personally I'm pretty firmly in the underlines camp so naturally I'm a little biased.

[JSWolf]

Personally, I want the footnote indicator to be large and underlined and bold. I want it to stand out. I don't want this tiny superscript nonsense that's not all that easy to see. I want to know it's there. I may not want to go to the footnote, but if you make it hard to see, by making it small, gray and not underlined, then get rid of it as you don't want anyone to click on it.

I like this... This is some[*] text that has a footnote.

[ghmerrill]

Originally Posted by phillipgessert

I think by saying you knew you could click because it was a hypertext doc you probably basically meant that you knew you could interact/navigate because you were within a system that allowed for that, right?

Well, yeah, exactly. That's been the point. As part of that background knowledge/assumption/attention you're predisposed to look for things that indicate navigational possibilities -- whether conventional ones or not. The other side of the argument (which we've seen) is where an explicit argument has to be mounted that you'll never think that something like a distinctive symbol appearing in places where a link would naturally appear is a link indicator. This then (under the assumption you note) appears as a kind of peculiar argumentum ad stupiditum argument where you (a) grant the awareness and sensitivity of the reader to be looking for navigational opportunities and clues, and then (b) deny that the reader will act on that awareness and sensitivity. Incoherence of this sort is rarely convincing.

Also, by the same sort of argument based on knowledge/prior experience, the asterisk comes out a winner since for centuries it's been used as a footnote indicator. In fact, if you look to see what typical footnote indicators are, the asterisk is regarded as the most common one. So any reader inexperienced in eText (or whatever we want to call it) would almost certainly think of the asterisk as a footnote indicator and -- with your background assumptions about being in a eText navigational environment -- be inclined to click it. Or at least that sort of claim is at least as powerful and believable as the contrary ones being made.

My point just being not everyone will know that.

Will "know" WHAT? What's the realistic scenario here? We've got someone who just bought a Kindle book INSTEAD (often) of the paperback version and knows full well what to expect in terms of that. Or are we restricting these scenarios to first-time users and buyers? Who -- in the scenario in question -- will NOT know that? Sure there are really BAD interfaces that inhibit their own use. But I don't think the suggestions I've been considering are among those -- they're just different. I'm not without experience in designing and implementing complex systems that need to be navigated by naive users and with the goal of not requiring them to take training or read through documentation in order to quickly see the navigational methods. That's one reason I wring my hands about this stuff. I don't offer that as evidence of anything, but just a hint that I'm not insensitive to the user/reader side of things, and across diverse user groups.

Jellby's point above is sound in general, but e.g. my preferred device has no touch at all, and I could see a less savvy user being less inclined to think "I can swipe therefore I can tap" on a device that allows neither.

My preferred device as well, but that's only because I habitually (from years of software development/testing/documentation) work with a very large monitor that lacks touch capabilities. I'm perfectly okay with touch (or voice, or telepathy) if it's supported in a way that allows me to have multiple large windows displayed simultaneously. But that's way outside the usual Kindle reader scenario. A lot of what's being said here is really just personal preference and run of the mill habit being disguised as appeals to standards and buttressed by vaguely supported claims. It's just a dressed up version of "Well, I like x and it's what I'm used to" with the addition of "And so what you're suggesting seems dangerous and counterproductive to me." Okay. People get to say that.

In any case personally I'm pretty firmly in the underlines camp so naturally I'm a little biased.

Biased is fine. I've nowhere suggested that underlining isn't an effective way to accomplish the desired goals. I've nowhere suggested that people shouldn't use it in the traditional way. I just don't think it's dangerous/immoral/ineffective to employ alternatives which -- by the very considerations you've offered -- appear to be reasonable and to have very reasonable expectations for success.

[ghmerrill]

Originally Posted by JSWolf

Personally, I want the footnote indicator to be large and underlined and bold. I want it to stand out.

Good for you -- and you should have what you want. This, of course, argues for user-selectable options for footnote and link indicators. What a concept! Don't hold your breath. Not because it's difficult to do. (Well, it's more difficult than just switching the font or background, etc.) Just because you'll get mountains of arguments about how it's difficult to do and (mostly) it's not necessary, and it's too complicated for people to use, and people aren't used to that, and people don't really "need" it, and blah, blah, blah (basically every software UI/UX meeting you've ever been in, if you've been in any ).

I don't want this tiny superscript nonsense that's not all that easy to see. I want to know it's there. I may not want to go to the footnote, but if you make it hard to see, by making it small, gray and not underlined, then get rid of it as you don't want anyone to click on it.

I like this... This is some[*] text that has a footnote.

Yes, that's a very common footnote convention. I'm pretty sure people were using it on stone tablets, and it's stood the test of time. I've considered it, but think it's ugly and there are better alternatives in terms of specific characters nowadays if you want your footnote indicators inline. I agree about the naked asterisk being. For an alternative, the strongest argument currently is how things will appear on monochrome displays -- where you absolutely need a distinctive indicator. Here, the "[*]" works well, but so do some alternative symbols from Unicode sets -- and they're less 18th-century and ugly.

[DNSB]

Looking at the nearest thing I have to a decent reference on style (the Canadian Style) on footnotes/endnotes/citations/etc., the recommendation is to use a superscripted number which can be between brackets or parantheses which are also superscripted.

An alternate is to use a symbol which is unique within a page and/or chapter ( *, †, ‡, §, ‖, ¶, etc.). Though these days, no one uses the traditional squared 4 dot punctuation mark ⸬ which looks rather like a double colon.

Given that footnotes do not exist as such in a ebook and are often collected in a single file as endnotes, I prefer to use unique superscripted numbers within square brackets just to make them larger and easier to touch and easier for me to locate when editing.

Of course, this runs into fun when a single endnote may be referenced from multiple locations and you do not have popups for the notes or a note links to another note.

[ghmerrill]

Originally Posted by DNSB

Looking at the nearest thing I have to a decent reference on style (the Canadian Style)

Everybody has his/her/its own standard. Old engineering saying (more popular as software has exploded): "Standards are great. You can't have enough of them"

Given that footnotes do not exist as such in a ebook and are often collected in a single file as endnotes, I prefer to use unique superscripted numbers within square brackets just to make them larger and easier to touch and easier for me to locate when editing.

I think the closest thing to footnotes in flowed text is the popup note ala Kindle. I really like it. Some may not.

Of course, this runs into fun when a single endnote may be referenced from multiple locations and you do not have popups for the notes or a note links to another note.

Yes, there does seem to be a tacit assumption that the relation between footnote references and footnotes, and between citations and sources cited, is 1-1. Not really unreasonable in the case of notes, though it's not hard to imagine wanting to refer to a note in more than one place. But in the case of citations, one might often (in various technical applications) want to cite a source in a number of places. So the link/display of the target in that case is trivial, but then how do you get back to the citing location (since there are multiple ones linking to the same target and parameter passing in HTML is ... er ... absent?)?

I scratched my head about this a couple of days ago and didn't see any posted solutions to it. So I'm not sure how others do it. But a solution using nested <div> elements with unique identifiers does solve it nicely. Naturally, having solved that problem, I then decided that I wouldn't use such links anyway. But I was pleased to finally find something useful about <div>s .