|
|
| Author |
Message |
| 25 new of 92 responses total. |
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.
|
devnull
|
|
response 50 of 92:
|
Mar 15 04:27 UTC 1999 |
What would people think of having two agora-like conferences, one of which
would have all the html features enabled, and people like me wouldn't bother
reading at all quite likely, and another one with no html features enabled?
|
srw
|
|
response 51 of 92:
|
Mar 15 19:56 UTC 1999 |
Eric is proposing that the HTML feature be established for each item.
Currently it is allowed by conference, and turned on for each response.
Doing any of this per item is a different approach than the one we've
taken so far. I'm not very compelled by the benefits.
This feature is an important feature for backtalk because there are
competing programs that offer it, and we get requests for it. Other
licensees of backtalk are generally very different from grex, though, so
there is no a priori belief on our part that this feature would be best
for Grex.
I agree with Remmers that enhanced text display, and hyperlinks would be
advantages. We have hyperlinks already, but HTML would allow hypertext
where the word is the link, rather than the URL.
I think inline images could be useful, but clearly they could also be a
vulnerability. Out of curiosity, I'd like to see it here, but I don't
have a good answer for worries about inappropriate images. Even sounds
may have some use, perhaps in the music conference.
Tags can be turned on or off individually within backtalk. It's easy
(for me), although it has to be done in the code. There's an implied
argument in that statement that it would be a good idea to allow it to
be done with a site configuration, but that's not planned.
|
janc
|
|
response 52 of 92:
|
Mar 16 15:37 UTC 1999 |
Here's a link to John's musical response in the backtalk test
conference:
http://www.grex.org/cgi-bin/pw/bt.new/peek:8,38
Backtalk currently allows EMBED but no BGSOUND. I'd personally be happy
to see EMBED go away.
Maybe we need to find ways to do at least per-site configuration of what
tags are allowed. Per conference configuration is a bit harder.
|
toking
|
|
response 53 of 92:
|
Mar 17 17:03 UTC 1999 |
and I quote:
conference 8 does not exist
|
mwg
|
|
response 54 of 92:
|
Mar 17 18:10 UTC 1999 |
If any form of HTML is to be allowed, a means of blocking the whole mess
would be a good idea. I've mentioned that, in the past, the
controllability of the responst had an inverse effect on the content, HTML
would likely result in messages with less than no content, if that makes
any sense. I really think that flat text is the best way to run a
conferencing system, and the increased formatting control of HTML is not
just asking for problems, it just about forces them to happen.
If HTML is not to be avoided completely, a user-settable ability to block
items/conferences/whatever containing it should be available.
I still hold that avoidance of HTML is the sane course, give that whatever
credence you will.
|
pfv
|
|
response 55 of 92:
|
Mar 17 18:37 UTC 1999 |
I agree:
The ability to accept boldness/fonts is one thing,
author-specified colors and images are another.
yer back to what I said earlier. been There, thought That.
|
dpc
|
|
response 56 of 92:
|
Mar 18 15:09 UTC 1999 |
I'd also appreciate an HTML-blocker.
|
janc
|
|
response 57 of 92:
|
Mar 21 18:51 UTC 1999 |
Ugh. I misentered the URL above. Should be:
http://www.grex.org/cgi-bin/pw/bt.new/peek:backtalk,8,38
|
janc
|
|
response 58 of 92:
|
Mar 21 19:20 UTC 1999 |
What exactly would an "HTML blocker" show you instead of the HTML
formatted output? A "plain-text" version, like what Picospan users see?
Or should it just make all such responses hidden?
Personally, my inclination is to turn the thing on and then fix problems
that actually appear, instead of trying to fix all the problems people
imagine might exist.
We went through a huge agonizing discussion about enabling anonymous
reading, with lots of people worried about how it would change or
destroy the spirit of the conferences. I implemented a "shylist"
feature, enabling people to filter their responses so anonymous readers
wouldn't see them. There are now five people on the shy list, one
reaped, one who has never posted a response to any conference, and one
who has posted exactly one message which contained six words and four
punctuation marks. The other two are fairly active participants. The
shylist was worth implementing as a nod to feelings of people who were
worried about anonymous reading, but in retrospect the whole frabble was
over a problem that never actually materialized.
My personal theory is that all the theories above about how HTML will
lead to disaster will not turn out to be correct. However, I have no
evidence at all for this theory. I am not enthusiastic about doing a
lot of coding to address problems that may or may not happen. I'd much
rather TRY IT, and if there are problems, FIX IT.
I've got a dozen different people with different worries and concerns,
and different ideas for what I should do. I can't code to that spec.
|
mwg
|
|
response 59 of 92:
|
Mar 21 23:02 UTC 1999 |
You can only do what you see as reasonable, we can toss in input, but in
the end, the staff makes the decision.
The reason I am arguing so hard against this is that the nearest
equivalent to this issue that I have direct experience with, that of color
text on the old dial-up BBSes, has a known and predictable consequence
that I do not want to see repeated here. If HTML can be useful, people
can chuck a pointer in thier responses to a real web page for things like
diagrams.
If HTML gets permitted, just make sure that there is a stripped
translation used for non-browser types. If the past is any guide, such
stripped posts will be fairly obvious from thier 'content'. The other
point, be sure that the support can be easily turned off, should it prove
necessary.
|
aruba
|
|
response 60 of 92:
|
Mar 22 00:16 UTC 1999 |
Re #59: Grex policy decisions are not up to the staff, though the staff of
course has to make decisions if no one else speaks up. But any policy issue
may be put to a vote if a member asks that it be so.
|
scott
|
|
response 61 of 92:
|
Mar 22 11:59 UTC 1999 |
There actually are some color responses out there, in the older conferences.
|