Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Tue 18 Feb 2020

Branching out: Would it run on a toaster?



Tue 18 Feb 2020

Branching out: Models, msgs, and microservices



Thu 13 Feb 2020

We added that to Midas... in 1999


February, 2020
SMTWTFS
      01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29

Search the weblog





























Genii Weblog

IBM: Please get a clue about anchor links

Mon 22 Jun 2009, 03:03 PM



by Ben Langhinrichs
One of the extremely frustrating things about working with Notes rich text is that it contains so many great ideas abandoned at the end of twisty passages, waiting to be discovered and revived by an intrepid future developer, except that the intrepid future developers have all wandered off to do Ruby on Rails or Flex or whatever.

One of these great concepts, added and then never fully utilized, is the anchor link.  I griped extensively about anchor links six years ago in Anchors aweigh, and I have made futile attempts to interest IBM ever since.  They are still in the product, still under-utilized, still missing the essential ability to add an anchor separate from the anchor link, and, hardly to my surprise, still rendered badly in MIME messages sent out by Notes 8.5, and still rendered badly in iNotes 8.5.  (FYI: I added programmatic support in our Midas Rich Text LSX in Version 1.2, back when Notes 4.6 came out, assuming it would quickly become unnecessary.  No such support is available even today in the Notes 8.5 native classes.)

While I can't believe I need to explain this, let me give a brief primer about the purpose of anchor links and how you might use them.  You put an anchor somewhere (in HTML, this would look like <a name="Bottom"> or <a name="Chapter%207">).  Then, other people can create a link to that spot in the text (in HTML, that might be <a href="#Bottom">Link to the Bottom</a> or, in the longer form, <a href="http://www.MyServer.com/mydb.nsf/0/A1C28F4D6CC5CB6B88256F15005676C7?OpenDocument#Chapter%207">Chapter 7</a>).  In the Notes client, you can't create the anchor separately (although see my post linked above for some clever ways to do this), but instead you create the anchor and then link to it immediately.  Stupid rule, because it means you must have edit rights, and indeed edit, a document in order to create a link to a specific point, but that's the limitation.

Now, here's the clue that IBM missed.  When you link to an anchor inside the same document, you stay in the same document.  This radical idea allows you to do handy things such as a Table of Contents on a long document, or links to specific places in the document.  So, when you email this document to somebody else, what do you not want them to do?  You don't want them to try to get back to your mailbox and your document.

Yet, in both iNotes and in outbound emails generated by the Notes 8.5 client (or any client back to R5 days, when they just used to skip the links entirely), the link created tries to open the document back in your mailbox.  What it does not do, and this is the really wonderful, sadistic touch, is keep the anchor in any form, but just skips it.  So, here are the various things IBM has accomplished for you:
  1. you go to a different document, which you shouldn't;
  2. the link is copied as a Notes URL, which makes little sense to the web client, and none to iNotes, and can't be followed back; and
  3. you have no more access to the anchor, thus ensuring that you haven't a clue where you were even meant to go.

Needless to say, iFidelity does a better job than this.  In iNotes and outbound rendering, it makes sure you go to the anchor in the same document.  In inbound rendering, it turns your link back into a link inside the same document.  There, IBM, one free clue.  Enjoy!

Update: Interestingly, I discovered that iNotes 8.5 actually seems to have a random response to anchor links.  Two different anchor links on the same page render differently, one as a long complex iNotes link that opens another copy of the same document, but not to the anchor, the other which is a Notes URL which does include the anchor, but doesn't go there when clicked.  I have not yet figured out why one acts one way and the other a different way, but if I create several anchor links, about 50% do one and 50% do the other - both wrong, but at least different!

Copyright 2009 Genii Software Ltd.

What has been said:


819.1. Henning Heinz
(22.06.2009 21:50)

Does it really generate anchors this way

[...]6C7?OpenDocument#Chapter%207 ?

This would make anchors part of the Query_String!?


819.2. Eric Mack
(06/23/2009 12:47 AM)

Have you ever looked at an IBM PartnerWorld email? Everyone I receive has broken anchor links that go nowhere, not in the page and not to an external URL. just broken.

Someone at IBM is probably pleased to be sending them out but they are useless, at least as they render to me.

I usually note the topics, delete the email and google for the links.

Ouch!


819.3. Les Z
(06/23/2009 02:14 AM)

This is one of the reasons that the company that just acquired us wants to move us to Exchange. The nice formatted newsletter that they send through e-mail is mercilessly butchered. I just don't think IBM gets it that while it's great to have all the fancy features like xPages, until we have true fidelity we've got a weak case for sticking with Notes. It's really too bad because we're just now moving to 8.5... Too little too late.


819.4. Ben Langhinrichs
(06/23/2009 02:49 AM)

Les,

Given the cost of migrating, it might be worth seeing if you could save a bunch of money and just use iFidelity to get better fidelity. Just a thought.

Ben


819.5. Henning Heinz
(23.06.2009 08:56)

@Ben Thank you

@Les Notes 8.5 Standard (not the old classic client) can use Internet Explorer for mail rendering. It has disadvantages (e.g. you should not upgrade to IE8 until 8.5.1) but it renders newsletters much better. Of course iFidelity might also be an option and it helps you to improve what you send outside of your company.