Rainers Horen
Sonnabend, den 30.04.2011 [20:12]
Walpurgis 2001: in Thüringen wird heute Abend in den Kleingärten das alte Gestrüpp und das Laub verbrannt – in Hamburg ist heute wieder großer Aufmarsch. Der Aufhänger ist die verfehlte Wohnungspolitik und das angedroht Duldungsende für die Rote Flora. Und so marschieren Sechstausend hochmotivierte Mitläufer gegen oder mit mindestens genau soviel adrett angezogene Polizisten.



Beitrag kommentieren

Freitag, den 29.04.2011 [19:22]
Heute ist nun der lang ersehnte Tag gekommen, von denen unsere Kinder noch ihren Enkeln erzählen werden: der Tag der Prinzenhochzeit. Wirklich großartig!



Aber was kann man nun mit dem AppceleratorTitanium anfangen? Da kommt ein Gedanke. So genial das TYPO3 ist, hat es doch einen schwergewichtigen Nachteil. Das interne Verwaltungswerkzeug (TYPO3-Jargon: Backend) hat die Ästhetik eines kruden Sozialhilfeantrages. Das ist wohl auch der Grund für die verminderte Akzeptanz dieses Systems jenseits des großen Teiches. Dem Klischee nach muss dort alles die Einfachheit einer Pizzabackmaschine haben. Nun ist das mit dem Admintool erst einmal zweitrangig. Es kommt auf die Schönheit, Anmut und Ästhetik der öffentlichen Ausgabe an. Nicht nur. Die Googlestartseite (gibt es eine andere?) gewinnt keinen Schönheitswettbewerb, ist aber dennoch nicht in aller Mundem, aber dennoch oft genutzt. Ist es nicht vielmehr so, das die Besuchsfrequenz mit der Änderungsgeschwindigkeit des Inhalts einhergeht? Sicherlich gibt es Millionen von Webs, auf die nur das eigene Marketing, fremde Rechtsanwälte und Suchmaschinen schauen – aber psst!

Wenn also eine Web erfolgreich sein soll, sollte sie nicht mit Fremdwerbung vollgeknallt sein, sondern mit pfiffigen, kurzweiligen und sinnstiftenden Inhalten. Diese Inhalte lassen sich durchaus durch Nutzer generieren (Crowdsourcing =/ Web2.0β), aber wer will das schon? Wirklich lesenswerte Beiträge kommen nur aus berufender Feder. Es soll sich ja vom allgemeinen Rauschen abheben. Da dann diese Texte oftmals aus dem Innern eines Betriebes oder gar Behörde kommen, müssen diese Kräfte motiviert werden. Geld zieht nicht – das haben sie schon auf ihrem monatlichen Kontoauszug. Also muss das Werkzeug zur Inhaltserstellung zumindest nicht Angst machen oder zu frustrierend sein. Nun ist das Standard-TYPO3-Redaktionswerkzeug nicht wirklich gruselig und wenn man es öfters in der Hand hat, dann schmeichelt es sogar die Hände. Aus dem Grund, warum gerade gestern der SPIEGEL vom Datenleck auf der UNESCO-Seite berichtete. Dort im Bewerberportal liegen immer noch zigtausend Bewerbungen offen rum. Adressiert werden die Seiten durch eine fortlaufende Nummer … Mit Sicherheit hat das nichts mit der mangelnden Qualifizierung der Programmierer, sondern mit mangelnder, weil bewußt eingeschränkter Kommnikation zu tun. Um einmal aus eigener Erfahrung zu sprechen – selbst Geldinstitute sind in solchen Sicherheitsfragen völlig ahnungslos.

Der Gedanke: bei größeren TYPO3-Projekten (=größeres Budget) ein spezielles Redaktionswerkzeug für das iPad oder iPhone zu schreiben. Dann sind supereinfache Bedienkonzepte machbar. Der Theaterintendant kann dann ganz einfach seinen Spielplan konfigurieren. Wäre nett. TYPO3 hat diese Fernsteuerschnittstelle (XMLrpc). Wenn jetzt die iPad-Anwendung dieses Protokoll spricht, dann ist der Drops gelutscht. In der etwas spärlichen Titanium-Dokumentation gibt es tatsächlich einen ¬entsprechenden Codeschnipsel, der allerdings die XML-Antwort vom Server nicht verarbeitet. Das wäre eine Aufgabe für die titaniuminterne Funktion, geht also mit ¬Bordmitteln.

