[Imc-alternatives] newswire vs. knowledge-base

[strypey at riseup.net]

Kia ora koutou

The purpose of all this theorizing is to get clear in my mind what we want the
site to present to the first-time user, and what the repeat user can customize.

I wrote:

>> So it seems to me we have to decide between the importance of these
>> two functions in the way we design the front page. Are we going to go
>> with a traditional IMC format (imc list, features, solutions-wire),
>> emphasising the alternatives news functions. Or are we going to
>> emphasise the activist networking functions?

Jay replied:
> I've actually always viewed the alternatives site as both, and this 
> is what would help give it power.  I still picture a front page with 
> a top feature, that either an editorial collective or user-ratings 
> would choose, and alternatives solutionwire running down the side of 
> the page, with a list of categories somewhere on the page that would 
> take the site user into our knowledge-base.

So how do we fit all these into one front page in a way that makes sense to a
new user? Following the traditional IMC format, we know we have our features
column in the centre and the open-publishing wire on the right. I assume to
fulfill the membership criteria of the IMC network we will need the cities list
on the left, but this can be quite small (see somes IMC sites where the regions
can be clicked open to show links to all the IMCs under each region). So that
leaves us with some space in the left sidebar, and possibly in the 'razorwire'
space at the top of the features column.

Perhaps the left sidebar could be used for the knowledge-base for Alt-IMC? Maybe
by adding the ability to edit the IMC list for their user account, like a set of
bookmarks - adding (or removing) site links under geographical categories (which
they can also edit). Perhaps the razorwire space could be used to display info
delivered by the activist networking functions chosen by the user (eg events;
feeds from lists, blogs, podcasts; streams; irc channels, instant messaging
etc). Or it might make more sense to divide those functions between both
razorwire and the top (or bottom) of the left (or right) sidebar.

These modules in our front page could use another site as its back-end - using
the web services Aaron describes. Where appropriate, an Indymedia server but it
could also be openplans.org or another site that most supports the kaupapa
(cause) of the group/ project. This separation of user interface from hosting
provides a relatively seamless user experience, while spreading the hosting load
and avoiding a single point of failure.

For example, let's imagine we used our site to organise our own project (after
all, if its not useful for our own project whose project will it be useful
for?). Each of us could have our activist networking account set up to include a
chat window in the razorwire which automatically logs into Che and joins up to
the alternatives channel (and any other channels we pre-set) whenever we visit
the site. If we make the site our homepage, we can chat together whenever we
open our browser.

The same approach could also help to integrate IMC sites, and the Indymedia
network resources - like indymedia.org, docs, irc, lists etc. This chat module
could be re-used on any IMC site. Anyone reading the site could automatically
join into a live chat in that IMC's irc.indymedia.org channel.

One possible drawback is the workload it would put on the user's browser, and on
Che. Can anyone more techy than me comment on this? Another is spam and other
abuse of the channels. A 'join chat' button in the entry field of the chat
window, with a captcha to keep bots from joining, would solve spam. As for
abuse, is potential abuse a good reason to keep people from gathering freely in
public space? As with the open-publishing newswire, I think the potential
benefits of user interaction outweigh the risks.

> On the other hand, Indymedia sites have been pretty awful at 
> developing a respository for accumulated knowledge, and that's 
> something we've been talking here about changing.

That's not entirely true. Docs.indymedia.org has housed an incredible body of
documentation about Indymedia itself. However, there has been a consensus that
to keep Indymedia network resources like Che (irc server), Sarai (list server)
etc from getting overloaded, they should be reserved for the Indymedia project.
I think this is a valid concern, which is why providing a portal to other
hosting options makes sense to me.

The archives of lists.indymedia.org lists, like this one, also accumulate
knowledge but it's a complicated process to summarize the ideas flowing through
lists on Twiki. We can put links on docs pages to list postings in the archives,
but we can't edit the posting (although we can comment on it on the docs page).
What would be cool is something like Jiglu.com spaces where list and open wire
postings, and features, can be dragged onto the wiki and edited, while a static
copy of the original remains chronologically archived in its original form.

There's a lot of brainstorming in there. Hope it all makes sense.

RnB
Strypes