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