29 lines
1.1 KiB
Markdown
29 lines
1.1 KiB
Markdown
|
= was man noch machen könnte
|
||
|
|
|
||
|
|
== Uhrzeiten im Portal
|
||
|
|
|
||
|
|
Die Uhrzeiten (Beginn, Ende) wurdem im Kalender im title-Attribut für den Link nach dem Ort eingefügt.
|
||
|
|
Das gleiche wäre im Portal noch offen, aber wo muss es rein?
|
||
|
|
|
||
|
|
== Events im Portal, Link im Zweifel auf den Kalender
|
||
|
|
|
||
|
|
Wenn ein Eintrag für Events oder News keinen Link hat, sollte der Link auf das Datum im Kalender verweisen.
|
||
|
|
* Datum im calendar muss einen anchor erhalten
|
||
|
|
* Wenn kein Link, muss der Link anhand des Datum gesetzt werden
|
||
|
|
again: Wo ist der Ansatzpunkt..
|
||
|
|
|
||
|
|
== Periodische Termine für calender etc.
|
||
|
|
|
||
|
|
Termin: Di 04mar14
|
||
|
|
* Absprache alternatives Format für Datum
|
||
|
|
* Umsetzung planen
|
||
|
|
|
||
|
|
== Termine verbreiten
|
||
|
|
|
||
|
|
Manche Termine sollen in die Welt posaunt werden, hier gibt es schon atoms, feeds.. mit sehr geringer Nutzung weil $user meist nur Email haben und eventuell in Listen mitlesen.
|
||
|
|
Hier wäre es gut Termine und Terminänderungen anwenderfreundlich z.B. über eine ML zu verbreiten.
|
||
|
|
|
||
|
|
== Termine scrapen
|
||
|
|
|
||
|
|
von einzelnen Projekten könnten durch einen Eintrag die Termine automatisiert von anderen Seiten ausgelesen werden um sie nicht manuell an mehreren Orten veröffentlichen zu müssen.
|