Freedom House: Internet Freedom Project Proposal

Company mission, history, services and people

LSNet enables user content websites with Drupal, communications with Google Apps, Internet connectivity through wireless and dial up and personal development through "Bar Camps" -for example http://www.ls.net/node/503.

LSNet began as a rural ISP in 1995, provided consulting services in International Health including mathematical modeling and network development.

LSNet continues to provide local services but about half our activity is in project development.

We are small and depend on developing local talent for larger projects

Browsing http://ls.net will reveal (perhaps too) much of our activity and background.
 

Website architecture, user testing and user interface design experience

LSNet built its first web server and site in 1995 (http://ls.net). 

Early experience included developing database driven websites for the Bolivian Ministry of Healthhttp://www.usaid.gov/regions/afr/leland/health.htm), an OLAP Population website for the UN in Bolivia, an online Census database for El Salvador.

We moved to PHPNuke in 1999, plog in 2002 and landed with Drupal in 2005.

We have developed several local "social" websites such as http://mtvaleumc.org/

Proposed project team and approach

Team

• Jim Tarvid, Engineer
• Robert "Woody" Woodside, Drupal specialist
• Jill Barrett, Editor - Writer

Our standard approach is to "sandbox" an installation at xxx.ls.net by creating the Apache stanza, DNS zone, creating the database, and installing Drupal. This is early in the module season for Drupal 6 so depending on the modules desired we may install Drupal 5. Modules are vetted in the sites drupal5.ls.net and drupal6.ls.net. Conversions are more complicated than new sites but the goal is the same, do the engineering to enable the user/client to dig in and begin the long trek to familiarity.

Timeline and estimated costs for delivering

Documented user types and needs

I anticipate that 4 or more roles will suffice

• administrator
• facilitator
• contributor
• public

The administrator role has global permissions and responsibilities. Facilitators match contributions with resources. Contributors are verified "members" who provide initial content. The public is provided read only access to the information that advances the interests of the organization and its contributors.  We start with the basic four roles and adapt as users interact with the sandbox. This component is part of the initial effort.

Graphic mock-ups for all unique page types

We don't do "mock-ups" but implement the essential page types as part of the initial effort. We find Drupal sites "evolve" more easily than "design". Drupal has its own personality and it is far more cost-effective to draw out its natural capacities than force it to meet pre-determined expectations.
 

A Web style guide specifying standard content types, content attributes, page layouts and all CSS elements

Content types and components and their attributes are self documenting in Drupal. Page layouts for "entities" are intrinsic. "Relations" depend on "views". Simple views such as summary reports are easy but can evolve into complex structures. It is best to start with the easy and let the difficult be guided by user feedback.

The LOE (level of effort) to develop the "sandbox" prototype is one week (40 hours). Our current rate is $60 per hour. Travel expenses are billed at CONUS rates. No travel need is anticipated to get us through the prototype. Thus the budget for the initial effort is $2,000.

Objectives:

1. accessibility by staff, contributors and the public depends on Drupal's intrinsic capabilities and the engineering of its deployment.
2. Drupal is modular to a fault, easily (perhaps too) extensible, has hundreds of modules - most of which work, can be plumbed to other applications but not trivially. It is resource intensive but modern hardware is generally up to the task.
3. Drupal depends on the data base for UTF content and has an extensive internationalization support. Of course, custom constructs require effort to be multilingual.
4. We use FCKeditor as an pop-out option for all textareas. I regularly use Kompozer to build HTML content offline.
5. Workflow has been extensively addressed by "newspaper" sites. I have only read about what that involves but my reading suggests extensive capabilities in workflow management.
6. Incident reporting can be well supported via CCK. Contributors must survive captcha, register with email validation and may be subjected to moderation rules.
7. CiviCRM is a project in its own right. Clients must expect to spend man weeks to exploit its capabilities. We can provide a "sandbox" for exploration and familiarization.
8. We have found that no content should be entered without having an account. Captcha (stupid math questions) have eliminated most of our "spam" problems. Blogs, Forums, Polls are well supported. The petition module is out of date but could be easily constructed with CCK. Surveys can be implemented either via CCK or "webform".
9. The Drupal community is vital as has been mentioned above. Module writing is done in PHP but requires technical experience and is not trivial to implement and maintain. In most cases, the functionality has already been addressed which vastly reduces the cost of development and maintenance.
10. Drupal profiles are extensible and end-user maintainable.
11. Drupal logging facilites are extensive. All content can be "versioned". All content can be exported via PHPMyAdmin.
12. We generally recommend Google Apps for staff communication. Drupal has user to user contact capabilities. The mass mailing module works for occasional mailings but Google mail will not handle mass outgoing traffic. CiviCRM has extensive campaign mechanisms.
13. Some level of research is achievable via "standard" views. Custom views can be added based on SQL queries. Data can be exported easily to CSV and I suspect XML as well.
14. UTF support is mainly an issue in setting up the database. I haven't done text messaging from Drupal but am aware of an SoC (Summer of Code) project to reveal the Google API.

References

1. Robert Varley - http://vekon.com - 3508 Prince William Drive Fairfax, VA 22031 USA Ph: 703-273-1129 Fax: 703-273-1129 varley@vekon.com (Note: LSNet engineered vekon.com, Jill Barrett edited the content
2. Maribel Manibo - http://ipas.org - ManiboM@ipas.org. Standalone Java project.