response 26 of 37:

Aug 6 16:08 UTC 2004

Cool.  I need to read up on rss.  That certainly has applications.

Backtalk is open source.  In theory, anything can be done with it.

response 28 of 37:

Aug 6 18:54 UTC 2004

Re. 24:  Agendae, you mean.

response 30 of 37:

Aug 9 18:03 UTC 2004

The potential advantage of a client program is speed.  I like the
backtalk interface better than the picospan one, but I wind up 
using picospan because it is faster.  There is also no reason the
client couldn't keep the server up-to-date on participant information.
In essence the client would be a cache and display program.

As to the "fixseen problem", really there are two.  The minor one is
that it does indeed mark things as seen.  Leaving no way to look at
the unseen stuff later.  Now if it marked things as something else,
say skipped, you could go back later and see what you missed.

The major problem is the need for Fixseen and conference restarts.
Picospan and Backtalk tend to bombard new participants with lots
and lots of old stuff.  There may be no perfect solution to this,
but I have two ideas.

 - Present items so that the one with the most recent response goes
   first.  This would tend to direct people to the most active stuff.
   It might also get some items to end sooner, cutting down on ones
   with hundreds and hundreds of responses.

 - When presenting an item with tons of unseen responses, at first 
   display only the ten most recent, or maybe as many as add up to
   6KB, or whatever to stop the deluge.

response 32 of 37:

Aug 10 14:44 UTC 2004

Actually, in picospan items can have three different states - seen, new,
and unseen.  Then you first join a conference the first and last items
are marked "new" while the rest are "unseen".  "Unseen" items are not
normally shown when you do a "read new".  You can do "read unseen" to
see both "unseen" and "new" items.  However, if at some point after you
first joined the conference an "unseen" item gets a new response, then
the entire item becomes new.

There is nothing wrong with the "fix seen" command - it does exactly
what it is supposed to.  Paul however seems to want a fourth state for
items to be in "skipped".  I guess you could mark items as "skipped" and
then they wouldn't come up unless you did a "read skipped" at some later
date.  This is different than the "postpone" command, where the item is
new again the next time you read the item.

I suspect that something like this could be accomodated if we did the
agenda thing - you'd just create a private agenda containing items you'd
like to come back to later but don't want to read now.

I have a file of notes on item types somewhere.  It was part of a scheme
for automating restarts and making better choices about what to show new
users.  It had to do with flagging different items different ways.  One
way to flag an item would be as a "rolling item".  Examples of rolling
items are the "why are you happy" item or the "vanity plate" item.  When
you read a conference for the first time, you'd see only the item text
and the 20 most recent responses to a rolling item.  (You could, of
course, go back and see the rest if you wanted.)  On the other hand, for
an item where someone enters a newspaper article and people discuss it,
you probably don't want this behavior.

Note the "rolling" flag would be an attribute of the agenda, not of the
item.  So the same item could be flagged as rolling in one agenda and
non-rolling in another.  Restarts would also be modified.  I see three
possible restart models for agendas:

  - Periodic restarts, possibly automated, like agora1, agora2, etc.
  - Archive.  When items are removed from the "petunias" agenda, they
    get placed in the "petunias-archive" agenda.
  - None.  Items removed from the agenda just vanish.  Actually they
    probably get placed on a "deadwood" agenda which automatically
    catches any item that is on no other agenda.

If you do restarts, you should be able to flag items as persistant. 
These items would automatically be carried over into the new version of
the agenda when you restart, retaining the same item number within the
agenda.  Then new version could be just a link to the old one, or it
could be a new copy.  For a rolling item, probably the last N responses
would carry over.

Biggest issue with agendas would be how to handle the posting of new
items.  I think there would be different schemes at the option of the
agenda organizer.  On any given agenda, the organizers could define the
set of users who can add items (either new items or linked items from
other agenda) to the agenda.  At one extreme, anyone could be allowed to
insert items, at the other extreme maybe only the organizer.  An
in-between solution would be to have a separate "petunias-new" agenda to
which anyone could post, then allow only the agenda organizer to move
things from there to the "petunias" agenda.  Readers could read either
or both.

Plainly there needs to be a limited hierarchy of agendas - within the
petunias agenda we could have petunias.new, petunias.archive,
petunias.1, petunias.2 etc.  All would share the same set of organizers.

response 34 of 37:

Aug 13 00:41 UTC 2004

Can you think of some way not to mark items with new response from twits as
unseen, or is this not a problem in backtalk?

response 36 of 37:

Aug 15 18:09 UTC 2004

I've changed my mind on how items should be ordered.  I now
think the item with the highest predicted score should go
first.  This assumes there is score pridiction of course.

Also it would be nice if entering a new item was as easy as
entering a response.  "Respond or pass" sort of encourages
people to respond, but there is no similar prompt for Enter.
Backtalk provides a box for new responses, but not one for
new items.  An "Add as new item" by the "Add Response" one
would be nice.