NPS Migration - Überblick und Corporate Design
Der Fachbereich stellt vom März bis November 2006 die wichtigsten seiner Webseiten auf ein neues Design, eine neue Navigationsstruktur und ein Content-Management-System (CMS), nämlich Infopark NPS, um. Diese Seite versammelt die wichtigsten Informationen darüber für die Projektmitarbeitenden und die interessierte Fachbereichsöffentlichkeit.
- Set DONE =
- Set NOPE =
Zielvorstellung (Kurzbeschreibung)
Nach der Reorganisation- werden die wichtigsten Webseiten des Fachbereichs (d.h. die obersten Ebenen) über das CMS verwaltet;
- haben diese Seiten alle das im neuen Corporate Design der Universität vorgesehene Aussehen;
- sind diese Seiten von veralteten Informationen und unnötiger Redundanz bereinigt;
- sind die Inhalte vor allem eines: hilfreich;
- gibt es eine klare und nachvollziehbare Navigationsstruktur und Seitenorganisation, so dass auch später hinzukommende Seiten zumeist in gut auffindbarer und pflegbarer Weise eingefügt werden;
- sind sinnvolle zusätzliche Seiten hinzugekommen
- für bislang zu schlecht bediente Zielgruppen (Studieninteressenten, Öffentlichkeit),
- für bislang hauptsächlich mündlich weitergegebene aber wichtige Sachverhalte (z.B. die Details des Vereinbarens mündlicher Prüfungen);
- sind wichtige Seiten, auf die es anderswo zahlreiche Verweise gibt, immer noch unter denselben Adressen wie bisher zu erreichen;
- sind die wichtigsten Einstiegsseiten aller daran interessierter Arbeitsgruppen ebenfalls ins CMS (inkl. neues Design) migriert;
- haben alle Personen, die sinnvollerweise einige dieser Seiten mit pflegen sollten, auch tatsächlich Schreibzugriff auf diese Seiten.
Zielvorstellung (Inhalte)
Prinzipien
- Keine Redundanz. Die Qualität von Seiten hängt stark davon ab, ob die Inhalte aktuell gehalten werden. Das ist aber sehr schwierig, wenn nicht klar ist, wo und wie oft eine Information ggf. geändert werden muss. Wir vermeiden deshalb Wiederholungen von Informationen nach Kräften und setzen statt dessen eifrig Hyperlinks ein.
- Seitenzahl begrenzen. Da die Pflege und insbesondere die Einhaltung der gewünschten Struktur umso schwieriger werden, je mehr einzelne Seiten es gibt, gestalten wir lieber etwas längere Seiten mit einem Inhaltsverzeichnis als alles in sehr kleine Schnipsel zu zerlegen. Unsere Benutzer sind zur Benutzung eines Rollbalkens durchaus in der Lage.
- Entwurfsideen erläutern. Damit einzelne Seiten und ganze Bereiche auch im Laufe längerer Pflege durch viele verschiedene Personen nicht ihre Struktur einbüßen, sollten sie explizit beschreiben, was wir uns bei dieser Struktur gedacht haben und wo nicht hineinpassende Dinge hingehören könnten.
Künftige Navigationsstruktur
Zielgruppenspezifische und lebenslagen-orientierte Navigation.
Dies wird hauptsächlich erreicht durch- entsprechende alternative Navigationsmenübäume
- eine Schicht von Navigationsseiten mit Erläuterungen
Liste umzustellender Seiten
Siehe MigrationNPSTodo. Bereiche:- Homepage inf
- Homepage math
- Lehre/Studium inf
- Lehre/Studium bioinf
- Lehre/Studium math
- Überblick Forschung inf
- Überblick Forschung math
- Fachbereichsverwaltung
Liste neu zu erstellender Seiten
Siehe die entsprechenden Unterabschnitte in MigrationNPSTodo.Zielvorstellung (Technik)
- Die Seiten werden wie bisher über die Server www.[mi|math|inf].fu-berlin.de angesprochen
- vermutlich in Proxy-Manier, der wirkliche Server ist http://www.cms.fu-berlin.de/_mi/
- Wichtige alte Seiten sind auch nach wie vor über ihren bisherigen URL erreichbar (per Weiterleitung)
- Um die Konsistenzwahrung auf Links im NPS maximal zu nutzen, bauen wir aber alle drei Teile in einen Baum des CMS (Pfade mi/mi, mi/math, mi/inf) und leiten von den Wurzelseiten der drei Server entsprechend weiter.
- Einige Seiten werden von einem Wiki-Server aus eingebunden und sind damit für alle FB-Mitglieder editierbar. Auch diese haben ähnliche logische Adressen.
Aufgabenliste und Status
Zu erledigen
- technische Infrastruktur einrichten
- Server: Proxydienst Wiki
- Unter dem URL http://qqq.inf.fu-berlin.de/w/web/topic sollte sichtbar gemacht werden die Seite http://projects.mi.fu-berlin.de/z/bin/view/web/topic und analog für alle Werte von 'web' und 'topic' (es kommen nur Buchstaben und Ziffern vor und es gibt keine weiteren Pfadlevels im URL)
- Analog dazu: Unter dem URL http://qqq.inf.fu-berlin.de/wa/web/topic bzw. https://qqq.inf.fu-berlin.de/wa/web/topic sollte sichtbar gemacht werden die Seite http://projects.mi.fu-berlin.de/z/bin/viewauth/web/topic bzw. https://projects.mi.fu-berlin.de/z/bin/viewauth/web/topic und diese sollten mit demselben Weiterleitungsmechanismus verbunden sein, wie er für das Wiki realisiert ist, d.h. http-viewauth wird umgelenkt auf https-viewauth und das verlangt zum Abruf eine Kerberos-Authentisierung gegen einen FB-Account. Und wiederum analog für alle Werte von 'web' (ausgenommen natürlich 'bin', das wird verboten) und 'topic'.
- Unter dem URL http://qqq.inf.fu-berlin.de/w/bin/op/web/topic sollte sichtbar gemacht werden die Seite http://projects.mi.fu-berlin.de/z/bin/op/web/topic für alle Werte von 'op' außer 'view' und 'viewauth'
- Um das zu erreichen, braucht man sowohl Rewrite-Regeln im Apache als auch eine kleine Korrektur am Code von TWiki (damit der von vornherein verkürzte URLs in das erzeugte HTML schreibt). Für eine normale Installation (ohne Proxy) ist das beschrieben auf http://twiki.org/cgi-bin/view/Codev/ShorterURLs. (Vorsicht, auf der Seite gibt es mehrere verschiedene Vorschläge. Nicht verwirren lassen.)
- Es ist erwünscht, das das TWiki die verkürzten URLs gleich von vornherein so erzeugt, so dass man nie einen Hyperlink (mit w/bin/view/X) zu sehen bekommt, der einen bei Auslösung auf einen anderen URL führt (nur noch w/X).
- Es ist erwünscht, dass dadurch das TWiki nur noch über den Proxy sinnvoll nutzbar ist, weil projects.mi.fu-berlin.de diese verkürzten URLs gar nicht auffinden kann. Dadurch verhindern wir, das unerwünschte projects-URLs in Umlauf geraten.
- Später werden wir http://projects.mi.fu-berlin.de/z umbenennen in http://projects.mi.fu-berlin.de/inf und in analoger Konfiguration zusätzlich einführen http://projects.mi.fu-berlin.de/math http://projects.mi.fu-berlin.de/mi http://projects.mi.fu-berlin.de/fbv und auf die entsprechenden Server qqq.math.fu-berlin.de etc. abbilden.
- Noch später wird das dann alles von qqq nach www umgelegt.
- Server: Authentisierung f. geschützte Inhalte (z.B. f. FBV)
- Server: Weiterleitungen f. alte URLs auf neue Inhalte
- Server: Proxydienst Wiki
- Fotos beschaffen/machen (für Titelbalken).
- Unter http://www.inf.fu-berlin.de/inst/zdm/bildwerkstatt/cms/ gibt es erste Skizzen und Fragen.
- Neue Seiten einrichten
- Inhalte bisheriger Seiten umstellen
- ggf. redaktionell überarbeiten
- Wichtige nichtstatische Inhalte auf Corporate Design umstellen
- KVV
- Karte
- Request-Tracker (?)
- Weitere technische Aspekte klären/lösen:
- Auf jeder Seite soll die Person genannt werden, die daran die letzte Änderung vorgenommen hat (plus Datum)
- Organisatorische Aspekte klären/lösen:
- die Schreibrechte sollten übersichtlich und nicht-verschachtelt sein.
- Zusätzliche Auskunftsseiten (z.B. FAQs verschiedener Art) einrichten und befüllen
- Pilottests
- weitere?
- Einstiegsseiten interessierter Arbeitsgruppen umstellen ist mehr oder weniger erledigt.
Migrierende und nicht-migrierende Bereiche
Folgende Tabelle umfasst eher einen Arbeitszustand und enthält auch Web-, nicht AG-Bereiche. Die hier gelinkte Tabelle umfasst den ziemlich endgültigen Zustand (2. April 2007) zum Ende des Projekts und umfasst nur AGs und zentrale Arbeitsbereiche. Bei nicht-migrierten Bereichen ist zu berücksichtigen, dass sie (1.) mindestens eine fuInstitution-Seite im NPS haben, und (2.) ALLE ihre Mitarbeiter in NPS eingepflegt haben. ("und co." soll heissen: diese und/oder andere Personen aus diesem Umkreis dazu)
Mehr oder weniger erledigt
Eintrag gemacht wann und von wem? Anmerkungen und Zweifel als Unteraufzählung in gleicher Weise einfügen.
- 2006-10-23: neues GruppenUndListen-Konzept beschrieben --- LutzPrechelt
- 2006-10-19: Dokumentation für das userinfo-Servlet angefertigt --- LutzPrechelt
- 2006-03-31: Liste umzustellender Seiten ist aufgesammelt --- LutzPrechelt
- 2006-04-20: Layoutschablonen sind eingerichtet (CeDiS hat zahlreiche mitgeliefert) --- LutzPrechelt
- Hier sind aber noch einige Fälle offen, die noch viel Arbeit machen dürften. Siehe MigrationNPSBenoetigteVorlagen
- 2006-04-21: Erste Fotos sind gemacht für Bildbalken und vorläufig eingebunden auf mi, inf und math --- Christian Zick
- Erst vorläufige Ergebnisse. Wir möchten ferner noch mehr Vielfalt erreichen.
- 2006-05-31: Proxy-Konfig und IMP Domäne sind eingerichtet --- PeterErtel und GeroEggers
- 2006-05-31: Bedarfsplanung für Navigation ist gemacht. Ergebnisse siehe MigrationNPSZielgruppenUndLebenslagen --- LutzPrechelt
- 2006-05-31: Navigation konkret entwerfen --- PeterErtel und Kerstin Nolte
- Exemplarisch anhand der Didaktik Mathematik-Seite
- technische Infrastruktur einrichten
- 2006-09-06: Liveschaltung Server: Proxydienst CMS --- PeterErtel, Technik
- 2006-09-11: CMS: Layouts, Navigation --- PeterErtel, Christian Zick
- Navigation entwerfen/einrichten
- 2006-08-28: Planung: Zielgruppen und Lebenslagen --- PeterErtel
- 2006-09-06: Benutzer befragen --- Christian Zick
- 2006-09-06: Unter http://qqq.inf.fu-berlin.de/ ist der laufende Zustand zu sehen. Kommentare willkommen. --- Technik
- Wichtige nichtstatische Inhalte auf Corporate Design umstellen
- 2006-08-06: Wiki-Skin --- PeterErtel
- Pilottests
- Wichtige nichtstatische Inhalte auf Corporate Design umstellen
- 2006-09-11: Personenverzeichnis --- LutzPrechelt, PeterErtel
Technische Probleme und Lösungen
Linkumsetzung für die Proxy-Server
- NPS erzeugt aus lokalen (d.h. innerhalb des CMS) Links normalerweise stets relative Links im HTML-Code
- Das führt zu einem Problem, wenn wir von einem Zweig in einen anderen Verweisen, z.B. von
_mi/inf/a/b/i.html(also aus Nutzersichtwww.inf.fu-berlin.de/a/b/x.html) nach_mi/math/m.html(also aus Nutzersicht www.math.fu-berlin.de/m.html). - In diesem Fall steht nämlich in
i.htmlals Adresse../../../math/m.html - Für den Browser also eigentlich
www.inf.fu-berlin.de/a/b/../../../math/m.html - Sinnvollerweise sollte der Browser daraus
www.inf.fu-berlin.de/../math/m.htmlmachen, so dass der Serverwww.inf.fu-berlin.dedie Anfrage entsprechend umlenken könnte. - Macht er aber nicht. Sowohl IE, als auch Firefox und Opera erzeugen statt dessen
www.inf.fu-berlin.de/math/m.html, unterdrücken also den überschüssigen und scheinbar unlogischen "=../="-Teil. - Deshalb kann der Server die Situation nicht sauber handhaben.
Es gibt jetzt folgende Möglichkeiten:
- Wir erzeugen solche Links ausschließlich für die Zweige
_mi/inf,_mi/math,_mi/fbv,_mi/miund reservieren auf jedem der vier Server die Pfadpräfixeinf, math, fbv, mi. Dann kann der Server die Situation trotz des falsch übermittelten Pfades korrekt behandeln (mittels mod_rewrite).- Nachteil: Eigentlich möchte man die automatische Linkverwaltung auch gern für Verweise auf zentrale Uni-Seiten (z.B. zum Thema Studium) nutzen. Das würde für jeden Teilbaum das Reservieren eines weiteren Pfadnamens nötig machen. Unschön.
Andererseits sind derzeit in CMS die Rechte ohnehin so, dass wir solche Links gar nicht als lokale Verweise ausdrücken können, weil wir nicht die nötigen Leserechte auf diese 'fremden' Teilbäume haben.
Grund dafür sind Geheimhaltungsbedenken (weil man dann nicht nur die Namen, sondern auch die (vielleicht noch nicht freigegebenen) Inhalte aller dieser Dateien, auf die man verweist, sehen kann). Außerdem kann der Eigentümer einer Datei diese nicht mehr löschen, wenn irgendjemand einen Verweis darauf gesetzt hat.
- Nachteil: Eigentlich möchte man die automatische Linkverwaltung auch gern für Verweise auf zentrale Uni-Seiten (z.B. zum Thema Studium) nutzen. Das würde für jeden Teilbaum das Reservieren eines weiteren Pfadnamens nötig machen. Unschön.
- Die Links werden mit entsprechenden TCL-Hooks direkt beim Export so umgeschrieben, dass Links, die auf einen anderen Server weisen, in absolute Links umgesetzt werden. * Nachteil: Das muss Herr Baur von der CeDiS für uns einrichten. Der hat Bedenken wegen des Performance-Overheads, da diese Logik für jeden einzelnen Link im gesamten NPS der Uni anspringen würde. Er will gelegentlich entsprechende Experimente machen, braucht dafür aber einige Tage.
- Die Links werden nach dem Export im Dateisystem mit Suchen-und-Ersetzen umgeschrieben.
- Nachteil: Probleme mit Nebenläufigkeit; evtl. aufwändig zu realisieren; ggf. Probleme mit komplizierten Seiten (Javascript).
- Wir schreiben gleich redaktionell stets absolute Links in die Seiten
- Nachteil: Der Nutzen des CMS, bei Umbenennung von Seiten automatisch alle Links dorthin zu ändern, geht für diese Links verloren. Dies ist die traurigste Lösung von allen und wir sollten nicht bereit sein, sie zu akzeptieren.
Fazit: Wir schreiben in unsere Daten relative Links und klären deren Umsetzung später.
Vorschlag: Mir scheint, wir sollten mal probieren, ob Lösung 1 wirklich funktioniert. Die wäre in der Praxis wohl am schmerzärmsten. --- LutzPrecheltBildbalken
- Bildbalkendateien können an beliebiger Stelle abgelegt werden.
- Sie werden angezogen von der Layoutschablone
fuIdentity, in der der URL eingetragen werden muss. - Jedes Verzeichnis kann für die Gesamtheit seiner Dokumente einen anderen Bildbalken erhalten, indem man dort eine entsprechende lokale Fassung von
fuIdentityablegt. - wir benutzen bis auf weiteres die Bildhöhe 80 pel. Linkes Bild hat 184 pel Breite, der Mittelbalken 586.
Zweisprachigkeit
- Rausfinden, wer und wie die Entscheidung fallen soll zum Thema deutschsprachig, englischsprachig, zweisprachig.
- Die Mathematiker haben offenbar durch einen englischsprachigen Studiengang Bedarf, auch für Studierende vieles auf Englisch vorzuhalten. Das gleiche gilt für die Bioinformatik. Dadurch verkompliziert sich die Lage.
- Also den ganzen Auftritt auf Englisch gestalten?
- Von Seite zu Seite entscheiden?
- Dafür brauchen wir Grundsätze. Welche sollen das sein?
- Oder Zweisprachiges vermeiden wie die Pest.
- Brauchen wir bei den FBV-Seiten überhaupt Englisch? Vielleicht nicht?
Vorschlag Prechelt: Studierende Deutsch, Studieninteressenten und Homepage zweisprachig, alles andere Englisch. Durch die Mehrfachnutzung der selben Inhalteseite für mehrere Zielgruppen wird das noch ein wenig komplizierter, aber nur begrenzt. Man muss ja auch f. Institutsmitglieder nicht unbedingt alles auf Englisch haben, sondern nur als Tendenz, damit auch ausländische, nicht Deutsch sprechende Mitarbeiter einfach zurecht kommen.
Vorschlag Zick: Als Standard wird im CMS vorgegeben, dass der (deutsche) Verzeichnisbaum 1:1 in das englische Verzeichnis kopiert (und dort natürlich übersetzt) wird. Dann erscheint automatisch in der Navigation das "englisch". Wenn es zwei Sprachversionen einer Seite gibt, sollte eine Kontrollstruktur her, die den Redakteur auf entsprechend notwendige Änderung oder Generierung im jeweils anderssprachigen Dokument hinweist. Ich meine, dass damit jetzt keine systematische Entscheidung notwendig ist, denn es kann jederzeit dezentral weiter übersetzt werden. Wir können nicht im Rahmen dieses Projekts eine grössere Übersetzungs-Task stemmen. - Von der Cedis gibt es dazu bisher noch keine Vorgaben oder gar Lösungen.
Navigation und Zielgruppenanliegen
Beim Aufbau der Navigation muss man auf ein paar Richtlinien achten. Mehr dazu in den AWS-Unterlagen von GeraldFriedland. Hier in aller Kürze:- Navigation nicht kontextabhängig ändern
- Einträge kategoriengerecht aufführen: z.B. alle Studiengänge auf einer Ebene, ohne aber die Abschlüsse (Master, Diplom, Bachelor, usw.)
- alternative Suchpfade über die Inhaltspfade abdecken: z.B. Auflistung aller Studiengänge, strukturiert sortiert nach Abschlussart. Siehe dazu Studiengangsüberblick auf der MI-Seite.
- ???
Wichtige Links
Unser Projekt
- GruppenUndListen, Gruppenstrukturen u.a. für die Verwendung der dyn. Mitarbeiterliste
- UserinfoSyntax, Parameter zum Konfigurieren der dyn. Mitarbeiterliste
- MigrationNPSFeatureSet, führt die vom Migrations-Team erstellten Eigenlösungen/Modifikationen auf NPS-Ebene vor
- MigrationNPSBenoetigteVorlagen, Anforderungen an neue Vorlagen für den NPS Einsatz, sowie sinniges uns unsinniges zu den existierenden Vorlagen
- Liste der umzustellenden und neu zu erstellenden Seiten
- Zielgruppen und Lebenslagen
- Archiv der Mailingliste Webmigration
- Mailingliste für Redakteure
- Namenskonventionen für Redakteure
Downloads
Externes
- Unterstützte Browser für das Redaktionssystem
- Infopark NPS-Dokumentation(insbesondere: Layouts und Links, NPSOBJ-Referenz, Redaktionssystem)
- Redaktionssystem des CMS
- CMS-Einführungs-Homepage der CeDiS
- http://www.cedis.fu-berlin.de/cms/doc/faq/allgemein/was-bedeutet-nps.html
- Apache 2.2 Dokumentation (insbesondere: mod_rewrite, mod_proxy)
- Corporate Design der FU Berlin
- Bisherige Webseiten des Fachbereichs, der Mathematik, der Informatik
Projektmitglieder
- LutzPrechelt (-75115, prechelt[at]inf.fu-berlin.de, Vertreter Informatik)
- Christian Zick (-75148, zick[at]mi.fu-berlin.de, Projektleitung)
- Konrad Polthier (-75871 , polthier[at]math.fu-berlin.de, Vertreter Mathematik)
- PeterErtel (Student, ertel[at]inf.fu-berlin.de, Hiwi)
- Holger Drost (-51401, drost[at]fbv.mi.fu-berlin.de, Vertreter Fachbereichsverwaltung)
- ChristopherOezbek (-75242, oezbek[at]inf.fu-berlin.de, für Technik beim Wiki)
- Carsten Schäuble (-75176, schauble[at]inf.fu-berlin.de, für Technik/Server)
Für Anfragen und Feedback bitte email an webmigration[at]lists.spline.inf.fu-berlin.de. Auf dieser Liste befinden sich die obigen Projektmitglieder.
Ansprechpartner bei der CeDiS
- für Fragen der Redaktion, Templates, Rechte etc. sowie alles, das mit Projektabwicklung/Finanzen zu tun hat: Mattis Neiling (Tel. -52531)
- für Fragen des CMS-Systembetriebs, Exports etc.: Jörg-Michael Baur (Tel. -55713)
Comments
Kümmert sich auch jemand um die Suchmaschinen? Momentan liefern Suchen wie "Informatik", "Informatik Berlin" oder "Informatik Studium" die FU eher an mittleren bis hinteren Stellen.
-- ChristopherOezbek - 2006-04-17 07:33 UTC- migrierte-nichtmigrierte.pdf: Migrierte/nicht-migrierte Bereiche, Stand 2. April 2007
- migrierte-nichtmigrierte.pdf: Migrierte/nicht-migrierte Bereiche, Stand 4. April 2007
Sitemap
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback