Kendra Website Update
Latest News:
Aug 2009:
This page is now to be maintained by DarrenMothersele
Website migration to Drupal
Kendra Website Tasks
OTHER TASKS:
Some other required tasks to be defined under a separate project: Server configuration (staging/production), version control (Subversion).
WEBSITE TASKS:
Tasks required for migration of website and implementation of new requirements:
- Define structure of Drupal website in terms of required Content Types, Taxonomies, Modules and other configuration.
- News section
- Participants (user profiles)
- Mailing list
- Wiki
- Events
- Projects
- For each object in current website(s) define how to migrate/map data.
- website pages
- wiki
- mailing list archives
- user profiles
- trials (to become projects)
- configure xml output of data for archiving and future migration
- Select appropriate social networking modules for Drupal and configure
- Passive data creation (for example, people who are featured but not registered)
- Printable views and PDF export
- Group functionality (dynamic mailing lists)
- Setup Drush
- Usernames/display names (see below)
- Pages for ingress points (wiki pages) for different classes of people
Overview:
The Kendra website has been built organically over the years, bolting on a wiki and majordomo. But it lacks many of the features expected of today's websites - such as RSS feeds.
The Kendra website needs major development for two reasons.
- It is an operational information repository. Kendra is a distributed virtual organization and the website is "the office". The Kendra website needs to support all the operational work undertaken by the membership.
- The Kendra website is also an essential marketing tool. It is used for communication both among the membership, and to prospective members and the media.
- There will be different momentum, motivation and goals depending on the marketing vs. operational perspectives.
Note: this list was made without detailed knowledge of Drupal so there may be things that are difficult on the list and things easy that we could add to the list.
Transfer Header:
(Something like this...)
- Newownername: Darren Mothersele
- Newowneruser: darren-mothersele
- Newpagename: Kendra Website Update
- Newpageurl: kendra-website-update
Requirements:
Mandatory or important requirements are identified by the use of the word must. Optional requirements are identified by the word could.
Pervasive Basics:
- Development:
- The site must be upgradeable to latest releases of Drupal easily and painlessly. That means developers can't hack the main code of Drupal. That means that all development work has to be done in custom modules. Please verify this.
- Internationalisation:
- Internationalisation must be possible from the start with a clear and defined procedure for making translations. For documents the master language will be English and all translations will slave off those. So, pretty much word for word translations - not like Wikipedia does it - more like GNU.
- Single Sign-in:
- There must be a single sign-in. No matter where you are on the site you only need to sign in once.
- Usernames, Display names, handles
- The unique identifier is a number that is never displayed. Users enter their own Display name (their real/full name) as a profile item. Override theme function to display full name rather than the unique id. When second or subsequent people come along with the same display name, add a disambiguator to end of name. If someone a search for real name then they come up with a disambiguation page for names. Display optional handle after real names -- but only if two people of the same name exist on the system say we only have one Neil Harris, their name would be displayed "Neil Harris" but if a second one joins, the first would be displayed as "Neil Harris [neilshandle]" and "Neil Harris [otherneilshandle]"
Public Facing:
- Moving Current Website:
- As a minimum, the website must support all the functions of the current Kendra website in terms of email list management, wiki, archives, trials, etc.
- The site must allow Kendra branding to be applied to the site, with a consistent user interface.
- The site must comply with relevant W3C standards about usability and accessibility.
- The site must support the needs of non-technical users as well as hackers.
- The site must easy to access through a corporate firewall.
- All data from the existing Kendra website must be copied over to the new site.
- All user passwords and login details must be copied over to the new site.
- The implementation must involve zero pain for Kendra users. They shouldn't have to do anything.
- All user/pass login details should be ported over with no changes.
- The following must be moved across:
- Registration:
- Current users should be able to send invites to their colleagues.
- Profiles:
- The site must have user profiles.
- Users must be able to update their own profile.
- Users must be able to set view permissions for their profile to either:
- Public
- Members only
- Connections only - (business/friends/family from set of all members).
- Users must be able to post a photograph on their own profile.
- Users must be able to post their company logo on their own profile.
- Users must be able to link/point to their company name from their own profile.
- Profiles must be searchable by name, location, organisational affiliation.
- Users must be identified throughout the site by their real name not by a userid or wikiname.
- A user's ID must not be exposed anywhere on the site.
- Should be able to create people and companies even if they aren't registered. So, we have a unified address book where some people "own" there information and some are just placeholders where we can store info about people and companies. And track what we have said to them and how we can target them, etc.
- Data:
- The site must enable people and organisation entities to be created by the users without having to be owned by who they are describing. That way we can run outreach campaigns and have membership targets. When targets become members they can take over their profiles.
- Blogs:
- The site could allow users to write a blog on their profile.
- Document Management:
- Kendra members will often work in groups producing documents which are subject to a formal review process and version control. Therefore, the site must support document management with formal version control.
- The site could support workflow for the drafting of formal documents.
- The site could allow formal documents to be searchable separately from other types of content.
- The site must store a master copy of any piece document (piece of content).
- Edits must be applied to the master copy of a document.
- Edits must be audit trailed so that changes can be analysed and, if necessary, backed out to an earlier version.
- Look And Feel:
- The site must fill the whole page (and not be limited to a certain width) like http://en.wikipedia.org/wiki/Main_Page, http://www.htmldog.com and http://drupal.org .
- The site must stay looking nice with fonts of at least size 20.
- The site could have a pure CSS with no tables.
- The site must use full web standards: CSS, etc.
- The site will use the user's browser default settings for colours, font size and typeface, but with attention to typography for clear readability.
- The site must use have a automatic anchor menu created from all anchors in a page.
- Groups:
- The site must allow users to belong to groups (or teams or working parties or clubs).
- Users must be allowed to belong to more than one such group.
- The site must support threaded discussion groups.
- Conferencing:
- The site could support real time chat / Instant Messaging.
- The site could support online videoconferences.
- Email:
- Aug 2009: Email/discussion integration. Mailman with archives and integration, or post notifications with Mail-to-web
- Bounce management and abuse address.
- Email must be integrated into the content management of the site.
- Email must only be used for one-way communication, not for discussions and not to allow copies of documents to proliferate.
- Users must be able to send and receive emails using an account of their own, not a special Kendra account.
- The site must allow users to subscribe to email alerts which tell them (for example) when content they care about has been changed.
- Email must be archived on the site as searchable content.
- The site must check for outgoing emails which bounce and have an exception handling routine.
- Extensive use of personalised URLs in newsletter/alert emails set out from the project to enable recipients, in one click, to: register for an event; subscribe to a group; rate an issue up or down; and so forth.
- Mailman and loose integration:
- Mailman has moderation, loop detection, etc, will have to do this ourselves for tightly coupled solution, also things like list archivers, Google Groups work well with mailman
- Drupal Notifications and Mail to Web:
- Drupal notifications can be enabled on all Drupal objects, thus potentially turning anything into a mailinglist.
- Social Networking
- Select appropriate social networking modules for new Drupal website. This includes: avatar images/avatar select, relationships (one way / two way), profiles (address book data), privacy options (need to specify how much is publically visible).
Development Environment:
- Tracking: Task, Time and Work
- Need to have something where we can create tasks and then child tasks and then log time worked against those tasks. Bear in mind that the time worked may not be a nice complete fit to a task. So, for any given period of time worked, a number of tasks could be worked on, and non of them yet completed. But obviously from the task view we'll be able to see who's worked on that task and when and how much.
- "Task Creation" is where the task is actually created/defined/described and "Task Action" is details about it being worked on. The spreadsheet isn't up to tracking "complex" tasks and time worked but it's a start. Also, after a task is created it needs to be authorised for actioning - working on. And then after work has been done it needs to be authorised for payment.
Development preferences:
- 1st pref: pure PHP + PHP modules
- 2nd: PHP and external non-PHP modules via PHP calling interface
- 3rd: PHP script invokes external program or web-service
- 4th: roll-your-own programming in PHP
- 5th: roll-your-own programming in anything else
- Want to package everything as Drupal modules: however, may need to specify external dependencies, ie "install this Drupal module, but you must have X package installed to make this function work"
Companies to quote for CMS update:
Structure:
Useful Drupal references:
Design:
Simon Trask's email with some good website design questions!
RDF Stores:
ARC performs well up to a few hundred thousand triples. If you need to store more than that, look at Java based solutions like Jena, Sesame or Virtuoso. Also, Mulgara.
Migration from Perl flat-file stores:
mysqlimport -u user -ppassword --fields-terminated-by='::' dbname flatfile.txt
![[Home]](/graphics/kendra-small.gif)