[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[kDev] RFC: Kendra Tools Project Plan 1...
Hi there All,
I'm starting to write Kendra Tools Project Plan. It's not easy for me
being a very visual guy. It's very early days but I'd like to get as
much feedback as possible so I don't waste time going down blind
alleys. I need to know as much about how one should format such a thing
as well as what content there should be in it. Please do ask questions.
Or, if you're up for really helping out with some collaborative
writing, then even better. Collaboration! ;-)
Comments, questions, assistance please...
Cheers Daniel
1. Introduction
This document is in its early stages of development. It needs some
formality. Please help! ;-)
2. Requirements
Groupware for collaborative design where people can talk in their own
languages.
3. 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.
4. Organisation
4.1 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.
5. Further Document Requirements
Need to prioritise what needs to be done within time frame.
6. Project Modules
6.2. Users
6.2.2. Developers
6.2.3. Content Owners
6.2.4. Content Consumers
6.2.5. Service Providers
6.2.6. Press
6.3. Tools
6.3.2. Profile
Users contact information such as addresses [each entity stands in its
own right so that many people can be employed by a company].
6.3.3. Calendar
Events and meetings.
6.3.4. Forum
Wiki, Majordomo, web bulletin board. Email lists with web archiving
like Yahoo but better. Need to know which emails are bouncing too.
6.3.5. Funding
Connecting people/orgs to funding organisations for their Kendra
Participant Projects.
6.3.6. Accounts
All financial accounts will be displayed on the website.
6.3.7. News
6.3.8. 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.
6.3.9. Development
6.4. Trials
6.4.2. Network
To bring content as close to the end user as possible for increased
quality.
6.4.3. Commerce
To enable payment systems to interoperate.
6.4.4. Catalogue
To enable content owners to make their content catalogues available to
kendraSystem.
6.4.5. Interface
To enable player applications to view catalogue and make commercial
transactions.
6.4.6. 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?].
6.4.7. Content
To enable content owners to get their content published on kendraSystem.
7. Concepts
7.2. 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.
7.3. Object Model
Any object will link to any object via any link. The data structure
should be able to be flexible.
7.3.3. Reverse links
So, I am a "son" of Paul and Paul is a "father" of me.
7.4. Views
The Tools and the Trials are views of the database.
7.5. 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.
8. Features
8.2. Multilingual
Initial translations of website and forums can be done by machine to
get content but then must enable users to suggest better translations.
8.3. Logging
Full user/action logging. Got to know what people are doing so we can
find out if we're being effective.
8.4. 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.
8.5. Content syndication
All website content must be made available in XML form for syndication.
8.6. 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.
8.7. Comment feedback for each page.
In fact, comment feedback for anything. These comments attached to
forums.
8.8. 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.
8.9. Email
Every user will get a firstname.lastname@xxxxxxxxxxxxxxxxxxxx alias.
Users can subscribe to other users to get every email sent by them or
received by them.
8.10. Must enable users to set privacy levels for their content.
8.11. Speed can be optimised later. Security and encryption should not
be a focus and can be done later if at all ever.
8.12. URL redirects: every external URL entered into database so we can
log who's going where and how many times.
9. Technology
9.2. Distributed Tools
All tools must be fully distributable among different hosts and be able
to communicate as if they were on the same host.
9.3. Authentication
Users decide the method. http or cookie or passport/.net (distributed)
or another.
9.4. 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.
10. Websites:
http://www.php.net/
http://pear.php.net/
http://www.mysql.com/
http://www.w3.org/
http://www.zope.org/
http://www.phpgroupware.org/demo/
http://www.common-forum.org/
http://www.common-forum.net/