You are not logged in. Login Now
 0-10   10-34   35-59   60-84   85-92      
 
Author Message
25 new of 92 responses total.
steve
response 10 of 92: Mark Unseen   Mar 7 06:56 UTC 1999

   Well, yes.  I think there will be at some point not so far off.
Whenever I feel human again I intend on working with our 'new' 2G
disks again.
janc
response 11 of 92: Mark Unseen   Mar 7 13:57 UTC 1999

Responses would be doubled only if they were posted via Backtalk as HTML
responses.  I believe that would be the minority of responses.

Ken:  I've added your suggestion to my Backtalk TODO list (which is huge
so don't hold your breath).
krj
response 12 of 92: Mark Unseen   Mar 7 19:12 UTC 1999

It's not urgent, just a fantasy.  Unless it tickles other peoples'
imaginations, I would say, don't bother.
i
response 13 of 92: Mark Unseen   Mar 7 20:46 UTC 1999

Re:  #8
No confession needed, steve.  I run du regularly & understand why "shove
some stuff into /bbs" is often your best available option.  (But if you're
feeling guilty, how about rm'ing or chown cfadm'ing a few of those little
dunno-what-they-are-but-look-like-scrap-to-me root-owned files that are
scattered around /bbs...) 
remmers
response 14 of 92: Mark Unseen   Mar 7 21:18 UTC 1999

Getting back to the issue of HTML in conference postings...

I see some benefits to HTML posting in a conferencing environment such 
as Grex's:

(1) More attractive, readable text via the use of such typographical 
devices as proportional fonts, boldface, italics, underlining.

