ESCAPE VELOCITY :: Help defeat a bad idea

« Cyberstalking | Main| A suggestion for the Writers Guild of America »

Help defeat a bad idea

Some one pitched the idea of storing feed reader content in the user's mail file in some future version of Notes. Please, help stop the madness by weighing in at Mary Beth Raven's blog.

And if you DO think this is a good idea, by all means, say so in the comments. I would very much like to educate anyone who is confused on this matter.

Posted by Nathan T Freeman On | Digg This | Permalink

Comments

1 - Hi Nathan,

Actually, Apple has this feature in their mail program since Leopard. The idea is not that bad I believe (at least in the Apple version): I check my mail every day and in the mean time my RSS feeds are checked as well, showing me "new mail" and "new rss posts" notifications.
However, after a while I preferred a dedicated program over this solution.

Posted by Martin Vereecken At 02:19:17 AM On 02/08/2008 | - Website - |

2 - I agree that storing the actual data in the mail.nsf is a bad idea but one of the options that they've offered is to store the data in a separate nsf and just to provide a link to it from the mail navigator. Isn't that similar to your suggestion?

Posted by Philip West At 04:40:33 AM On 02/08/2008 | - Website - |

3 - I agree there's madness here....

Please let's NOT add yet another hard-to-keep-track of place to store user experience data.

Posted by Craig Wiseman At 12:21:21 PM On 02/08/2008 | - Website - |

4 - I read the comments on Mary Beth Raven's blog, and I can see both sides, but the perspective that matters most is the end user's. When data is lost or not up-to-date, they don't care how complex the template is or where the data is stored. They just want their data accessible, backed up, and portable.

There are lots of 'workarounds' to meeting these needs and I think they are all clunky. What I'd like to see is either...all 'my Notes data' (scope being contacts, journal, RSS, bookmarks) in one file...OR...all 'my Notes data' in multiple files, that are somehow linked, managed via policy, and replicated as a group. That linkage is missing. Roaming is a start but has too many limitations right now.

Posted by Richard Thomsen At 01:59:43 PM On 02/08/2008 | - Website - |

5 - @4 "OR...all 'my Notes data' in multiple files, that are somehow linked, managed via policy, and replicated as a group"

That, I believe, is *the* solution.

Posted by Kerr At 02:48:00 PM On 02/08/2008 | - Website - |

6 - @5 - Kerr, that is what I have been advocating for years. Ever since I learned that the calendar data was going to be stored in the mail file in 4.5. That was a mistake back then, and storing RSS feed data in the mail file would be a mistake now. Providing easy one-step replication across a set of related databases is the way to solve this. Done right, users won't even know, and that's the way it should be. Users have no need to know what files the data is stored in.

Posted by Richard Schwartz At 03:04:08 PM On 02/08/2008 | - Website - |

7 - It is a bad idea. It should be stored in a separate database. It will just bloat more the mail database. It will be slower and harder to manage and fix. The mail database itself is already too bloated. Lotus should be heading in the opposite direction and break up the mail database into smaller databases.

Posted by Richard Moy At 06:37:41 PM On 02/08/2008 | - Website - |

8 - @6 - I agree, but I see no indication that we're going to see a reasonable and *reliable* way to manage, replicate, and protect/backup the myriad of data and config info that makes up the user experience.

Given, that I'd vote to simplify it and keep the feed config info in the mail file.

I would agree to keep the actual feed info in a separate db.

Posted by Craig Wiseman At 09:07:11 PM On 02/08/2008 | - Website - |

9 - "I see no indication that we're going to see a reasonable and *reliable* way to manage, replicate, and protect/backup the myriad of data and config info that makes up the user experience."

Craig, development is driven by customer demand. You'll see an indication that we'll get this when we, as the customer & partner community, insist on getting it.

If we accept a poor solution because we think that the good solution is too unlikely, then we'll simply get a product that slides into mediocrity. Emoticon

None of us want that.

Posted by Nathan T. Freeman At 08:50:09 AM On 02/09/2008 | - Website - |

10 - @9 - Sounds scaringly like our typical American voting system...

I'm hearing the right solution here -- "sets" of dbs tied together that replicate/inhierit/etc. together.

Posted by Erik Brooks At 05:05:04 PM On 02/09/2008 | - Website - |

11 - @9 - Agreed. I've posted an IdeaJam about it.
{ Link }
I guess what set me off about it was the overblown rhetoric (you'd think that some of it was left over from the Bush Admin's thrust to get us into Irag) and the fact that there was *no better idea proposed*. As I said in the IdeaJam, either segment the user data & config into a policy-manageable set OR collapage it into the mailfile. Just splitting up the user data more leaves us in a FAR WORSE position.

Posted by Craig Wiseman At 08:43:21 AM On 02/11/2008 | - Website - |

12 - Uh, Craig?
Iraq has a Q at the end.

Posted by Craig Wiseman At 09:17:41 AM On 02/11/2008 | - Website - |

11 Aug

Hire Me

Downloads

Search

Disclaimer

Welcome to Escape Velocity!

Opinions expressed here by Nathan T. Freeman are not necessarily those of his employer. However, there's a decent chance they are, so check with them if you really want to know.

But really... do you need that kind of validation? Are the opinions expressed here in doubt?

MiscLinks

ESCAPE VELOCITY