response 26 of 49:

Feb 13 22:30 UTC 2000

do we have a license for our use of picospan, or did we purchase a copy?
do our legal option allow for the modification of the source code for our own
use, so long as we do not distribute the modified version?
and, would there be a legal issue with our being provided an uncompiled source
code to a program we have the legal rights to run? (again, so long as we do
not distribute)

response 28 of 49:

Feb 13 23:05 UTC 2000

Incidentally, having source code to a product doesn't
necessarily buy you as much as one might think.  Suppose
Grex purchases a source license for XYZ Conferencing
Software, Version 2.1.  Some Grex staffers invest a
lot of effort into modifying it so that it does certain
things the way we want.

A year later, XYZ Version 3.0 comes out, with lots of
nifty enhancements, but which doesn't include our own
modifications.  What do we do -- upgrade to 3.0 and
modify it for our needs all over again (which might be
a lot of work, depending on how different 3.0 is from
2.1), or stick with a now-obsolete version of the 
software?

response 30 of 49:

Feb 14 06:09 UTC 2000

Whoa there, I think you people are getting way way carried away.

Let's look at the current situation with PicoSpan.  What happens when
you currently join an existing conference is easy to describe.  It does
something by default that is very nearly the right thing.  & it doesn't
take any work to make it continue to do what it does.  That is, it's a
good "80%" solution, and that's important, because it's one of those
compromise cases where it's hard to do a lot better than 80%.  Jan has
evidently made a slightly different compromise in backtalk - evidently
he was faced with a UI where it was not so attractive to present a lot
of different options for what to read next, & so wanted backtalk to be
"smarter" about what it showed people.  So far, I haven't heard any
evidence that what it does is actually "better"--just "different".

Now let's look at some of the proposals above.  One was to make
everything "new".  Does this help the newbie in agora?  No.  Does it
help the long-time user of grex?  No.  Another suggestion was to make a
selected set of items near the end "new".  There were (if I recall
right) 2 sub-proposals for how to do this -- some sort of threshold
selection logic that is likely to be expensive to compute, and a manual
system where the fw selectes what's new.  The former is hard even to
describe and has all sorts of fuzzy parameters that are difficult to
characterize.  I don't believe it would be possible to come up with an
automatic system that would be materially better than the current sytem.
No matter how you slice it, there would still be "new" and "unseen"
stuff, and in agora especially, you are only increasing the amount of
stuff they see automatically -- which is just just wrong (we already
dump *way* too much automatic stuff on new users.)  The latter requires
that fw's maintain that list, which means it's going to be out of date.
It's the same as the "agenda" problem in Confer II.

I think some of you people who are so keen to change things need to
spend some time watching new people actually learn to use grex without
prompting (this means you need to resist the urge to tell people what
they should be doing, even when they ask you), and see what they really
do when they're forced to rely on their own intelligence and what they
see on the screen.  Then, you need to do this over & over again, because
*each* person is different.  Even this won't do anything to help you see
effective solutions, but it will at *least* show you what some of the
problems are.

So far as seeing effective solutions go, the first hard fact you have to
realize is, for many cases, there *is* no effective solution - computer
conferencing is intrinsically interesting to a very small subset of
humanity.  The 2nd hard fact to face is, you can't *tell* someone what
they should do, and expect them to learn.  This may be
counter-intuitive, because our entire educational system is designed
around this theory.  Nevertheless, it remains the fact that the best way
to learn something is to *want* to solve a problem, and to be open,
creative, curious, and willing to experiment.  This is hard to study,
because we're all taught that this is bad, and this is particularly hard
to study in in new people learning to use grex, because they *don't*
want to look stupid in front of you.  The last hard to face fact is, in
any system where you are faced with a lot of different people with
different expectations, there is no one answer that will work for
everyone--in fact, there's no one answer that will work for *most*
people.  This means you are inevitably in the "filter" business -- you
are designing a system that will catch some people's attention, and piss
a lot of other people off in the process who will go elsewhere.  So, one
of the choices you are making when you design a system like this, is the
sort of people you want to attract to the system.  I can tell you right
off that the sort of people I wanted to attract when I designed PicoSpan
and newuser for m-net was "smart people who want to yak a lot." If my
goal had instead been "get stupid people to say something at once", or
"get as many people on at once as possible", I might have designed
things very differently.  Having said all that, I'll also say that there
are things I would do differently in PicoSpan if I were to do it over
again, in part because we have better computers today, and in part
because I've learned lessons from PicoSpan.  I hope to get the chance to
do just that someday - it's one of those "get around to it" things.

