I believe AZW format permits underlined text in the content. In that case, can kindle-it leave the URLs underlined and hyperlinked?
When reading pushed articles on kindle, it’d be helpful to know where and what part of the article is a hyperlink. If not browse from the kindle itself, it’d be helpful to know that where certain text is pointing to, so that this can be looked up online later.
Thanks for the suggestion. We don’t include hyperlinks deliberately. To avoid distractions while reading. Nicholas Carr had a good post about this http://www.roughtype.com/?p=1378
This works well for some articles, but not so well for other articles (where the links themselves may be quite an important part of the piece).
We are thinking about ways to allow links to be included if the user wants them. But for the time being to get to the links, the article link (the only link we do include in our MOBI files) at the end of the article should take you to the original article with all its links included.
Interesting article there. I’d admit that hyperlinks are indeed a distraction, but I do feel they at times complete the content.
I’m keen on giving the user a choice to include them, if you choose to include them in the future.
Thanks.
Jeenu
Thanks Jeenu, I also think it’s good for us to offer it as a choice so I hope this option will be included in the feature.
We can’t tell the difference between normal text and hyperlinks. This is a problem.
Nicholas Carr had a good post about this.
Imagine if the hyperlink in the line above wasn’t blue. We would have no idea which article you were referring to.
The no link approach is definitely better on articles that have been written in such a way that the links aren’t a key part of the text. We’ve always imagined Push to Kindle’s primary use to be for that kind of long-form content. When that’s the case, there is a good case for omitting them. As Carr explains
Even if you don’t click on a link, your eyes notice it, and your frontal cortex has to fire up a bunch of neurons to decide whether to click or not. You may not notice the little extra cognitive load placed on your brain, but it’s there and it matters. People who read hypertext comprehend and learn less, studies show, than those who read the same material in printed form. The more links in a piece of writing, the bigger the hit on comprehension.
But we realise that’s not the only type of content people send, and a feature to preserve links has been requested quite a lot. We actually added support for it in the web app last year. It’s not currently available in the mobile apps, but we hope to add it to them too.
I agree with the article but the current implementation changes the writing in a way that it loses the context. If we were to remove the links, they should be included in the footnotes. The article also states this:
Collecting all the URLs into a single block of text at the end of the article works very well. It illustrates Carr’s point, and it improves the experience of reading the article.
Anyhow, it looks like you guys already implemented a feature to preserve links in the web app. However, “Keep links” doesn’t seem to be working. EPUB output includes the following css.
a { text-decoration:none; color:inherit; }
Thanks for letting us know! This should be fixed now. The EPUB readers we test with - Calibre, SumatraPDF, and Thorium - display links despite this CSS line. So I think that’s why we missed it.
Please do let us know if you still have trouble.
Looks like it’s fixed. Thanks!