Hello Steve,
I still think the way to do this is to keep account seperate...but
just have "Global filters" that work an all accounts or a subset of
accounts. In fact, that almost goes against bloat...because you
wouldn't have to run duplicate filters ever. (This is of course
particular to my situation where I have two email accounts that I
filter similarly)
This wouldn't be a paradigm shift, this wouldn't mean a massive
restructuring of TB!
Derek
Written in response to your letter of Friday, January 07, 2000, 1:52:50 PM:
SL> Friday, January 07, 2000, 10:33:32 AM, Allie wrote:
>> a) Add new email address to existing account.
>> b) Create new Account
>> How is adding the a) option to go along with the already existing
>> b) option a paradigm shift? :)
SL> Because it requires merging the streams and requires either a lot more
SL> macros or TB! implementing "personalities", IE, detecting which account the
SL> message was sent to and using that account to send out on. How would that
SL> interact with the current system? What would happen if I drag a message from
SL> one account to another to force the issue of a change? Will it overrride
SL> that?
SL> The two paradigms, "personalities" and separate accounts, combined, has
SL> never been done. How is that not a different paradigm?
>> insist on managing entirely different accounts in different
>> instances/windows or otherwise offer multiple personalities and multiple
>> e-mail addresses per account support instead.
SL> Exactly the problem. It is rare to find it done right because programmers
SL> just can't grasp the basic concept.
>> However, sometimes, things get too cut and dry and the application becomes
>> tedious to use.
SL> Granted. However, I find "cut and dry" tedious easier to deal with than
SL> the "constant codling of user-created problems" tedious. The former, at
SL> least, I can automate to suit my tastes based on tools available to me to make
SL> them less tedious. The latter I have to somehow undo automatic behavior. It
SL> is easier to automate than it is to unautomate.
>> There must be an optimum balance between user facilitation, keeping in mind
>> that users do things differently, code quantity, and trying to make the
>> various provided tools not too specialized to facilitate a particular need.
SL> There is. Users do do things differently, that is why there should be
SL> different, specialized products. No one product will ever be everything to
SL> everyone. I would be tickled pink if we could get the computer industry to
SL> agree to completely open standards on data transfer and then let the
SL> components be completely interchangeable. With that we could have authors
SL> focus on one thing without having to worry about integration. I'd love to see
SL> a TB!/PMMail style email client that did not implement a text editor and spell
SL> checker but, instead, just game the individual hooks for external tools and
SL> left it at that. Why? Then they could focus on the client and not the
SL> completely separate products of "specialized text editor" and "specialized
SL> spell checker." If that were the case I bet we'd have killer IMAP support
SL> already in TB!.
SL> Quite frankly, if Alex is happy with Pegasus and how it works, all
SL> the power to him. Why he is still on TB! mailing list is beyond me since it
SL> clearly doesn't work in the manner he chooses.
--
Best regards,
Derek mailto:[EMAIL PROTECTED]
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
