640x480.de

„Innovative Informationsvisualisierungen“

Wir begleiten ein Projekt an der Bauhaus-Universität Weimar. Basis ist unser Webdesign für Bazon Brock.

Der Eintrag im Vorlesungsverzeichnis sieht reichlich nüchtern aus.

„Brocks Website (http://www.bazonbrock.de/), seit 2011 betreut vom Weimarer Gestaltungsbüro Kohlhaas & Kohlhaas, stellt seine umfangreiche Arbeitsbiographie mit einem Volltextarchiv bestehend aus 2,7 Millionen Wörtern, knapp 1200 Bildern, 33 Videos und 70 Tondokumenten zur Verfügung. Gemeinsam mit Kohlhaas & Kohlhaas wollen wir auf Basis dieses reichaltigen Datenbestandes innovative Informationsvisualisierungen für Brocks Werk entwerfen und implementieren.“

Wir geben praktische Erfahrungen konkreter Webdesign-Projektarbeit für Bazon Brock in die wissenschaftliche Diskussion und freuen uns auf gegenseitige Inspiration im Projekt „Bazon Brock: Visualizing a thinker’s life“ an der Fakultät Medien der Bauhaus-Universität Weimar.

Update November 2013: Auf der Website der Professur Virtual Reality and Visualization Research gibt es nun auch eine offizielle Projektseite.

22.03.2013 | Noch keine Kommentare

Neuer Beruf: „System-Sekretär/in“ oder „Secret Administrator“

Was kleinen Unternehmen und Freiberuflern echt weiterhelfen würde, wäre jemand, der sich liebevoll und sachkundig um IT & Co kümmert, Office-Software bedienen kann (und weiß, dass man damit mehr machen kann, als mit einer Schreibmaschine), in der Lage ist, Telefonate freundlich entgegenzunehmen, Rechtschreibung nicht als notwendiges Übel betrachtet, ein wenig Ahnung von Buchhaltung hat … und überhaupt alles ein bisschen zusammenhält – die Kombination aus Sytemadministrator/in und Sekretär/in eben. Das wär’s.

12.02.2013 | Noch keine Kommentare

MoSCoW-Meeting

Unsere kleines Entwicklerteam traf sich heute zur Priorisierung der Aufgaben zur Finalisierung von Akira2.

Die Feature-Liste ist geschlossen, jetzt geht es ans Aufarbeiten der letzten Problemstellen, Kontrolle und Doku. Bei der Sortierung der Aufgaben sind wir nach der MoSCoW-Priorisierung vorgegangen.

15.01.2013 | Noch keine Kommentare

Telefonbuchsynchronisation

Wer kennt das nicht: da hat man E-Mail Programm, und iPhone und mehrere Benutzer und eine Telefonanlage und am Ende findet man gerade die Adresse oder Telefonnummer genau da nicht, wo man sie braucht obwohl die ganz bestimmt irgendwo eingetragen wurde.

Was also tun? Das muss alles synchronisiert werden.

Bei mir ist die Konstellation so: 

• Egroupware als zentraler Adress- und Kalenderserver mit zwei Benutzern, also zwei Adressbüchern.
• Thunderbird auf diversen Computern als E-Mail Client. Hier erfolgt der Zugriff auf die Egroupware Adressen mit Hilfe des Sogo-Connectors von Inverse via CardDav
• Fritz!Box mit Firmware 5.29, dran angeschlossen einige DECT Mobilteile. Derzeit gibt es hier keine richtige Synchronisation.
• dazu iPhone und iPad, Zugriff erfolgt über Carddav auf den Egroupware Server

Eigentlich funktioniert der Zugriff auf die Adressen schon ganz gut, der einzige Wermutstropfen ist die Anbindung der Telefonanlage. Das ist deshalb ärgerlich, weil das Telefon eigentlich ja der natürlichste Platz für die Benutzung von Telefonnummern ist. Bisher ging die Synchronisation der Fritzbox leidlich gut mit einem Thunderbird-Plugin namens ThunderBox. Leider funktioniert das nun nach einem Update der Fritzbox Firmware überhaupt nicht mehr.

Da muss also eine bessere Lösung her.

Nach ein bisschen Recherche habe ich herausgefunden, das man mit der FritzApp fürs iPhone das aktuelle Adressbuch des iPhone als XML Datei exportieren kann, die dann über das Web-Interface der Fritzbox dort importiert werden kann. Sicher nicht der einfachste Weg, aber das sind wir ja bei Computern in heterogenen Umgebungen gewohnt.

Leider gibt es ein Problem: bei den Namen in den Telefonbucheinträgen in der Fritzbox wird nicht in Vor- und Nachname unterschieden. Alle Einträge stehen deshalb in der Form "Vorname Nachname" im Telefonbuch der Fritz!Box. Das ist ungünstig, weil ich es eben lieber hab, wenn die Namen im Adressbuch nach Nachname sortiert werden. Ausserdem ist das ganze Prozedere natürlich viel zu umständlich.

Nachdem ich mit die Struktur der XML-Exportdatei angesehen habe, kam mir sofort die Idee, eine solche Datei per PHP selbst zu erzeugen - natürlich aus den aktuellen Daten der Egroupware Datenbank. Dann kann ich den Inhalt der XML Datei selber formatieren, also z.B. das Namensfeld mit dem Nachname voran bestücken.

Evtl. ist es sogar möglich, den ganzen Export/Import Vorgang soweit zu automatisieren, dass einfach die Egroupware Adressbücher der beiden Nutzer per Knopfdruck aktuell in die Fritz!Box zu übertragen werden.

Mal sehen. Vielleicht implmentiere ich das noch dieses Jahr - nach Weihnachten, wenn die besinnliche Zeit beginnt. Die Idee steht jedenfalls.

Nachtrag (27.10.2013):

Mittlerweile habe ich ich das implementiert (auf der Basis der Fritz!Box API von Gregor Nathanael Meyer) und es läuft bei mir auch ganz gut. Ich stelle das Skript hier mal zur Verfügung, aber Achtung: Benutzung auf eigene Gefahr. 

fritzbox_egw_sync.zip (zip / 7 Kb)

23.12.2012 | 7 Kommentare

Bildschirmauflösungen

„Die Web-Seite soll ganz auf den Bildschirm passen“, sagte der Auftraggeber. „Auf welchen?“, fragten wir.

Weil wir solche oder ähnliche Wünsche des Öfteren hören und uns sehr daran liegt, unsere Auftraggeber zu professionalisieren, hat Martin mal wieder eine kleine SVG-Fingerübung gemacht.

Herauskam eine Grafik, die eine subjektive Auswahl von 27 der aktuell verfügbaren nativen Auflösungen von Mobiltelefon-, Tablet- und Desktop-Monitoren zeigt. Die tatsächlich dargestellte Auflösung (Stichworte Retina, virtuelle Auflösung) wird hier noch nicht berücksichtigt.

Eine dynamische Grafik, gekoppelt an die jeweilige Piwik-Statistik einer Website, ist in Arbeit.

17.12.2012 | 3 Kommentare

Bildbehandlung in flexiblen Layouts

Unser Ansatz zum Thema adaptive/responsive images

Problematik: bestmögliche Bildqualität bei optimalen Ladezeiten. Auslieferung unterschiedlicher Bildgrößen für Desktop oder Smartphone.

Bildauslieferung im Grid-System (wie es bisher war)

Bei Seiten mit festen Layouts (z.B. www.architekten-thueringen.de, 24er-Grid nach dem 960 Grid System) ist von vornherein durch das Template klar, welche Bildgrößen benötigt werden, z.B: Projekt-Kurzansicht (grid6 = 230px), Projektdetailseite, Bild über ganze Inhaltsspalte (grid12 = 470px), Großansicht in der Lightbox (grid18 = 710px) und so weiter.

Diese Größen werden in der Projekt-Konfiguration festgelegt:

$GLOBALS['imageSizesReceiver']['grid_3'] = array(110,110);
$GLOBALS['imageSizesReceiver']['grid_4'] = array(150,150);
$GLOBALS['imageSizesReceiver']['grid_5'] = array(190,190);
$GLOBALS['imageSizesReceiver']['grid_6'] = array(230,230);
$GLOBALS['imageSizesReceiver']['grid_12'] = array(470,470);
$GLOBALS['imageSizesReceiver']['grid_18'] = array(710,710);
$GLOBALS['imageSizesReceiver']['grid_24'] = array(950,950);

Beim Hochladen eines Bildes in das CMS werden die entsprechenden Bildgrößen sofort berechnet und im Dateisystem abgelegt. Beim Ausliefern der Seite werden dann jeweils die richtigen Bildgrößen an der richtigen Stelle angezeigt.

Bildauslieferung im flexiblen Layout (das ist neu)

Für das Webdesign unserer flexiblen Layouts (z.B. www.baukultur-thueringen.de) gehen wir einen anderen Weg. Hier ändert sich die benötigte Bildgröße nicht nur nach der Stelle der Verwendung des Bildes im Template, sondern auch noch je nach Ausgabegerät.

Beispiel-Seite mit verschiedenen Bildgrößen und flexiblem Layout

Wir gehen vom Template für den großen Monitor aus und definieren Bildgrößen für die verschiedenen Layoutboxen (volle Breite, halbe, drittel, viertel, sechstel, usw.) Für die kleineren Bildschirme werden diese Breiten in die jeweilig gewünschte Breite übersetzt (so wird z.B. aus einer halben Box auf dem Desktop eine ganze Box auf dem Smartphone, aus einer Viertelbox eine Halbe, etc.)
Die entsprechende Tabelle in unserer Konfiguration sieht dann so aus:

$GLOBALS['imageSizes']['full']=array(1600=>960, 1024=>960, 768=>768, 480=>480);
$GLOBALS['imageSizes']['half']=array(1600=>480, 1024=>480, 768=>480, 480=>320);
$GLOBALS['imageSizes']['third']=array(1600=>768, 1024=>768, 768=>480, 480=> 320);
$GLOBALS['imageSizes']['twothirds']=array(1600=>768, 1024=>768, 768=>480, 480=>320);
$GLOBALS['imageSizes']['quarter']=array(1600=>240, 1024=>240, 768=>480, 480=>320);

Auch die Behandlung der Bilder im CMS (Akira) erfolgt nun anders. Beim Hochladen wird nur das Originalbild im Filesystem abgelegt. Die Skalierung erfolgt erst bei der Auslieferung einer Seite – das skalierte Bild bleibt im Filesystem liegen. Das hat jeweils beim ersten Aufruf eines Bildes in einer bestimmten Auflösung eine kleine Verzögerung zur Folge. Alle weiteren Aufrufe nutzen dann das vorgerechnete Bild.

Im Seitenheader ermitteln wir das Ausgabegerät über Javascript und legen diese Angabe in einem Cookie ab.

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+'; path=/';</script>


Damit wird also beim ersten Laden der Seite auf einem Gerät festgelegt, welche Bildgrößen ausgeliefert werden und das bleibt dann (auch trotz Änderung der Browsergröße erhalten). Der Desktop ist hier ein Sonderfall, weil nur dort Größenänderungen Sinn möglich sind. Auf Mobilgeräten lade ich die Seite ja immer mit der gleichen Auflösung.

Noch eine kleine Abgrenzung zum Schluss: Wir haben hier nicht nach einer Lösung für vollflächige Hintergrundbilder gesucht, die beim Browser resizing dynamisch nachgeladen werden. Im Vordergrund steht bei uns die effektive Darstellung und Auslieferung von Bildern im Seiteninhalt.

Weitere Ansätze für responsive images in einem Artikel bei speckyboy design magazin

26.11.2012 | 5 Kommentare