Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs






June, 2009
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 30

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Mon 22 Jun 2009, 11:10 PM
It turns out that IBM has kind of, sort of, dealt with anchor links in iNotes 8.5, if you know the secret incantations and follow the unwritten rules.  Since nobody at IBM has galloped forth to defend their honor, I guess that I must.

OK, the most important ingredient in the secret sauce: set the target of the anchor link to "_self".  This may not be intuitive to most users, so here is a little step by step:

1) Save the email, even though you haven't sent it yet, because you can't create an anchor link until it is saved.

2) Edit - Copy As - Anchor Link... will allow you to name the anchor and will copy the doclink into memory.

3) Go to where you want to use the anchor link, highlight the text you want to use as a link hotspot (you could just paste this as an anchor link, but trust me, that seems to cause more problems than it's worth), and use Create - Hotspot - Link Hotspot, which will automagically paste the link information in, including the anchor.  This is good!

4) Remembering the secret sauce, set the value next to Frame (which in most other places is known as the Target, but not in Notes) to "_self". but without the quotes (which will really ruin your day).

5) Now, so long as you don't mail this to anyone else (since it appears that iNotes doesn't respect the $KeepSent value as it should, although I need to test that further), your anchor links should actually work in iNotes.

So, mea culpa for assuming that IBM had no clue about anchor links.  I didn't recognize what was happening, because iFidelity automatically assumes the "_self" target is intended for self-referential anchor links unless a different actual target is set.

Copyright © 2009 Genii Software Ltd.

Tags:

Mon 22 Jun 2009, 03:03 PM
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.

Tags: