[Updwww-devel] The front and back end

[David T. <da...@pu...>]

Hi all,

While you guys are working on the back-end database stuff, Tina P 
(another volunteer) and I have started thinking about how the site will 
look to users. Since the power of organizing online is that you can 
target content to users' interests, it makes sense for us to present 
tailored web content. Below I lay out the reasons for tailoring the 
content, and the technological need this implies.

The issues which probably need the most discussion are (predictably) at 
the end, and mainly have to do with how we interface between a content 
management system (CMS) and the tools you are writing now. What do you 
think (respond to the list so everyone can see)?


How tailoring content is more effective
---------------------------------------
The value that UPD adds is that we coordinate different specialized 
communities so that they act in concert, and maximize their influence 
over processes that have been dominated by corporations which coordinate 
their strategies. Targetting information is crucial to this strategy in 
three scenarios:

1) Targeting content is very effective for public domain issues that 
span several borders. For example, if the broadcasters treaty we're 
working on now goes through in its current form, it will make it harder 
to reuse broadcasted video. People in the UK might care about that 
because it means they won't be able to "remix" video on their computer, 
or because documentary filmmaker will be hobbled in their work. But in 
India, very few people remix video, and they don't produce many 
documentaries. The broadcast treaty screws them by making it harder to 
access educational content. So if someone from the UK comes to the site, 
we want him to see something different than someone in India, because we 
want to maximize the chances that each will take action.

2) The broadcast example covers the case where there's a single issue 
(in this case a multilateral treaty) that will affect many countries. 
But there may be times when an issue directly affects only a handful of 
countries. A recent example is Australia's agreement with the US last 
week to "strengthen" their copyright laws to create a market for US 
goods. In that case we would have wanted Australians to come to our site 
and see, "Watch out, the US is bullying your country into adopting 
harmful copyright provisions! Write to the president!" And we would have 
wanted US users to see, "Our trade reps are bullying Australia, write to 
the US trade reps!"

3) The most obvious case is one in which there is an issue which 
directly affects only one country. And in that case we want only users 
from that country to see the issue.

It's easy to target content for these three scenarios via e-mail, once 
we have country affiliations in our database, but it's slighly trickier 
to do with the web. We have to query users for their country the first 
time they come to the site, remember it every time thereafter, and send 
them to the appropriate page.


Generating the content
----------------------
So far I've only covered content consumption, but the other side is how 
we generate the content. To cover IP issues all around the world, or at 
least try to target global issues to the interests of particular 
regions, we're going to need a team of people. It's too much labour for 
1 or 2 people to collect information and re-write it in a 
locale-specific way, and it's less efficient than a team which can tap 
into more sources of information (the Slashdot lesson).

If we have a team of content generators who research and write content, 
then we need to make it easy for them to submit the stuff they produce. 
But we don't want to give everyone FTP access, and although we will need 
some kind of moderation process, we don't want to have a bottleneck 
person who has to physically format and upload everything.

So my conclusion from this is that we need to use a "Content Management 
System," (CMS) which makes it easy to target information to users' 
interests, and easy for several people to submit content, with some kind 
of moderation process.

There are several pre-packaged open source programs that have gotten 
good reviews, but I'm concerned about how we can make these interface 
work with the applications you are working on now. There are two 
packages that seem ubiquitous in the non-profit world:

Plone - runs on Zope, uses Python, doesn't naturally interface with 
MySQL, as far as I can tell. http://www.plone.org

Drupal - runs on PHP, uses MySQL to store information. gets the best 
reviews. http://www.drupal.org

I would really like to use Drupal, since there seems to be a lot of 
support for it, and as far as I can tell it has a decent-sized 
development community. But, it uses PHP, and it's unclear to me whether 
PHP works with Perl. This paper, section 4, says yes:

http://www.theperlreview.com/Articles/v0i7/php.pdf

But the developers at Slashcode say no:

http://www.slashcode.com/faq.shtml#SlashInstallation1

I'm not sure how to evaluate this. Lots of non-profits are using Drupal, 
so if your Perl scripts *do* work with PHP, that means they could 
interface with Drupal, which would mean that the community of users for 
the tools you are making would be large. That would be good.

The final option is Slashcode:

http://www.slashcode.com/
http://sourceforge.net/projects/slashcode/ - uses Perl and MySQL

Slashcode is a possibility suggested by James, and it is used by 
Slashdot. But its documentation is poora at this stage, and the 
community of people using it isn't as large.

What should we do? Can we tell whether Drupal will work with your 
scripts? Or are we locked in to Slashcode?

OK, now I'm going to get some dinner... :)

David