(2) The ability to display special symbols (such as math symbols) and 
characters from non-English alphabets (e.g. German umlauted characters, 
French accented characters, and so forth.

(3) The capability of displaying images to clarify or illustrate a 
point.

But there are some negatives that concern me:

(1) I presume that HTML responses will be shown in proportional font by 
default, and plain-text responses in fixed-pitch font. The effect of 
intermixing these in random order - which will inevitably happen since 
some people will post using Backtalk and others using Picospan - could 
be unattractive and distracting. (I don't really know how bad this will 
be until I see it.)

(2) Some people will inevitably insist on using "glitzy" features of 
HTML in most or all of their responses - larger fonts, colored fonts, 
animated GIF's. Even a little of this would be a perpetual annoyance.

(3) With most browsers, it is very easy to paste a prepared HTML 
document into a text entry form. (I did so in a couple of responses in 
item 8 of the "backtalk" conference. Check it out, using the new 
version of Backtalk.) I worry that this would make Grex an attraction 
to spammers.

A worst-case scenario would be that conferences in which HTML posting 
is turned on become poster children for the "decline of graphics 
standards" (see Larry Kestenbaum's item about this in winter Agora) as 
well as dumping grounds for spam.

Now, that's a worst-case scenario. The reality might not be as bad. But 
these are some issues to think about.

Have you considered HTML subsets as a configuration option, that is,
allowing certain tags to be selectively turned on or off, at the option 
of the fairwitness? Turning off <IMG> would discourage spam, and 
turning off <FONT> would control certain other forms of potential 
obnoxiousness. On the other hand, there are conferences where you'd 
probably want to allow those tags (e.g. "classified").

The negatives I've mentioned might or might not be significant problems 
in practice. It depends on user behavior.
pfv
response 15 of 92: Mark Unseen   Mar 7 21:35 UTC 1999

        I'd also recommend a "storage format" that is NOT html - so that
        shell-users can ignore the "glop" and Backtalk folks get it parsed
        properly (it's what I';ve been toying with myself).
jep
response 16 of 92: Mark Unseen   Mar 8 16:40 UTC 1999

Will there be a way for Backtalk users to avoid HTML in user messages?  
I'm looking forward to seeing what happens when people start using the 
new version of Backtalk, but at the same time, I can imagine problems 
with HTML in messages which I or others might want to avoid.
remmers
response 17 of 92: Mark Unseen   Mar 8 17:56 UTC 1999

I suppose it could be a configuration option. That is, the user could 
specify that they always want Backtalk to show them the plain-text 
version of a response, even if an HTML version exists. Sounds easy to 
implement.

Speaking of configuration options, are screen colors configurable by 
the user in the new Backtalk? Although I mostly like Backtalk a lot, 
I'm getting tired of being forced to read certain conferences in color 
combinations that I find unlikeable or even downright fatiguing.
janc
response 18 of 92: Mark Unseen   Mar 9 04:57 UTC 1999

I know what you mean.  Coop always causes me eyestrain.

But Backtalk has one basic defect that you have to keep in mind.  Every
new page is a completely new run of the program.  That means
configuration files can't just be loaded once and saved in memory, they
have to be loaded and parsed again on every hit of every page.  The more
configurability I put in, the slower the whole thing gets.  Until I
develop a way to save more state between processes (FastCGI or the moral
equivalent), I'm inclined to keep the number of different configuration
options modest.

So I'm not very enthusiastic about letting fairwitnesses ban individual
HTML constructs.  For one thing, it's confusing for users to have to
remember which HTML tags work in which conferences.

My notion in designing the Pistachio interface was that fairwitnesses
should be able to give their conferences distinctive looks.  I like that
a lot.  Conferences with default color settings actually kind of annoy
me.  It seems wrong for the staff conference and agora to be the same
color.  So, though I find the contrast between text and background too
low in "coop", I do like the fact that I can recognize that it is "coop"
at a glance.

If I let user's override conference background colors, then either all
conferences turn the same colors, which is deathly dull, or I have to
let users configure conference colors on a per conference basis. 
Theoretically, the latter solution is fine.  In practice, I'd have to
figure out how to store not just setting for each user and settings for
each conference, but settings for each user/conference pair.  And I have
to figure out how to find and load those settings fast on every hit by
every user on every conference page.  Glug.

Futhermore, this messes badly with people using
<FONT COLOR=RED>Hello</FONT> stuff in HTML postings, because how can I
be sure that no user has a red background?

So for now my solution is that you either (1) complain to the
fairwitness that his conference colors stink, or (2) use your browser's
preference menu to override the conference color, or (3) highlight the
text with your cursor.  I use option 3 to read coop.
davel
response 19 of 92: Mark Unseen   Mar 9 12:02 UTC 1999

Some of us *like* deathly dull, Jan.
remmers
response 20 of 92: Mark Unseen   Mar 9 20:10 UTC 1999

I don't get the "deathly dull" bit. I did conferencing for years with a text
interface that always looked exactly the same, and found it continuously
enjoyable. So did you.

Somehow, setting up a system in which one has to worry about what color
someone might be entering their text in seems antithetical to the notion of
conferencing being for good conversation.
mwg
response 21 of 92: Mark Unseen   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".
other
response 22 of 92: Mark Unseen   Mar 11 02:27 UTC 1999

i suggest a counterpoint.  making the html tools available may well increase
the amount of junk postings, but they will also offer greatly improved
referencing and illustration of discussion points, especially with the
abilility to paste URLs and tabular information with assurance that the
formatting will remain intact.
rtg
response 23 of 92: Mark Unseen   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.
scott
response 24 of 92: Mark Unseen   Mar 11 11:43 UTC 1999

I disagree with rtg's point 3 right above...  I like the Grex "one long
thread" approach much more than the Usenet model of many forks.  I hate having
to navigate all those little forks...
davel
response 25 of 92: Mark Unseen   Mar 11 13:37 UTC 1999

What Scott said.
aruba
response 26 of 92: Mark Unseen   Mar 11 14:20 UTC 1999

Ditto.  I also don't like encouraging people to respond by email to things
in the conferences.  About half of all usenet responses I have read are people
asking questions, followed by "I don't follow this group, so please respond
by email".  We're interested in building a community of people who stick
around, and the fact that most Usenet groups are not that is one of the major
things that drove me away from it.
pfv
response 27 of 92: Mark Unseen   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.
cmcgee
response 28 of 92: Mark Unseen   Mar 11 18:04 UTC 1999

I too like the non-email stylewe have here.  Occaisonally I have to make a
"way back" reference so that my two cents gets attached to the right response.
But usually, if the conversation has gone on too far, my response is pretty
irrelevant anyway.  And I can always email the person who wrote the original
response.  

One can always use the "q" command to jump to the end of the item for a
response, then go back and continue reading.  
janc
response 29 of 92: Mark Unseen   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?

cmcgee
response 30 of 92: Mark Unseen   Mar 11 23:38 UTC 1999

Could 2a be considered (or is it already happening):  Alt 2 for 1 or two
novice-read conferences?  Just so we can get a feel for how non-HTMLers are
impacted by this.  If Nat agrees, I'd offer small business for a tryout, and
maybe cyberpunk could be asked?
other
response 31 of 92: Mark Unseen   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.
devnull
response 32 of 92: Mark Unseen   Mar 12 12:17 UTC 1999

I really don't like the idea of having personal preferences of fairwitnesses
being forced on everyone; I dno't see any reason why the settings for
agora should be different from the settings in science or the settings
on auction.

(Then again, perhaps agora is a special conference where html would be
reasonable.)

But in general, it would be good if the topical interest conferences could
all be configured the same way.

I don't really use the conferences intended for new users, or the backtalk
test conferences, and if those are different, that's OK with me.

But whatever policy we pick, I hope it's one where the science, auction,
coop, and radio conferences (for example) all have the same settings.

Hmm.  What happens if you link an item between different conferences with
different policies?
jep
response 33 of 92: Mark Unseen   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.  
remmers
response 34 of 92: Mark Unseen   Mar 12 19:33 UTC 1999

I've expressed a concern about the <IMG> tag being potential spam-bait. 
There's another concern, which I hate to bring up, but I think we need 
to think about it. The <IMG> tag will make it very easy to incorporate 
sexually explicit images in responses. All someone would have to do is 
put something like

        <IMG HREF="http://raunchy.sex.com/oh_wow.gif">

in a Backtalk HTML response, and low and behold, the GIF image, even 
though it is not stored on Grex, will show up on the screen of 
everybody reading the response via Backtalk.

Much of the sexually explicit stuff on the web is password-protected, 
but there's a lot that isn't and that therefore could  very easily be 
incorporated in responses here on Grex.

Question: What do we do when something like that shows up?
 0-10   10-34   35-59   60-84   85-92      
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss