Improvement of the FFII member participation system ("Aktiv")

Topic: What can we do to further improve the participation system?

Feedback via eMail to aktiv-helpffiiorg please.

Also see AktivInternals, for an explanation of the innards of Aktiv.

User Interface

(For all planned changes, please try to keep in mind that since Sept.2002 about 40.000 supporters have signed up using this system and are thus to some degree accustomed to the current UI-structure)

Site-Structural Improvements

(How do the pages relate - where do we put the various functions)

(tbd)

Process-specific improvements

(Example: The member-signup process/procedure including payment-selection)

(tbd)

Page-specific improvements

(local improvements on specific pages)

(tbd)

HTML-Layout Improvements

(The site-wide visual layout that our Aktiv pages follow)

My original goal was, to keep each Aktiv-template an entity that can be viewed in a browser or processed using a Web-Editor. To some degree, this has been useful, since it facilitates changes by others without them having to know much about the systems internals. However a site-wide layout cannot be easily maintained that way. Therefore I'm about to switch to a more (HTML-)fragment-based approach.

A header and footer template needs to be defined that is included by all pages.
Use of <TABLE>s for formatting needs to be unified over all Aktiv pages (historically grown & somewhat chaotic).
I've been playing with using more CSS (also as a replacement for <TABLE>-based layout) but we need to support the broadest set of browsers possible. CSS for layouting plus real browser independence is a "science" by itself...
Forms must still be usable on Lynx e.g.
mwas: I do not enjoy tweaking HTML and CSS to produce the desired visual result (not to mention the brwoser-specific issues!). Hopefully we can find someone who does!

Performance

Problem: genba (the server that Aktiv runs on) is charged with too many tasks. Even the plain web pages (www.ffii.org and swpat.ffii.org) are served extremely slowly at times. Reaction time in a ssh shell logged in on genba exceeds 15 secs at times. This had been improved a few weeks ago by our admins (better network card, config tweaks) but things became worse again the week of Oct 20. Some measures for off-loading genba have not yet been implemented (moving images to another server, moving the Eurolinux petition to another server). Update 04/2004: Since Zope is off off the genba server performance has improved a lot.

Resource Consumption

Make it a mod_perl handler
Reduce extensive logging performed by Aktiv (Done in 04/2004)