— now feed filtered (NF) : the good stuff that should get through now and needs attention
— later feed filtered (LF) : the stuff that can wait but could be attended to if the now feed is not overbearing
– bad feed filtered (BF) : the bad stuff that shouldn’t get through ever
– unknown feed filtered (UF) : the stuff that needs attention because you don’t know what the hell it is … or your intelligent agents don’t know what it is … this, i suppose, comes full circle to your NF or (perhaps profoundly) to SOMBODY ELSE’S NF.

— feed speed (FS) : this is mostly to do with NF attention … how much can an individual take?

As an example, take existing mail protocols and “priority” settings (which nobody uses as far as I’m aware until they have an emergency … so they are pretty mush useless on the front-end).

Lets say you have a feed-based office with IM to the desktop/pda/user and you let users and groups dictate their feed flow. Everybody in a “company” starts out with the same level of access to one another and the same NF priority. Naturally, a given person is going to pay more attention to messages from other people based upon various personal and group criteria that are established outside the computing realm. This needs to be encoded into the system.

The simplest example I can think of is, lets say, Peter and Zoe are close (friendly) and are working on a project together. They are usually very focused when they communicate through IM so they would like to prioritize those messages … they make them RED or something physiognomically similar.

Typically in IM systems the color would be associated with a person. In a more refined system the “colour” (lets say mtag?) would emerge from whatever criteria are established by the users and groups communicating. As the message moves through the feeds, it’s mtag can change … and a user can dictate how their system responds to that mtag … and how their system’s responses are changed by the mtag’d messages that reach them.

mtags can be used by the system to work out somebody’s “feed load” and balance things accordingly … eg rather than Peter setting his messaging system to say “I’m on vacation, I’ll be back next week”, the system could just assume he is (he didn’t log in lately) and it could start to redirect or deal with messages differently

Or when Zoe tries to send Peter a message asking if he?d like to have lunch, the system implicitly (NOT explicitly) assumes he can’t because he’s accepted a lunch meeting with other business partners and responds to Zoe automatically, because Peter trusts Zoe, that Peter would love to (as usual) but that he’s had to go to a business lunch. Rather than having to overtly click through Peter’s schedule, Zoe has just done what she would have done had Peter been IHF (In Her/His Face) … she asks him and he explains why. Staring at a calendar becomes unnecessary.

From an administration perspective, your messaging systems would send you a message when a user hasn’t logged in for a while and suggest that you change the way you deal with them because in the past you have removed those users from the system after a certain length of time … and all this based on lightweight messaging rather that intricate click-through settings.

sorry, a little vague and jumpy but … my screen stares at me.

The problem with depending on this stuff for things like meeting schedules would be the exceptions when it gets it wrong — you can’t afford to have your systems screw up when you need to be in a client meeting…