Zwischenzeitlich wäre es wohl auch sinnvoll zu sichten, was mit dem Titanium-Werkzeugkasten alles so anzustellen geht. Die nebige Webdemo zeigt natürlich nicht die volle Dynamik. Aber es ist schon besser, als einfach nur Bildschirmfotos hin zulegen.

Wie den Anschein hat, haben die die Kollegen Programmierer etwas dabei gedacht. Der Teufel wird wohl im Detail stecken, aber immerhin. Im System gibt es viele Dinge, die es im jQueryMobile/phonegap-Gespann nicht gibt – so auch das Updating bei Zug an der oberen Kante ;-))

Auch an eine Maps-Darstellung ist gedacht. Allerdings gibt es nur die Darstellung eines Markers. Ob auch komplexe Problemlösungen möglich sind, bleibt offen. Zur Not ist auch der Webview möglich. Allerding ist das eine teure Lösung. Das heißt, dann wird es träge. Wohlgemerkt: phonegap ist reinster Webview.

Beitrag kommentieren

Donnerstag, den 28.04.2011 [08:48]
Von den bekannten ¬Webgrrls ist gestern der Wunsch vorgetragen, ob ich nicht im September 2011 einen Vortrag darüber halten könnte, wie sich die Webdesignerinnen dem Thema Smartphone nähern könnten – Webdesign goes mobile. Da in diesen Kreisen wenige oder keine Programmierkenntnisse vorhanden sind, sollen sich die Betrachtungen auf Designprobleme beschränken. Das Thema schon mal hier gedanklich vorzubereiten, ist eine wunderbare Idee – es füllt sinnvoll den Donnerstagvormittag im ABSURD, in dem gerade wieder eine großartige Ausstellung von ¬Bärbel Fooken (Otto Dix des Nordens) ihren angemessenen Raum gefunden hat:

Fangen wir einfach beherzt mit dem Einstieg an: verschiedene wissenschaftliche Studien der Smartphoneanbieter legen den Gedanken nahe, dass sich der Informationskonsum eindeutig vom Desktoprechner über Laptop zum Smartphone entwickelt. Es ist schon nett, überall auf das Weltwissen zugreifen zu können und gleich mal zu schauen, was heute Abend in dem Kino kommt, auf das man/frau gerade zusteuert. Auch auf dem Wochenmarkt lachen einen die leckeren Kohlrüben an und schon wird das Phone herausgezogen, um mal zu gucken, was man aus dem Rummelsburger Ananas alles bereiten kann. Wenn also die Netzgemeinde auf immer kleinere Bildschirme schaut, ist es auch als Inhaltsanbieter sicher sinnvoll dorthin zu schauen. Die gute Nachricht: die Qualifizierung im Webbereich kann weiterhin verwendet werden. Es gibt aber einige Punkte zu beachten. Das ist der Inhalt dieses Artikel und des Vortrages.

Vorerst die wirklich gute Nachricht: auf allen Smartphones ist ein Webbrowser installiert. Dieser Webbrowser nutzt als Renderingmaschine Webkit – besser bekannt als Safari. Das vereinfacht natürlich die Entwicklung: einmal weil es nur einen Browser gibt und was noch schöner ist: Safari ist HTML5/CSS3-fähig. Ade also diese ganzen mühsam erstellten Farbverläufe, runden Ecken und weichen Schatten. Dafür braucht es jetzt kein teures Programm mehr, das kann alles der Browser mit Bordmitteln. Das freut besonderns den Nichtgrafiker ;-) Es gibt aber nicht nur Faulheitsargumente: es soll Webs geben, bei denen sich die Inhalte öfters ändern. Farbverläufe, runde Ecken an Bildern und anderer Schnickschnack wären ohne laufendes Zutun eines Photoshopartisten kaum möglich.



Obiger Bildschirmausriss zeigt ein Teil der neuen Möglichkeiten. Zusätzlich sind beim neuen Safari auch Animationen ohne Javascript möglich. Diese tollen Möglichkeiten werden exzessiv in den WebApp-Frameworks benutzt und sind hier schon öfters beschrieben worden.

Was passiert nun, wenn eine gewöhnliche Webs (so wie diese) auf einem Smartphone aufgerufen wird? Da der Viewport (das Schaufenster) auf einem Smartphone wahrscheinlich wesentlich kleiner als 960 Pixel ist, wird die Seite beispielsweise auf 320 skaliert. Mit den üblichen Gesten kann der geduldige Internetangucker sich nun den Inhalt erschließen. Für einen gewissen Notbetrieb mag das angehen, aber alles was geht, kann auch noch besser gehen.

Wie sehen gewöhnliche Desktop-Webs aus? Auch hier gibt es Platzbeschränkungen und das Web ist keine papiernes Flugblatt. Bei der Gestaltung eines Flyers oder Plakates wird der Designer immer als erstes gefragt: „auf welcher Fläche hätten Sie es gerne?“. Dann legt beispielsweise Photoshop eine Leinwand von 2000×1000 Pixeln oder Millimetern an und schon beginnt die kreative Phase. Der Bildschirm ist in dieser Hinsicht ganz anders aufgestellt. Er hat eine variable Größe und man kann ihn nach unten scrollen. Aus pragmatischen Gründen gibt es also keine Blattorientuerung mehr. Einfach, weil senkrechtes Scrollen einfacher als Blättern ist – das stört weniger den natürlichen Lesefluß.

Nach einigen Irrwegen von freischwebende, mittenzentrierten Postkarten haben sich in letzter Zeit einige Paradigmen durchgesetzt: Damit die wichtigsten Informationen mit geringstem Aufmerksamkeitsverlust präsent sind, befindet sich dieser Inhalt in einem Bereich, der ca. 960px breit ist. Auch wenn Bildschirme heute meistens größer sind, wird sich häufig auf diese Breite beschränkt. Aus ergonomischen Gründen kann eine Textzeile eh nicht länger als 40 Anschläge sein, so dass die vorgegebene Breite durch Menüs und Aktuellbereiche weiter eingeschränkt wird. Jetzt kommen wir zu einem wichtigen Punkt: im Web ist es enorm wichtig, den Gucker die Sicherheit zu geben, sich nicht im Cyberspace zu verlieren. Deswegen ist eine klare, sofort verständliche Navigation anzubieten. Klare Navigation hat zwei Aspekte: der Nutzer weiß immer, wo er ist und wie dieser gerade aufgeschlagene Inhalt zu anderen Inhalten steht, dass heißt, wie es wieder oder „nach oben“ geht. Inhalt und Menü sind also immer auf der gleichen Seite.

Auf einem Smartphone ist dafür kein Platz. Der Trick ist nun der: in einer überdeutlichen, reinen Menüführung wird der Nutzer zum Inhalt geführt. Damit er den inneren Zusammenhang mitbekommt, wird er mit animierten Übergängen an Händchen genommen. Das einzige Zuggeständnis an eine immer präsente, durchgängige Navi ist die unten platzierte ¬Glyphischbar. Das ist eine schwarzweiße Hauptnavigation und prangt immer unten.Eine kleine Auswahl ist hier zu sehen und ist sicher Inspiration und Tummelplatz neuer Kreativität.



Im eigentlichen Inhaltsbereich gibt es auch einige Spielregeln. So wie es im OldschoolWeb mindestens zwei Todsünden gibt – nämlich der überflüssige, insbesondere der waagerechte Rollbalken und das unsägliche Popupfenster – so ist es in der schönen neuen Mobilwelt absolut verpönt, wenn die Seite von der horizontalen Ausdehnung nicht in den Viewport passt. Ist nämlich ein Inhaltselement größer als dieses, beginnt die Seite zu wabern und zu schaukeln. Ganz schlimm! Die Seite kann ruhig sehr lang sein. Das ist nicht weiter tragisch, weil der Nutzer es gewohnt ist, schnell mit dem Finger nach unten zu flutschen. Waagerechtes Wischen wird nur innerhalb der Navigation und bei Photogalerien erwartet.

Dreht man ein Smartphone, dann wird das vom Neigungssensor bemerkt und das Browserfenster bekommt andere Abmaße. Entweder ist das CSS flexibel genug, um das abzufangen (fließende Container) oder der Webdesigner hält zwei HTML/CSS-Konstrukte vorrätig, die dann nach Auftreffen des Ereignisses 'orientationchanged' per Javascript umgeschaltet werden können.

Noch einige Worte zu Besonderheiten des iPhones. Es hat eine Auflösung von 460×320 Pixel. Das ist die Auflösung, auf die der Entwickler per CSS Zugriff hat. Macht er also ein Bild 320 Pixel breit, dann passt es genau im Portrait-Modus in den Viewport. In Wahrheit hat das Gerät aber doppelte Auflösung. Diese Reserve nutzt der interne Renderer für Kantenglättung. Das ist übrigens der Grund, warum GeoMaps im nativen Modus schärfer daherkommen als bei Webapps, weil bei Webapps dann doch nur 256×256-Kacheln ausgeliefert werden. Eine weitere Besonderheit ist die Vollschirmbetriebsart. Dabei erscheint auf dem Desktop (hier Home genannt) ein kleines Icon. Bei Klick darauf wird intern Safari mit der hinterlegten Webadresse gestartet. Während der Startzeit des Browsers erscheint ein Startbildschirm (eine schöne Kreativspielwiese) um dann die Webseite ohne Browserframework (Rahmen und Adresszeile) zu zeigen. Warum das SPIEGEL-Online nicht so macht, wird wohl ewig ein Rätsel bleiben …

Wie funktioniert das? zwei Einträge im HTML-Kopf der Seite melden dem Browser Pfad zum Icon und zum Vorschaubild. Klickt der Nutzer auf der Startseite auf den mittleren Button im unteren Browserbalken, dann wird Safari verlassen und das Icon angelegt. Der Laufmodus lässt sich per Javascript abfragen. So kann frau/mann entweder einen mehr oder weniger dezenten Hinweis einblenden, der zu dieser Handlung auffordert („Bitte speichere mich für den Vollscreenmode“) oder im vollzogenen Fal die Adresszeile per CSS ausblenden.

Jetzt kommen wir zur Hauptfrage des Themas: „Webdesign goes mobile“. Nämlich, wie kann ich das technisch umsetzen? Der erste Ansatz wäre die händische Lösung mit einem Texteditor der Wahl. Sicherlich geht das auch mit fertigen HTML-Editoren. Das bleibt den jeweiligen Vorurteilen überlassen. Das mit dem händischen Ansatz war natürlich ein Scherz. Das würde jedes Budget sprengen und auch unbeholfene Lösungen zeitigen. Sinnvoll ist ein Framework, das die eigentliche Problemlösung von der Technik abschirmt. Was müsste es leisten? Es müsste das Styling der einzelnen GUI-Elemente (Listen, Formulare, Überschriften) übernehmen, die Übergänge zwischen den Seiten realisieren und animieren, aber auch über Ajax/JSONP das Nachladen dynamischer Inhalte machen. Was oft übersehen wird: das Touchhandling. Auf Smartphones gibt es durchaus andere Benutzereingaben. So gibt es kein Hover-Effekt, dafür gibt es Gesten, die das skalieren oder scrollen anstoßen. Das Framework muss also auch diese Events verarbeiten, um dann beispielsweise einen Scrollview zu bedienen.

Den Anfang hat iUi gemacht. Dieses WebFramework ist vom Erfinder des bekannten Firebugs. Darauf aufsetzend ist jQtouch entwickelt worden. Jonathan Stark ist ganz groß in diesen Dingen. In Deutschland sind schon zwei Übersetzungen seiner Bücher erschienen. Dieses Projket heißt jetzt Sencha und hat sicher seine Zukunft. Wer mit jQuery unterwegs ist, dem wird jQueryMobile gefallen. Dieses system hat im Gegensatz zu jQtouch mehr einen themenorientierten Ansatz und bietet abstraktere Elemente. Von der „Programmierung“ unterscheiden sich die System nicht groß, so dass hier allgemeine Tipps gegeben werden können.

In nullter Näherung befindet sich der gesamte Webseiteninhalt auf einer HTML-Seite. Die einzelnen Seiten sind DIV-Container, deren Sichtbarkeit vom System verwaltet wird. Der Klick auf einen Link wechselt die Sichtbarkeit und vollzieht die Animation. Die hierarchische Navigation wird wie zu erwarten über UL-LI-Konstrukte realisiert. Der Typ der Animation wird über CSS-Klassen im Linktag gesteuert. Innerhalb der Seiten gibt es Kopf-, Inhalts- und Fußbereich, die teilweise automatisch mit passendem (Navigations-)Inhalt gefüllt werden.

Das Fazit für Webdesignerinnen: es gibt Hoffnung und neue Horizonte. Wie bei all diesen Dingen gibt es auch ein Wermutstropfen: im mobilen Web braucht's weniger oder anderes Grafikdesign – oder wohlwollender gesagt, es braucht andere Qualifikationen. Die Zukunft bleibt spannend.
Beitrag kommentieren

Mittwoch, den 27.04.2011 [10:56]
Ein Stellwerksproblem legt die ganze Ringbahn lahm. Das ist ein wunderbare retardierendes Moment in dem so hektischen Großstadtleben. Dann klappen wir das MB-Air auf schalten den persönlichen Heißpunkt ein und bloggen ein wenig. Das mit dem Appcelerator hat sich gütig geklärt. Zwischen den Android-Versionen hat sich der Lagerart eines Tools geändert. Leider wissen die Tutorials im Netz nichts von der Notwendigkeit des Symlinks. Das sind die WUZ-Dinge (wildes, unbekanntes Zeug), die eine Kalkulation erschweren.



Nun ist aber die Kuh vom Eis, der Drops ist gelutscht. Schauen wir einmal, was Titanium im Vergleich zum Gespann phonegap/jquerymobile so bietet. Als erstes fällt die engere Anbindung an das System isn Auge: es gibt beim Appcelerator/Titanium zusätzlich zur Kopplung an die Sensoren wie Kompass/Neigungsmesser/Geoposition auch noch Zugriff auf die Kamera, den Screenshotmechanismus, Kontakte und die Kamerarolle. In der Beispieldemo Kitchensink fehlen allerdings Beispiele zu den Themen Maps und Photogalerien. Das mag noch nichts bedeuten. Die Gestaltung der Oberfläche erfolgt nicht über Stylesheets, sondern über Eigenschaften der Javascript-Bibliothek. Dem ersten Anscheine nach gibt es keine CSS-Klassen mit denen man Gruppen von Elementen gemeinsam mit einen Stil versehen kann. Eine denkbare gemeinsame Regel wäre: jeder Überschrift zweiter Ordnung hat die und die Farbe, Innen und Außenabstände usw. Jedes Element wird einzeln gestylt. Wenn dem wirklich so ist, dann ist das recht unflexibel.
Beitrag kommentieren

Dienstag, den 26.04.2011 [14:31]
Da kommt ein Anruf rein: „Kennst Du ¬Titanium?“ – und schon hat der Tag einen Sinn bekommen. Was ist das? Apps für das iPhone und für die anderen Geräte kann man im jeweiliegen nativen Code (ObjectivC/Java) entwickeln oder man kann sich davor drücken. Dafür spricht Einiges.

Auf all diesen Geräten gibt es einen Webview, das heißt ein Internetanguckprogramm – aber eben ohne die übliche Navigation drumherum. Der erfahrende Webprogrammierer baut also ein Webapp und die läuft dann „nativ“. Das fühlt sich schon sehr gut an. Der andere Weg ist ein reines Javascriptprogramm, das nach ObjectivC/Java gewandelt wird und dann wirkllich nativ ist. Übrigens: Javascript und Java haben bis auf den Namen nichts gemein.

Jeder neue Coderlebensabschnitt beginnt mit dem Runterladen des Paketes – so auch bei Titanium. Das war einfach. Nun gibt es ein Zusatzpaket, das auch viele Beispiele enthält. Es heißt Kitchen Sink und ist auch schnell runtergeladen und angeflanscht. So gedacht. Aber: es ist ja immer etwas. Im Rootverzeichnis des KitchenSink-Paketes ist nichts zum importieren. Alle Dateien sind geghostet (=begeistert?). Dafür gibt es eine Lösung. Der Import funktioniert so nicht. Einfach ein neues Projekt anlegen und dann reinkopieren. Jetzt kommt der nächste „Stolperstein“: um einfach nur einmal reinzuschnuppern, muss sowohl die iPhone-Entwicklungsumgebung als auch der Android-Kram auf der Maschine sein. Das dauert erfahrunsgemäß. Schon weil über 4 Gigabyte aus dem Netz zu holen sind. Im Falle der Entwickjlungsumgebung von Apple ist das vergleichsweise einfach: holen, auspacken und installieren. Bei Android muss man Eclipse holen und hinpacken. Danach gibt es im Hilfepfad einen Punkt „Softwareinstallation“. Dort kommt die ¬Android-Sache rein. Auch das dauert wieder eine gewisse Zeit, derweil ein Espresso die nachmittäglichen Melancholie überbrücken kann.



Auf dem Screenshot sieht das schneller aus als in der Soheit. Nun schaut mir die Maske mit leicht verändertem Inhalt (Balken kriecht nach rechts) schon seit einer Ewigkeit entgegen. Leider mäkelt jetzt Titanium immer noch rum, weil es den Android-Kram nicht findet. Das Leben könnte so schön sein. Nach wirklich langer Überlegung und Hilfe durch den Hochseehecht ist es klar, in dem SDK muss per ln -s ./platform-tools/adb ./tools/adb eine Biegung gebaut werden.
Beitrag kommentieren

Montag, den 25.04.2011 [22:04]


Nachfolgender Twittermonitor zeigt die Inflation von Machbarem und die ständig wachsende Informationsflut. Falls es noch nicht jeder weiß, Twitter ist so etwas wie ¬CB-Funk. Jeder kann quatschen und selbstverständlich auch zuhören (wenn er/sie dazu noch kommen). Es ist für Poser und Rampensäue das überhaupt niedrigschwelligste Angebot. In der Grundfunktion kann die Ergüsse von Jemanden abonieren – das folge ich ihm und nenne mich Follower. Zusätzlich gibt es eine Volltextsuche, die sofort alles annalysiert. Werfe ich also in das Monitorprogramm den Begriff Grill rein, dann sehe ich fortlaufend alle Nachrichten (=Tweets), die das Suchwort enthalten. Nun gäbe das Verfahren ein noch größeres Rauschen und man hat sich darauf geeinigt, wichtige Worte mit # beginnen zu lassen. Suche ich also nach #AKW bekommen ich alle Nachrichten, in denen jemand das Wort und die Problematik besonders wichtig findet.

Das ganze Twitterimperium ist letztlich ein riesiger, kostenloser Kleinanzeigenmarkt, auf dem es sehr viele Anzeigen gibt, in in dem man in Echtzeit sehr schnell suchen kann (und muss). Wie in Programmiererstammtischen zu beobachten hat Twitter einen gewissen Suchtfaktor. Da gibt es Programme, die mehrere Tweets monitoren. Schon das rechtfertigt einen größeren Monitor.



Im Übrigen ist Twitter so eine Erscheinung wie Fratzenbuch, Fernsehen oder BILD: keine tut es wirklich. So etwa wie ein Raucher/Trinker jederzeit aufhören könnte.



Oder wie die Mac-Sucht: „Ich kann jederzeit zuklappen.“ Heute war im Absurd absolute Mac-Dichte: sechs Geräte an drei Tischen.


Beitrag kommentieren