response 21 of 92:

Mar 10 20:12 UTC 1999

My experience in the old Dial-Up BBS community showed that the ability to
fancy up messages with color and such effects had the fairly consistent
result of reducing the system to a drivel farm.  Color became an "avoid
flag" when I was wandering around systems.  I'd much rather see the whole
idea dropped like a hot phaser than implemented, because this road has
been trod before, and the serious conferencing types do *NOT* want to go
there.

Responses to the effect that the color codes and such will not be visible
to the Picospan users aside, I expect it to be very easy to identify
heavily-"treated" messages from thier "content".

response 23 of 92:

Mar 11 09:22 UTC 1999

I hate to rain on your parade, but I'd veto all HTML postings, period. 
There's so few people who know how to do it well, and so many who do it
poorly or inappropriately, that it gets in the way of understanding
people, rather than facilitating it.  If the response box is just a text
box, and there is no editing help to make sure the tags entered are
syntactically correct and balanced, I can predict more eyestrain from
even the unintentional typo.

What I would like to see:
1) repeat the item #0, or at least the title, just above the response
box, as a reminder of what the topic is, and maybe we'd have less drift.

2) Provide a link by each response, with target mailto: the person who
wrote that entry.  Hopefully, this would re-direct the chatty asides and
jibes to email, and streamline the conference, so I wouldn't have to
stay up all night reading...

3) Make the system more heirarchical, less linear.  I'm thinking like
the old compuserve forums, where it was possible to respond to a
response directly, and the system kept track of the threading.  It's
annoying here to read something, and want to respond, then I have to
wait until I've read another forty responses before I get a response
box.  By then, I'm sure no one would know what I was trying to say.

response 25 of 92:

Mar 11 13:37 UTC 1999

What Scott said.

response 27 of 92:

Mar 11 17:56 UTC 1999

        As far as color and such, what would be nice is something akin
        to the yapp/picospan .cfonce file...

        Currently, I've got all the color and reformatting I want, (well
        excepting that 'more' whacks the color, periodically). This would
        perhaps be a case for a User Style Sheet? 

        While toying with my own bbs stuff, I considered ('am considering')
        System Style Sheet, Conf Style Sheets, User Style Sheets: each
        capable of overriding the others to the left.

        Setting a size-limit on the User defined styles, and uploading
        them as part of a users "record" - and filtering them defensively 
        - would satisfy everyone concerned. Further, it ain't all that
        more complicated that diddling the .cfonce files - and is prolly
        easier in the end.

response 29 of 92:

Mar 11 20:46 UTC 1999

So we need somehow to converge this to some kind of decision.  I see
three alternatives:

 (1) Allow no HTML postings anywhere on Grex.

 (2) Default HTML postings off, but allow fairwitnesses the option of
     turning them on in their conferences.

 (3) Default HTML postings on, but allow fairwitnesses the option of
     turning them off in their conferences.

Does anyone object if I go ahead and implement option (2) above?

If so, what procedure for making a decision should we take - more
discussion followed by board vote, or a member vote?

response 31 of 92:

Mar 12 02:44 UTC 1999

how about this:

allow users to set either html or plaintext format for items as and when they
enter them.

give all users a setup choice between reading A) all items in the format in
which they were entered.  B) all items in plaintext.   and  C) *only* items
entered in plaintext.  

this setup option could be user-changeable at will.

response 33 of 92:

Mar 12 15:07 UTC 1999

I really like the idea of giving the fw's the choice of whether to allow 
HTML.  This will allow experimentation -- anyone who doesn't like the 
choice made by the fw can start a new conference.  It won't take long, 
using this approach, to find out whether HTML is useful, and whether 
it's intrusive.  

response 35 of 92:

Mar 12 20:12 UTC 1999

if it popped up in poetry, I personally would have no problem with
killing the item/response

response 37 of 92:

Mar 13 13:43 UTC 1999

Re resp:35 - If the image showed up in a response to an existing item,
you would indeed have a problem with killing it, since fairwitnesses
don't have the power to censor individual responses.

response 39 of 92:

Mar 13 18:20 UTC 1999

re 38:

        Doc, I can't imagine he'd want to have Backtalk shoving pics
        upstream, hence, he'd want to snip out the IMG stuff..

        I didn't imply or mention categorizing goofy formats.

response 41 of 92:

Mar 14 07:13 UTC 1999

option C) would be for those who are so against html posts that they don't
even want to consider reading an item entered to allow html posting.  it would
treat all such items as forgotten by default, and only display items entered
as plaintext.  

i think that having the person entering each item be able to determine its
html/plaintext format is ideal.

response 43 of 92:

Mar 14 20:58 UTC 1999

Yes, as currently set up, the new Backtalk supports the <IMG> tag. I'm
curious whether it also supports such things as <EMBED> and <BGSOUND>.
Might someone reading an item suddenly hear sound coming from their PC
speakers because someone stuck in a link to a MIDI file somewhere?

Regarding HTML posting, I see it as providing three separate
capabilities:

(1) Enhanced text display - proportional fonts, automatic formatting of
lists and tables, support for non-ascii character sets such as ISO Latin
8859-* for display of characters in foreign alphabets.

(2) Hypertext - links from responses to other items and responses, and
to resources on the internet. Actually, the current Backtalk implements
this, since it recognizes and "clickifies" URL's and has a special
syntax for referencing other items and responses.

(3) Multimedia - inline images, music, sound effects.

I can see how (1) and (2) can be beneficial in a conferencing
environment. We already have (2), and I'm glad we do.

My reservations are about (3). Our text interface has been extremely
successful in realizing our goals of information-sharing, interpersonal
interaction, and community-building. Lots of people are decent writers
and conversationalists. However, very few are decent graphic designers.
(Witness some of the color choices that fw's have made for conferences.)
Distracting images can interfere with the flow of text. Yet it's so easy
to embed images using HTML, that my worry is that the capability would
be overused and shift Grex away from our main goals. I've mentioned
other reservations about images earlier: An open newuser plus images in
responses provides a new and I'm afraid too-tempting way to attack Grex.
(If you don't see what I'm talking about, I'll be happy to explain
further.)

Anyway, my current thinking is that I'd be a lot happier with the idea
of Grex being used as a testbed for HTML posting if multimedia stuff
such as images was either not supported or could be selectively turned
off on a per-conference basis without throwing out HTML altogether. If
I'm being a stick-in-the-mud, please set me straight. Do people think
our users would be conscientiously self-regulating about multimedia
posts in the same way they've been about text postings?

The Backtalk developers - Jan Wolter and Steve Weiss - must think that
HTML posting is a good idea, because they put a lot of work into
implementing it. It's clear that they'd also like to try it out on Grex.
I'd be interested in what each of them sees as the benefits to Grex from
having it.