nicht angemeldet
Der Martin
dedlfix
Der Martin
Gunnar Bittersmann
Gunnar Bittersmann
Der Martin
Der Martin
Gunnar Bittersmann
Hi, über die Sinnhaftigkeit von Progress Loading Lines kann man sicher geteilter Meinung sein. Gehen wir deshalb mal davon aus, dass der User weniger genervt davon ist, wenn er das Ende einer Wartezeit glaubt, vorhersehen zu können. meine Frage zielt aber auf etwas anderes: Kan man im Bereich einer Webseite überhaupt sinnige Progress Loading Lines einsetzen? Mir fällt hier derzeit nur ein, eine Webseite vorzuschalten, die eine wie immer geartete Progress Loading Line anzeigt und den Rest währenddes per Ajax nachzuladen. Natürlich hat dann der Balken nichts mit der wirklichen Ladezeit zu tun, aber der User sieht eben in der ladezeit irgendwas.
Was ich aber richtig klasse fände, wäre, wenn es eine Technik gäbe (oder man diese imitieren könnte), die erkennt, dass eine Webseite länger benötigt und dann (also bedarfsgerecht) eine "Wartegrafik" einblendet. Nur, wie soll das gehen?
Also nicht zu realisieren, oder gibt es da doch ansatzweise Lösungen?
Jochen
Hallo,
über die Sinnhaftigkeit von Progress Loading Lines kann man sicher geteilter Meinung sein.
ja, über die Bezeichnung auch. Ich kannte bisher Progress Bar oder Fortschrittsbalken; Progress Loading Line ist mir aber noch nicht begegnet. Sei's drum.
Gehen wir deshalb mal davon aus, dass der User weniger genervt davon ist, wenn er das Ende einer Wartezeit glaubt, vorhersehen zu können.
Ja, reine Psychologie. Wir sind generell unruhiger, wenn wir den zeitlichen Verlauf oder das Ende eines Vorgangs nicht abschätzen können. Auch im wirklichen Leben.
Kan man im Bereich einer Webseite überhaupt sinnige Progress Loading Lines einsetzen? Mir fällt hier derzeit nur ein, eine Webseite vorzuschalten, die eine wie immer geartete Progress Loading Line anzeigt und den Rest währenddes per Ajax nachzuladen. Natürlich hat dann der Balken nichts mit der wirklichen Ladezeit zu tun, aber der User sieht eben in der ladezeit irgendwas.
Das Ding muss ja auch nicht unbedingt die Zeit abbilden, es könnte ebenso die Anzahl der zu ladenden Objekte sein oder die Datenmenge (die normalerweise in etwa mit der Zeit korreliert).
Was ich aber richtig klasse fände, wäre, wenn es eine Technik gäbe (oder man diese imitieren könnte), die erkennt, dass eine Webseite länger benötigt und dann (also bedarfsgerecht) eine "Wartegrafik" einblendet.
Gibt es schon. Hat praktisch jeder Browser integriert: Die Eieruhr oder was immer das jeweilige GUI sonst verwendet, um dem Nutzer zu signalisieren: Wart mal bitte.
Ciao,
Martin
Hi,
Gibt es schon. Hat praktisch jeder Browser integriert: Die Eieruhr oder was immer das jeweilige GUI sonst verwendet, um dem Nutzer zu signalisieren: Wart mal bitte.
Problematisch. Denn alles, was nicht vom Server kommt, ist fast genauso schlecht, als wenn gar nichts kommt. Es solte also wirklich etwas sein, was der User als "Serverarbeit", noch besser als "fortschreitende" Serverarbeit erkennen kann. btw: Den Begriff habe ich selber auf einer Webseite abgekupfert. Mir gefallen alle von Dir genannten Begriffe (je deutscher, je besser gefällt er mir) auch besser. Einigen wir uns also gerne ab hier auf einen "Fortschrittsbalken".
Jochen
Tach!
über die Sinnhaftigkeit von Progress Loading Lines kann man sicher geteilter Meinung sein. Gehen wir deshalb mal davon aus, dass der User weniger genervt davon ist, wenn er das Ende einer Wartezeit glaubt, vorhersehen zu können.
Oder dass er überhaupt eine Raktion auf den Klick sieht. Das kann auch eine Sanduhr oder ein moderner Ersatz sein.
meine Frage zielt aber auf etwas anderes: Kan man im Bereich einer Webseite überhaupt sinnige Progress Loading Lines einsetzen? Mir fällt hier derzeit nur ein, eine Webseite vorzuschalten, die eine wie immer geartete Progress Loading Line anzeigt und den Rest währenddes per Ajax nachzuladen. Natürlich hat dann der Balken nichts mit der wirklichen Ladezeit zu tun, aber der User sieht eben in der ladezeit irgendwas.
Wenn man keine Zeit hat oder berechnen kann, und auch nicht anhand abgearbeiteter Menge eine Fortschritt beziffern kann, sollte man keinen sich füllenden Fortschrittsbalken darstellen. Ein schlechtes Beispiel dafür sieht man beim Service stoppen und starten unter Windows. Der Balken geht gleichmäßig bis 50%, dann verlangsamt er sich bis 75% und wird diesem Prinzip folgend immmer langsamer. Windows kann nur hoffen, dass der Service sich irgendwann ausgekäst hat. Ich vermute, dass es keine Möglichkeit gibt, dass ein Dienst Fortschrittsmeldungen an die Service-Systemsteuerung geben kann.
Was ich aber richtig klasse fände, wäre, wenn es eine Technik gäbe (oder man diese imitieren könnte), die erkennt, dass eine Webseite länger benötigt und dann (also bedarfsgerecht) eine "Wartegrafik" einblendet. Nur, wie soll das gehen?
Das ist die Frage. Kannst du Daten auftreiben, anhand derer sich ein Fortschritt berechnen lässt. Das wäre die wichtigste Frage an der ganzen Geschichte. Die zweite wäre, wie man diese Information während des Warteprozesses nebenher vom Server zum Client bekommt.
- Wie sol eine erkennung funktionieren?
Diese Frage kannst nur du selbst anhand deines Szenarios beantworten. Bei der Frage nach der Übertragung ist auch Ajax nicht unbedingt die beste Technik, weil auch damit kein häppchenweises Übertragen von Information garantiert möglich ist.
- Wer soll die Grafik ausliefern? Entweder liefert der Server die Daten (dann brauchts keine Grafik mehr) oder er liefert nichts (also auch keine Grafik)
Server liefern nicht, die Clients stellen Requests. Üblicherweise. Mit Websockets kann man allerdings einen Kommunikationskanal betreiben, durch den auch der Server unaufgefordert zum Client etwas senden kann. Das braucht aber etwas mehr Konfiguration auf der Serverseite als nur ein PHP-Script hinzukopieren.
dedlfix.
Hi,
Oder dass er überhaupt eine Raktion auf den Klick sieht. Das kann auch eine Sanduhr oder ein moderner Ersatz sein.
Die (Klickreaktion) kannst Du ja bereits im Skript unterbringen, das den Request absendet. Das meine ich aber nicht.
Wenn man keine Zeit hat oder berechnen kann, und auch nicht anhand abgearbeiteter Menge eine Fortschritt beziffern kann, sollte man keinen sich füllenden Fortschrittsbalken darstellen.
Meine ich auch. Aber eine Rückmeldung des Servers, dass er arbeitet (selbst wenn auch der unbedarfteste user inzwichen weiß, dass meist animierte GIFs zugrunde liegen), wäre dem User sicher an genehmer als eine weiße Seite (besonders, wenn die nicht immer auftaucht, sondern bei Seiten, die wirklich etwas mehr Ladezeit beanspruchen).
Das ist die Frage. Kannst du Daten auftreiben, anhand derer sich ein Fortschritt berechnen lässt. Das wäre die wichtigste Frage an der ganzen Geschichte. Die zweite wäre, wie man diese Information während des Warteprozesses nebenher vom Server zum Client bekommt.
Jein. Bei einer Suchfunktion könnte ich bspw. sehr gut in Datenpakete unterteilen, die bereits durchsucht wurden und andere, die noch hzu durchsuchen sind. Bei anderen Funktionen kann ich das schwieriger. Mir gehts aber gar nicht um den wirklichen Fortschritt. Im ersten Schritt würde mir die zweitwichtigste Frage viel wichtiger sein. Wie bekomme ich die Daten zum Client?
Bei der Frage nach der Übertragung ist auch Ajax nicht unbedingt die beste Technik, weil auch damit kein häppchenweises Übertragen von Information garantiert möglich ist. Mit Websockets kann man allerdings einen Kommunikationskanal betreiben, durch den auch der Server unaufgefordert zum Client etwas senden kann. Das braucht aber etwas mehr Konfiguration auf der Serverseite als nur ein PHP-Script hinzukopieren.
Die möglichkeit werde ich bei meinem leider nciht haben.
Gibts trotzdem einen Weg?
Jo
- Wie sol eine erkennung funktionieren?
- Wer soll die Grafik ausliefern? Entweder liefert der Server die Daten (dann brauchts keine Grafik mehr) oder er liefert nichts (also auch keine Grafik)
Also nicht zu realisieren, oder gibt es da doch ansatzweise Lösungen?
Mit Ajax/XHR-Objekt kannst Du sowohl upload als auch download Prozesse monitoren über das <progress>-Element.
Matthias Apsel
Auge/* UPload */
xhr.upload.onprogress = function(e) {
if (e.lengthComputable) {
document.getElementById('progress').value = (e.loaded / e.total) * 100;
}
}
/* Download */
xhr.onprogress = function(e) {}
Ansonsten einfach eine Throbber-Grafik laden (wenns unbedingt sein muss).
MfG
meine Frage zielt aber auf etwas anderes: Kan man im Bereich einer Webseite überhaupt sinnige Progress Loading Lines einsetzen? Mir fällt hier derzeit nur ein, eine Webseite vorzuschalten, die eine wie immer geartete Progress Loading Line anzeigt und den Rest währenddes per Ajax nachzuladen.
Ich denke da musst du konkreter werden. Wovon willst du den Ladefortschritt anzeigen? Für eine einzelne Ressourcen deren Größe bekannt ist, ist das einfach. Für viele Ressourcen unbekannter Anzahl, unbekannter Größe -- oder gar eine ganze Website -- lässt sich kein genauer Fortschritt berechnen. Da bleibt nur eine gleichbleibende Anzeige "wird geladen" als Text, Bild, Animation, ohne Prozentangabe oder Zeitangabe.
Was ich aber richtig klasse fände, wäre, wenn es eine Technik gäbe (oder man diese imitieren könnte), die erkennt, dass eine Webseite länger benötigt und dann (also bedarfsgerecht) eine "Wartegrafik" einblendet. Nur, wie soll das gehen?
Meiner Meinung nach ist das nicht nötig. Webseiten können so aufgebaut werden dass der Ladefortschritt für den Benutzer ersichtlich ist. HTML und Co. sind darauf ausgelegt:
- Wie sol eine erkennung funktionieren?
Dazu müsste man erst einmal den Zeitpunkt "die Seite ist geladen" feststellen können. Da gibt es das gute alte window.onload aber noch vieles mehr:
https://developer.mozilla.org/en/docs/Web/API/Navigation_timing_API
- Wer soll die Grafik ausliefern? Entweder liefert der Server die Daten (dann brauchts keine Grafik mehr) oder er liefert nichts (also auch keine Grafik)
Erkläre einmal bitte welche Fehlerfälle du behandeln willst. Wenn der Server mitten im Laden plötzlich abschmiert (selten) oder die Internetverbindung weg bricht (häufig), so kann das eine Webseite nur schwer erkennen.
Bei XMLHttpRequest bekommst du in der Tat die genauesten Fehlermeldungen: Serverfehler, Timeout, Internet weg usw. Nur ist es nicht praktikabel alle Ressourcen einer Seite einzeln mit XMLHttpRequest zu laden. ;-)
Richard
Hallo,
Ich denke da musst du konkreter werden. Wovon willst du den Ladefortschritt anzeigen?
das ist allerdings eine gute Frage.
Für eine einzelne Ressourcen deren Größe bekannt ist, ist das einfach.
Ist es das wirklich?
Für viele Ressourcen unbekannter Anzahl, unbekannter Größe -- oder gar eine ganze Website -- lässt sich kein genauer Fortschritt berechnen.
Doch, und ich finde, gerade dann wird es sinnvoll. Man kann den Fortschritt, wie ich schon ausgeführt habe, auf die Zahl der Objekte oder auf deren Gesamt-Datenvolumen beziehen. Das sind Werte, die bekannt sind.
Da bleibt nur eine gleichbleibende Anzeige "wird geladen" als Text, Bild, Animation, ohne Prozentangabe oder Zeitangabe.
Die ist aber nicht mehr wert als die berüchtigte Eieruhr.
Aber das Problem liegt ganz woanders: Internet-Nutzer sind ungeduldig. Wenn eine Webseite zum Laden deutlich Zeit braucht, also so viel Zeit, dass eine Fortschrittsanzeige schon in Frage kommt, dann hat man die meisten Besucher schon verloren, während die Fortschrittsanzeige noch signalisiert, es dauert nur noch einen kleinen Moment.
Das Ziel muss also sein, die gefühlte Ladezeit zu verringern. Das heißt, das Dokument an sich sollte möglichst kompakt und schlank sein; Bildressourcen (meist JPEG) sollten so stark komprimiert sein, wie es der Qualitätsanspruch gerade noch zulässt. Es ist nicht schlimm, wenn ein paar wenige Bilder erst mit ein paar Sekunden Verzögerung nachgekleckert kommen, solange die Webseite als solche einigermaßen zügig erkennbar und lesbar ist.
- Das Laden von CSS "blockt" meist die Darstellung. Zumindest für eine bestimmte Zeit.
Je nach Browser. Braucht eine externe CSS-Ressource einen Moment länger, zeigen manche Browser den Inhalt schon mal für einen Moment ungestylt an. Das erlebe ich mit Opera öfters. Das ist vielleicht gewöhnungsbedürftig, aber eigentlich eine gute Sache.
So long,
Martin
@@Der Martin
Da bleibt nur eine gleichbleibende Anzeige "wird geladen" als Text, Bild, Animation, ohne Prozentangabe oder Zeitangabe.
Die ist aber nicht mehr wert als die berüchtigte Eieruhr.
Das ist ein Fortschrittsbalken mit Prozentangabe oder Zeitangabe aber auch nicht. Beides ist ein Ausdruck dafür, dass der Entwickler/Produktmanager nicht weiß, wie man dem Nutzer das Gefühl gibt, nicht zu warten.
Das Ziel muss also sein, die gefühlte Ladezeit zu verringern.
So isses.
Letztens einen Artikel zu gelesen, wie man das machen kann. Wenn ich ihn wiederfinde, verlinke ich ihn hier.
LLAP 🖖
@@Der Martin
Da bleibt nur eine gleichbleibende Anzeige "wird geladen" als Text, Bild, Animation, ohne Prozentangabe oder Zeitangabe.
Die ist aber nicht mehr wert als die berüchtigte Eieruhr.
Das ist ein Fortschrittsbalken mit Prozentangabe oder Zeitangabe aber auch nicht. Beides ist ein Ausdruck dafür, dass der Entwickler/Produktmanager nicht weiß, wie man dem Nutzer das Gefühl gibt, nicht zu warten.
Dann frag ich mich, wofür das <progress>-Element entwickelt worden ist.
MfG
PS: Professionell gemachte Websites die für ein bischen Text 150 Requests und mehr in die Welt hecken, geben mir nicht das Gefühl warten zu müssen sondern eher das Gefühl schnell wieder abzuhauen und nie wieder zu kommen.
Hallo pl,
Dann frag ich mich, wofür das <progress>-Element entwickelt worden ist.
Zum Beispiel für die Visualisierung des Standes der Bearbeitung eines Fragebogens oder der Erstellung eines Artikels.
Im Wiki gab es mal eine Vorlage EditStatus mit fünf Status (Bearbeitung noch offen, Bearbeitung übernommen, Bearbeitung abgeschlossen, Korrekturlesen abgeschlossen, Fremdkorrektur abgeschlossen).
PS: Professionell gemachte Websites die für ein bischen Text 150 Requests und mehr in die Welt hecken, geben mir nicht das Gefühl warten zu müssen sondern eher das Gefühl schnell wieder abzuhauen und nie wieder zu kommen.
+1 ;-)
Bis demnächst
Matthias
@@Gunnar Bittersmann
Das ist ein Fortschrittsbalken mit Prozentangabe oder Zeitangabe aber auch nicht. Beides ist ein Ausdruck dafür, dass der Entwickler/Produktmanager nicht weiß, wie man dem Nutzer das Gefühl gibt, nicht zu warten.
Letztens einen Artikel zu gelesen, wie man das machen kann. Wenn ich ihn wiederfinde, verlinke ich ihn hier.
Ich hab ihn nicht wiedergefunden.
Aus dem Gedächtnis: Eine Möglichkeit war, statt Eieruhr/drehendem Rad/Fortschrittsbalken etwas anzuzeigen, was die Illusion von Inhalt erzeugt.
Beispiel Produktübersicht, Liste von Produkten mit Bild, Beschreibung, Preis – in Grid dargestellt, für Produkte jeweils gleichgroße Boxen. Beim (Nach)laden von Produkten kein drehendes Rad anzeigen, sondern ein (Hintergrund)bild, das solch eine Box nachahmt: Fläche für das Bild, graue Balken für den Text.
Eine andere Möglichkeit hat Denys Mishunov in seinem Talk „Deconstructing Performance“ auf der From the Front in Bologna gezeigt: dem Nutzer sofort positives Feedback geben – optimistic UI (Folien 54 bis 64).
Statt des drehenden Rads wird dem Nutzer die erfolgreiche Verabeitung der Daten suggeriert – schon während diese zum Server übertragen werden. Die Datenübertragung läuft im Hintergrund. Nur wenn dabei etwas schief läuft, wird dies dem Nutzer mitgeteilt. Anstatt die allermeisten Nutzer auf die Bestätigung warten zu lassen nimmt man inkauf, dass man bei sehr wenigen Nutzers die Bestätigung korrigieren muss.
LLAP 🖖
Hallo Gunnar,
Statt des drehenden Rads wird dem Nutzer die erfolgreiche Verabeitung der Daten suggeriert – schon während diese zum Server übertragen werden. Die Datenübertragung läuft im Hintergrund. Nur wenn dabei etwas schief läuft, wird dies dem Nutzer mitgeteilt. Anstatt die allermeisten Nutzer auf die Bestätigung warten zu lassen nimmt man inkauf, dass man bei sehr wenigen Nutzers die Bestätigung korrigieren muss.
Du kannst dir nicht vorstellen, wie sehr mich dieses Prinzip ankotzt. Eine Software, die ganz gross in sowas ist, ist Thunderbird – die belügt einen auch fein, dass alles abgeschlossen sei. Und dann macht man das Notebook zu, geht in den Mittag, spielt vielleicht am Handy rum und plötzlich hat man einen inkonsistenten Stand. Es gibt bei diesem Szenario so viele Stellen, an denen fälschlicherweise angenommen wird, dass schon alles gut geht – ich bin damit mehrfach auf die Nase gefallen. Und jedesmal, wenn etwas schief geht, schwindet das Vertrauen etwas mehr - denn es wird einem ja erstmal Erfolg vorgegaukelt.
Nein danke. Ich will mich nicht belügen lassen. Es ist sicherlich nicht gut, mir eine Progressbar vor die Nase zu setzen, aber die habe ich 1000 mal lieber als dieses Konzept.
LG,
CK
Hallo Christian,
Anstatt die allermeisten Nutzer auf die Bestätigung warten zu lassen nimmt man inkauf, dass man bei sehr wenigen Nutzers die Bestätigung korrigieren muss.
Du kannst dir nicht vorstellen, wie sehr mich dieses Prinzip ankotzt.
mir ist das noch nirgends aufgefallen, aber ich würde dieses Prinzip auch keinesfalls haben wollen.
Eine Software, die ganz gross in sowas ist, ist Thunderbird – die belügt einen auch fein, dass alles abgeschlossen sei.
Bei welchen Vorgängen? Beim Empfang von Mails ist es ja offensichtlich, wann sie vollständig übertragen sind - dann nämlich, wenn sie endlich im Posteingang angezeigt werden. Und beim Versenden kenn ich das so, dass bis zum Schluss, also bis auch der SMTP-Server den Transfer bestätigt, der Fortschrittsbalken angezeigt wird. Eventuell bleibt der mal eine Weile bei 99% stehen, aber er ist noch da und zeigt damit deutlich: Da läuft noch was.
Ärgerlich sind höchstens Hintergrund-Vorgänge wie etwa das Neu-Indizieren der Ordner, das beim nächsten Mal wieder von vorn beginnt, wenn man es unterbricht. Aber das hat keine wirklich negativen Folgen.
Und dann macht man das Notebook zu, geht in den Mittag, spielt vielleicht am Handy rum und plötzlich hat man einen inkonsistenten Stand. Es gibt bei diesem Szenario so viele Stellen, an denen fälschlicherweise angenommen wird, dass schon alles gut geht – ich bin damit mehrfach auf die Nase gefallen. Und jedesmal, wenn etwas schief geht, schwindet das Vertrauen etwas mehr - denn es wird einem ja erstmal Erfolg vorgegaukelt.
Da bin ich absolut bei dir, nur das Beispiel T-Bird kann ich nicht nachvollziehen.
Nein danke. Ich will mich nicht belügen lassen. Es ist sicherlich nicht gut, mir eine Progressbar vor die Nase zu setzen, aber die habe ich 1000 mal lieber als dieses Konzept.
+1
So long,
Martin
Hallo Martin,
Eine Software, die ganz gross in sowas ist, ist Thunderbird – die belügt einen auch fein, dass alles abgeschlossen sei.
Bei welchen Vorgängen?
Z.B. beim Verschieben mittlerer Mengen von E-Mails. Thunderbird gaukelt sehr schnell vor, dass das Verschieben abgeschlossen sei, obwohl ich weiss, dass das nicht so schnell passiert sein kann. Gut, inzwischen weiss ich es. Das erste Mal dachte ich naiverweise, dass sie die neuen IMAP-Features nutzen, und dass das verschieben deshalb so schnell abgeschlossen sei.
Übrigens, beim verschieben grosser Mengen von Mail bekommt man die lustige JS-Meldung, dass ein Script zu lange braucht, und ob man es nicht stoppen will, die man auch aus dem Firefox kennt.
Beim Empfang von Mails ist es ja offensichtlich, wann sie vollständig übertragen sind - dann nämlich, wenn sie endlich im Posteingang angezeigt werden.
Haha, falsch. Die Mail wird angezeigt, wenn genug Daten unten sind, um sie anzuzeigen - das kann lange vor dem kompletten Download der Mail sein. Noch so ein Fall, wo ich schon mit auf die Nase gefallen bin.
Und beim Versenden kenn ich das so, dass bis zum Schluss, also bis auch der SMTP-Server den Transfer bestätigt, der Fortschrittsbalken angezeigt wird. Eventuell bleibt der mal eine Weile bei 99% stehen, aber er ist noch da und zeigt damit deutlich: Da läuft noch was.
Das stimmt.
LG,
CK
Hi,
Eine Software, die ganz gross in sowas ist, ist Thunderbird – die belügt einen auch fein, dass alles abgeschlossen sei.
Bei welchen Vorgängen?
Z.B. beim Verschieben mittlerer Mengen von E-Mails. Thunderbird gaukelt sehr schnell vor, dass das Verschieben abgeschlossen sei, obwohl ich weiss, dass das nicht so schnell passiert sein kann.
hmm. Ja, etimmt wohl, dass T-Bird hier kein unmittelbares Feedback gibt - also kein "Bitte warten", kein Fortschrittsbalken oder so. Aber ich sehe dann an der aufwärts bzw. abwärts zählenden Anzahl der Nachrichten in den zwei betroffenen Ordnern, dass noch etwas läuft. Gut, das kann man natürlich auch leicht übersehen, wenn man nicht darauf achtet.
Übrigens, beim verschieben grosser Mengen von Mail bekommt man die lustige JS-Meldung, dass ein Script zu lange braucht, und ob man es nicht stoppen will, die man auch aus dem Firefox kennt.
Ups. Das hatte ich noch nicht, obwohl ich auch schon Hunderte von Mails auf einmal verschoben habe.
Beim Empfang von Mails ist es ja offensichtlich, wann sie vollständig übertragen sind - dann nämlich, wenn sie endlich im Posteingang angezeigt werden.
Haha, falsch. Die Mail wird angezeigt, wenn genug Daten unten sind, um sie anzuzeigen - das kann lange vor dem kompletten Download der Mail sein. Noch so ein Fall, wo ich schon mit auf die Nase gefallen bin.
Öhm. Muss ich mal drauf achten. Ich hätte jetzt behauptet ...
Ciao,
Martin
Hallo Martin,
Übrigens, beim verschieben grosser Mengen von Mail bekommt man die lustige JS-Meldung, dass ein Script zu lange braucht, und ob man es nicht stoppen will, die man auch aus dem Firefox kennt.
Ups. Das hatte ich noch nicht, obwohl ich auch schon Hunderte von Mails auf einmal verschoben habe.
Ich spreche hier von etwa 200k Mails. Hunderte ist wenig, das geht innert weniger Sekunden.
LG,
CK
Hi,
Ups. Das hatte ich noch nicht, obwohl ich auch schon Hunderte von Mails auf einmal verschoben habe.
Ich spreche hier von etwa 200k Mails.
ach du Sch... so viele habe ich nicht einmal insgesamt über die letzten 10 Jahre angesammelt. Ich habe hier pro Ordner maximal irgendwas im niedrigen vierstelligen Bereich.
Hunderte ist wenig, das geht innert weniger Sekunden.
Wenn du meinst. Für meine Begriffe ist das schon viel. :-O
Ciao,
Martin
Hallo Martin,
Ups. Das hatte ich noch nicht, obwohl ich auch schon Hunderte von Mails auf einmal verschoben habe.
Ich spreche hier von etwa 200k Mails.
ach du Sch... so viele habe ich nicht einmal insgesamt über die letzten 10 Jahre angesammelt. Ich habe hier pro Ordner maximal irgendwas im niedrigen vierstelligen Bereich.
FLOSS-Entwicklung findet oftmals über Mailinglisten statt. Ein Ein-Jahres-Archiv der pg-hackers-Liste z.B. ist etwa 120k Mails gross. Ich bin auf mehreren Listen dieser Grösse. (Und nein, ich lese nicht alle Mails ;-)
LG,
CK
@@Der Martin
Anstatt die allermeisten Nutzer auf die Bestätigung warten zu lassen nimmt man inkauf, dass man bei sehr wenigen Nutzers die Bestätigung korrigieren muss.
Du kannst dir nicht vorstellen, wie sehr mich dieses Prinzip ankotzt.
mir ist das noch nirgends aufgefallen, aber ich würde dieses Prinzip auch keinesfalls haben wollen.
Ich will schon, dass Anwendungen offline first funktionieren.
Nein danke. Ich will mich nicht belügen lassen. Es ist sicherlich nicht gut, mir eine Progressbar vor die Nase zu setzen, aber die habe ich 1000 mal lieber als dieses Konzept.
+1
−1
LLAP 🖖
Hallo,
Du kannst dir nicht vorstellen, wie sehr mich dieses Prinzip ankotzt.
mir ist das noch nirgends aufgefallen, aber ich würde dieses Prinzip auch keinesfalls haben wollen.
Ich will schon, dass Anwendungen offline first funktionieren.
ich auch, aber das bedeutet, dass das Nachladen optional ist und ein Scheitern kein großes Manko darstellt. Nur: Woher kommt dann nach deiner Prämisse der erste Rutsch an Daten? Genau, also doch online. Dann übertrage ich doch lieber mit dem initialen Transfer eine geringfügig größere Datenmenge und brauche dann nicht häppchenweise erneut beim Server anzufragen und nachzuladen.
So long,
Martin
@@Der Martin
Ich will schon, dass Anwendungen offline first funktionieren.
ich auch, aber das bedeutet, dass das Nachladen optional ist
Offline first bedeutet, dass die Verbindung zum Server/Internet optional ist
und ein Scheitern kein großes Manko darstellt.
Ja, das. Wie so oft eine Abwägung der Folgen von false positive vs. false negative.
Nur: Woher kommt dann nach deiner Prämisse der erste Rutsch an Daten?
Aus dem local storage. Bspw. bei Mailclients durchaus gängig, dass zuvor heruntergeladene Mails beim Start der Applikation da sind und man diese lesen und beantworten kann – auch ohne Netzverbindung. Die Synchronisation, d.h. das Herunterladen neuer Mails und das Abschicken der Mails aus dem Postausgang geschieht freilich erst, wenn wieder eine Verbindung besteht – aber dann automatisch ohne weiteres Zutun des Nutzers.
Dann übertrage ich doch lieber mit dem initialen Transfer eine geringfügig größere Datenmenge und brauche dann nicht häppchenweise erneut beim Server anzufragen und nachzuladen.
In diesem Thread ging es nicht um die Frage nach der initial zu übertragenden Datenmenge; in diesem Subthread schon gar nicht. Sondern um das allgemeine Konzept: Nutzer warten lassen (und ihn das wissen lassen) vs. Nutzer nicht warten lassen.
LLAP 🖖
Hallo,
Ich will schon, dass Anwendungen offline first funktionieren.
ich auch, aber das bedeutet, dass das Nachladen optional ist
Offline first bedeutet, dass die Verbindung zum Server/Internet optional ist
ja, so meine ich das auch, aber irgendwo muss mal eine Information herkommen, mit der ich starten kann.
Nur: Woher kommt dann nach deiner Prämisse der erste Rutsch an Daten?
Aus dem local storage.
Wir reden hier eigentlich von Webseiten bzw. Webanwendungen. Da muss ich davon ausgehen, dass der Besucher sie irgendwann zum ersten Mal aufruft, oder sie von seinem letzten Besuch her nicht mehr im Cache hat. Also brauche ich für den Einstieg die Online-Verbindung.
Bspw. bei Mailclients durchaus gängig, dass zuvor heruntergeladene Mails beim Start der Applikation da sind und man diese lesen und beantworten kann – auch ohne Netzverbindung.
Ja, bei Mailclients ist es üblich, dass sie eine lokale Kopie haben, und im Gegensatz zum Browser-Cache ist die normalerweise auch persistent, während Inhalte aus dem Browser-Cache jederzeit zugunsten neuer Daten rausfliegen können (oder beim Schließen des Browsers sogar absichtlich gelöscht werden).
Aber wie gesagt, um Mailclients ging es ja hier gar nicht.
Dann übertrage ich doch lieber mit dem initialen Transfer eine geringfügig größere Datenmenge und brauche dann nicht häppchenweise erneut beim Server anzufragen und nachzuladen.
In diesem Thread ging es nicht um die Frage nach der initial zu übertragenden Datenmenge; in diesem Subthread schon gar nicht. Sondern um das allgemeine Konzept: Nutzer warten lassen (und ihn das wissen lassen) vs. Nutzer nicht warten lassen.
Genau, und deshalb plädierte ich dafür, zu Beginn, wo er sowieso einen Augenblick warten muss, etwas mehr als die minimal nötigen Daten zu übertragen, damit Nachfolge-Requests nach Möglichkeit gar nicht mehr erforderlich sind.
So long,
Martin
@@Der Martin
Ja, bei Mailclients ist es üblich, dass sie eine lokale Kopie haben, und im Gegensatz zum Browser-Cache ist die normalerweise auch persistent, während Inhalte aus dem Browser-Cache jederzeit zugunsten neuer Daten rausfliegen können (oder beim Schließen des Browsers sogar absichtlich gelöscht werden).
Wer tut den sowas absichtlich‽
Und ist nicht local storage was anderes als Browser-Cache? Hat da nicht jede Anwendung ihr eigenes Stückchen Speicherplatz?
Aber klar, um bei einer Webapp irgendwas darzustellen, muss schon irgendwann mal irgendwas übertragen worden sein; sie also schon mal aufgerufen worden sein.
Was dann dieses Irgendwas ist …
Ich glaube, der Guardian war’s, der offline first das Grundgerüst der Seite (incl. Stylesheet) vorhält, damit die Seite eben so aussieht wie die Guardian-Seite aussehen soll, und wenn keine Artikel geladen werden können, wird ein Kreuzworträtsel angezeigt.
Bei der Beantwortung der Frage „Was ist besser als nichts?“ kann man ja mal innovativ sein.
Aber wie gesagt, um Mailclients ging es ja hier gar nicht.
War ja nur ein Beispiel.
Aus Nutzersicht ist die Unterscheidung zwischen nativer App (früher™ sagte man „Programm“ dazu) und Webapp aber auch irrelevant.
Genau, und deshalb plädierte ich dafür, zu Beginn, wo er sowieso einen Augenblick warten muss, etwas mehr als die minimal nötigen Daten zu übertragen
Das kann – wie ich im Nachbarthread beipflichtete – sinnvoll sein, muss aber nicht.
damit Nachfolge-Requests nach Möglichkeit gar nicht mehr erforderlich sind.
Kommt HTTP/2, kommt Umdenken.
LLAP 🖖
Mahlzeit,
[...] während Inhalte aus dem Browser-Cache jederzeit zugunsten neuer Daten rausfliegen können (oder beim Schließen des Browsers sogar absichtlich gelöscht werden).
Wer tut den sowas absichtlich‽
ich zum Beispiel. Und nicht nur ich.
Sinnvoll ist das u.U. da, wo ein PC von mehreren gemeinsam genutzt wird (z.B. Familie) und "er" nicht unbedingt will, dass "sie" sieht, wo er so überall rumsurft. Oder umgekehrt.
Okay, man könnte auch verschiedene Benutzerprofile einrichten; die Ehepaare und Familien, die ich persönlich kenne, benutzen ihren gemeinsamen PC aber alle unter einem einzigen, gemeinsamen User-Account.
Und ist nicht local storage was anderes als Browser-Cache? Hat da nicht jede Anwendung ihr eigenes Stückchen Speicherplatz?
AFAIK ja, aber ich bin mir nicht sicher, ob local storage wirklich persistent ist oder vielleicht auch einer Art Garbage Collection unterliegt, wenn der dafür vorgesehene Speicherplatz mal eng wird.
Ciao,
Martin
Hallo Der Martin,
Sinnvoll ist das u.U. da, wo ein PC von mehreren gemeinsam genutzt wird (z.B. Familie) und "er" nicht unbedingt will, dass "sie" sieht, wo er so überall rumsurft. Oder umgekehrt.
Okay, man könnte auch verschiedene Benutzerprofile einrichten; die Ehepaare und Familien, die ich persönlich kenne, benutzen ihren gemeinsamen PC aber alle unter einem einzigen, gemeinsamen User-Account.
Oder den por^W^Wrivate modus nutzen.
Bis demnächst
Matthias
Hallo Matthias,
sorry, das muss raus:
Oder den por^W^Wrivate modus nutzen.
Ist dir bewusst, dass das ^W die Tasten-Kombi Ctrl+W bezeichnet und ein Wort rückwärts löscht? ;-) Du hast da nach Auflösung also stehen: „Oder rivate modus nutzen.” ;-)
Das kommt aus der Usenet-Zeit, als es noch immer mal wieder Probleme/Inkompatibilitäten mit der Tastatur gab und Tasten-Kombinationen nicht immer korrekt an das Host-System übertragen wurden. Stattdessen stand dann dort halt das ^W.
LG,
CK
Hallo
Hallo Matthias,
sorry, das muss raus:
Oder den por^W^Wrivate modus nutzen.
Ist dir bewusst, dass das
^Wdie Tasten-Kombi Ctrl+W bezeichnet und ein Wort rückwärts löscht? ;-) Du hast da nach Auflösung also stehen: „Oder rivate modus nutzen.” ;-)
Sicher? Wenn ich zähle, wird aus por^W^Wrivat mit zwei Rückwärtsschritten doch nur das „o“ und das „r“ gelöscht. Das „p“ bleibt also erhalten und wird, um „rivat“ ergänzt, zu „privat“.
Tschö, Auge
Hi,
sorry, das muss raus:
Oder den por^W^Wrivate modus nutzen.
Ist dir bewusst, dass das
^Wdie Tasten-Kombi Ctrl+W bezeichnet und ein Wort rückwärts löscht? ;-) Du hast da nach Auflösung also stehen: „Oder rivate modus nutzen.” ;-)Sicher? Wenn ich zähle, wird aus
por^W^Wrivatmit zwei Rückwärtsschritten doch nur das „o“ und das „r“ gelöscht.
achte auf den Unterschied "Delete Word left" und "Delete character left" (aka Backspace).
Das „p“ bleibt also erhalten und wird, um „rivat“ ergänzt, zu „privat“.
Das wäre beim Backspace ^H der Fall, und das hat Matthias wohl auch gemeint.
Ciao,
Martin
Hallo Auge,
Ist dir bewusst, dass das
^Wdie Tasten-Kombi Ctrl+W bezeichnet und ein Wort rückwärts löscht? ;-) Du hast da nach Auflösung also stehen: „Oder rivate modus nutzen.” ;-)Sicher? Wenn ich zähle, wird aus
por^W^Wrivatmit zwei Rückwärtsschritten doch nur das „o“ und das „r“ gelöscht. Das „p“ bleibt also erhalten und wird, um „rivat“ ergänzt, zu „privat“.
Ich habe da mal was für dich hervorgehoben ;-)
LG,
CK
@@Christian Kruse
Hallo Auge,
Ist dir bewusst, dass das
^Wdie Tasten-Kombi Ctrl+W bezeichnet und ein Wort rückwärts löscht? ;-) Du hast da nach Auflösung also stehen: „Oder rivate modus nutzen.” ;-)Sicher? Wenn ich zähle, wird aus
por^W^Wrivatmit zwei Rückwärtsschritten doch nur das „o“ und das „r“ gelöscht. Das „p“ bleibt also erhalten und wird, um „rivat“ ergänzt, zu „privat“.Ich habe da mal was für dich hervorgehoben ;-)
„Milz an Auge: Ich sehe was, was du nicht siehst!“ :-D
LLAP 🖖
Ich habe da mal was für dich hervorgehoben ;-)
„Milz an Auge: Ich sehe was, was du nicht siehst!“ :-D
Auge an Milz: Halt die Klappe, du blinde Nuss, sonst fliegst du raus!
;-)
So long,
Martin
@@Der Martin
„Milz an Auge: Ich sehe was, was du nicht siehst!“ :-D
Auge an Milz: Halt die Klappe, du blinde Nuss, sonst fliegst du raus!
Falsch. Zur Strafe jetzt nachsitzen!
LLAP 🖖
@@Gunnar Bittersmann
und ein Scheitern kein großes Manko darstellt.
Ja, das. Wie so oft eine Abwägung der Folgen von false positive vs. false negative.
Und die Abwägung kann an verschiedenen Stellen einer Anwendung durchaus unterschiedlich ausfallen.
Bspw. in einem Shop: Beim Hineinlegen eines Produkts in den Warenkorb muss nicht auf die Bestätigung vom Server gewartet werden. Man kann dem Nutzer sofort anzeigen, dass das Produkt im Warenkorb gelandet ist und ihn weiter shoppen lassen, während die Übertragung läuft und das Produkt auch serverseitig im Warenkorb landet.
Sollte dabei bei einem von 1000 Nutzern etwas schieflaufen, muss er das Produkt nochmal in den Warenkorb tun oder falls er den Übertragungsfehler gar nicht mitbekommt, dann kauft er dieses Produkt eben nicht. Dafür haben 999 andere eine bessere user experience.
Beim Checkout hingegen muss der angezeigte Inhalt des Warenkorbs mit dem auf dem serverseitigen System übereinstimmen. Die Bestätigung der Bestellung darf dem Nutzer erst angezeigt werden, wenn das System die Bestellung auch wirklich entgegengenommen hat.
LLAP 🖖