man bedim len?

TxtPL erhält nun auch ein Loop.
Nach langen Debatten mit Kollegen und Freunden wurde ich "persuaded" (ich liebe das englische Wort "persuade" - das läßt sich sowohl mit überzeugen, als auch mit überreden überzetzen), in TxtPL auch ein Loop einzubauen.

Syntax etwa so:

<#loop  
     name=""      # Name des Loops, falls es
                         #  spaeter nochmal verwendet werden soll
    template=""   # Templatedatei, falls nicht im 
                          # Erstreckungsbereich definiert
    field="fieldname" # Feld, entweder Hash- oder Array-Object
                            # muss vorher definiert sein in
                            # txtplobj->{data}{fieldname}
    type="field|number"    # field: Er laeuft ueber das 
                           # Object ein Field
                           # Number: Er laeuft ueber einen Zahlenbereich
                           # wenn attribut field definiert, dann 
                           # ist field hier default
   start = \d         # falls type=number, dann startwert
   end = \d           # falls type=number, endzahl
   addnum = [\d | ++ ]   
                           # falls type=number, steigwert, 
                           # per default ,dann ++
    #>
    ...
   <#endloop#>

Nun denn, ich setz mich nunmehr dran.
Wenn auch unter Murren.
IMHO tut das nicht wirklich not, weil man Loops viel gezielter und schneller im Programm machen kann als in einer Templatesprache.

Dabei werd ich dann wohl auch mal die Website von TxtPL endlich mal updaten. Wird mal höchste Zeit, das man dort mehr findet als nur ein paar Beispiele.

...hatte der FTP-Server ftp.uni-erlangen.de des RRZE.

Hauptverantwortlich für diesen Peak: Die ISO-Datei von Wikipedia und das Suse 9-Image.

Gratulation an Björn Reimer, der den FTP-Server in den letzten Monaten und Jahren zu einen der wichtigsten FTP-Downloadservern in Deutschland machte.

Meine Vortragsfolien zur Vorstellung und der 6-Monate-Bilanz des RRZE-Webdesigns sind nunmehr online:
http://www.rrze.uni-erlangen.de/ausbildung/campustreffen/akbyweb-28-10-2004.pdf

Gestern tagte der Arbeitskreis Bayrischer Webmaster in Bamberg.

Wiedereinmal war es ein sehr interessantes Treffen, wo man sich mit den Kollegen gut austauschen konnte.
Ein großer Punkt diesesmal auf der Tagesordnung: Typo3.
Typo3 ist der zeitige Renner auf dem Gebiet CMS an Universitäten. 3 der vertretenen Universitäten nutzen es, bzw. haben vor kurzer Zeit damit angefangen.

Leider konnte keiner wirklich längerdauerende Erfahrung im Universitätsalltag mit Typo3 aufweisen. Wohl aber waren die Probleme bei den meisten gleich und nicht technik-bezogen: Organisatorische Probleme machen an jeder Universität oder FH den technischen Ansprechpartnern das Leben schwer. Die Einführung von guten Konzepten und Techniken wird in den meisten Fällen nur durch "Reibungsverluste" innerhalb der Verwaltung erschwert oder gar verhindert.

Oder anders gesagt: Durch die Einhaltung von strengen hierachischen Entscheidungswegen in Zeiten bei denen aufgrund knapper Personalstellen kaum Zeit da ist (besonders bei den Entscheidungsträgern) um sich mit einer Thematik richtig auseinanderzusetzen, kommen richtige Entscheidungen zu spät oder garnicht.



Nun ja.
Wir setzen Typo3 nicht ein. Und auch kein anderes unflexibles CMS.

Stattdessen konnten wir am RRZE in der ersten 6 Monate-Bilanz sehr, sehr viel gute Erfahrungen und Feedback sammeln, welche sich auch zahlenmäßig ausdrücken lassen.

Ich kann es nicht oft genug betonen: Gerade jetzt, wo es an allen Stellen an Personal fehlt (ausser wohl in der Verwaltung - jemand muss ja das Papier schaufeln und Bedenken tragen), ist eine größere Eigenverantwortung und Freiheit bei den Mitarbeitern der einzige Weg zu schnellen und auch praktikabeln Lösungen.
Die Fachkompetenz liegt nun mal in den Experten an der Front.
Dementsprechend muss jedes Verwaltungssystem für Webseiten dieser Situation auch Rechnung tragen.
Und das bedeutet:
Ein CMS im öffentlichen Bereich

• muss fast alles ermöglichen, fast in Richtung WIKI gehen
• darf alte, gewohnte Arbeitsmethoden, die bewährt und etabliert sind, nicht behindern. So darf ein CMS nicht einfach dazu zwingen, die gesamte langjährige Erfahrung eines Mitarbeiters in einer Programmiersprache oder in einem Editor, wegzuwerfen!

Es muss so frei sein wie möglich, und so einschränkend wie notwendig.

Anderenfalls hat man irgendwann mal ne tolle neue Website eröffnet mit einem tollen, teueren CMS, aber nach nem halben Jahr hat man die selben Seiten wie am Anfang, weil kein Mitarbeiter das Zeug akzeptiert.

Das Campustreffen wird am 9.11. stattfinden.
Update: Das war zu früh gedacht: Es wurde in anderes Treffen vergessen, was da schon statt findet. An dem Tag kommt Microsoft und hält einen Vortrag über dessen Updatedienst...


Aufgrund es großen Interesses wird erstmal nur ein "kleines" campustreffen gemacht und im Frühjahr (Februar) dann ein richtiger öffentlicher Workshop.

Dann besteht auch mehr Hoffnung, daß die Verordnung so langsam absehbarere Gestalt genommen hat;
Laut Mail von gestern aus dem IuK-Planungsstab des Innenministerium wird die bay. Verordnung zur Barrierefreiheit noch etwas auf sich warten lassen. Derzeit befindet sich die Verordnung noch in der Diskussionsphase in den Ressorts. Ein Schwerpunkt in den Diskussionen ist offenbar die Kostenfrage.
Dies ist in Bayern gerade dahingehend von Relevanz, wurden doch die öffentlichen Einrichtungen in denletzten Monaten ziemlich auf Sparflamme gesetzt.
Die Universitäten mussten dabei auch viele Planstellen einsparen.

Man kann schliesslich auf der einen Seite das Geld wegnehmen, auf der anderen Seite Forderungen stellen, die eine (wenn auch nur anfänglich) kostenbehaftete Umstellung verlangen.

Terminplanung:
Am 28. Oktober bin ich beim 5. Treffen der bayrischen Webadministratoren der Rechenzentren und Hochschulen (AK-By-Web).

Mal sehen, was sich bei den Kollegen getan hat.
besonderes interessioert es mich, ob die Kollegen, die noch letztes mal von ihrem neu gekauften NPS geschwärmt hatten, noch immer so euphorisch sind ;)

Wenn ja, hab ich schon ein Wermutstropfen für sie: Ich hab eine Anfrage von einem (uni-interdisziplinären) Webprojekt, daß von dort zu uns flüchten will, weil wir so ein nettes Webangebot haben ...

Wahrscheinlich in der ersten Novemberwoche werd ich ein Campustreffen zum Thema Barrierefreiheit durchführen.
Diverse Anfragen hierzu sind bereits raus. Darunter auch an die WAI-Liste und das Innenministerium, resp. derren IuK-Koordinierungsstelle.

So wie es jetzt bereits aussieht, ist das Interesse sehr hoch. So langsam stellt sich die Frage, ob unser üblicher Sitzungssaal für 50 Menschen ausreicht...

Das ganze richtet sich dabei zunächst hauptsächlich an die Webverantwortlicher und Webworker, die Websites für Einrichtungen der Uni Erlangen-Nürnberg machen.
Es wird jedoch wohl auch für andere Kollegen aus dem öffentlich-rechtlichen Bereich offen sein.

Alles weitere demnächst auch hier.

Auf Strohhalm gibt es derzeit ein überaus seriöses Jobangebot unter der Überschrift Jobangebot für die Cracks.

http://www.strohhalm.org/.someon?action=forum%2Fforum_thread&id=235335&pid=&sub=

Am Ende wird noch einem dum...äh, unerfahrenen Schüler gesucht, der Software installiert für 8- 10 Euro die Stunde.

Dies verleitete mich dazu, eine (Neu?)Definition des Wortes "Cracks" zu versuchen:


Def.: "Crack"
Woertliche Herkunft aus: "Hacker" und "Cracker".
Im Umgangssprachlichen Gebrauch auch "Freak" genannt.Hier jedoch bezogen auf Computer und IT.

Bezeichnet einen jungen, meist maennlichen Menschen, der vernarrt in IT ist und gerne stundenlang vor dem Computer sitzt um vermeintlich geniale und krasse Algorithmen zu nutzen, mit dessen Hilfe Big Brother wieder ausgetrickst wird. Ein Crack ernaehrt sich in der Regel von Pizza und Bier oder von dem erkalteten Abendessen von Mama.
Ein Crack erachtet es als Ehre und Hochachtung, ja sogar als Auszeichnung an, wenn ihn jemand fragt ob er dieses oder jenes macht. Mit einer gewissen Menge an virtuellen Honig wird der Crack nicht nur ohne Bezahlung arbeiten, er wird sogar dem Auftraggeber umsonst neue, vermeintliche genial sichere (aber danach oft fuer die taegliche Arbeit unbrauchbare) Betriebssysteme und Komponenten installieren und stundenlang darueber dozieren koennen, wie wichtig es ist, schallwellenunempfindliche Fensterscheiben und mit Kupferdraehten durchzogene Tapeten zu haben.

