From: Boris Kraut Date: Wed, 21 Oct 2015 22:26:10 +0000 (+0200) Subject: Designed for Internet Explorer X-Git-Url: http://git.marmaro.de/?p=krt-msg;a=commitdiff_plain;h=e8bc958654f2ffa7be241e04d46de9819a800f42 Designed for Internet Explorer --- diff --git a/2015-10-21T22:26:09Z.msg b/2015-10-21T22:26:09Z.msg new file mode 100644 index 0000000..06d320e --- /dev/null +++ b/2015-10-21T22:26:09Z.msg @@ -0,0 +1,81 @@ +From: Boris Kraut +To: undisclosed-recipients: ; +Date: Thu, 22 Oct 2015 00:26:09 +0200 +Message-ID: <20151022002609.KbePcg@android-1246794.local> +Reply-To: Boris Kraut +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.