Difference between revisions of "Website core"

From Drafts
Jump to: navigation, search
(Properties)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[Category:Website development]]
 +
 
What are the priorities of the system? What needs does it have to address first? What we have to do and what is secondary? What is best done by a blog or a wiki and what needs specific development?
 
What are the priorities of the system? What needs does it have to address first? What we have to do and what is secondary? What is best done by a blog or a wiki and what needs specific development?
  
Line 39: Line 41:
 
Priv=not visible to the public; Full=not visible in the quick edit interface; Dlist=dropdown produced from a static list; DBlist=dropdown calculated from the database;
 
Priv=not visible to the public; Full=not visible in the quick edit interface; Dlist=dropdown produced from a static list; DBlist=dropdown calculated from the database;
  
 +
*ID
 
*Name
 
*Name
 
*First name
 
*First name
Line 45: Line 48:
 
*Job/quality(Full)
 
*Job/quality(Full)
 
*Portrait
 
*Portrait
*Language(Dlist)
+
*[[Language List]](Dlist)
 
*Gender(Dlist)
 
*Gender(Dlist)
 
*Country of origin(Dlist)
 
*Country of origin(Dlist)
Line 117: Line 120:
 
=== Sound module ===
 
=== Sound module ===
  
storage and indexation of sounds, recordings, archives, etc. possibly generates streaming.
+
Storage and indexation of sounds, recordings, archives, etc. possibly generates streaming.
 +
 
 +
Sounds are either indexed in other backends: radioswap, cik or 'floating' sounds that will only be indexed in the sound module.
 +
 
 +
Information to mix, connect and shuffle.
 +
 
 +
Properties
  
 +
*ID
 +
*title
 +
*subtitle
 +
*date of production
 +
*date of publication
 +
*lastmod date
 +
*public
 +
*who is speaking?(interviewee+er connected to the participants database)
 +
*persons(roles) - uploader/editor
 +
*projects
 +
*internal comments
 +
*group of sounds?
 +
*annotation(one field or segments?)
 +
*annotations for internal coordination of acquisition/editing, see "infos son" in digitales 2002.
  
 
=== Text module ===
 
=== Text module ===
Line 127: Line 150:
  
 
possibility to add incoming feeds and mix them. per event, programme, etc. Also see how to integrate this into the weblogs.
 
possibility to add incoming feeds and mix them. per event, programme, etc. Also see how to integrate this into the weblogs.
 +
 +
=== Links module ===
 +
 +
=== Downloads module ===
 +
 +
possibility to tag items and have them listed for download, with links back to context?
  
 
== Services ==
 
== Services ==
Line 144: Line 173:
 
language + translations
 
language + translations
 
* at the moment, the amount of languages in which a post is possibly translated is hardcoded and multipl ways of dealing with translations are in place -> homogeneity needed. what are our needs in term of translations?
 
* at the moment, the amount of languages in which a post is possibly translated is hardcoded and multipl ways of dealing with translations are in place -> homogeneity needed. what are our needs in term of translations?
 
+
* important to homogenise the language names (FR in place of FRA, etc) in the database and in the scripts.
 +
* important: when creating an entry in the generic translation framework, we need to give it a language.
  
 
=== Metadata ===
 
=== Metadata ===
  
 
link content to taxonomies, tags, keywords.
 
link content to taxonomies, tags, keywords.

Latest revision as of 12:48, 20 December 2006


What are the priorities of the system? What needs does it have to address first? What we have to do and what is secondary? What is best done by a blog or a wiki and what needs specific development?

Modules[edit]

Image module[edit]

The image module provides a handy way to store images to include as illustrations in articles via a web interface. It is by no means a replacement for the image gallery

function:

upload / resize / generate html code for images

permissions:

image module is contextual. If user is granted access for an event, s/he will have access to the image folder with the same rights.

modifs to existing module:

make one folder per programme/context, adapt to new permission scheme, multilingual?


Guests/participants module[edit]

guests -> replace by participants

guest or team or both?

roles

connect to profiles(access)

This guest has been interviewed in Cuisine interne


Properties[edit]