Solcherart Cracks werden in der Regel von echten Hackern gemieden. Erinnern sie den Hacker oft selbst an die eigene unruehmlichen Jugendjahre zurueck. Die Crack-Zeit ist fuer echte Hacker und IT-Professionals entsprechend vergleichbar, wie die Pickel der Pupertaet es sind fuer Erwachsene.

(Dieser Beitrag hat sich aus einer Forendiskussion auf SelfHTML ergeben. ich denke aber er passt auch hierein, bevor in in die unergründlichen Tiefen des Forumsarchives verschwindet)

Die Anfangsfrage war:

Wo ist die Crux, wo liegt das Problem, barrierefreie Seiten zu erstellen?


Ich denke es liegt im Kern an zwei Dingen:

1. Die übliche Marketingschiene funktioniert nicht mehr.
   In anderen Worten: Reicht es bei bisherigen, "herkömmlichen" Webdesign nur den Auftraggeber zufrieden zu stellen und nur dessen Geschmack zu treffen, ist dies nun nicht mehr der Hauptfokus.
   Barrierefreiheit heisst hauptsächlich, daß es den Besuchern und Benutzern der Website angepasst sein muss!
   Dies einem Auftraggeber zu vermitteln und diesen auch davon zu überzeigen, daß dessen Geschmacks- und Technikvorstellungen manchmal nicht nur veraltet sondern auch hinderlich sind, ist wirklich eine Herausforderung!
   Diese Herausforderung wiederum kann man nur mit echter Überzeugungsarbeit leisten. Nicht durch schöne Klarsichtfolien oder PR-Geschenke!
   
   Lange Rede, kurzer Sinn: Die gesamte Verkaufsschiene muss nun Qualität liefern und nicht mehr nur gut reden können!
2. Wer sich zu sehr auf veraltete Verbreitungswege und Techniken versteift hat, hat naturgemäß Probleme beim Umstieg.
   Die Firmen wiederum, die dies zu verantworten haben, weisen natürlich jede Schuld von sich (teilweise sogar zu recht).
   (Unmoralisch halte ich es aber schon, wenn heute noch große Internetagenturen und SOftwarefirmen an Kommunen Lösungen verkaufen, von denen sie wissen müssen, daß es ein Fehlkauf ist. Andererseits sind Firmen wie Microsoft oder Bertelsmann nicht dafür da, die CIO-Aufgaben für die Auftraggeber zu übernehmen. Im Gegenteil sorgen ja die Fehler bzw. vergessenen Umsetzungen zur Barrierefreiheit, daß es Folgeaufträge gibt... )
   Dies geht sehr tief auch ins das Thema ein, daß alte Zöpfe in Frage gestellt werden müssen. Ganz simples aber extrem heikles Beispiel: Benutzung von WORD.
   Jahrelang haben einige Leute erfolgreich mit WORD publiziert und gemacht. Und jetzt auf einmal wird dies in Frage gestellt, weil irgendwelche dahergelaufene Linuxuser (igittigitt) das nicht lesen können?
   Was nicht sein darf, das kann nicht sein!
   
   Das Beispiel soll zeigen: Es beginnt im Kopf und mit den eigenen Vorstellungen. Man geht quasi immer von sich selbst aus und denkt dass dies dann auch für andere passen wird.
   
   Ist aber eigentlich nicht so!
   Barrierefreiheit beginnt damit, die Barrieren im eigenen Kopf einzureissen. Nämlich die Barrieren, die dafür sorgen, daß man nicht über den eigenen Tellerrand schaut!
   
   Aber wie schwer es ist, das Umdenken, daß Neudenken und das eigene Infragestellen zu fordern, dürfte auf der Hand liegen.

Ansonsten ist die technische Umsetzung einer barrierenfreien Website nicht soooo anspruchsvoll. Nur der 2. Schritt ist echt die Nuss, die viele niemals knacken können und auch nicht wollen.

Eine etwas rhetorisch, zynische Frage, die ich kürzlich einen Kollegen stellen musste:

Du möchtest also Logindaten plain und ohne SSL übers Netz schicken. Aber wenn der Webserver, der in unseren durch IPtables, Router, Firewall, NIS geschützten Netz steckt, die Daten erhalten hat, willst du die Daten nur verschlüsselt über ein kompliziertes Keyverfahren an den Firebird weiterschicken, worin diese Daten nochmals gecryptet werden.
Hab ich das richtig verstanden?