Hier sollte es zu einer wesentlichen Verbesserung kommen. Die Jahresberichte sollen prominenter angepriesen werden und die berichte besser “surfbar” werden. Vorige/Nächste/Inhaltsverzeichnis-buttons gehören prominenter, damit sie überhaupt wahrgenommen werden.

Hier würde ich Vorschläge von den Designern brauchen, um abschätzen zu können, was das kostet.Sollte aber nicht die Welt sein.

• statistik: berechtigungen in der projekte-db ändern. einrichtungen sollen auch alte einträge bearbeiten/löschen können 2h

• strukturdaten: fehler in engl. complexsearch 4h (da muss etliches komplett neu überarbeitet werden - das war ein tiefer strukturfehler von franz) peter 2007-11-05
• strukturdaten: englische version der strukturanalyse-interpretation soll downloadbar sein. 1h
• strukturdaten: kennzahlenumrechnung 2h

Derzeit ist der content im textarchiv sprachenunabhängig. Da die Kategorien aber auf deutsch und englisch implementiert werden sollen, muss der content sprachabhängig werden.

• einführen eines “language”-feldes in den kategoriedatenbanken. eine kategorie wird im backend einmal für jede sprache angelegt. theoretisch kann dann sogar das ranking in den unterschiedlichen sprachen anders sein, was aber nicht empfohlen wird. die bestehenden einträge werden natürlich vom system kopiert.
• es können dann also beliebige viele sprachen pro kategorieeintrag existieren (de, en, es, cz ...). wenn ein eintrag in der ausgewählten sprache nicht existiert,wird er auf englisch angezeigt.

• änderungen im backend: 1h
• bisher werden die daten in den templates direkt mit get_data implementiert. es muss eine neue get_data-funktion geben, welche die alte transparent ersetzt, aber eine sprachangabe ermöglicht. diese funktion muss das fallback auf englisch im falle eines nichtexistierenden eintrags ermöglichen. und zwar pro datensatz. HMMM... 7h
• geringfügige Änderungen in den templates 3h
• content-änderung - aufgabe der contentmanager

gesamt : 11h

derzeit kommt gleich die complex-search. gut wäre zuerst die singleslot und dann die complexsearch zum aufklappen. schwierig abzuschätzen, wie aufwändig das ist. 1h-10h

analog zu den realisiert-von auf der startseite. statische logos in einem rahmen. 1h

• textarchiv : KAPITEL in der complexsearch ist als einziges nicht eingerückt 1h

veranschlagt : 7h

technisch ist das in der goldfisch::search2::search() zu lösen.

my $sort_ids=[sort {$si->{$cid}->{$a}->[$sortmode] <=> $si->{$cid}->{$b}->[$sortmode]} @{$rv->{$cid}}];

hier kann die sortierreihenfolge leicht adaptiert werden. p4 im suchergebnis ist derzeit 0 oder 1 und kann einfach und hoffentlich automatisiert auf -0/-1 bzw. r0/r1 ergänzt werden.

find . -type f | xargs grep SORTIERSCHEMA

Problematischer ist hier eher das userinterface. hier muss in allen suc.trefferliste.XX die möglichkeit des “reverse” eingebaut werden.

vorschlag:

erster click auf eine spalte sortiert immer aufsteigend. ein zweiter click dann absteigend.

beispiel : die ergebnisliste beinhaltet titel, jahr. Defaultmässig wird nach Jahr sortiert. Um nun nach dem Titel absteigend zu sortieren muss man auf “titel” clicken, damit nach titel aufsteigend sortiert wird und dann nochmals auf “titel”, damit nach titel absteigend sortiert wird. Ich kann mir keine bessere möglichkeit vorstellen, die technisch machbar wäre. die optimale lösung wäre natürlich bei jeder spalte 2 pfeile anzubieten. Einer nach oben und einer nach unten und je nachdem auf welchen man clickt ... - Das ist vom Aufwand her ein Wahnsinn, weil für jede Spalte in jedem Suchergebnis 2-3 neue Bilder benötigt werden, was die designer stundenlang beschäftigen würde und ich muss die bilder dann auch noch einbauen !!

• Zeitschriftenartikel : “sponsor”-feld unter der suche 1h

• Zeitschriftentitel :
  • neues feld : standortangabe, multilinetext, wiki 1h
  • neues feld : coverupload, autoresize, inkl. link 1h

• modulnamen zu links machen 2h

• suchergebnisliste - rechte spalte : modulübersicht : die “übermodule” werden nur durch logos repräsentiert, was verwirrend ist. hinzufügen von text: 4h

• suchergebnisliste eines moduls : der modulname im tabellenkopf sollte clickbar sein und zum modul führen 4h

• google optimierung ~ 7h

• durchsuchen von pdf, docs etc. 10h

• verbesserung der searchengine (bugfix des 10000+bugs) 5h

• mailingliste kb_bifeb: kloiber, grete, max, stefan, zwilli, christian, thomas, peter

• Schnittstelle zur übernehme der DIE Daten 5-10h

• complexsearch unter das inhaltsverzeichnis : ?? 3h für das erste modul. 1h für jedes weitere

Der Warenkorb ist die Möglichkeit, Einzeldatensätze als Zitate zu sammeln und als gesammelte Zitatliste auszudrucken oder zu vermailen.
Der Ausdruck “Warenkorb” ist dabei gegen einen treffenderen zu ersetzen.
Alle zitierbaren Datensätze (derzeit nur ZA,UF,ZT,WM !!) können dabei mittels einem click in den Warenkorb gegeben werden. (zB über einen Warenkorb-button beim “Literaturzitat drucken”)