Priv=not visible to the public; Full=not visible in the quick edit interface; Dlist=dropdown produced from a static list; DBlist=dropdown calculated from the database;

  • ID
  • Name
  • First name
  • Pseudo
  • Title(Full)
  • Job/quality(Full)
  • Portrait
  • Language List(Dlist)
  • Gender(Dlist)
  • Country of origin(Dlist)
  • Date of birth(Full)
  • Name of the organization or add one (quick form)(DBlist)
  • Street(Full)(Priv)
  • Nr(Full)(Priv)
  • Zip(Full)(Priv)
  • City (Full)(Priv)
  • province, state, misc(Full)(Priv)
  • Country(Full)
  • Phone / (Priv)
  • Phone / (Full)(Priv)
  • Phone / (Full)(Priv)
  • Phone / (Full)(Priv)
  • Phone / (Full)(Priv)
  • Phone / (Full)(Priv)
  • Event of encounter(Priv)(DBlist)
  • Description of the context of the meeting (Full)(Priv)
  • Cuisine interne interview(DBlist)
  • Url rel to encounter:
  • Url(Full)
  • Url(Full)
  • (EN)Biography
  • (NL)Biographie
  • (FR)Biographie
  • (ES)Biographia(Full)
  • Medium(primary) (Priv)(Dlist)
  • Medium(secondary) (Priv)(Dlist)
  • Medium(ternary)(Priv)(Dlist)
  • Email(Priv)
  • Email(Full)(Priv)
  • PGP key(Full)(Priv)
  • Url
  • Newsletter subscribed(Priv)
  • Status(Priv)
  • Remarks(Priv)

Project module[edit]

deals with the structure of the events. The project modules has to deal with events at three different 'moments': announce the event, give news while the event is happening, and 'archive' the event.

A project is a long term set of activities, publications, ... that follows a certain thread(ie. Copy.cult, cyberfeminism, Stitch And Split...)

Properties:

  • Start date or period
  • Title
  • Description
  • Url
  • Logo
  • Image folder

Programme module[edit]

A programme is a collection of activities and series. An edition of Verbindingen-Jonctions is considered as a programme.

Series module[edit]

Inside a programme, certain activities can be linked together under a certain title(ie. Free Licenses was considered as a series inside the programme Verbindingen-Jonctions8) To be discussed: a series could spread through different programmes and projects?

Events module[edit]

An event is an activity bound to one place and time(ie a lecture or a concert). It has a start time and an end time. (ie. The Book Presentation in Verbindingen-Jonctions8 is an example of an event)

Publication module[edit]

A publication can be a book, a live CD, a sound, a radioshow, a tvshow, etc. It is not necessarily

Sound module[edit]

Storage and indexation of sounds, recordings, archives, etc. possibly generates streaming.

Sounds are either indexed in other backends: radioswap, cik or 'floating' sounds that will only be indexed in the sound module.

Information to mix, connect and shuffle.

Properties

  • ID
  • title
  • subtitle
  • date of production
  • date of publication
  • lastmod date
  • public
  • who is speaking?(interviewee+er connected to the participants database)
  • persons(roles) - uploader/editor
  • projects
  • internal comments
  • group of sounds?
  • annotation(one field or segments?)
  • annotations for internal coordination of acquisition/editing, see "infos son" in digitales 2002.

Text module[edit]

from writing/versioning to publishing of text + pdf export

Syndication module[edit]

possibility to add incoming feeds and mix them. per event, programme, etc. Also see how to integrate this into the weblogs.

Links module[edit]

Downloads module[edit]

possibility to tag items and have them listed for download, with links back to context?

Services[edit]

the services are components that give generic functionalities for the modules. ie, every module will need translation, permission, etc.


Permission[edit]

to accomodate more users/writers/collaborators, the permission system needs to be adapted

  • who has access to what? we need to think of scenarios for that


Translation[edit]

language + translations

  • at the moment, the amount of languages in which a post is possibly translated is hardcoded and multipl ways of dealing with translations are in place -> homogeneity needed. what are our needs in term of translations?
  • important to homogenise the language names (FR in place of FRA, etc) in the database and in the scripts.
  • important: when creating an entry in the generic translation framework, we need to give it a language.

Metadata[edit]

link content to taxonomies, tags, keywords.