Trotzdem ist mein Berufsleben nicht immer befriedigend, denn alles Digitale unterliegt einem grundsätzlichen Problem. Digitale Informationen sind uns nah und zugleich physikalisch entfremdet, sie sind nicht greifbar und trotzdem da – immateriell. Wenn ich Schreiner wäre, oder Architekt, hätte mein Schaffen einen realen Höhepunkt indem am Ende etwas vor mit steht, dass ich berühren und erfühlen kann. Andere Menschen könnten den Stuhl oder das Haus sehen und nachvollziehen, wie es gefertigt wurde.

Die Schönheit von Software hingegen ist nur für diejenigen begreifbar, die ebenfalls Software schreiben. Da im Arbeitsleben selbst wir Programmierer hin und wieder ein Schulterklopfen brauchen – auch wir haben ein mehr oder minder ausgeprägtes Geltungsbedürfnis – kann dies praktisch nur von anderen Wissenden erfolgen. Vielleicht gibt es deswegen viele Blogs zu diesem Thema. Natürlich kann der Kunde sagen, dass ein bestimmtes Detail einer Anwendung schön gelöst ist, aber das ist etwas anderes, denn der Kunde versteht nicht, wie genial das in einer wunderschönen Funktion im Source-Code umgesetzt wurde. Code is poetry – aber eben nur für Programmierer. Für alle Außenstehenden, nicht Wissenden stellt Quellcode ein unverständliches Kauderwelsch dar.

Vielleicht schraube ich deswegen so gerne an Motorrädern herum. Das Ergebnis ist real. Aber was ist schon real…?

Viel braucht es wirklich nicht, nur ein wenig HTML und ein wenig CSS, wobei der HTML-Code für das Menü absoluter Standard-Code ist, der auch für ein Top-Menü Verwendung finden würde.

		Home
		Weblog
		Infos
		Pornos
		Impressum
	

Der “menucontainer” ist übrigens überflüssig, den habe ich nur verwendet, weil ich das Menü nicht zentrieren, sondern etwas versetzt nach links anzeigen wollte.

Klarer wird es sichlich mit dem folgenden CSS, welches das Menü darstellt:

* {
	margin: 0em;
	padding: 0em;
	border: none;
}
#menucontainer {
	width: 800px;
	margin: auto auto;
}
#menu {
	width: 200px;
	-webkit-transform: rotate( -90deg );
	-moz-transform: rotate( -90deg );
	-moz-transform-origin: 100px 100px;
	filter: progid:DXImageTransform.Microsoft.BasicImage( rotation=3 );
}
#menu a:link, #menu a:visited {
	background-color: #F00;
	color: #FFF;

	margin-bottom: 25px;
	width: 200px;
	height: 50px;
	padding: 5px;
	line-height:90%;
	display: block;

	font-family: sans-serif;
	font-weight: bold;
	font-size: 24px;
	text-decoration: none;
}
#menu a:hover {
	background-color: #DDD;
	color: #F00;
}

Wenn ich ein CSS-Stylesheet beginne, schalte ich zuerst für alle Elemente die margins, paddings und die borders aus, um sie später für die Elemente wieder zu setzen, wo ich diese Eigenschaften wirklich brauche. Das macht die ganze Sache immer klarer und behebt viele Probleme mit dem IE auf einen Schlag.

Dem div “menucontainer” wird dann eine Breite von 800 Pixeln zugewiesen und ein automatischer margin, wodurch das gesamte div element im Browser zentriert wird.

Dann kommt schon die Anweidung, die das Menü gegen den Uhrzeigersinn dreht. Zuerst wird eine Breite vergeben, die der Breite der einzelnen Menüpunkte entspricht. Das muss so sein, sonst funktioniert es im IE 7 nicht.
Danach folgen Anweisungen für die verschiedenen Browser um die Rotation durchzuführen. Wichtig beim FireFox: “-moz-transform-origin” muss korrekt gesetzt werden, sonst sitzen die Menüpunkte später zu tief. Jeweils die Hälfte der Menüpunkt-Breite für horizontalen und vertikalen Wert haben sich bei mir bewährt.

