Okay, its been a while now since the policy was put into effect allowing unregistered reading via Backtalk was put into effect. Without having any statistics to back it up, it seems like the policy has been a bust. I have yet to come across one person who joined Grex because or after they read it anonymously. I dont think unregistered reading is promoted right on the web page for one thing, its understated and if you blink twice you might not even notice the option is even there. Also if someone is jumping into a conf anonymously, they dont need to be seeing "you have 186 unread items" It should be set up, if possible, so that in unregistered reading, the only unread items are those posted that particular day. That way, an anonymous person will see "there are five unread" or "ten unread messages" which will seem far more manageable. We went through to much grief debating this and setting this up, not to follow up on it and try to improve it so that we start seeing results! ,61 responses total.
Is it too early for me to say "told ya so"? >8) I think that some, if not all, of the folks who supported unregistered reading did it on principle, not just to get new members. If that's the case, then it's not a bust, regardless of the result. OTOH, I would like to hear what folks think of the results of the policy so far.
Dunno. It sure doesn't seem to have been a disaster, at any rate. Lets wait a while to decide. (We have some PR activities coming up that may make a difference.)
Thank you for your second paragraph, Rob.
I recently did a search on Grex, and AltaVista has lots of indexes into various anonymous cf's on grex. If someone was to do a search on agora, for example, they'd get Grex. Don't know how helpful that is... :)
I used the peek syntax once to point a non-grexer to a grex item once. I am glad that the capability exists.
Re 3 - You're welcome. Some of us do think before we type. >8)
I don't think anyone thought that unregistered reading would be a "boon" to the conference activity here, but there was a lot of light and heat coming from some folk, thinking that it was horrid that we'd allow such a thing. So Rob is right--I voted to allow such reading, not because it would attract the hordes, but that it didn't make sense not to allow it. We allow completely unverified telnet access to enable anonymous readings of conferences, so web-style reading isn't much different. If anything is to be changed, I would think it should be in BackTalk, to optimize whatever things that might need it, quite regardless of wether or not the entity reading a conference is registered or not. Now, I haven't used BackTalk enough yet, so I can't say if that should happen or not. It certainly seemed quite good when I used it. But if we need to tweak things, lets do them at the appropriate spot.
Well, yesterday I sent E-mail to Mike Myers (original founder of M-Net). I asked him to comment on my history article. I gave him the URL of that and http://www.cyberspace.org/cgi-bin/bt/peek:agora:44 , the URL of the discussion item in Agora. He read the article and the conference item, and sent me back some comments, including asking for more information on how to connect to Grex. So if he ever shows up, maybe that's one near victory for unregistered reading. Of course, Mike isn't exactly your average new user. Still, one of the ways you can use this is to put links in your E-mail messages or home pages to specific things on Grex you want to point people to. For a pointer to the femme conference do: http://www.cyberspace.org/cgi-bin/bt/peek:femme For a pointer to this item do: http://www.cyberspace.org/cgi-bin/bt/peek:coop:45 For a pointer this response (assuming nobody slipped in) do: http://www.cyberspace.org/cgi-bin/bt/peek:coop:45:8 The peek script is smart enough to use the pistachio interface for unregistered users, and there is a blurb at the bottom of the page with pointers to the registration page.
This response has been erased.
Yup, search engines are the controversy, all right.
An interesting thought. Well, perhaps we should see how many people would scream if say, Agora were open to search engines. I mean, it is the front door of Grex--I think that conference would be a great one to have indexed, and likely keep all the others closed off unless the participants specifically want it opened.
I like the idea of keeping everything but Agora closed. For me, it's a comfortable balance between accessability and privacy.
This response has been erased.
Its OK to have links out there that are bad, in search engine land. Given that Agora lasts 3 months each incarnation, some large fraction of the people who look up in a search engine and find Grex stuff in an Agora will find it. Others will find about the existence of Grex at least, even if they don't find what the search engine produced. Given that, it doesn't take that much effort to look at the url and try it without the file specifics, and wind up at Grex's front door. I don't see anything wrong with that.
This response has been erased.
I was one of the people who pushed very strongly to open the conferences up to anonymous reading, but I'm less comfortable with getting them indexed in search engines. From what I'm remembering of the discussion at the time of the vote, there was a very strong stipulation that if anonymous reading were allowed, steps would be taken to keep the conferences from being indexed. It's one thing to have Grex's discussions out where people may stumble across them, but it's quite another to have discussions which take place on Grex pop up whenever anybody does a search for something contained in the item, or for that matter, the name of somebody who participated in the discussion. I'm sure there are plenty of things I've said on Grex over the years that I woudln't want to be the first thing to pop up when somebody does a search for my name.
Certainly some people will jsut go away, thats a given. But if we sparked an interest, its likely that some people will look us up and see what we offer.
Yeah, but given the way old links hang around, and the way Agora rolls over, after a year or two Grex will be "that place with all the dead links".
If you are going to open agora to search engines, you need to put a warning in the login banner: Anything you write on Grex may be held against you -- forever.
What about putting links in a web page to one of the conferences? Would anyone object to that?
I'm lacking in data. Can anyone tell us:
1. How many people have read/posted anything on Grex via
Backtalk since it has been available?
2. How many people read/post anything on Grex via
Backtalk in a typical month?
3. What is the fraction of readings via Backtalk
which are done by unregistered folk?
I would strongly oppose indexing conferences on Grex for search
engines.
I did some things to specifically discourage search engines from indexing the conferences. However, I am not at all confident that they would index the conferences if I took those blocks out. If I were writing a search engine, I'd make it reluctant to index the output from CGI programs. I don't think we tried to block search engines on HVCN, and it's had anonymous reading much longer than Grex, and I've never seen an HVCN conference page indexed (and I have done web searchs that should have hit it if it had been, like searches for my name, for instance). In short, actually getting the conferences indexed might be non-trivial. You'd probably have to do something like convert the conferences periodically into static web pages and put those up. John Remmers did some software like this once. And I'm not sure I'd like it if it did work. Do I really want anyone who searchs the web for "Jan Wolter" to find every response I've posted on Grex? Probably not.
Hey, I wouldn't mind. I've been trying to get an anthology of Jan Wolter's writings together for several years now, and a search engine that would index all his responses would sure help. :) Yes, a couple of years ago I wrote a back end to Picospan that would convert items in a conference to static HTML pages and generate an index. My thought was that this would be useful for (1) archiving old conferences in easily retrievable and searchable form, and (2) making selections of current items available for easy lookup via Grex's main web page, as an enticement for people to run newuser and become grexers. The program was never installed, for a couple of reasons: (1) people were concerned about search engines indexing the stuff (the mini-controversy over this was a foreshadowing of the HUGE argument about non-registered reading through Backtalk), and (2) Backtalk came along and rendered it obsolete. Of course, my program still exists and could be run to generate read-only search-engine-indexable web versions of conferences. Any objections? :) Note the smiley. However, currently, I don't think there's any rule against me or some other user doing something like this on their own. Simple rule of thumb, folks: If you don't want the world to be able to find and read your words, don't say your words on Grex. The Grex conferences are NOT designed for private, or even limited-access, conversations. Re the original issue raised in this item: Though I strongly favor the unregistered reading feature of Backtalk, I never expected it to bring in huge hordes of new users overnight, or in fact to make much of a noticeable impact on Grex in the short term. In fact, it hasn't. I think the whole heated controversy about this feature was pretty much a tempest in a teapot. I do find unregistered reading convenient as a way of sharing information stored on Grex with non-Grexers. I plan to email the URL of my ragtime item in the music cf. to a couple of people I met at a ragtime festival I attended last week and who I think are good potential grexers. Hopefully the bait will entice them into running newuser. Indeed, if the unregistered reading feature brings us only a few new users this way, I count it as a success. After all, it's more than we had before, and the cost is infinitesimal.
Quite right, John. Grex is open.
So I assume nobody has any answers to the questions I asked in #21 above? How about some rough approximations?
I always thought the debate was way to overstated considering what was being argued. I've always thought that the whole thing was kind of irrelevant.
Re #25: Yes, it would be worthwhile to collect usage statistics on these kinds of things. We do have much of the raw data needed to get some kind of answer to those questions, though it is buried in huge masses of other data. I'd be interested in doing that, but it is much lower priority than getting the 4/670 up or getting the next release of Backtalk out. I think Mark Conger had expressed some interest in developing programs for some statistic-generation tasks, but I haven't heard of he'd found time for that.
No, I haven't been able to sit long enough to work on those yet. Soon, I hope.
Well, janc, can you tell just from glancing thru the data if just a handful of folks are using Backtalk, or a whole bunch?
The data is not in a form that you can "just glance at". With a little grepping I can figure out that there have been 208 "hits" on backtalk in the last week. After some cutting and sorting, I was able to figure out that these hits came from 48 different IP addresses. I would guess that this is on the order of 35 to 40 different users.
Ok, thanx! So we're talking about a quite small percentage of Grexers coming in thru Backtalk.
What percentage of conferencers is that? Careful how you downplay it.
Of course, there's no way to know how many different people ran picospan in a given month, so we'll never know. :)
Well, it seems to me that part of the problem is people aren't yet using backtalk to it's full capacity. For instance, when and if I get off my ass and get my web page made, I'm planning on putting in a link to the anonymous version of the Amalgam conference. I'd be curious to see what sort of use that'd get...
I don't think it's a "problem" that very few Grexers are using Backtalk yet. It's still under development and will take a while to become popular. The speed is still a major issue. Yesterday at M-Net's Bod meeting, Dave Thaler, the author of a similar system called WebYAPP which M-Net uses, discussed speed. Apparently the big slowdown is when someone starts up WebYAPP it has to invoke a *lot* of M-Net system processes, so for the present at least telnet is a lot faster than access from the Web.
That hasn't particularly been my experience with backtalk.
Well, backtalk is certainly slower than either telnet or dialin for me, but perhaps I'm alone in that.
This response has been erased.
That just might do it. :)
I think ISDN has helped Backtalk be easier to use. We know it has some performance issues, but they are not in backtalk itself, but rather they are inherent in the stateless nature of an http connection. Still there are ways to cut down on this overhead, and Jan recently outlined some improvements he plans in this area. For conferncing a lot, picospan wins, but for incidental conferencing, backtalk wins because you bypass the queue and don't have to log in and start picospan. I have no idea how webyapp compares to backtalk in the area of performance.
I don't know enough about webyapp to say for sure, but I would expect Backtalk to be pretty similar in speed, perhaps a smidgeon faster. I think both are stateless (unlike webcaucus), both interpret scripts (though I think Backtalk's script language is about as fast as it could be, so it might slightly outperform webyapp there), and both are based on the somewhat inefficient Picospan file structure (though Backtalk uses some additional index files to speed things up). My own assessment is that Backtalk still has some ways to go before it is the best conferencing system around, but it is already pretty competitive with webyapp. It's probably however that M-Net has a slightly less overburdened machine right now, which may be more than enough to consume any basic difference in software performance.
'stateless?' What is?
This response has been erased.
One of the reasons that PicoSpan has a fairly unsophisicated database, is that when running, PicoSpan can keep a lot of state around and do things fairly fast. For instance, whenever you read an item, the first thing it does is scan through the item to build up a structure in memory that says where all the responses start for the item.
And then the in-memory structure persists as long as the user "stays in" the item, so that going back and re-displaying previous responses is fast. A web-based conferencing program can't keep stuff in memory between accesses because the web just isn't designed that way -- any host resources allocated to a user go away as soon as a page download is finished.
Let's assume there's no queue. Does the discussion about web-based conferencing being "stateless" mean that web-based conferencing will always be slower (and hence less satisfactory) than telnet- based or dialin-based conferencing?
Depends on your definition of "satisfactory". Web-based systems let me type at speeds limited only by my own PC speed, use client software that I like, and use client software that is friendlier to (for instance) voice dictation software than a term program would likely be.
It should be possible to build web-based systems that are just as fast as text-based systems. Faster even.
It may be quite difficult to design something as efficient (frugal with system resources) using a web interface as with text. Designing something that is "just as fast/faster" is not a problem if you assume hardware that is sufficiently cheap & fast. There are some messy GUI issues, however, that make this a bit less than straightforward.
To get just as fast, you need to go to persistant processes of one time or another - a true client server relationships. To get faster you need to move a lot of processing over to the client, maybe something like a Java applet running under your browser which keeps track of participation files and stuff like that. Assuming your computer is faster than 1/64th of Grex, this should be faster. All of this is possible. None of it is easy. It definitely does require breaking away from the standard way of building web applications.
If you have a slow network link, then it can't be "just as fast"; with
a straight text interface you can start to read before it all appears,
and you don't have the packetizing overhead on both input and output.
Also, with persistant processes, you have to have more central machine
resources (memory, etc.) because it's not always possible to detect
when the user has abandoned their session.
Efficiency is not a win with web based stuff.
The 2 wins of web based stuff are
(1) local full-screen graphical stuff. Buttons, and boxes, and
pictures, and sometimes even more.
(2) ubiquitous. Nearly everyone has a web browser, and understands
the technology.
This response has been erased.
It depends on the browser. Still, it's not likely most people would care to page through more than one screen-full of text before all of it is shipped over.
Drift: Are there other web-based conferencing systems out there besides Backtalk, suitable for a small company's internal use? Is Backtalk available for use (for a price, surely! :-) by a small company for its internal use? I assume that Backtalk depends on a Unix-based web server, as opposed to, say, a Windows NT-based server?
Albaugh, WebYAPP is a web-based conferencing system which is used (at least) by MacWorld. E-mail thaler@m-net.arbornet.org for details.
This response has been erased.
Lynx (right here on grex) uses the same library as mosaic, and has the same "no text until it's all here" behavior.
For a good database of web conferencing systems, check out http://freenet.msp.mn.us/~drwool/webconf.html Backtalk, is, of course, the best conferencing system on earth (or on any of the outer planets and associated moons), so you don't really need to look at that.
In particular, does Backtalk depend on being run on a Unix-based web server?
Yes.
However, I just recently went from completely blank computer to full linux setup with working backtalk in about a day, so that's not too much of a problem. Granted, there's not much traffic on backtalk, unless I go and type something, but hey, it's my own PC. :)
You have several choices: