ESCAPE VELOCITY

1 - @20/@19 - Handling offline cases seems simple enough to me:

If the original message was created *after* mail had been replicated then just delete it from the local mail.box. Pop up a message box about the recall having succeeded.

If the original message was created *before* mail had been replicated (i.e. it's "too late"), then Notes queues up a recall e-mail to be sent at next replication. Pop up a message box saying something such as "Your message has already been sent to the mail server, and you are currently working offline. Notes will try to recall the message when you next replicate your mail and inform you if it is successful."



I'm going to guess that case #1 will be 90% of the offline cases.

2 - As a former AOL Tech support rep, I believe that if properly designed, message recall can be made to work for ANYONE. AOL has had this for years and they receive few calls on the issue.

Even AOL members understand that it only works for messages sent to other AOL users. They understand that once read, they won't be able to unsend a message.

As for the mixed environment, perhaps IBM should make ND8 smart enough to not enable it by default unless it knows it's in an all ND8 environment? That may be asking a bit much.

3 - AOL had an easier to understand interface for mail than Notes does. It almost hurts to say that, but it's true. That "Fischer-Price" style of presentation has always made it easy for an AOL user to see what's going on.

4 - ..."platform heels and fishnet stockings looking for a party in the South Bronx?"

I only did that once, okay? Can't a guy experiment once in a while?

(sorry...... couldn't resist)

5 - People seem to have an innate understanding that you can't unsay what has already been heard, you can't unwrite what has already been read, you can't destroy all copies of anything that you have let out of your control even once, you can't close Pandora's Box once it is opened. To those of us who are in-the-know, there is no implementation for this feature that isn't, by definition, broken. End-users still, however, seem to like having it. This drives those of us who know better crazy, but other systems do have the feature and how many end-users have you ever heard complaining about it? In my case, exactly none.

6 - @Whitheld: From what I understand, Message Recall in Notes will recall messages that have been read. In that instance, it simply deletes the message from the users' mail file (whether it has been read or not). HOWEVER, the owner of the mail file may elect NOT to implement the ability for message deletion/recall. Would you think that this feature is broken? I would guess "Yes."

7 - Well, I suggest Ed re-read Damien's saga of his formula engine rewrite. { Link } It's the last paragraph under "Quiting Iris" that's applicable here.

Personally I feel that the UI folks should have answered "No!", because the question should really be: "Is it ready for prime-time?". The answer is no because it doesn't "just work", not yet at least. The feature needs more depth.

By that I don't mean that message recall should do the impossible, simply that Samantha be informed if it doesn't or potentially won't succeed. Notification could be either at time of recall or via a mail notification, whichever is more applicable given the recipients.

Note: This opinion is based on an R8 test client in a R7 world, so there's no way for me to really check the facts before I pontificated. If Notes does check for "recallability" when run against an R8 server, then kudos to IBM for a job well done.

8 - I agree, so not prime time, ESPECIALLY for Samantha.

Just some further thoughts on the topic:
- shouldn't the admin be able to set an organizational policy, and
- doesn't this have compliance fallout?

Compliance isn't just a US thing, even here in Africa, we are now required to store (and be able to retrieve) all corporate emails or face stiff penalties. How does message recall fit into that?

9 - @6 - Colin, they don't check.

I'd post a screenshot, but it's probably against the beta NDA rules. In any case, when you click Recall, you're presented with a list of the recipients that you can check off. Then you have a checkbox to "recall even if read" and "notify me of recall status."

There's a message at the bottom of the dialog that says "this feature will only work if the user is on Lotus Notes."

The first thing this should do is filter out anyone's address that isn't in the local domain. There's a corner case where if the user was on another cross-certified Notes domain, it might work, but really, do we consider this a relevant opportunity?

The second thing is that it should check to see whether the user allows recalls. The problem is: the control for recall permissions is in the user's mail preferences, which are probably not available to the requestor at runtime. So what SHOULD happen is that if I permit message recall in my mail preferences, it should flag that in my person doc in the directory. Then the recall interface at runtime should check to see if I even allow it, and reveal based on that.

FURTHER, the recall interface could pretty easily tell the Domino version number on the recipients' mail server. It's right there in the directory, under "Server Build Number." If that build doesn't support message recall, then I shouldn't be allowed to select that recipient.

Is this the way it works today? Of course not. If it DID work this way, I'd say, by all means, include it by default -- because then it's a proactive interface feature, and it educates the user as part of their interaction with it.

But that's not what happens. Instead, the user blindly selects who to withdraw the message from, then waits for responses from various platforms that may or may not be forthcoming. For instance, I recalled a message froma gmail user which caused me to receive a cryptic DSN from google, and caused the user to get some strangeness on his blackberry, where he was lucky enough to guess what I was doing.

Does that sound like primetime to you? Or is this IBM just trying to check off the feature list?

10 - As much as I wish compliance issues would shut this matter down, Rich correctly points out on Ed's thread that if you're compliant, then you have journaling. And if you journal, then the message was already journaled, even if you recall it.

And yes, there are admin controls over this. I'm not sure exactly how they work, as I don't have a Domino 8 server with the Domino 8 NAB design on it. Clearly whatever they are, they don't translate down into the template UI, though.

11 - Couple of comments

Complaince is not broken by this no more than it is by any other user initaited mail deletion. If users care about compliance then they must capture every email at delivery time using Domino journaling. In fact the recall request message itself will also be jounalled and captured as it is sent.

Also there is a user option (on by default) to deliver to the requestor, a tracking report which will inform Samantha that the message was unable to be be recalled because it was not delivered to a mail server (Domino or other) that could process the recall requestand , if on a Domino server, whether it hs been opened.

Hopefully this balances ths notion that the feature set not ready for primtime.

Rob Ingram - Domino Product Manager

12 - re "Filter out any address that isn't in the local domain..." Not so easy as you might think, particulary if the recipients are in a group and the user is off-line. (How does it handle unexpanded groups, by the way?...)

re "it should flag that in my person doc..." Why do you assume that it is in everyone's interest to let people know whether or not they are allowing recall? Is it anybody's business whether or not I've implemented a way to block read-notification messages.

re "could pretty easily tell the Domino version number..." Not if the user is off-line.

13 - Rob, the problem is that the user is expected to initiate the recall action, and then be informed by the system that they can't do it. That's bad interface design. And it's not even necessarily your team's job to address it.

You know what this is like? It's like the "EDIT PERSON" action in the Directory. Every user is presented with this action when they're in the directory. Why? Only a handful of users can actually use it. And you know whether the action is going to work in advance of the user clicking on it. So why does it show up? If I don't have Editor rights to the directory, it merely OPENS the person doc, and I can't change anything.

This is a problem in, like, 90% of Notes apps. And it's just indicative of a lack of polish on the part of template designers.

Recall is another example of this. You can tell in advance a lot of the conditions on whether it work. The proper way to handle that is to explain to the user in advance, not go with a "try and report failure" model.

14 - Urgh, that'll teach me to read before I comment.

Mary Beth does state that it will use a Mail policy or Server Config.

15 - @3 - sounds like the dress code at the AOL call center. (actually, it was "No bathing suits, and no pajamas, but we make exceptions to the Pajamas rule occasionally".

@Nathan - I agree, AOL had an e-mail interface that even a <insert disqualified stereotype here> could use. Doesn't mean Lotus should try to deliver an interface that is simple AND powerful.

I agree with a lot of the sentiment that I see toward asking for a recall and then being told it can't be done. It would mean more overhead, but in an organization where it is enabled any event or condition that would keep you from recalling a message should be tracked so that the user knows up front what they can and can't do. AOL accomplished this by having the feedback happen instantly (As I recall - been over a decade) - you'd click unsend and instantly be told it was done or not.

disclaimer: I've not read enough about recall, and haven't tried it out yet.

16 - And just to add to what Rob has said: your system already has message recall. Your CxO calls you and says "Hey, Mr. Sys Admin employee. Delete this message from all mailboxes." If you're in an organization with a true compliance solution, you can follow the boss's order without any fear that you are breaking compliance rules. You could even go into the Domino journal and remove the message, because in a true compliance environment the message hasn't just been journaled by Domino... it has already been transferred to a tamperproof storage system.

And by the way, I can tell you a story about this exact scenario happening. It was before the compliance era. It was even before the Notes era. It was due to a message that had been sent, containing a binary file attachment. The mail system included a viewer for binary attachments, which anyone could use. And the file happened to include some disk sectors that had not been overwritten from their previous use, and that previous use was as the repository for an alt.sex.something Usenet group feed. Someone saw the text, complained, and management reacted accordingly. This was a close (mini-computer era) mail system that could have had a functional recall feature, but it did not. So the admins shut of all access to all servers, and then went through all mailboxes manually, removing the message.

17 - @11 - "Not so easy as you might think, particulary if the recipients are in a group and the user is off-line."

It expands the group to the extent that it can. Then it's easy enough to tell for each member whether they have a different domain.

"Why do you assume that it is in everyone's interest to let people know whether or not they are allowing recall? "

Good question. If I request a recall, and you don't permit them, do I get a notification to that effect? If so, then it might as well be in the directory.

"could pretty easily tell the Domino version number... Not if the user is off-line."

Domino SERVER version number, Rich. To tell you whether the server itself supports recall.

And honestly, you could still find out client version. The AdminP process has put that into your person document for years. There's a very significant amount of detail in your person doc on that.

18 - Nathan, in the mail policy document, you can enforce a policy to (1) allow recall (2) recall messages sent to users of the policy [This is cool because you could have a policy for CxO's to prevent people from recalling anything sent to them! Muwahaha!!!] (3) allow recall of read items, and (4) allow recall of message a certain # of days old.

@offline - Some users would think this would work. However, if they are working offline, then they ALREADY have a method to recall the message in Notes 7 and earlier if the message was sent while offline - open local mail or smtp.box and delete the message before connecting!

So, if IBM deems that this should be enabled by default, an admin setting up a Notes 8 server can just disable message recall in all of the mail policy documents and then allow users to enable it. I'm not sure it should be enabled by default, by the way. The admin should also provide some documentation about this feature and how/when it works as expected.

Also, the message may not be marked as "read" if it gets to a user's wireless device before recall is processed. This should be related to users as well. And users should know that message recall isn't intended to be a CYA procedure. They should be responsible about sending the email beforehand. This can be said of many other things...

19 - @Richard

Wait, the user's trying to do a recall off-line? Would they really expect that to work?

If that's a valid use-case, surely they'd then expect an email response with results of their recall when it's processed at the server, which would then do all of the above-mentioned checks.

That's not to say I exclude a notification when they actually go online and do their mail replication, I'm just not sure how practical that would be.

20 - @15 Yes, SERVER version number. How will your client get that from the Domino Directry if you are off-line and don't have a replica of it?

@16 Would the user expect recall to work off-line? It depends who you believe.

Nathan seems to think that Samantha should just expect it to work in all circumstances, even though the screen actually tells her that it might not work, so it seems to me that one should assume that Nathan's Samantha would expect it to work even if she is in Island mode when she issues the recall and then replicates afterward.

I may give Samantha a little bit more credit than Nathan does, but honestly I can't rule out the possibility that she thinks it will work if she's off-line.

And why, in fact, wouldn't it? I can't even come up with a reason why Samantha would think it won't work, because it DOES work! A recall is just a special kind of message, so presuming I do connect to the network and replicate after I send it, it works no differently than if I had been on-line in the first place.

So, what I'm pointing out here is that yes... IBM could put more intelligence into the recall feature. I don't deny that at all, and maybe it would be good overall. But Notes is already so intelligent in other respects that it gets in the way. It's will actually be hard to make this new intelligence work in all the circumstances Notes is capable of dealing with.

It's just not possible to get it to 100% certainty that Notes will know who recall will work for and who it won't. And if you can't get to 100%, perhaps its better not to try for 90%, but instead just let users know right up front that recall is a low-probability crap-shoot.

21 - @19 Chris: yes, users who are offline do already have a way to recall messages; presuming that they haven't already replicated. But most users don't know about this method. At least, most who are Bookmark users and therefore never see the mail.box icon on their desktop.

22 - I could not agree with you more. In fact I think the whole concept of mail recall is bad. Once you have sent a letter you cannot recall it, you have to live with the consequences, well it should be the same with e-mail. There is no need for this feature companies need to train staff about using e-mail and the fact that once you have sent the mail then that it done. Its technology for the sake of it rather than as an aid to your work. Bad move IBM.