Codecandies

Bildergalerie bei ZEIT ONLINE, Ansicht auf dem iPad

Die Touchbedienung ist einer der großen Unterschied zwischen Tablet- und Desktopcomputer. Dieses Bedienkonzept, wie es der Nutzer inzwischen auch schon aus den sog. nativen Apps gelernt hat, so sinnvoll wie möglich umzusetzen und zu nutzen, sollte auf jeden Fall Teilaufgabe einer HTML5-App sein. Leider stehen der App im Browser nicht alle Schnitsstellen und Fähigkeiten zur Verfügung, die bei der Programmierung einer nativen App genutzt werden können. Darauf kommt es aber allein auch nicht an, wie gesagt, es geht eben auch und vordringlich um das Bedienkonzepte.

Als alten Hut muss man zum Beispiel die Bedienung mit Knöpfen sehen, denn Buttons sind eben typischerweise Klickziele für den Mauszeiger und weniger für den Finger. Obwohl ein Button natürlich auch in der Touchbedienung funktionieren kann; dann muss er aber groß und gut zu treffen sein, und auch noch erkennbar, wenn der Nutzer den Finger darauf legt. Trotzdem, ein Button zum Vor- und Zurückblättern in einer Bildergalerie, ist nicht wirklich tabletgemäß.

Um es kurz zu machen: in einer Bildergalerie wie dieser hier will der Nutzer sliden – mit dem Finger das Bild aus dem Viewport schieben – und nicht Knöpfe drücken. In der Tabletversion haben wir das im Ansatz umgesetzt. Nutzt man die Seite mit dem iPad, kann man mit dem Finger von einem Bild zum nächsten navigieren. Da ich danach gefragt wurde, will ich kurz erklären wie das funktioniert (und danach auch noch dazu kommen, was noch verbessert werden muss).

Zunächst mal haben wir das Konzept der meisten Bildergalerien auf ZEIT ONLINE übernommen. Die bestehen zum Ladenzeitpunkt nur aus ihrem ersten Bild, die restlichen Bilder werden nachgeladen und versteckt horizontal rechts vom ersten Bild aufgereiht. Klickt man einen der Buttons wird der Container mit den Bildern einfach immer um Bildbreiter nach links oder rechts bewegt.

Die Bedienung durch die Buttons haben wir nur durch die Touchbedienung erweitert. Vielleicht sei kurz erwähnt wie Javascript einen solchen Touchevent sieht: es gibt die vier Events touchstart, touchmove, touchend und touchcancel. Die ersten drei laufen immer nacheinander ab, wobei touchmove solange wiederholt wird, wie man mit dem Finger über die Touchoberfläche slidet. touchcancel tritt auf, wenn eine Touchaktion abgebrochen wird, bspw. wenn man mit dem Finger über den Bildschirm hinaus geht. Die Events haben als Eigenschaften (man kennt das von Mouseevents) u.a. die Bildschirmkoordinaten, wo sie ausgelöst wurden.

Damit lässt sich also leicht erkennen, ob zwischen touchstart und touchend eine Bewegung, also ein Swipe stattgefunden hat. Hier mein seht vereinfachtes, beispielhaftes jQuery-Plugin dazu (nur als Beispiel, nicht zur Implementation gedacht oder empfohlen):

$.fn.addSomeTouch = function (options) {
	var xmoved = 0, xstart = 0;
	return this.each( function() {
		// touchstart event
		$( "img", this ).bind( "touchstart", function () {
			// jeder Finger ist ein Feld im Array
			// hier: 1-Finger-Geste
			if( event.touches.length == 1 ) {
				// Startpunkt merken
				xstart = event.touches[0].pageX;
			}
		});

		// touchmove event
		$( "img", this ).bind( "touchmove", function () {
			// Bewegungsentfernung messen
			xmoved = event.touches[0].pageX - xstart;
		});

		// touchend event
		$( "img", this ).bind( "touchend", function () {
			// Limit für Verzögerung
			if( xmoved >= 50 ) {
				alert( "I was touched and will move left." );
			} else if( xmoved <= -50 ) {
				alert( "I was touched and will move right." );
			}
			// Reset
			xstart = 0;
			xmoved = 0;
		});

		$( "img", this ).bind( "touchcancel" , function() {
			// bei Abbruch zurücksetzen
			xstart = 0;
			xmoved = 0;
		});

	});
};

Wie gesagt, das ist kein Code für den Produktionseinsatz.

Und was stimmt jetzt nicht? Nun, im Moment setze ich die Fingerbewgung nur als Schalterersatz ein. D.h., die Reaktion ist dieselbe, als würde man auf den Links- oder Rechtsknopf drücken, die ehrlicherweise ja auch noch da sind. Da bleibt ja noch Raum für die Weiterentwicklung, denn so richtig responsiv ist das ja noch nicht.

Und am Schluss noch ein schöner Link dazu: bei Touching and Gesturing on the iPhone, gibt’s viele Grundlagen nachzulesen und das meiste gilt auch für’s iPad.

Javascript ist, angesichts seiner etwas holprigen Entstehungsgeschichte eine eigentlich recht elegante Scriptsprache. Es krankt jedoch daran, dass in Javascript im Grunde alles geht und alles gemacht wird und jedesmal anders. Will man mit Kollegen zusammen an einem Javascriptprojekt arbeiten, ist der eigene Dialekt ebenso hinderlich, wie mangelnde Sauberkeit beim Codeschreiben. Beachtet man aber neben einem guten Stil in Javascript einige elementare Regeln, kann man seine Scripte dadurch auch noch merklich schneller und kompakter machen.

Coding Guidelines

In Sachen Coding Guidelines gilt auf jeden Fall: jede Regel ist besser als keine Regel. In Javascript kann man viele böse Dinge schreiben, die kein Mensch versteht, die aber trotzdem hervorragend funktionieren. Die Sprache lässt einfach vieles zu, was trotzdem schlechter Stil ist. Vor kurzem haben sich die Entwickler von jQuery einen Styleguide verpasst, die JQuery Core Style Guidelines, das ist schon eine wunderbare Grundlage. Einfach copy & pasten.

Wichtig ist dabei auch, die Verwendung von JS Lint (JSLint will hurt your feelings.). Mit diesem Tool kann man die übelsten Stylefehler vermeiden und die Einhaltung des Styleguides automatisiert überprüfen. Die Einführung dazu ist mehr als lesenswert. Besonders praktisch für Nutzer von Textmate (Lieblingseditor) ist das JS Lint Bundle.

Codeverbesserung: erster Durchgang

Sich aufzuraffen, seinen Code zu überarbeiten, ist nicht leicht. Aber: der Wille zur Verbesserung und das Wissen, dass der erste Aufschlag meist nicht optimal ist, trennt den Programmieren vom Scriptingguy, oder so. Hier ein paar schnelle und einfache Schritte, die Javascript schon deutlich verbessern. Federice Galassi hat darüber eine wunderbare Präsentation gemacht. Die Maßnahmen führen aber nicht nur in Richtung unobtrusiveness, sondern sind auch geeignet, Javascript schneller und wartbarer zu machen. Kurz zusammengefasst:

1. Entferne alles Inline-Javascript aus dem HTML-Code.

   Also <script> Code…</script> raus aus den Seiten und in eigene Dateien (besser eine eintige) packen. Diese dann mit <script src="datei.js"></script> aufrufen. Und das am besten am Ende der Seite, direkt vor </body>.

2. Alle Inlineevents aus dem HTML entfernen

   Weg mit <a class="klick" href="#" onclick="foo();">Klicken Sie hier</a>. Das kann besser machen. Mit jQuery beispielsweise: $("a.klick" ).bind("click", function() { foo(); });, jedenfalls aber in der externen Javascriptdatei.

3. Javascript-Pseudolinks entfernen

   Mit Todesstrafe wird der uralte Javascript-Pseudolink bestraft! Sowas geht gar nicht: <a href="javascript:foo()">Klicken Sie hier</a>

4. CSS-Code aus dem Javascript entfernen.

   Innerhalb des Javascriptes sollte kein CSS verwendet werden (Trennung von Präsentation und Programmierlogik). D.h. sowohl Zuweisungen wie $("a" ).css("background","#ff0000" ); oder auch document.getElementById("id").style.color("#ff0000"); und ähnliches schreiben teilweise lange unüberschaubare style-Attribute in den HTML-Code und produzieren DOM-Zugriffe. Stattdessen schreibt man die CSS-Anweisungen in eine CSS-Datei

   // bspw. base.css
   a.rot {
   	background: #ff0000;
   }
   

   und nutzt im Javascript

   $("a").addClass("rot"); // Farbe an
   $("a").removeClass("rot"); // Farbe aus, oder gleich:
   $("a").toggleClass("rot"); // je nach dem
   

   CSS bewegt sich wesentlich schneller und gewandter durch das DOM als Javascript.

5. Businesslogik aus dem Javascript entfernen (Client-Server-Anwendungen).

   Bei Client-Server-Anwendungen kann es einen entscheidenen Geschwindigkeitsvorteil bedeuten, komplizierte Berechnungen nicht auf dem Client (also mit Javascript) sondern auf dem Server auszuführen. Wenn man sich also schon Daten vom Server holt, dann sollte man vermeiden mit diesen Daten Berechnungen auf dem Client auszuführen. Ein Beispiel:

   // Schlecht!
   $.get("action.php", function ( data ) {
       if ( data ) {
           if ( data.kontostand > data.dispokredit ) {
               alert("Konto überzogen" );
           }
       }
   });
   
   // Besser!
   $.get("action.php?dispoberechnung", {konto:"123456"}, function ( data ) {
       if ( data.dispo === false ) {
           alert("Konto überzogen" );
       }
   }
   

6. DOM-Operationen auf ein Minimum beschränken!

   Nicolas Zakas formuliert es in High Performance JavaScript (Build Faster Web Application Interfaces) so:

   An excellent analogy is to think of DOM as a piece of land and JavaScript (meaning ECMAScript) as another piece of land, both connected with a toll bridge (see John Hrvatin, Microsoft, MIX09, http://videos.visitmix.com/MIX09/T53F ). Every time your ECMAScript needs access to the DOM, you have to cross this bridge and pay the performance toll fee. The more you work with the DOM, the more you pay. So the general recommendation is to cross that bridge as few times as possible and strive to stay in ECMAScript land.

   Daraus ergibt sich eine klare Anweisung: greife sowenig wie es eben geht auf das DOM zu.

   Ein Domzugriff ist dann gegeben, wenn ein DOM-Element erschafft, ins DOM einhängt, ein Element im DOM verschiebt, Attribute hinzufügt und so weiter und so fort. Am allerschlimmsten sind die sogenannte HTML-Coolections und das iterieren hierauf.

   // ein ganz böses Beispiel!
   function innerHTMLLoop () {
       for ( var i = 0; i < 15000; i++ ) {
           document.getElementById("meinLink" ).innerHTML +="a";
       }
   }
   

   Hier erleben wir schlappen 15000 DOM-Aufrufe der übelsten Art. Stattdessen vermeidet man solange wie möglich den Zugriff aufs DOM:

   // dann besser so
   function innerHTMLLoop2 () {
       var content ="";
       for ( var i = 0; i < 15000; i++ ) {
           content +="a";
       }
       document.getElementById("meinLink" ).innerHTML += content;
   }
   

   Goldene Regel: pro Funktion sollte es nur einen Zugriff auf den DOM geben. So kann es beispielsweise Sinn machen, sehr lange auf Strings mit HTML zu arbeiten und erst am Ende alles zusammen per $( var ).appendTo( 'body' ); ins DOM zu hängen. Ausser in Chrome und Safari ist es sogar noch schneller innerHTML zu benutzen, in jQuery $("#meinKram" ).html( var );. Hier scheiden sich allerdings die Geister, weil innerHTML nicht standardkonform ist, wohl aber von jedem Browser unterstützt wird.

7. Große HTML-Chunks ggf. durch Templates ersetzen.

   Wegen der schon oft angesprochenen Trennung von Content und Präsentationslogik ist zu überlegen, ob man für große HTML-Stücke die man in den Code einspeisen muss, vielleicht besser HTML-Templates verwendet, den Code also in externe Dateien auslagert und nachlädt (auf welche Weise auch immer). Als Vorstufe dazu und Kompromiss kann man auch bis mittelgroße Codeschnipsel im verborgenen Teilen des HTML-Dokuments unterbringen und sich dann per .clone() oder wieder .html() einlesen und wiederverwenden.

   Die Verwendung eines Templatesystems setzt aber bspw. wieder ein eingenes Plugin voraus, Schnipsel im HTML verursachen beim Laden wieder DOM-Zugriffe. Hier muss man genau abwiegen, was der Performance hier zuträglich ist, sicherlich auch in Abhängigkeit vom der Größe des HTML-Codes der benötigt wird.

8. Keine/wenig globalen Variablen nutzen!

   Variablen die ausserhalb von Funktionen definiert werden, sind, auch wenn sie mit var geschrieben werden, globale Variablen, die im window-Namensraum gespeichert werden. Es besteht die Gefahr, dass diese an anderer Stelle ungewollt überschrieben werden, außerdem ist der Zugriff auf window langsam. Stattdessen speichert man Variablen aus dem Window-Namensraum in lokalen Variablen zwischen, auf die der Zugriff wesentlich schneller erfolgt.

Fortsetzung folgt

Dieser 8-Punkte-Plan ist aber nur ein Einstieg. Wenn man ein Programm so optimiert hat, kann man praktisch direkt wieder von vorne anfangen und weitere Verbesserungen einbringen. Das wird dann das Thema eines weiteren Artikels hier.

If you find yourself with a lengthy condition to get a Boolean, or your true/false Boolean is showing up again and again, you might be on target to create a custom expression for your selector. And making them could hardly be easier…

Screenshot ZEIT ONLINE, Wissen Centerpage, iPad Version, Design: Information Architects

Liest man die gängigen Webdesign-Sites findet man eine Fülle von Tipps, wie man seine Website anpassen kann, damit sie auch auf dem iPad funktioniert. Der Tenor: mit css media queries ein paar zusätzliche Stylesheets für das iPad liefern, im Scriptteil ein wenig die Touch- und Gestureevents einsetzen, Flashvideos raus, Buttons größer: fertig! Das war nicht ganz das, was uns vorschwebte…

Das mit den media queries ist so eine Sache

Kurz gesagt: CSS media queries sind im Moment eine schicke und elegante Lösung, wenn man seine bestehende Website mit ein paar Handgriffen an die Gegebenheiten verschiedener, zumeist kleinerer, Displays anpassen will. Ebenso taugen sie sicherlich dazu, eine Web-App zu bauen, die nur auf Tablets funktioniert und im Desktopbrowser leer oder ungestyled bleibt (aber wer will das schon?). Für eine große Contentwebsite, die zweigleisig unter der gleichen Adresse unterschiedliche Styles an Desktopbrowser und Tablets ausliefert, sind sie jedoch (zumindest im Moment) nicht zu gebrauchen.

Das liegt zunächst einmal daran, dass mit Mediaqueries eingeschränkte Stylesheets zunächst mal allesamt heruntergeladen werden und dann entschieden wird, was angezeigt wird. Für den mobilen Einsatz und auch für den Tableteinsatz kommen sie damit kaum in Frage. Beim ersteren schon allein wegen der Downloadmengen, beim letzteren kommen wie die Erfahrung zeigt noch weitere Datenmengen an Javascript und z.B. größeren Bildern hinzu. Ein Fass ohne Boden.

Die von mir zunächst favorisierte Lösung führte aber dazu, dass nicht nur IEs kleiner Version 9 via conditional comments eigene Stylesheets zugeteilt bekommen mussten, auch Firefox 3.0 und kleiner können mit den mediumabhängigen Styles so gar nichts anfangen.

Ohne Javascript geht’s (derzeit) nicht

Und auf tut sich die böse Tür des user agent switching. Zwar gibt es eine Javascript-Lib, die css media queries gewissermassen emuliert, das ist aber ein weiterer gut 20kB großer Download ist, ein Monster mithin, das zudem nur mit Queries innerhalb von CSS-Dateien, aber nicht innerhalb von <link /> zulässt.

Stehen zusätzlich Anforderungen im Raum, dass auch ein Schalter zur Rückkehr zur klassischen Website eingebaut werden soll, oder wenn man feststellt, dass eben Tablet nicht geleich Tablet ist, man also für verschiedene Tablets noch kleinere Anpassungen vornehmen muss, dann ist man schnell dabei auf den user agent zu schauen. <interlude>Das vereinfacht übrigens auch gewaltig die Entwicklung der Seite, da man sie während des Bauens parallel zum iPad/iPad-Simulator auch im Firefox previewen kann. Das geht natürlich nur mit User Agent Switcher. Dann aber kann man den geliebten Firebug nutzen um wenigestens die Elemente auf der Seite und ihre Styles zu indentifizieren und auch das Scriptdebugging ein wenig zu unterstützen. Dinge die es auf dem iPad nicht oder nur sehr rudimentär gibt.</interlude>

Diese Lösung ist allerdings noch nicht das Endstadium, allein weil wir nach und nach die Site für weitere Tablets fit machen wollen. Im Laufe dieser Zeit werden wir auch das UA-switching wieder entfernen und durch bessere Methoden ersetzen.

Screenshot ZEIT ONLINE, Navigation, iPad Version, Design: Information Architects

Der Spass an der Entwicklung

Eins muss man gleich sagen: Entwicklung für Tablet (speziell das iPad) macht einen Heidenspaß. Zum einen ist die Touchbedienung faszinierend. Ich bin so einer, der ein mouse-over-Menü entwickelt und sich dann stundenlang daran erfreuen kann, wie beim Hovern über den Menüpunkt das Menü animiert ausfährt. Auf dem Tablet kann man solche Lösung praktisch zum Anfassen programmieren (natürlich ohne :hover). Ich habe das Menü bestimmt mehrere tausend Mal ausprobiert. Oder die Bildergalerien (obwohl ich da noch nicht zufrieden bin). Die Möglichkeiten des Webkit sind wirklich hervorragend und das geniesst man natürlich. Obwohl es auch ein wenig zu verführerisch ist, wenn man in die Hölle der Desktopbrowser zurückkehrt und feststellt, dass es da draussen immer noch Internet Explorer gibt… ;)

Kleinere Schlaglöcher

Ein paar Dinge waren allerdings echte Kopfnüsse. Da ist zum Beispiel der Viewport-Tag. Schon bei diesem Blog hier habe ich Probleme damit gehabt. über diesen einen Tag den Viewport und vor allem die Vergrößerung so zu setzen, dass es für iPad und iPhone gleichermaßen funktioniert. Das Design der iPad-Seite erforderte ganz klar ein:

<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">

Das passt allerdings nicht zu unserer Art, das iPhone zu bedienen. iPhone-Nutzer werden beim Besuch gefragt, ob sie die mobile Website besuchen möchten, oder die klassische Seite. Mit dem obigen Meta-Tag kann man diese dann aber auf dem iPhone nicht mehr skalieren. Für das iPhone empfiehlt sich eher:

<meta name="viewport" content="width=device-width">

Will man allerdings (für das iPad) zwei Ansichten für Portrait- und Landscapemodus präsentieren (vs. vergrößerte Portraitansicht im Landscapemodus), dann ist man auf das minimum-scale=1.0, maximum-scale=1.0 festgelegt.

Überraschenderweise kann man aber auch diesen Metatag per Javascript setzen! Es hat allerdings ein wenig gedauert, bis ich das einfach mal ausprobiert habe (hüstel). Außerdem musste dafür ganz schön an unserer Seitenstruktur geschraubt werden.

Wie geht’s weiter?

Zunächst mal kommen jetzt schnell weitere Tablets dazu, mit denen man die Seite betrachten kann. Es war leider schnell klar, dass man mit einem Schlag nicht alle Tablets bedienen kann. Mindestens an den Einstellungen des Viewports müssen Anpassungen gemacht werden, wahrscheinlich auch etwas CSS und Script. Wobei, wir wollen jetzt auch nicht jedes Tablet das neu auf den Markt kommt kaufen (der Gadgetjäger in mir fragt natürlich: »warum eigentlich nicht«). Man wird sehen, was sich am Tabletmarkt noch tut und was sich durchsetzt. Wir räumen zunächst mal dem Galaxy Tab von Samsung gute Chancen ein, und wenn RIM mit einem Tablet kommt, wird’s ja vielleicht auch nochmal interessant.

Abschließend sei gesagt, dass die Sache natürlich ein gutes Stück weit vom Design der Information Architects lebt, Oliver Reichenstein hat dazu einen schönen Artikel geschrieben, der auch die – ich nenne es mal so – medienpolitischen Hintergründe gut erfasst und viel von dem Geist beschreibt, der hinter dieser Webapp steckt.

Noch ein paar Artikel und Stimmen zum Thema: iPadMag, Editors Weblog, iPad Planet NL…

Über die berühmten CSS Media Queries haben wir ja schon viel gehört und gelesen. Mitunter werden sie unnütz für das mobile Web angesehen und ohne eine nennenswerte Zusammenarbeit mit Javascript wird man wohl auch nicht auskommen. Damit wissen wir ja schon einiges. Hier im Blog sind sie seit den letzten kosmetischen Korrekturen im Einsatz (einfach mal die Fenstergröße anpassen oder Codecandies auf dem Kindle 3 aufrufen), sehr schön kann man das auch bei den iAs anschauen.

Was Jason Grigsby vor allem kritisiert ist, dass man um eine Anpassung bspw. für mobile Clients zu erreichen, mehr anstatt weniger Code hinzufügt:

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

www.cloudfour.com

Das wäre natürlich kontraproduktiv und ist für große Websites, die sowieso schon immer mit ihrem Gewicht zu kämpfen haben auch tatsächlich keine Alternative. Zudem hat man ja auch keine Unterscheidung für die ausgelieferten Medien, bspw. Bilder. Große hochaufgelöste Bilder braucht man bspw. für das iPad, aber nicht für das kleine Display eines Mobiltelefons. Smartphones wie das iPhone4 fallen aus dieser Kritik aber eher heraus, lechzt es doch nach noch höher aufgelösten Bildern als der Desktopwebbrowser. Hier müsste dann je nach Nutzungssituation unterschieden werden.

Allen Lösungen gemein ist im Moment, dass die mit media queries spezialisierten Seiten, nur wenige kleine Effekte anbieten, bspw. schmalere Spalten, verkleinerte Bilder etc. Was aber, wenn die Seiten für das iPad und später auch das iPhone wirklich komplett anders aussehen sollen? Versucht man sämtlichen CSS-Code zu überschreiben, landet man schnell in der Codinghölle und das Gewicht der Seite explodiert. Ich habe mich nun gefragt, mal in Bezug auf das iPad (und andere Tablets) gesehen, deren Nutzung ich weniger als mobile Nutzung betrachte, wie man mit den media queries nun zwar genug, aber eben möglichst wenig CSS-Daten an die Browser schicken kann. Mein derzeitiger Lösungsansatz sieht so aus siehe Update am Ende des Artikels:

<!--[if IE]>
	<link rel="stylesheet" href="css/base.css" type="text/css" />
<![endif]-->
<link media="only screen and (min-device-width: 769px)" rel="stylesheet" href="css/base.css" type="text/css" />
<link rel="stylesheet" media="only screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="css/ipad.css" type="text/css" />

Zur Erklärung: Zunächst mal werden die IEs bedient, die derzeitig nicht in der Lage sind media queries auszuwerten. Der bekommt ganz normal sein CSS geliefert. Die restlichen Stylesheets ignoriert ein IE dann geflissentlich. Alle anderen Browser widerum ignorieren die conditional comments und falls sie eine min-device-width größer 769px haben, laden und zeigen sie das normale base.css. Hernach folgt dann das CSS für das iPad, mit einem Query auf seine Werte abgestimmt.

Soweit zur Theorie. In der Praxis scheint das so zu funktionieren. Lädt man viele verschiedene CSSse, kann das allerdings schnell unübersichtlich werden, da alle nichtmobilen CSSse doppelt aufgeführt werden müssen.

Anregungen und andere Ideen sind mehr als willkommen.

Artikelbild: Some rights reserved by anarchosyn.

Update: Zwei Tatsachen haben inzwischen dazu geführt, dass ich selbst nicht mehr so überzeugt von dieser Lösung bin: 1. werden ob mit media queries oder ohne immer alle Dateien vom Browser gezogen. Man spart aber ggf. durch weniger CSS-Überschreiben, je nach Art und Größe der Styles; 2. wichtige Info: schon Firefox 3.0 kann keine CSS media queries.

Obwohl ich hier Internet habe, lasse ich lieber Drachen steigen. Habe schon ein Buch durchgelesen. Bin entspannt.

Nach über einem Jahr mein Zimmer endlich fertig eingerichtet.

Soeben habe ich Kathrin Passig bei Buzz entfollowed, wegen zwei fürchterlichen Tiraden über das Sharen und Resharen in Google Reader und Buzz (Teil 1, Teil 2), auf die ich durch diesen Artikel aufmerksam geworden bin. Frau Patzig ereifert sich darüber, dass ihre bei Google Reader geshareten Items oft ohne Quellenangabe weitergeshared werden, somit also ihr, die sie die entsprechenen Quellen ausgegraben hat kein Tribut gezollt wird. Sie bezeichnet zudem diesen völlig normalen Vorgang als Schwarzfahren in der Aufmerksamkeitsökonomie, was mich wirklich ein wenig ärgert. Hört sich für mich eher an, wie Auffallen um jeden Preis.

Was Leute wie Frau Passig einfach nicht geregelt kriegen ist, dass es eine Abstufung im Wirtschaftsmodell der Webaufmerksamkeit gibt. Natürlich glauben diverse Menschen, dass sie auch noch an einem ihrer Darmwinde ein @xyz dranpappen können, der allgemeinen Schaffenshöhe wegen, begreifen aber nicht, dass man genau umgekehrt eben nicht überall den Stempel: »ich hab’s gefunden« drankleben muss, ums mit den Schweizern zu sagen. Ich sehe im sharen eines Blogartikels in Google Reader, mglw. auch noch ohne weiteren Kommentar, selbst einfach nur durch das Anklicken eines Icons, keinerlei Schaffenshöhe. Punktum. Deswegen mag auch jeder von Euch Artikel, die ich im Google Reader resp. Buzz share, unter seinem Namen weitersharen soviel er oder sie mag. Das schert mich wenig und ficht mich auch nicht an. Ich habe dazu nämlich weiter nichts getan, als den Artikel selber gelesen und für gut befunden, nicht aber gut genug, ihn in meinem Blog zu featuren. Dort sammle ich nämlich die wirklich wichtigen Links.

Wenn die Autorin oder der Autor aber selbst etwas dazugetan hat, bspw. in seinem eigenen Blog die Originalquelle in Beziehung zu anderen Quellen gesetzt hat, oder den eigenen Senf dazu getan hat, dann bin ich sofort bereit und willens eine Quelle anzugeben. Lustigerweise gibt es sie dann nämlich auch, die Quelle, mit Link und allem. In Zeiten der weiterverlinkten Links, die verlinkt werden, ist es IMHO müßig, wenn da eine Art Urverlinkungsrecht eingefordert wird. Nervt mich sogar geradezu, wenn beispielsweise auf Twitter hundertfach geretweetet wird. Es ist so langweilig, wenn jemand auf Twitter nichts weiter tut, als auf “Retweet” zu klicken. Nicht dass ich das nicht in Ausnahmefällen auch schon gemacht hätte, aber ich halte Twitter eher für eine Plattform der selbstgetätigten Äußerung, als der Weitergabe von Links. Dafür nutze ich Google Reader. Damit verbinde ich—und jetzt beginne ich mich zu wiederholen—aber noch keine besondere Schaffenshöhe, jedenfalls nicht, wenn ich Links weitershare oder Links von mir weitergeshared werden. Wenn ich jedoch einen Link aus Google Reader in meinem Blog verarbeite, also zu Schaffung eigenen Contents nutze, dann verschweige ich die Zwischenquelle auf keinen Fall. Ist das zu kompliziert? Oder unlogisch?

Leute die das anders sehen, soll es geben, ich muss ihnen aber ja nicht followen. Plonk!

P.S. Nachdem Herr Lobo noch vor kurzem Fileshare als Diebe bezeichnete und nun Frau Passig Linksharer sozusagen der Beförderungserschleichung bezichtigt, würde ich am liebsten aus Sicherheitsgründen alles was ich in deren gemeinsamen Buch »Dinge geregelt kriegen – etc. etc.« gelesen habe, wieder vergessen, es sozusagen entlesen, aber das funktioniert mit diesem altmodischen Kram natürlich wieder nicht…

»This is how I choose to work these days…«

Eine prima Idee, ich sag’s ja, verschlichter Dich…, beinahe wie mein Schreibtisch (Danke an Marc für den Link).