Der Warenkorb selbst hat folgende Funktionen:

• anzeigen der aktuellen einträge im warenkorb (link auf den einzeldatensatz)
• löschen von einem oder mehreren Einträgen
• löschen von allen einträgen
• Druckansicht der gesammelten Zitate
• Vermailen der gesammelten Zitate (antispamlösung nötig !!)

Der Warenkorb selbst ist “sticky”. Dh : Ein Besucher, der nach zwei Tagen vom gleichen Rechner wieder auf die Webseite kommt, findet seinen alten Warenkorb vor. Eine Anmeldung per Passwort ist nicht erforderlich, wohl aber die Verwendung von Cookies.
Eine Anmeldung und die Verwaltung von mehreren Warenkörben/Recherchen ist nicht gewünscht, da die Zielgruppe hierfür zu klein und der Aufwand zu hoch ist. (automatisiertes Anmeldesystem etc.)

Es gibt die bestehende zitat-Funktion, die auf dem ergebnis der get_data-funktion beruht. Der Warenkorb muss also über einen eindeutigen Schlüssel (der in einem cookie gespeichert wird) die basisdaten für jeden warenkorbeintrag in einer tabelle speichern, so dass der eintrag per link jederzeit aufrufbar ist und das zitat eindeutig reproduziert werden kann. Dazu muss ein Interface für die Verwaltung und Auswertung des Warenkorbs designt und implementiert werden.

• neue funktion : put_in_warenkorb 1h
• neue funktion : delete_from_warenkorb 0:30h
• neue funktion : get_warenkorb 0:30h
• neue funktion : print_zitat_liste_from_warenkorb 2:00h
• organisation : 10h
• implementierung der umgebung und des backends: 20h
• design und umsetzung der warenkorbseite : 20h

summe : 55h

• warenkorb laden. es gibt vorgefertigte Literaturlisten zu bestimmten Themen, die in den Warenkorb geladen und dann angeschaut werden können.

Der Walkthrough sollte die Möglichkeit bieten, eine “guided Tour” durch die Seite zu machen, die von einem Contentmanager erstellt wurde. Man sieht dabei die ganz normalen Seiten plus einen “zurück, weiter, start, exit-guided-tour”-button und einen optionalen Text ???

Technisch ist das weniger Problem als darstellerisch, denke ich. Wo tut man die “zurück,weiter”-buttons hin?? sie müssen auf jeder Seite an der gleichen Stelle sein um den implementierungsaufwand zu reduzieren und die usabilty zu erhöhen.

Organisatorisch:

• es gibt ein eigenes “modul” namens “guided tour”, das im backend bestückt wird. Die bestückung im backend ist im wesentlich ein textfeld, wo untereinander die einzelstationen der tour als links eingefügt werden.
• im frontend kann man das modul wählen und hat dann eine liste der vorhandenen guided tours mit einer beschreibung und man kann dann durch click einsteigen.
• eine guidedtour kann auch (wie eine suche) als einfacher link von überall verlinkt werden. man kann auch direkt mitten in eine guidedtour verlinken !!
• wenn man bei einer guided tour auf einen link auf der seite ausser VOR/ZURÜCK clickt, verlässt man die guided tour ???
• es gibt bereits etliche “vorige/nächste”-buttons auf der seite, zB in der statistik und in der historiografie. da bedarf es designerischen geschicks, damit es da zu keiner konfusion kommt.

der walkthrough erfolgt über einen wrapper. die information, dass man sich in einem walkthrough befindet, in welchem und an welcher stelle wird in der url ähnlich dem open oder dem debug-paramater kommuniziert. die tt2_lib fängt diesen parameter ab und fügt die nötigen buttons an der richtigen stelle in die ausgabe ein.

• konstruktion des backends : 2h
• umsetzung des wrappers : 5h
• design des moduls, der buttons: 10h
• organisatorisches : 5h
• implementierung : 10h

30h

news sollen über einen rss-feed abonierbar sein. ~5h

kleines bild für newsübersicht : ~3h (2h design, 1h technik)

Viele Seiten sind derzeit sehr beschränkt in den gestaltungsmöglichkeiten, dafür sehr effizient in der verwaltung, suche und datenimport.

es sollte versucht werden, die datenbankeinkastelung für definierte bereiche der webseite zu verlassen und ein völlig frei gestaltbares wiki zu betreten.

das erfordet etliche überlegungen in bezug auf struktur, design und technik.

Insbesondere ist die Frage zu überlegen, ob man bestehende Daten (zB OH-Historiografie, VÖV-page) ins wiki übernehmen will, was den Aufwand erhöhen würde.

Eine Kostenabschätzung ist hier sehr schwierig, ich würde das aber sehr wichtig finden und schlage eine Arbeitsgruppe vor, die sich zu diesem Thema trifft und die Anforderungen bestimmt die an dieses System gestellt werden. Auf dieser Basis kann ich dann einen Kostenvoranschlag und eine techn. Konzept erstellen. Kosten für die Arbeitsgruppe und das Konzept : ~10h

• complexsearch unter das inhaltsverzeichnis : ?? 3h für das erste modul. 1h für jedes weitere

• wb: backenddesign 3h -> kommt nach evaluierung der eigentl. probleme

• mailverteiler: wunsch einen newsletter herauszugeben - mailinglisten zu erstellen

billige lösung : ~1h schulung und 30min einrichtung pro mailingliste

• content mehrsprachig machen