Kendra Tools Project Plan
Introduction
- This document is in its early stages of development. It needs some formality. Please help! ;-)
Requirements
- Groupware for collaborative design where people can talk in their own languages.
Terminology
- I'm not using formal terminology in this project plan. I'm coming at this very much from the interface end of things with a spattering of ideas about what to do at the core.
Organisation
- Time Scale
- 8 months from beginning of March 2003.
- need to complete: website and trials.
- 1 month building concept.
- 3 months to build website and trials.
- 3 months to move to more generic platform.
- 1 month to document.
Further Document Requirements
- Need to prioritise what needs to be done within time frame.
Users
- Developers
- Content Owners
- Content Consumers
- Service Providers
- Press
Tools
- Profile
- Users contact information such as addresses [each entity stands in its own right so that many people can be employed by a company].
- Calendar
- Forum
- Wiki, Majordomo, web bulletin board. Email lists with web archiving like Yahoo but better. Need to know which emails are bouncing too.
- Funding
- Connecting people/orgs to funding organisations for their Kendra Participant Projects.
- Accounts
- All financial accounts will be displayed on the website.
- News
- Events And Meetings
- People organise meetings. Link in calendar. Conference organisers enter info about their conferences. This then has to be rated to make sure it passes criteria. Link in calendar.
- Development
Trials
- Network
- To bring content as close to the end user as possible for increased quality.
- Commerce
- To enable payment systems to interoperate.
- Catalogue
- To enable content owners to make their content catalogues available to kendraSystem.
- Interface
- To enable player applications to view catalogue and make commercial transactions.
- Rules
- To codify the requirements of content owners for their content [how much is it? Where can it be shown?]. To codify requirements of content owners for their content [how much will I spend? When do I want it?].
- Content
- To enable content owners to get their content published on kendraSystem.
Concepts
- Interface
- Wherever a user is on the website there should be some standard ways of accessing information. Where a person's name is shown it should always be hyperlinked to their main record. This should go for any object. In some contexts all text will be hyperlinked like to take you through to a translation page for that text. Or a comment page. Or a rate/vote page.
- Object Model
- Any object will link to any object via any link. The data structure should be able to be flexible.
- Reverse links
- So, I am a "son" of Paul and Paul is a "father" of me.
- Views
- The Tools and the Trials are views of the database.
- Language
- It's crucial to the whole project that users can speak their own language. Not only their "mother tongue" but also business language will vary from company to organisation to individual. It's important that we don't shoehorn users into a way of speaking that they don't like otherwise they'll leave the project. So, let people speak how they want. If we are going to do that then we need to be able to somehow link people's words together when they have the same meaning.
Features
- Multilingual
- Initial translations of website and forums can be done by machine to get content but then must enable users to suggest better translations.
- Logging
- Full user/action logging. Got to know what people are doing so we can find out if we're being effective.
- Attribution
- All statements on the system must contain an identifier for the person or organization making the statement. (issues: traceability, anonymity, non-repudiation?)
- Name Space
- Each user would have their own name space. Even within this name space there could be duplicates. For example a user could know 2 people called "John Smith". If a user wants to describe an object then they could use a word from their own or someone else's name space. If it's from someone else's namespace they could freeze definition of that name there or allow it to be modified by the owner.
- The system should also permit shared namespaces, so that groups of users can communicate more easily. Issues: should there be DisAmbiguation (I think so) or a truly global namespace? (I would like to think so, but there are scaling/philosphical issues)
- Content syndication
- All website content must be made available in XML form for syndication.
- Rated users/participants/organisations
- List of translators for all languages, or just one language. Most common poster to forums. Any statistic should be able to be mined.
- Comments
- Feedback for each page. In fact, comment feedback for anything. These comments attached to forums.
- Targeted email newsletters
- Users will be directed to content relevant to them: consumers, service providers, content owners/creators, developers, press... and how often they get updates. So, that means that the newsletters are created dynamically from manually/automated edited content. Users create their own newsletter by picking up content from the website such as financial/accounts and network trial summaries.
- Email
- Every user will get a firstname.lastname@public.kendra.org.uk alias. Users can subscribe to other users to get every email sent by them or received by them. All email sent and received via Kendra aliases will be publically archived.
- Privacy
- Must enable users to set privacy levels for their content.
- Speed
- Speed can be optimised later.
- Security and encryption
- Security and encryption should not be a focus and can be done later if at all ever.
- URL redirects
- Every external URL entered into database so we can log who's going where and how many times.
Technology
- Associated technologies: RDF?, RSS?, SQL?, ...
- Distributed Tools
- All tools must be fully distributable among different hosts and be able to communicate as if they were on the same host.
- Authentication
- Users decide the method. http or cookie or passport/.net (distributed) or another.
- Coding
- PHP (with PEAR), MySQL? (4 for better Unicode support?), W3C valid XHTML strict and CSS. All content (including code) is held on the database and so can be compiled on fly. All code modules should talk to each other via webservices (soap, XML) so that they can be easily distributed over a number of servers if necessary.
- Comment: W3C Valid HTML 4.01 Transitional might be "more compatible" than XHTML Strict for now: implement both and make this a run-time option, changing the default as browser tech improves?
Websites:
![[Home]](/graphics/kendra-small.gif)