Hello Ali & all fellow TBUDL members,
Wednesday, December 01, 1999, 12:53:11 AM, Ali wrote in response to my saying:
>> Since my past email client had an accounts column, it was easy for
>> me to keep house manually, depending on source, content,
>> importance, follow up required etc. and the decision I'd make at
>> the moment.
>> In TB I *can't* do that, without destroying my parked flags (that's
>> what they are to me, and all they are to me).
AM> TB! keeps all accounts completely independent of each other. I
AM> personally prefer this but that's just my humble opinion. :)
If an account column was available in the "setup columns" menu, TB
users would have a choice of using one structure and / or the other.
AM> If the accounts are kept separate from each other then there's no
AM> need for an accounts column. :)
Agreed, in general terms. But there *could* be occasion in which one
would want to mix messages from different accounts (on a single theme,
for instance) in the same folder. Thinking about it, if the folder
column could programmed to show only the receiving account as the
final destination) and the message itself never left there, but was
instead dynamically linked to whatever visual structure the user chose
to give it, it seems to me at the moment that this might be an ideal
solution. (However, the idea hadn't *occurred* until this moment).
In other words, all messages would reside in the inbox of the
receiving account, or even in a single message depository. The rest of
it would b accomplished with short cuts, aside from what was deleted
from trash itself or wiped. This arrangement would make it very easy
to find anything, if there was any doubt as to it's location.
Any comments? How difficult would this be to implement on non-windows
systems (such as Linux)?
AM> Outlook is more along what you seem to be suggesting where mail
AM> from all accounts is kept in one area, the argument being, why
AM> separate the mail when all accounts belong to the user.
In this case, the assumption is that the user wants to see all
incoming mail on arrival, without jumping around between folders then
filter or move them from there. However, this arrangement in no way
precludes the user from filtering given messages to a given folder on
arrival.
My previous email client was Calypso, which I liked using until it
crashed for good and found out that mcsdallas, the distributor - which
is either *only* a distributor or (unlike TB), has *very* poor contact
with it's development staff and *no* functioning user group I could
find - is made up of let's say less than helpful individuals (an
understatement), which is nuf said for Calypso, for now.
I *have* used both Outlook Express and Outlook 98 a little, but like
most MS products, incorrectly anticipates what it thinks the user
wants and tries to impose that on the user, while successfully
impeding the user from achieving what *he or she* wants to do. (nuf
said for Outlook & MS also, except that ms, or rather mswin95, is
part of the problem that arose w/ Calypso and never-the-less-must
still be dealt with for now - until changing os's - unlike Calypso
which can't do many of the things TB does so well anyway).
Incidentally, as for changing OS's, the only thing holding me back is
developer support for the applications I use and the time required for
doing what we're doing here - assimilated and familiarizing myself
with the paradigm and design of TB, as well as looking ahead to where
"we" want to go, consensually.
>> Once again, you appear to be ignoring read & reply message filters,
AM> ... since they don't seem to be an immediate issue just yet. :)
I discovered that, further on in your post.
...
AM>>> Yes, I am eagerly awaiting help file documentation on 'regular
AM>>> expressions' use in TB!. So far, all my knowledge is being attained
AM>>> through other apps that use Regexps.
>> Have you had any results?
AM> I have used regular expressions a couple times but can't find use for
AM> it in my own message filtering. Steve Lamb mentioned that regular
AM> expressions could make me not have to create all the rules that I use,
AM> but I don't think so, since for each folder that I create to which
AM> messages are filtered, I need to create at least one rule with at
AM> least one string defined. Regular expressions may help if a rule has
AM> many strings defined and one could possibly create a regular
AM> expression that covers all the strings, thus preventing my having to
AM> enter all the strings separately. I *do* have a couple folders with
AM> many alternate strings entered, but the headers vary so much in unique
AM> content, that using a regular expression to accurately cover strings
AM> that will correspond to all and only those messages that I wish to
AM> filter is nigh unto impossible.
Understood. Looks like there's no immediate need there on my part
either, but *would* like to know more, once more info is available.
>> Using alt + f + f gives you a choice of any or all or the 4 sets
>> available - in, out, read & replied.
...
AM> Yes, it does. You therefore have four filter sets, two equally
AM> functional, but the other two being restricted to filtering only
AM> replied or read messages.
>> The logic to it is not as apparent as it cold be, but there *is*
>> functionality there. Rules *can* be activated relatively
>> independently, within the constraints of the range of choices
>> given. I'm not sure of the advantages to this though, if any.
AM> <snip>
>> Once again, there is a degree of freedom here, but I'm still not
>> sure ... that TB's filtering processes are on the same level as
>> some of the other things I know and like about TB, in relation to
>> other options used by other email clients.
>> Is there something unique about TB's filtering design that somehow
>> jives particularly well with other positive aspects of TB? As its,
>> it seems useful but subject to improvement.
And both Paula and Alexander have expressed similar views.
AM> I don't see the advantage either. I think the present implementation
AM> is an attempt to make things clearer but they have, to me, done the
AM> opposite. :( The filter manager should, IMHO, be just like the address
AM> book in design. All filter rules are made from the same template. You
AM> may create filter sets as you create address groups. All rules gain
AM> their function as you tick away at options etc. to 'carve' it into
AM> shape.
Yes.
AM> If you make the Inbox the source folder, the rule becomes an
AM> incoming filter rule and if the source folder is the Outbox, it
AM> becomes an outgoing filter rule. You should be able to make these
AM> rules executable upon various events, singly or in combination. Say
AM> for example: Toggle switches should be provided to make each rule be
AM> automatically applied upon either receiving mail, sending mail, opening or
AM> closing the source folder, or just to make it plain manual only.
With you on that.
AM> Message attributes should be offered as filter criteria on a per rule
AM> basis, such as, message read, unread, replied, message age, message
AM> priority etc. If flags and color coding are being supported in future
AM> versions then these should be offered as criteria for filtering as
AM> well. Message dates (age) should also be offered as criteria which
AM> could make automatic archiving possible. If message date criteria are
AM> not offered then in the folder properties, instead of simply offering
AM> the option to remove old messages, also give an option to copy old
AM> messages to a particular folder for automatic archiving.
Very good. And if the programming is done on an object oriented basis,
more specific child rules w/ individual variations could easily be
generated from parent rules, in line with the user given file
structure and the procedural activities that accompany that.
Also, all of this could be linked to both the ticker and the present
message search capacity, which allows searching for a single string
only (albeit in multiple locations - even Netscape Messenger does
more, although TB is much better once messages are found).
>> I do notice that filtering does respect the park flag when moving the
>> message.
AM> I'm surprised that filtering moves parked messages. Aren't parked
AM> messages supposed to be messages that are not delete-able or moveable
AM> unless you unpark them? :)
Rules rule. They don't even ask permission or advise you. For me, what
I want (and need) is a way to flag messages, not necessarily park
them, and this will undoubtedly be addressed in future versions. And
if the concepts mentioned above are feasible and implemented in future
versions also (why move things around when links will do), I would say
that TB would stand a real chance of greatly expanding it's user base.
(I say that not in a goal oriented way, but rather as an inference
that the increased consistency and ease of use these modifications /
additions suggest, would result in a highly useful and therefore
desirable and competitive email client / server product.
>> Thanks for running through this with me. We are definitely getting up
>> to speed, and the groups help is unexcelled.
AM> Yes, this has been a fun exercise in filtering techniques.
And useful, in my case. I hope it was in the case of others also.
(This thread has 54 messages on my machine at present, and I'll wager
that more is still on the server - I'm off line at present - since
most TB mail comes in early here, do to the time difference).
Perhaps more will come of it. At the very least it has confirmed for
me that this is where I want to be. (There is no sense in depending on
products that serve primarily to debit a credit card, with no real
concern for the user's continued and successful use of it).
Perhaps there is a greater lesson here. My work deals with community
and (mostly, for now) rural development; and both policy and project
development figure in our area of competence. Independently of TB, we
may have a working model for development here on this list.
Getting back to TB, it will be interesting to wait and see what
RITLabs thinks about this, also.
Best regards,
Douglas Hinds
[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]>
--------------------------------------------------------------
