|
|
| Author |
Message |
| 25 new of 92 responses total. |
davel
|
|
response 25 of 92:
| 
Mar 11 13:37 UTC 1999 |
What Scott said.
|
aruba
|
|
response 26 of 92:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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?
|
toking
|
|
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
|
pfv
|
|
response 36 of 92:
|
Mar 13 05:19 UTC 1999 |
This presumes Backtalk is so damned stupid it neither filters
input to axe suchlike ("gasp! censorship!!") nor filters the
output (geez, an echo)
|
remmers
|
|
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.
|
remmers
|
|
response 38 of 92:
|
Mar 13 14:06 UTC 1999 |
Re resp:36 - Pete, if you can figure out how to write software that can
reliably decipher and categorize the content of graphic images, you
could be rich and famous.
|
pfv
|
|
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.
|
janc
|
|
response 40 of 92:
|
Mar 14 01:20 UTC 1999 |
I don't understand what Pete is talking about. IMG tags work in
Backtalk. We could certainly filter them out. I'm not convinced that
we want to.
If an item is linked between a no-HTML conference and an HTML
conference, then html entered from the HTML conference will be seen
in the no-HTML conference. Currently the rule blocks only the ability
to enter HTML, not the ability to display HTML. I could easily change
that, but I'm not sure one should.
I don't understand option (C) in Eric's proposal.
|
other
|
|
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.
|
other
|
|
response 42 of 92:
|
Mar 14 07:18 UTC 1999 |
doing it by item, as the choice of the enterer, would also eliminate any
issues about conference linked items...
|
remmers
|
|
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.
|
remmers
|
|
response 44 of 92:
|
Mar 14 21:22 UTC 1999 |
Heh. I checked. The new backtalk does indeed do sounds. If you're using
a browser that plays MIDI files, try clicking on the following URL for
an out-of-this-world multimedia experience. (But not if anybody in the
same room with you is trying to sleep or concentrate on anything.)
http://www.cyberspace.org/cgi-bin/pw/bt.new/pistachio/read?conf=backtalk&cs
el=&i
tem=8&rsel=38&noskip=1&showforgotten=2
I don't know if Backtalk will clickify that or not since it's so long.
You might have to type it in by hand.
|
remmers
|
|
response 45 of 92:
|
Mar 14 21:27 UTC 1999 |
(It didn't clickify it due to length. But you can probably copy & paste
into into your browser's "go to" box.)
|
aruba
|
|
response 46 of 92:
|
Mar 15 00:07 UTC 1999 |
John, could you give us an example of what kind of attacks you're worried
about? My apologies if you already did and I've forgotten.
|
dpc
|
|
response 47 of 92:
|
Mar 15 01:48 UTC 1999 |
Could we limit sexually explicit HTML graphics to the sexually explicit
conferences? 8-)
J/K. I'm not sure we should allow graphics at all in items
and responses, actually.
|
other
|
|
response 48 of 92:
|
Mar 15 03:35 UTC 1999 |
I have proposed a specific set of solutions to handling html tags in
grex's conferences, and i would very much like to know what issues of
concern it fails to address, aside from that of grex regulating the
content of audio and image data. since we don't much regulate text
data, i don't imagine we need to code such regulation into backtalk,
although we should discuss a policy addendum for handling complaints
about data content on a case-by-case basis. this would be the necessary
planning for eventualities such as the linking of sexually explicit
images or otherwise offensive (to some) image or audio files to grex
conference postings.
Let me summarize my proposed solutions. Please address the ways in
which they do not address the aforementioned concerns. Otherwise,
please feel free to propose alternate solutions. Keep in mind that
unless we focus on finding solutions which address the particular
concerns we present, we are not moving the discussion toward a
satisfactory conclusion.
1) Allow backtalk users to define new items as either plaintext or html
at the time they are entered, by the user entering the new item.
2) Allow backtalk users to specify a preference to either display:
A) only items entered as plaintext
B) all items, regardless of format, displayed in the format in which
they were entered
C) all items, regardless of format, but displayed only in plaintext.
These settings would allow users to specify how they see grex conference
postings, and allows those who are opposed to html postings to
automatically ignore any items entered as html. All settings would be
user-changeable (except item definition) at will, and ignored html items
would be treated as simply forgotten, so they could be manually
'remembered' if the user desires.
|
other
|
|
response 49 of 92:
|
Mar 15 03:37 UTC 1999 |
the above assumes that all items either entered or read through picospan
would be treated as plaintext.
|