Years ago I posted an item in agora proposing that Grex host blogs for it's users. Hardly a cutting edge proposal, even then, but it seemed like a good idea and was generally approved of. I started work on some modifications on Backtalk to provide a blog interface. And then I stopped. In the last month, I picked up working on this again, and maybe I'll get it done this time. I'm hoping to be able to get a demo version up within the next month or so. Here's basically how it would work. There would be some web page somewhere where people who have a Grex account can sign up for a Grex blog. Doing this, would give them a blog that would be accessible at (in my case) http://janc.cyberspace.org/. Obviously the "janc" would be replaced by the user's login ID. The blog would be pretty much your basic blog. You'd be able to choose from some pre-defined "skins" that control the appearance of the blog, or create your own skin via a rather complex web interface. (This mostly already exists, and I was able to generate skins the pretty nearly clone three random blogs that I regularly read.) RSS would be supported by the blogs, as would trackback (I think). Blog owners will pretty much rule the roost in their own blogs. They can decide who can post comments (anonymous users, people with Grex accounts only, only selected Grex users, or nobody at all). They can delete unwanted comments from their blogs. They can open their bogs up so others can make postings, and so forth. From a technical point of view, of course, the blogs are really backtalk conferences in disguise. Each blog is implemented internally as a conference, with the owner being the fairwitness, items being postings, and responses being comments. It will actually be possible (though unusual) to view the blogs via the usual backtalk abalone interface or via fronttalk. It will not be possible to read them from Picospan, because Picospan would let random people post, which is undesirable in a blog. I want to emphasize that from an administrative policy point of view, I think these blogs should be treated as a separate service from Grex conferences. The established free-speech rules on Grex conferences would not be changed. In Grex conferences, fairwitnesses are treated as "owners" of the conference content in any sense. In Grex blogs, the blog owner would be quite explicitly the owner of the blog. So though at some deep down level the software would be the same, these would be separate services from an administrative point of view. Blogs will probably not appear on the "list of conferences" in the grex conferences. From the blogs it may be possible (if the blog owner chooses to include a link) to get a list of "other blogs on Grex", but that won't include grex conferences. It will not be possible to link items from the blogs into conferences or other blogs (unless the blog owner permits it). It probably would be possible to link Grex conference items into your blog, though that would be weird. My inclination would be to allow people to do things like place google ads on their blogs. Obviously that would never to tolerated on a Grex conference. My plan at this point is, once I get the software to a usable level, to just put it up on Grex as an "experimental service". The blog sign-up page will include a warning saying that the blogs may disappear, or the features and capabilities of the blogs may change without notice during the experimental period. We'll have a discussion here, and we'll either modify the blogging software or remove it, depending on how people feel about things.16 responses total.
I *really* like this idea
I'm all for it!
Sounds great.
Just to be an echo- I like it too. :)
Anne, that's not an echo. That's participation in Grex's most critical user feedback mechanism. Truly, being an active participant is sometimes that simple.
While I am not so fond of blogging for myself (I prefer to communicate via email, these forums and instant messaging), I see this as a product that would be welcome and might help with recruiting efforts. That said, if a couple of people here started keeping weblogs, I would probably look at them, at least occasionally (yes, that means you Dan, and UnixPapa).
I'm curious how you'll exclude linking to blog items from conferences. A lot of people blog because they want what they have to say to be visible to the world. For that to work, their blog has to be discoverable. Currently, search engines are off-limits to Grex conferences, via the robots.txt exclusion. It would be cool if Grex blogs were not subject to this exclusion, or at least that one could choose to opt out of it, so that the blog is indexed by Google and is findable via Google Blog Search, Technorati Blog Search, and similar tools. (In general, I'd like to see Grex more visible on the web...)
I certainly think that it would be nice if blogs could be searchable. As for linking to blog items from conferences, I think that can bring up some interesting issues. But what about the opposite? I mean, one of the things that would be an advantage to me as a blogger would be the ability to write an entry, post it in agora as an item and then link it to my blog.
One of the things I like about Livejournal, and dislike about Vox (yeah, I have accounts all over) is that Livejournal allows for threaded 'conversations' and Vox doesn't. Would it be possible to make the Grex Blogs work in a threaded fashion, so a person could reply specifically to one comment rather than the way conferences currently work?
In a sense, threading is already possible in Backtalk - you can say, for
instance "re resp:6" and Backtalk will create a link back to response
#6. I guess that's not really full-blown threading in the sense it's
usually meant on mailing lists and usenet groups, though. Not sure I'd
want that - when discussions can branch into sub-discussions and
sub-sub-discussions, following the whole thing becomes exponentially
cumbersome. I like the strictly linear response structure that one has
in conferences here, and also in most blogging software.
Grex blogs provide an opportunity to make the rest of Grex more visible.
I'd like to see sidebar links to the Grex home page and Backtalk
entrance page on every blog page, for example.
Again on the subject of linking, can the Backtalk blogging system avoid
the auto-linking flaw that currently exists for conferences? What I'm
talking about is this. Consider the statement:
Be sure to check out item:agora,14 for the latest Happy Hour news.
Backtalk will link this to item 14 of the current Agora, which as I type
this is indeed about the Happy Hour. Three months from now, Agora will
have been restarted, item 14 is likely to be about something completely
different, and the above statement will be wrong, making me look like an
idiot. :)
I guess Backtalk is doing the best it can with that, given that there is
no built-in system of "unique identifiers" for items that is guaranteed
not to change over time. I'm just wondering if this can be avoided for
the blogs, or even some day remedied for the conferences too.
Hey, and what's the problem with being an idiot? Some of my best friends are idiots! ;-) By the way, I'm really happy this blogging bit is going forward. Thanks, Jan.
Controls on linking: I'm currently writing a new access control scheme for Backtalk. This will give very fine grained control of access in a conference. Depending on the conference configuration, these permissions will be editable either only by cfadm or by fairwitnesses for the conference. On Grex the fancy configuration settings will only be used for blogs, where they will be settable by the blog owners. You'll be able to control exactly who may post, who may edit, erase, etc. You'll also be able to control who can link items out of the conference, what conferences they can be linked to, and which items can be linked. The default will probably simple be not to allow linking out of blog items. Of course, this wouldn't in general, prevent Picospan from linking an item from a blog to a conference, since Picospan won't pay any attention to my access control settings. But Picospan won't even have the blogs in it's conflist, so it won't know those conferences exist, and won't create any links from them. The problem with the item:4 references in linked items, really goes back to the fundamental half-wittedness of Picospan's data structures. I could solve the problem by expanding out the links at post time, so that an links like item:14 would be automatically convertedinto item:coop,14. But even that wouldn't suffice, because if coop restarts we'd want the" coop" will no longer point to the same place. Really we want ite m:coop9,14 (or whatever). Here "coop9" is something we hope will be a uniquename for the conference, good forever. But, in fact, given the Picospan data structures, there is no way to find such a uniquename for a conference, or to ensure that it remains unique. To really solve this problem requires creating some new data structures, and leaving picospan compatibility in the dust. Probably a good idea, on the whole. Having trees of responses instead of a linear list of responses is sort of the other major model of conferencing. Backtalk inherits some low-level infrastructure for that from Yapp. In yapp, when you respond to an item from the "respond or pass prompt" they you can say "resp 13" to say that you are responding to response 13 of the item. Yapp still displays the responses in chronological order, but responses entered that way will say <responding to response 13> or something on that, so the "parent" of the response is stored. I could write an interface that would actually display these as a tree. Then you'd be able to have a dual view of the same item. From one interface, it would look like a tree of responses, from another interface it would look like linear list of response, with a lot of them having "Re: response 23" kinds of headers. I have never actually implemented a hierarchical interface though, probably mostly because I was never really very fond of them. It'd be nice to do in an AJAX interface, where you can expand out arbitrary subtrees though.
I, too, prefer a linear interface. I agree with remmers that with a "threaded" interface, "following the whole thing becomes exponentially cumbersome." A linear interface is more conversational. The discussion flows the way a live conversation with all participants in the same room at the same time would. For that reason, I'd rather not see a "dual view" of the same item implemented, because it would encourage some participants (those using the threaded interface) to veer off onto multiple tangents, creating the "sub-discussions and sub-sub-discussions" remmers mentioned, making it difficult to follow no matter which interface you chose. A linear interface tends to discourage that. Anyone who wants to veer off on a tangent can always start a new item.
Not in a blog: only the blogger can start new items. I think some will find the 'threaded' view more useful. If the programmer wants to write it, let's see how it works.
I find the tree interface more useful- in blogs. You can keep a running conversation between a couple of people going without necessarily cluttering up everything. The way Livejournal does it- you get a page of responses to a posting, if the responses reach a certain number than the entire response to a response will not be shown, just the header and who posted it. Plus the non-blog owner can have an easier time of it. Vox doesn't do this and often people will post a comment and then have to remember to come back and check to see if their comment got responded to and there isn't a quick visual way to do that. From my personal organizational preferences it's a neater way of keeping conversations together. Sure, a posting is kind of like a discussion at a party, however, even at a party you're more likely to talk to one group of people, then move to another group and so on.
Re #14: Maybe the blogger should be able to choose whether the linear, threaded, or both views are available to his/her readers. Re #15: Yes, at a party you may move between groups and take part in multiple discussions, but this is more like multiple items than it is like multiple threads within an item. Multiple threads is something that would be impossible to do live. It would mean taking part in multiple discussions simultaneously, as well as starting new discussions on the fly, and continuing the old ones as well. The human mind is incapable of the level of multitasking that would require.
You have several choices: