+From: Boris Kraut <krt@nurfuerspam.de>
+To: undisclosed-recipients: ;
+Date: Thu, 22 Oct 2015 00:26:09 +0200
+Message-ID: <20151022002609.KbePcg@android-1246794.local>
+Reply-To: Boris Kraut <krt@nurfuerspam.de>
+Subject: [.plan] Designed for Internet Explorer
+
+Nein, das hier wird kein Aufreger ueber obsolete Software oder irgendwelche
+Legacy-Webanwendungen, die doch noch auf einen IE -- und dazu noch in einer
+uralten Version -- beharren. Es geht eher darum, dass wir daraus nichts ge-
+lernt haben. Das Grundproblem ist doch, dass wir (in diesem Falle) Software
+so "designen", als ob wir schon ganz genau wuessten, wie die Umstaende und
+Bedingungen sind, in/unter der diese Software eingesetzt wird. Klar, man hat
+natuerlich immer ein gewisses Ziel, evtl. sogar eine Zielgruppe, aber immer
+mehr wird sich auf solche Vorgaben verlassen. Ich weiss nicht, evtl. ist es
+nicht mehr Ziel, eine moeglichst breite Nutzung auch ausserhalb des vorher-
+gesagten, angedachten Rahmens zuzulassen, oder man vertraut zu sehr den Um-
+fragen oder Meinungen von "Profis". Vielleicht ist es auch eine falsche
+Arbeitsumgebung: Wer als Entwickler nur die "idealen" Gegebenheiten um sich
+herum findet, der koennte schnell verleitet werden, dies als normal anzusehen.
+Ich weiss es nicht.
+
+Anstatt fuer den IE werden heute Programme fuer eine staendige, stabile und
+schnelle Internetverbindung designed -- und das obwohl es (in DE) immer noch
+weite Gebiete gibt, die nicht ueber nennenswerten Breitbandzugang verfuegen,
+obwohl die gaengigsten Zugangstechniken inzwischen alle drahtlos arbeiten und
+daher inherent unstetig sind. Die Konsequenz muesste doch ganz logischerweise
+sein, dass man darauf achtet, dass die Basisfunktionalitaet auch offline
+funktioniert und diese generell im Programm bzw. in der ersten Programmversion
+vorhanden ist. Aber das Gegenteil ist der Fall: Day-One-Patches sind keine
+Seltenheit, genau wie das Nachladen oder Streamen von essentiellen Funktionen.
+Fuer den Anfang wuerde ich mich auch mit sehr simplen Verbesserungen zufrieden
+geben:
+
+Wenn eure Software nur mit einem Betreiber-Account funktioniert, dann stellt
+sicher, dass ihr eine Option anbietet, den Benutzername und das Passwort fuer
+die Dauer einer Session zu speichern! Rechnet damit, dass der Benutzer die
+Verbindung verliert, ggf. auch ungemerkt, d.h. eure Software muss in der Lage
+sein Verbindungen samt Anmeldevorgang neuaufzubauen. Haeufig ist das ja schon
+so, nur die wenigsten Entwickler scheinen damit zu rechnen, dass diese Probleme
+auch beim ersten Anmelden passieren koennen. Ich durfte heute fast 10 mal ein
+Passwort an einem mobilen Geraet eingeben, weil die Formulardaten immer wieder
+zurueckgesetzt wurden. Ohne Moeglichkeit diese zu speichern oder sie in die
+Ablage zu kopieren. Wer schonmal laengere Passphrasen auf Touchgeraeten ein-
+gegeben hat, wird meinen Frust verstehen... oder soll mich das dazu verleiten
+einfachere Passwoerter zu nutzen? Oder einen Single-Sign-On-Anbieter a la
+Google, Facebook und Co.?
+
+Auch Downloads sind eigentlich ein Problem, das ich als geloest abgetan habe.
+Selbst unter Windows zu 56k-Zeiten gab es Downloadmanager, die Resuming unter-
+stuetzten. Dieses Feature scheint bei so einigen mobilen Anwendungen noch nicht
+angekommen zu sein. Aber auch auf Stationären PCs, NAS, Konsolen usw. gibt es
+zwar meist die Moeglichkeit, aber einen Download automatisch nach einiger Zeit
+wiederaufzunehmen, das scheint vielen ein ganz unnatuerlicher Wunsch zu sein:
+Liebe Entwickler, wenn ich eurem Geraet schon erlaube, dass es im Hintergrund
+Downloads ausfuehren darf, dann macht das auch. Ich moechte nicht noch einmal
+-- gerade bei einer langsamen Internetverbindung -- einen grossen Download an-
+stossen und nach einigen Stunden zurueckkommen, nur um feststellen zu muessen,
+dass er nach 20 Minuten Laufzeit pausiert wurde weil zeitweise das Internet
+lahmte oder der Remoteserver nicht erreichbar war.
+
+Das waren jetzt nur zwei Beispiele, weitere hatte ich zu anderer Zeit hier
+schonmal genannt. Leider muss man davon ausgehen, dass die Zugangsqualitaet
+eher abnehmen als steigen wird: Evtl. bekommen wir ein schnellereres Netz,
+aber dafuer werden die Ausfallhaeufigkeiten steigen -- mehr Nutzer, ein
+gefiltertes oder zensiertes Netz, marode Infrastruktur usw. werden ihre
+Auswirkungen spuerbar sichtbar machen. Es ist klar, dass die meiste moderne
+Software nicht fuer diese Zukunft taugt... und daran duerfte sich auch nichts
+aendern, denn die meisten Unternehmen sind ja bestrebt den Nutzer moeglichst
+abhaengig zu machen -- Funktinalitaet und Daten in die Cloud, der Nutzer
+staendig online und damit ueberwachbar. Das perfide daran ist, dass "alles in
+die Cloud" das Problem ist, von den Unternehmen aber als die "Loesung" an-
+gepriesen wird: Speichert alles online, dann koennt ihr jederzeit daruf zu-
+greifen. Hier wird so getan, als ob der Geraetewechsel oder -ausfall das
+Problem sei, nicht die Konnektivitaet. Zum Glueck gibt es auch einige neue
+Bestrebungen, die dem Trend entgegenstehen, z.B. das vermehrte Setzen auf
+lokale, direkte Kommunikation zwischen Geraeten und Nutzern, oder das "robust"
+machen von XMPP, IRC und anderen Alt-Technologien. Dennoch werde ich das
+Gefuehl nicht los, dass wir vor einer ganzen Weile, als Internet wirklich
+noch anfaellig und RocketScience war, die bessere Software fuer die Probleme
+der Zukunft hatten.
projects / krt-msg / commitdiff