response 32 of 49:

Feb 14 11:49 UTC 2000

As far as I know, it's hard-coded into Picospan.

Re resp:27 - right, not an issue with Picospan.  My comment was
directed at the notion of having source code for a product that's
still under active development, like YAPP.  Keeping a local
version in sync with new releases of the product is not a small
task.

response 34 of 49:

Feb 15 04:06 UTC 2000

I don't know the answers to any of Mary's questions.

Let me describe what Backtalk does when new users join a conference.

By default, it does *exactly* what Picospan does.  The first and last
item are marked new.  All other items are marked "unseen" so that "read
new" will not display them on the user's first visit to the conference. 
If the user visits the conference a second time, all the "unseen" items
that have had activity since the last time he was there will be new.

Using Backtalk, the fairwitness can change this default behavior for his
or her conference.  They can do either or both of two different things:

  - Change the list of items that are new on the first visit.  Maybe
    for some reason item 5 contains information that you think all new
    users should see on their first visit.  You could add that item to
    the list of items that are "new" on newuser's first visit.  This
    can be very useful - if you have "rules" for the conference in a
    frozen item that is not item 1, then with Picospan many new users
    will never see that item, because with no responses showing up on
    it, it will never be new.  But although this is useful, it is not
    a general solution for the problem.

  - Make all items which have had activity in the last X days new.  So
    I might say that for the agora conference, the first item, the last
    item, and all items that have had activity in the last 24 hours
    should be new.  Thus, the user sees on his first visit exactly what
    Picospan would show him on his second visit, if his first visit had
    been 24 hours ago and if he hadn't actually read anything on his
    first visit.  I think this is better than the default behavior,
    because it makes things seem just a little more lively on his first
    visit, without drowning the newuser in a lot of dead old items.  For
    this to work well, the time period X has to be chosen appropriately
    for the conference - more active conferences should have a smaller
    X value than less active conferences.  (It might be nice to be able
    to say you want the 10 most recently active items to be new, but I
    haven't implemented that.)

Note that Backtalk's behavior is really a very small refinement on
Picospan's behavior.  The basic concept of "unseen" items that aren't
shown to new users until there is activity on them is an excellent one. 
I'd think making all items new for new users would be much more
obnoxious (though it is possible for a fairwitness to do that in
Backtalk, and it might even be useful to do so in a conference like
Auction which will never get very big).

response 36 of 49:

Feb 15 13:08 UTC 2000

I don't think there's quite that, but I'm sure it's feasible for
a program to be written, external to Picospan, that you could run
and that would have that effect; i.e. if the program were called
"mun" (for "Make Unseen New"), you could type

       mun agora

to have every unseen item in agora marked as new.  Or a more
elaborate program could be written that mimics Backtalk's more
complex behavior that Jan describes above.  If you invoke the
program *before* joining the conference, then it would have the
desired effect.  (Jan's hypothetical "awfulprogram" was essentially
that; the only "awful" part was the kludgy technique for
invoking it automatically on the user's behalf.)

response 38 of 49:

Feb 15 17:23 UTC 2000

Ah yes, that's definitely simpler.

Yes, there's a system-wide .cfrc equivalent, whose name I don't
remember offhand.

Regarding the issue that Eric raised in this item:  I definitely
prefer the current default to simply treating every unseen item
as "new".  But I think it should be easier for users to find out
about the "read unseen" command.  It's useful in the way Joe
just described -- to browse older items that haven't seen
activity for a while.

response 40 of 49:

Feb 15 21:01 UTC 2000

It might be useful if the Agora login screen displayed something
like this:

        Type:

          read          - to read material new since your last visit
          read unseen   - to read items you've never seen
          read since -3 - to read material posted in the last 3 days

(Actually, you'd want to display this to Picospan users only, not
Backtalk users.  Hm, how to do that...)

response 42 of 49:

Feb 16 13:27 UTC 2000

Yes, you're quite right.  Picospan and Backtalk login screens
can be different.

response 44 of 49:

Feb 28 07:00 UTC 2000

i'm curious about that, too.  it would be good to know.

response 46 of 49:

Mar 3 06:49 UTC 2000

 or, of all else fails, we can just make a note to bring it up u
nder new business.

response 48 of 49:

Mar 11 22:58 UTC 2000

Small lull in discussion. I haven't gotten to the subsequent items yet
(haven't read coop in a while), so this may be redundant. I think the the main
argument against this is impact on new users. So there shouldn't really be
anything wrong with setting it up as a personal option (except for technical
aspects). So we should do it.