Die einzelnen Menüpunkt können beliebig formatiert werden, auch margins und paddings sind kein Problem. Wichtig ist allerdings, dass “display” auf “block” gesetzt wird und feste Breiten und Höhen vergeben werden, sonst wird es Probleme bei der Darstellung geben.

Getestet habe ich die Anweisungen im IE 7 und im FireFox 3.5. Im IE 6 läufts so lala, könnte man sicherlich auch noch hinbekommen, aber ich bin der Meinung, dass der IE 6 nicht mehr unterstützt werden muss. Wer den IE 6 noch nutzt, der fährt auch Autos ohne Bremsen.

Hier gibt’s die komplette Datei und hier eine kleine Vorschau, wie es aussehen könnte:

Also probierte ich ein wenig rum, versuchte die Querys zu optimieren, den Code umzustricken, mit dem Ergebnis, dass alles nichts brachte. Eine Query von 3000 Datensätzen dauerte teilweise Minuten lang – was natürlich in der Rechnerwelt mehr als eine Ewigkeit ist. Okay, es wurden ziemlich viele Tabellen per Join hinzugezogen, aber 3000 Datensätze… pah, das ist doch wirklich lächerlich.

Also bin ich nochmal die Tabellenstruktur durchgegangen und siehe da: Zwei ID-Felder waren nicht mit einem Index versehen. Nach dem Hinzufügen dauert die Query dann 0,00 Sekunden. So soll es sein.

Blöder Typo3 Kickstarter. Wer damit arbeitet, aufgemerkt: Das Ding vergisst bei bestimmten Konstellationen die Indizes, also von Hand anlegen, sonst kann euch die Query bei komplexen Joins um die Ohren fliegen.

Das Veranstaltungskalender-Modul ist übrigens ziemlich pornös geworden: So mit Drag n Drop und Medienupload im Overlay, halt alles was man so mit Scriptaculous + Prototype so machen kann und Typo3 von Haus aus nicht mitbringt. Außerdem kann der Kalender wiederholende Termine an bestimmten Wochentagen, wobei die Eingabe richtig schön einfach ist. Ist auf jeden Fall eine nette GUI geworden.

Übrigens mag ich Typo3 nicht, die API ist scheiße dokumentiert und die Icons im Backend ätzend fitzelig und alles andere als selbsterklärend. Ich hoffe es ist bei der Entwicklung dieses einen Moduls geblieben. Schade, dass wir in der Firma kein WordPress anbieten. Da hätte ich richtig Spaß!

Also werden die besten Entwürfe an den Kunden übermittelt und natürlich entscheidet er sich für den, der einem selbst am wenigsten gefällt. Überzeugungsarbeit ist zwecklos, der Kunde hat schließlich immer Recht. Ergebnis ist letztendlich, dass die Motivation die Seite umzusetzen nicht wirklich gegeben ist. Das hat mehrere Gründe: Frustration, dass das Design, das man selbst für gut und richtig befunden hat nicht angenommen wird und natürlich auch die Tatsache, dass das Ergebnis für einen selbst ja aus Prinzip schon nicht befriedigend sein kann. Und eine rechte Lösung gibt es auch nicht: Der Kunde entscheidet und Design ist nun mal eine Geschmacksfrage.

Das macht wohl den Unterschied zum Profi-Designer aus: Er produziert Layouts, die alle so gut sind, dass er sie ohne Gewissenbisse umsetzen kann.

Bei einem Programmierauftrag ist das anders, denn beim Programmieren obsiegt immer die Logik, ist Kern des Ganzen und kaum angreifbar. Für einen Außenstehenden gibt es beim Programmieren viel wenig Geschmacksfragen. Vielleicht programmiere ich deswegen lieber, als das ich Layoute.