Daten aus einer Javascript Funktion in einen Warenkorb legen

[ReiniG]

Ich versuche eine einfache Sitzplatzreservierung für ein kleines Theater zu erstellen. Dazu lade ich die Sitzreihen zeilenweise aus einer Textdatei, in der Sitznummer und Status (f, r, b) gespeichert ist. Wenn der User jetzt auf einen Sitz klickt, dann ändert sich das Bild von frei auf ausgewählt:

<?php 
$counter = 0;
$file = 'seats.txt';
$line = file($file);
for($i=0;$i < 14;$i++){ 
	$counter = $counter + 1; 
	$string = $line[$i]; 
	if($counter == 8) { echo "&nbsp &nbsp <img src='R1.bmp' /> &nbsp &nbsp &nbsp &nbsp"; } 
	if(substr($string,4,1) == "f") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_10.bmp' title='0' /> &nbsp &nbsp"; } 
	else if(substr($string,4,1) == "s") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_2.bmp' title='2' /> &nbsp &nbsp"; } 
	else if(substr($string,4,1) == "r") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_1.bmp' title='1' /> &nbsp &nbsp"; } 
	else {
    echo "<img id=$i onclick='myFunction(id)' src='chkBox_3.bmp' title='3' /> &nbsp &nbsp"; }
}
?>

<script>
function myFunction(imgID) {
  var img = document.getElementById(imgID).title;
  if (img == "1") {
  window.alert("Reserved seat!");
	} else if (img == "2") {
  window.alert("Sold seat!");
	} else if (img == "3") {
  window.alert("Handicap seat!");
	} else if (img == "4") {
  document.getElementById(imgID).src = "chkBox_10.bmp";	
  document.getElementById(imgID).title = "0";
  } else {
  document.getElementById(imgID).src = "chkBox_4.bmp";	
  document.getElementById(imgID).title = "4";
  }
}
</script>

Wie bringe ich jetzt die ausgewählten Sitze (aus der client side Javascript Funktion) in den Warenkorb (event. auf eine neue Seite)?

[Robert R.]

Hallo,

ich würde jede Reservierung sofort einzeln per XHR ans Backend weitergeben (per POST). Wenn der Status 200 zurückkommt, dann erst im Frontend auf reserviert umschalten. Frontendstatus müssten sein:

• frei
• XHR läuft
• Reservierung angenommen (nur für den gerade aktiven User)
• Fehler bei der Reservierung (nur für den gerade aktiven User)
• besetzt

Der User sieht also alle für ihn reservierten Sitze als "Reservierung angenommen" und alle anderen besetzten als "besetzt"

XHR geht gabz simpel mit jQuery.

Wenn man es gut machen will, müssten alle Clients, die gerade die Seite besuchen, bei jeder Änderung einen Serverpusch bekommen, damit sie die Daten neu laden.

LG
RR

[Gunnar Bittersmann]

@@Robert R.

ich würde jede Reservierung sofort einzeln per XHR ans Backend weitergeben (per POST). Wenn der Status 200 zurückkommt, dann erst im Frontend auf reserviert umschalten.

Nein; Rückmeldung im Frontend sofort. Optimistic user interface ☞ Folien 54 bis 64

S.a. dieses Posting von mir. Und auch jenes.

LLAP 🖖

[chorn]

und auch unbedingt das hier lesen:

Nein danke. Ich will mich nicht belügen lassen.

[Gunnar Bittersmann]

@@chorn

Nein danke. Ich will mich nicht belügen lassen.

Darauf hatte ich im weiteren Verlauf des Threads schon geantwortet. Es ist eine Abwägung, 1000 Nutzer sinnlos warten zu lassen oder bei einem eventuell(!) eine suggerierte Bestätigung etwas später wieder zurücknehmen zu müssen. Mit „belügen“ hat das wenig zu tun, da übertreibt CK maßlos, IMHO.

Die Abwägung sollte klar sein. Im Normalfall geht alles gut. Kein Grund, Nutzer unnötige Wartezeit verbringen zu lassen.

Dass es aber auch kritische Stellen gibt, wo man diese Abwägung nicht treffen darf, hatte ich erwähnt.

LLAP 🖖

[Robert R.]

Hallo,

und auch unbedingt das hier lesen:

Nein danke. Ich will mich nicht belügen lassen.

Das kann ich voll unterstützen - zumal die Anzeige eines sauberen Status im Client möglich ist!

LG
Robert R.

[Gunnar Bittersmann]

@@Robert R.

Nein danke. Ich will mich nicht belügen lassen.

Das kann ich voll unterstützen

Es ist bedauerlich, wie wenig Gedanken sich manche Entwicker immer noch um (perceived) performance machen.

LLAP 🖖

[dedlfix]

Tach!

Es ist bedauerlich, wie wenig Gedanken sich manche Entwicker immer noch um (perceived) performance machen.

Also ich möchte ungern nur eine gefühlte Reservierung haben, weil ich auf das Gefühl verzichten kann, mit mehreren Personen auf demselben Platz zu sitzen.

Jetzt mal Butter bei die Fische. Wie genau würdest du den Ablauf beim Reservieren aus Nutzersicht haben wollen? Bedenke auch, dass Bestätigungen vermutlich rechtsverbindlich sein müssen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Jetzt mal Butter bei die Fische. Wie genau würdest du den Ablauf beim Reservieren aus Nutzersicht haben wollen?

Der Nutzer wählt einen Platz, dieser wird ihm sofort als durch ihn belegt angezeigt. Das ist bei Checkboxen schon der Fall. (Erwähnte ich schon Checkboxen?) Im Hintergrund wird die Anfrage asynchron an den Server geschickt und der Platz auch dort (temporär) als für diesen Nutzer reserviert markiert. Sollte da zufällig gerade ein anderer schneller gewesen sein, bekommt der Nuzter wenig später (je nach Verbindung Sekundenbruchteile bis wenige Sekunden) eine entsprechende Meldung und die Checkbox wird auf disabled gesetzt.

Der Nutzer wählt einen weiteren Platz …

Nachdem er alle gewünschten Plätze gewählt hat, drückt der Nutzer „Karten kaufen“. In dem Moment gilt:

dass Bestätigungen vermutlich rechtsverbindlich sein müssen.

(vermutlich ohne „vermutlich“). Hier muss der Nutzer tatsächlich auf die Bestätigung vom Server warten, dass auch wirklich alle gewünschten Plätze für ihn reserviert wurden.

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Im Hintergrund wird die Anfrage asynchron an den Server geschickt und der Platz auch dort (temporär) als für diesen Nutzer reserviert markiert.

Unnötig zu erwähnen, das die AJAX-Funktionalität progressive enhancement ist. Denn …

Nachdem er alle gewünschten Plätze gewählt hat, drückt der Nutzer „Karten kaufen“.

… das Abschicken des Formulars (also der Kartenkauf mit Reservierung der Plätze) funktioniert auch ohne JavaScript. Nur dass dann die Wahrscheinlichkeit etwas höher ist, dass ein anderer einem die gewünschten Plätze vor der Nase wegschnappt.

LLAP 🖖

[ReiniG]

Danke für deine Ausführungen!

Der Nutzer wählt einen Platz, dieser wird ihm sofort als durch ihn belegt angezeigt. Das ist bei Checkboxen schon der Fall... Im Hintergrund wird die Anfrage asynchron an den Server geschickt und der Platz auch dort (temporär) als für diesen Nutzer reserviert markiert. Sollte da zufällig gerade ein anderer schneller gewesen sein, bekommt der Nuzter wenig später (je nach Verbindung Sekundenbruchteile bis wenige Sekunden) eine entsprechende Meldung und die Checkbox wird auf disabled gesetzt.

Und wo und wie baue ich da die AJAX Funktion ein? Etwa als change-Ereignis?

Brauche ich bei dieser Vorgehensweise überhaupt ein flock() beim Auslesen der Datei?

Wie handhabe ich das mit "temporär"? Ich ändere ja bei der Anfrage direkt in der Datei bei jenem Sitzplatz den Status. Damit ist für jede neue Abfrage dieser Platz nicht mehr verfügbar. Außer der User gibt ihn selbst wieder frei. Aber ...

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

Und wie mache ich das?

Nachdem er alle gewünschten Plätze gewählt hat, drückt der Nutzer „Karten kaufen“... Hier muss der Nutzer tatsächlich auf die Bestätigung vom Server warten, dass auch wirklich alle gewünschten Plätze für ihn reserviert wurden.

D.h. nachdem der User hier ja nach jedem Auswählen eines Platzes eine visuelle Rückmeldung vom Server bekommt, dass der jeweilige Platz für ihn reserviert (oder eben bereits von jemand anderen inzwischen reserviert) wurde, brauche ich da noch eine Session? Zum check-out auf einer anderen Seite werden die gewählten Sitze ja über das Formular übertragen.

Und was mache ich, wenn der User dann die Karten nicht kauft oder beim Zahlvorgang etwas schiefgeht oder er zurückgeht und die Auswahl ändert?

[Julius]

Hallo ReiniG,

Und wo und wie baue ich da die AJAX Funktion ein? Etwa als change-Ereignis?

Via addEventListener kannst du eine Funktion bestimmen, die auf ein bestimmtes Ereignis reagiert. Du kannst das Event auch auf das übergeordnete Element registrieren – das ist das hier schon mehrfach erwähnte „Bubbling“:

<!doctype html>
<html>
<meta charset="utf-8">
<form id="test">
 <label><input type="checkbox" id="1"> Erster</label>
 <label><input type="checkbox" id="2"> Zweiter</label>
 <label><input type="checkbox" id="3"> Dritter</label>
</form>
<script>
function test(event)
{
  var elem = event.target;
  console.log(elem.getAttribute('id'));
}

document.getElementById('test').addEventListener('change', test);
</script>

Brauche ich bei dieser Vorgehensweise überhaupt ein flock() beim Auslesen der Datei?

Ich meine ja, weil mir ja sonst ein anderer Prozess die Datei während des Lesevorgangs verändern kann (die dabei eingelesene Datei könnte dann ja einen inkonsistenten Datenbestand enthalten). Beim Auslesen kannst du ja so sperren, dass weiterhin andere Prozesse lesen können. Beim Schreiben exklusiv.

Wie handhabe ich das mit "temporär"?

In einer Datenbank würde man die Session-ID des reservierenden Nutzers und das Eintragedatum beim betreffenden Sitzplatz speichern und dann beim Auslesen kontrollieren, ob die spezifizierte Zeitspanne schon abgelaufen ist (dann einfach neue Session-ID und Zeitstempel ablegen) und wenn nicht, ob der aktuelle Nutzer der war, der den Sitzplatz reserviert hat.

Ich ändere ja bei der Anfrage direkt in der Datei bei jenem Sitzplatz den Status.

Vielleicht solltest du lieber eine Datenbank, beispielsweise MySQL/MariaDB benutzen.

Damit ist für jede neue Abfrage dieser Platz nicht mehr verfügbar. Außer der User gibt ihn selbst wieder frei. Aber ...

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

s. o.: Du brauchst erst beim Anzeigen des Formulars zu überprüfen, ob der Platz noch vorgemerkt ist.

Nachdem er alle gewünschten Plätze gewählt hat, drückt der Nutzer „Karten kaufen“... Hier muss der Nutzer tatsächlich auf die Bestätigung vom Server warten, dass auch wirklich alle gewünschten Plätze für ihn reserviert wurden. D.h. nachdem der User hier ja nach jedem Auswählen eines Platzes eine visuelle Rückmeldung vom Server bekommt, dass der jeweilige Platz für ihn reserviert (oder eben bereits von jemand anderen inzwischen reserviert) wurde, brauche ich da noch eine Session? Zum check-out auf einer anderen Seite werden die gewählten Sitze ja über das Formular übertragen.

Prinzipiell reicht das aus, aber wenn die Nutzer sich Karten für wenige Minuten „vorreservieren“ können sollen, musst du sie schon irgendwie wieder erkennen und dafür bräuchtest du halt die Session.

Alternativ kannst du es dir auch einfach machen und die Verfügbarkeit eines Platzes nur beim Laden des Formulars prüfen und dann noch einmal bei der endgültigen Registrierung, dafür brauchst du dann kein Ajax. Falls dein Formular nicht den Andrang wie das von Apple für deren „keynote“ hat, würde ich auf das Überprüfen und Vormerken erst beim finalen Speichern machen und dem Nutzer im Falle eines oder mehrerer nicht mehr freien Platzes das Formular noch einmal zur Bearbeitung vorsetzen (die bisherigen Eingaben natürlich wieder laden!).

Und was mache ich, wenn der User dann die Karten nicht kauft oder beim Zahlvorgang etwas schiefgeht oder er zurückgeht und die Auswahl ändert?

Für den Fall, dass du das mit einem Zeitstempel löst, läuft die Zeit einfach ab und der Platz kann neu vergeben werden. Wenn du ein „dummes“ Formular ohne Ajax benutzt, wird der Platz ja erst beim endgültigen Kauf reserviert.

Gruß
Julius

[Gunnar Bittersmann]

@@ReiniG

Und wo und wie baue ich da die AJAX Funktion ein? Etwa als change-Ereignis?

Ja. Oder input-Event.

Wie handhabe ich das mit "temporär"? Ich ändere ja bei der Anfrage direkt in der Datei bei jenem Sitzplatz den Status. Damit ist für jede neue Abfrage dieser Platz nicht mehr verfügbar. Außer der User gibt ihn selbst wieder frei.

Autsch. Das heißt, ein Nutzer kann alle Plätze für sich reservieren ohne einen Kauf zu tätigen und blockiert damit alle Plätze für alle Zeit, niemand anderes kann mehr Karten kaufen und die Veranstaltung findet vor leeren Reihen statt?

Irgendwas muss da laufen und ausgewählte, aber nicht gekaufte Plätze wieder freigeben.

Und wie mache ich das?

Cronjob?

LLAP 🖖

[roundturn]

Moin,

Autsch. Das heißt, ein Nutzer kann alle Plätze für sich reservieren ohne einen Kauf zu tätigen und blockiert damit alle Plätze für alle Zeit, niemand anderes kann mehr Karten kaufen und die Veranstaltung findet vor leeren Reihen statt?

Irgendwas muss da laufen und ausgewählte, aber nicht gekaufte Plätze wieder freigeben.

Und wie mache ich das?

Cronjob?

wie wäre es denn für den Anfang mit:

• Benutzer muss sich als erstes authentifizieren
• Jede Vorreservierung bekommt einen Timestamp
• Es wird eine Offenzeit festgelegt, die dem User auch (ungefähr) angezeigt werden kann am Client. Diese zählt seit Beginn des Reservierungsvorganges also seit dem ersten Click.
• In der Session wird eingetragen, wieviele Vorreservierungen bestehen (Limit festlegen!)
• Wenn der User kauft, wird vorher der Timestamp aller vorreservierten Plätze geprüft, der Kauf eingetragen und das Limit in der Session zurückgesetzt. Danach kann er weitere Plätze buchen.

Bei der Abfrage, welche Plätze noch frei sind, wird die Timestamps geprüft. Ist das Zeitlimit bereits abgelaufen, ist der Platz automatisch wieder frei und bekommt beim Vorreservieren einen neuen Timestamp.

Und übrigens:
Wenn man das mit einer Datenbank macht, muss man zuerst prüfen, ob sich seit dem letzten Lesen etwas verändert hat und darf nur dann etwas ändern, wenn alle Daten gleich geblieben sind. Dafür benutzt man die Session als Zwischenpuffer, da man den Vorgang nicht in SELECT und UPDATE aufteilen darf (ohen die Tabelle oder den Satz zu sperren, was aber über einen Roundturn hinweg schwierig ist), sondern die Prüfung beim Update in der WHERE-Klausel vornehmen muss.

Beim Arbeiten mit Low-Level-Dateien gilt das analog: Erst (SHARED) lesen, in die Session eintragen und zum Client senden. Bei Änderungen erst die Datei EXCLUSIV sperren, dann nochmal lesen (!) und mit dem Sessionpuffer vergleichen, dann die Daten geändert zurückschreiben.

Dann geht auch nichts schief mit den Raceconditions und den Roundturns.

Response Code 200
roundturn

[pl]

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

Klingt gut. Dumm wäre jedoch, wenn der Kunde nach Ablauf der "gewissen Zeit" auf Kaufen drückt und eine Überweisung auslöst. Was machste da?

[Auge]

Hallo

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

Klingt gut. Dumm wäre jedoch, wenn der Kunde nach Ablauf der "gewissen Zeit" auf Kaufen drückt und eine Überweisung auslöst.

Warum sollte er das tun? Der Kunde sieht/liest doch, ob die Bestellung erfolgreich war oder nicht. Warum sollte eine Zahlung bei nicht erfolgreicher Bestellung überhaupt erfolgen?

Tschö, Auge

[pl]

Warum sollte er das tun? Der Kunde sieht/liest doch, ob die Bestellung erfolgreich war oder nicht.

Du verstehst das Problem nicht: Zwischen Reservierung und Bezahlung liegt eine programmierte Karenzzeit die einen Deadlock verhindern soll. Damit jedoch ist der gesamte Prozess nicht mehr atomar. Somit kann es eben doch passieren, dass Geld fließt für Plätze die mittlerweile wieder freigegeben wurden.

Das ist für beide Seiten ärgerlich, aber nicht zu verhindern.

MfG

[Gunnar Bittersmann]

@@pl

Du verstehst das Problem nicht

Und ich glaube, du verstehst die Lösung nicht.

Zwischen Reservierung und Bezahlung liegt eine programmierte Karenzzeit die einen Deadlock verhindern soll. Damit jedoch ist der gesamte Prozess nicht mehr atomar. Somit kann es eben doch passieren, dass Geld fließt für Plätze die mittlerweile wieder freigegeben wurden.

Nein, Geld fließt erst, wenn die Karten gekauft werden – und zwar die ganze Bestellung auf einmal.

Das ist für beide Seiten ärgerlich, aber nicht zu verhindern.

Doch, dass wird dadurch verhindert, dass durch die Auswahl eines Platzes noch kein Kauf zustandekommt, sondern eine temporäre Vorreservierung.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Du verstehst das Problem nicht

Und ich glaube, du verstehst die Lösung nicht.

Oder ich hab falsch verstanden, was du mit „zwischen Reservierung und Bezahlung“ meinst.

Das hieß für mich: zwischen Vorreservierung und Kauf, wobei Kauf = drücken des Buttons „Karten kaufen“.

Was zwischen Kauf und tatsächlicher Überweisung des Geldes (meinst du das mit „Bezahlung“?) liegt, ist sowieso außerhalb des Systems, wie Auge schon sagte.

LLAP 🖖

[Auge]

Hallo

Warum sollte er das tun? Der Kunde sieht/liest doch, ob die Bestellung erfolgreich war oder nicht.

Du verstehst das Problem nicht:

Nein, ich verstehe dein Problem wirklich nicht.

Zwischen Reservierung und Bezahlung liegt eine programmierte Karenzzeit die einen Deadlock verhindern soll.

Du willst mir doch nicht erzählen, dass du ein System im Sinn hast, das zwischen der Reservierung/Bestellung und der Bezahlung, die im deutschen Bankensystem schon mal mehrere Tage in Anspruch nehmen kann, gesperrt ist.

Damit jedoch ist der gesamte Prozess nicht mehr atomar.

Warum sollte er das auch sein? Ich habe noch keine Website gesehen, wo so etwas atomar ist. Ich bestelle etwas. Die Bestellung wird bestätigt oder zurückgewiesen. Im ersten Fall weise ich nach Eingang der Bestellbestätigung (auf wqelchem Weg auch immer) die Bezahlung an, im zweiten Fall nicht. Punkt, um, aus. Da gibt es kiene Notwendigkeit für Atomarität.

Somit kann es eben doch passieren, dass Geld fließt für Plätze die mittlerweile wieder freigegeben wurden.

meiner Meinung nach sollte es eher vorkommen, dass eine Bestellung nicht bezahlt wird und daraufhin die Plätze wieder freigegeben werden müssen.

Das ist für beide Seiten ärgerlich …

Das kann je nach Nachfrage nach der Veranstaltung und dem Zeitrahmen ärgerlich für den Veranstalter werden. Der Besteller bezahlt einfach nicht und macht sich quasi aus dem sprichwörtlichen Staub.

… aber nicht zu verhindern.

Grundsätzlich kann es natürlich zu „Fehlzahlungen“ kommen. Dann überweist man eben zurück. So oft passiert das ja nun auch nicht.

Tschö, Auge

[dedlfix]

Tach!

Du verstehst das Problem nicht: Zwischen Reservierung und Bezahlung liegt eine programmierte Karenzzeit die einen Deadlock verhindern soll.

Zwischen Reservierung und Bezahlung liegt die verbindliche Bestellung. Und zu dieser werden die Plätze nicht nur reserviert sondern verbindlich gebucht.

Kunde sucht aus und reserviert. Kunde geht zur Kasse und schließt den Vorgang ab, die Sitze werden gebucht. Wenn Kunde hingegen den Vorgang nicht abschließt, wird die Reservierung nach einer Zeit im Minuten- oder Stunden-Bereich aufgehoben. Gebuchte Plätze haben keine automatische Freigabe, das lohnt bei dem kleinen Theater vermutlich auch nicht und kann bei Bedarf per Hand erfolgen.

Damit jedoch ist der gesamte Prozess nicht mehr atomar. Somit kann es eben doch passieren, dass Geld fließt für Plätze die mittlerweile wieder freigegeben wurden.

Nicht erfolgte Zahlungen sind (hoffentlich) ein Sonderfall. Der Status "reserviert" löst sich von selbst, wenn keine Bestellung erfolgt. Der Status "gebucht" darf sich nicht lösen, ohne dass eine Klausel im Vertrag die Bindung bei nicht erfolgter Zahlung bis zu einer festgelegten Frist aufhebt.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wenn Kunde hingegen den Vorgang nicht abschließt, wird die Reservierung nach einer Zeit im Minuten- oder Stunden-Bereich aufgehoben.

Minuten, eher im einstelligen Bereich; s.a. m1690604

LLAP 🖖

[dedlfix]

Tach!

Wenn Kunde hingegen den Vorgang nicht abschließt, wird die Reservierung nach einer Zeit im Minuten- oder Stunden-Bereich aufgehoben.

Minuten, eher im einstelligen Bereich; s.a. m1690604

Aus meiner Sicht als Kunde hab ich es lieber länger, dass etwas im meinem Warenkorb verbleibt.

Wenn ich es darauf anlege, das Theater zu schädigen, dann hilft auch die Verkürzung auf Minuten nicht viel, dann muss ich nur meinen Bot auf ein kürzeres Intervall einstellen.

Die kürzere Verfallszeit verlagert das Problem nur in Richtung ehrliche Kunden, ohne es zu lösen. Falls das überhaupt ein Problem ist. Wenn sowas auftritt, kann man ja immer noch als erste Maßnahme die eine Variable mit der Zeit ändern.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wenn Kunde hingegen den Vorgang nicht abschließt, wird die Reservierung nach einer Zeit im Minuten- oder Stunden-Bereich aufgehoben.

Minuten, eher im einstelligen Bereich; s.a. m1690604

Aus meiner Sicht als Kunde hab ich es lieber länger, dass etwas im meinem Warenkorb verbleibt.

Wenn ich es darauf anlege, das Theater zu schädigen

Es geht eher darum, dass andere Kunden geschädigt werden, wenn jemand Plätze reserviert, aber nicht kauft, und die Plätze dann stundenlang blockiert sind.

Ein paar Minuten sollten ausreichen, um sich seine Plätze auszuwählen und tatsächlich für den Kauf zu entscheiden.

LLAP 🖖

[dedlfix]

Tach!

Aus meiner Sicht als Kunde hab ich es lieber länger, dass etwas im meinem Warenkorb verbleibt.

Wenn ich es darauf anlege, das Theater zu schädigen

Es geht eher darum, dass andere Kunden geschädigt werden, wenn jemand Plätze reserviert, aber nicht kauft, und die Plätze dann stundenlang blockiert sind.

Ein paar Minuten sollten ausreichen, um sich seine Plätze auszuwählen und tatsächlich für den Kauf zu entscheiden.

Ja, ist mir schon klar, aber nicht immer braucht man nur ein paar Minuten. Manchmal muss noch die Omma angerufen werden und die findet ihren Kalender nicht so schnell, und vorbei sind die paar Minuten und der Kunde ärgert sich vielleicht. Amazon verkauft zwar keine Sitzplätze im Theater, aber dort würden theoretisch auch schon ein paar Minuten zum Abschließen von Einkäufen reichen. Trotzdem leert sich da mein Warenkorb auch nach Tagen noch nicht. Und das ist nicht nur zu meinem Vorteil, wenn ich das Ding, ohne es neu suchen zu müssen, dann doch noch kaufe. Tage müssen es vielleicht in dem Theater nicht sein, aber ohne Not die Zeit zu knapp zu gestalten, hilft auch niemandem. (Begehrte Veranstaltungen wären hingegen ein solcher "Not"fall.) Diese Entscheidung muss letztlich der Betreiber treffen.

dedlfix.

[Tabellenkalk]

Hallo,

Trotzdem leert sich da mein Warenkorb auch nach Tagen noch nicht.

Der Vergleich mit Amazon hinkt. Dort bestellt man in der Regel Dinge, die irgendwo auf Lager sind (oder waren) und dir mehr oder weniger prompt zugeschickt werden. Danach kannst du sie nutzen.
Bei einer Buchung für eine Theatervorstellung geht es erstens um einen bestimmten Termin und zweitens kann bei Ausverkauf nicht einfach nachproduziert werden.

Gruß
Kalk

[ReiniG]

Die Buchungssysteme der großen Theater geben dem Kunden hier 8-10 min von der Auswahl der Plätze bis zur Bezahlung. Diese Zeit wird erneuert, wenn der Kunde zurück zur Auswahl geht und diese ändert.

Schließt er den Bezahlvorgang in dieser Zeit nicht ab, wird der Warenkorb geleert und die Plätze wieder frei gegeben.

Für große Theater ist diese Zeitspanne verständlich, da das System stärker frequentiert wird. Unter der Voraussetzung, dass ich als Kunde meine Daten für die Bezahlung griffbereit habe, ist das auch Zeit genug.

Aber für ein kleines bis mittleres Theater (in unserem Fall 150 Sitzplätze), wo das System nicht so stark frequentiert wird, möchte ich doch etwas mehr Zeit geben. Ich dachte so 15-20 min. Aber sicher nicht Stunden oder gar Tage.

[Gunnar Bittersmann]

@@dedlfix

Ja, ist mir schon klar, aber nicht immer braucht man nur ein paar Minuten. Manchmal muss noch die Omma angerufen werden und die findet ihren Kalender nicht so schnell, und vorbei sind die paar Minuten und der Kunde ärgert sich vielleicht.

Das ist das Problem dieses Kunden. Das sollte nicht auf alle anderen Kunden abgewälzt werden. Muss er eben die Omma vorher anrufen. Oder er muss die Plätze nach dem Telefonat halt nochmal auswählen. Wenn sie dann schon weg sind, hat er halt Pech gehabt. Wegen eines einzelnen alle anderen zu ärgern, kann nicht Sinn der Sache sein. Und auch nicht im Interesse des Seitenbetreibers, seine Karten nicht zu verkaufen.

LLAP 🖖

[Auge]

Hallo

Ja, ist mir schon klar, aber nicht immer braucht man nur ein paar Minuten.

Das ist das Problem dieses Kunden. Das sollte nicht auf alle anderen Kunden abgewälzt werden. Muss er eben die Omma vorher anrufen. Oder er muss die Plätze nach dem Telefonat halt nochmal auswählen. Wenn sie dann schon weg sind, hat er halt Pech gehabt. Wegen eines einzelnen alle anderen zu ärgern, kann nicht Sinn der Sache sein. Und auch nicht im Interesse des Seitenbetreibers, seine Karten nicht zu verkaufen.

Du hältst es tatsächlich für problematisch, die Reservierung länger als „Minuten, eher im einstelligen Bereich“ aufrechtzuerhalten? Du denkst, dass damit „alle anderen“ geärgert werden? Was für ein weltfremder Blödsinn.

Wenn die Reservierung nach „Minuten, eher im einstelligen Bereich“ verfällt, dann ärgerst du Kunden, und zwar (so ziemlich) alle. Wer mir (und ganz gewiss nicht nur mir) die vorläufige Reservierung nach weniger als 15 Minuten unter den Füßen weghaut, will mein Geld nicht. Und wer als Veranstalter wegen der vorläufigen Reservierung von mehr als „Minuten, eher im einstelligen Bereich“ seine Karten nicht verkaufen kann, macht definitiv etwas falsch.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Du hältst es tatsächlich für problematisch, die Reservierung länger als „Minuten, eher im einstelligen Bereich“ aufrechtzuerhalten? Du denkst, dass damit „alle anderen“ geärgert werden? Was für ein weltfremder Blödsinn.

Ich kriege die guten Plätze nicht, weil irgendein Dödel die ausgewählt hat, ewig mit seiner Omma telefoniert und am Ende die Plätze doch nicht kauft. Natürlich bin ich dann verärgert.

Warum sollte man jemandem zwischen Auswählen der Plätze und Drücken auf „Tickets kaufen“ mehr als 5 Minuten Zeit geben?

Davon ist die ganze Zeit die Rede, nicht die Zeit bis zum Abschluss des Checkouts (Eingeben der Adresse, der EC-/Kreditkartendaten etc.)

LLAP 🖖

[Auge]

Hallo

Warum sollte man jemandem zwischen Auswählen der Plätze und Drücken auf „Tickets kaufen“ mehr als 5 Minuten Zeit geben?

Weil nicht nur der „Dödel“, der zwischendurch seine Oma anrufen muss, mehr als fünf Minuten brauchen kann. Halte dich doch einfach mal nicht ausschließlich an deinem Verhalten fest sondern beziehe jenes der vielen Anderen ein, die ein anderes Verhalten als deines haben. Du bist nicht der Maßstab aller Dinge.

Zudem sorgen 15 Minuten Vorreservierung bestimmt nicht dafür, dass du „die guten Plätze“ nicht mehr bekommst. Davon gibt's ja wohl nicht nur drei oder vier Stück, die ausgerechnet dann, wenn du Plätze reservieren willst, alle von jemand Anderem vorreserviert sind.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Warum sollte man jemandem zwischen Auswählen der Plätze und Drücken auf „Tickets kaufen“ mehr als 5 Minuten Zeit geben?

Weil nicht nur der „Dödel“, der zwischendurch seine Oma anrufen muss, mehr als fünf Minuten brauchen kann. Halte dich doch einfach mal nicht ausschließlich an deinem Verhalten fest sondern beziehe jenes der vielen Anderen ein, die ein anderes Verhalten als deines haben. Du bist nicht der Maßstab aller Dinge.

Ich hatte explizit nach „Warum“ gefragt; du hast keinen konkreten Grund genannt.

LLAP 🖖

[Auge]

Hallo

Ich hatte explizit nach „Warum“ gefragt; du hast keinen konkreten Grund genannt.

Was ist da so schwer zu verstehen?

Wer mir … die vorläufige Reservierung nach weniger als 15 Minuten unter den Füßen weghaut, will mein Geld nicht.

Weil nicht nur der „Dödel“, der zwischendurch seine Oma anrufen muss, mehr als fünf Minuten brauchen kann.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Ich hatte explizit nach „Warum“ gefragt; du hast keinen konkreten Grund genannt.

Was ist da so schwer zu verstehen?

Wer mir … die vorläufige Reservierung nach weniger als 15 Minuten unter den Füßen weghaut, will mein Geld nicht.

Weil nicht nur der „Dödel“, der zwischendurch seine Oma anrufen muss, mehr als fünf Minuten brauchen kann.

Was daran schwer zu verstehen ist: wie ein Konjunktiv „brauchen kann“ die Antwort auf die Frage nach einem konkreten Grund dafür sein soll.

Du hättest dir irgendein an den Haaren herbeigezogenes Beispiel ausdenken können, aber nicht einmal ein solches ist die eingefallen‽

LLAP 🖖

[Auge]

Hallo

Ich hatte explizit nach „Warum“ gefragt; du hast keinen konkreten Grund genannt.

Was ist da so schwer zu verstehen?

Wer mir … die vorläufige Reservierung nach weniger als 15 Minuten unter den Füßen weghaut, will mein Geld nicht.

Weil nicht nur der „Dödel“, der zwischendurch seine Oma anrufen muss, mehr als fünf Minuten brauchen kann.

Was daran schwer zu verstehen ist: wie ein Konjunktiv „brauchen kann“ die Antwort auf die Frage nach einem konkreten Grund dafür sein soll.

Du hättest dir irgendein an den Haaren herbeigezogenes Beispiel ausdenken können, aber nicht einmal ein solches ist die eingefallen‽

Klar, weil ich sage, dass es sein kann, dass ich mehr Zeit, als von Herrn Bittersmann zugestanden, brauche, bin ich verpflichtet, Herrn Bittersmann die Gründe detailliert darzulegen. Geht's noch? Wenn ich denn mehr Zeit brauche, gehen dich die Gründe dafür genau nix an. Ich bin keineswegs verpflichtet, hier reale oder real erscheinende Beispiele vorzubringen oder mir diese einfallen zu lassen.

Finde dich damit ab, dass andere Menschen allgemein oder in Einzelfällen andere Anforderungen haben als du.

Tschö, Auge

[dedlfix]

Tach!

Klar, weil ich sage, dass es sein kann, dass ich mehr Zeit, als von Herrn Bittersmann zugestanden, brauche, bin ich verpflichtet, Herrn Bittersmann die Gründe detailliert darzulegen. Geht's noch? Wenn ich denn mehr Zeit brauche, gehen dich die Gründe dafür genau nix an. Ich bin keineswegs verpflichtet, hier reale oder real erscheinende Beispiele vorzubringen oder mir diese einfallen zu lassen.

Vom Inhalt her stimme ich eigentlich zu, beim Tonfall sehe ich noch Verbesserungspotential. 😉

Finde dich damit ab, dass andere Menschen allgemein oder in Einzelfällen andere Anforderungen haben als du.

Mitunter ist es jedoch sinnvoll, der Gegenseite ein konkretes Szenario zu diesen Anforderungen zu liefern, damit da ein besseres Verständnis aufgebaut werden kann.

dedlfix.

[Auge]

Hallo

Finde dich damit ab, dass andere Menschen allgemein oder in Einzelfällen andere Anforderungen haben als du.

Mitunter ist es jedoch sinnvoll, der Gegenseite ein konkretes Szenario zu diesen Anforderungen zu liefern, damit da ein besseres Verständnis aufgebaut werden kann.

Bei Herrn Bittersmann mit Verständnis zu rechnen, ist sehr, mMn sogar zu optimistisch. Ich rechne nicht damit, egal ob mit oder ohne Lieferung eines konkreten Szenarios.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Bei Herrn Bittersmann mit Verständnis zu rechnen, ist sehr, mMn sogar zu optimistisch

Argumenten gegenüber bin ich immer aufgeschlossen. Wenn selbst auf Anfrage keine kommen, sondern nur Rumgelaber, dann zeige ich dafür wenig Verständnis, das ist wohl wahr.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Ich kriege die guten Plätze nicht, weil irgendein Dödel die ausgewählt hat, ewig mit seiner Omma telefoniert und am Ende die Plätze doch nicht kauft. Natürlich bin ich dann verärgert.

Kriegst du doch gar nicht mit. Du kriegst nur mit, dass die Plätze weg sind und gehst erstmal davon aus, dass sie verkauft sind. Wenn du später wieder kommst und sie sind wieder frei, freust du dich höchstens.

Warum sollte man jemandem zwischen Auswählen der Plätze und Drücken auf „Tickets kaufen“ mehr als 5 Minuten Zeit geben?

Weil ich mehr Zeit brauche, mich zu entscheiden. Immer.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Ich kriege die guten Plätze nicht, weil irgendein Dödel die ausgewählt hat, ewig mit seiner Omma telefoniert und am Ende die Plätze doch nicht kauft. Natürlich bin ich dann verärgert.

Kriegst du doch gar nicht mit. Du kriegst nur mit, dass die Plätze weg sind und gehst erstmal davon aus, dass sie verkauft sind.

Ich hatte gehofft, das merkt keiner. 😉

Warum sollte man jemandem zwischen Auswählen der Plätze und Drücken auf „Tickets kaufen“ mehr als 5 Minuten Zeit geben?

Weil ich mehr Zeit brauche, mich zu entscheiden. Immer.

Nimm dir die Zeit, die du brauchst. Ich denke nur nicht, dass die Zögerer einen Anspruch darauf haben sollten, die Plätze ewig zu blockieren.

LLAP 🖖

[Gunnar Bittersmann]

@@pl

Wenn der Nutzer nicht innerhalb einer gewissen Zeit auf „Karten kaufen“ drückt, gibt der Server die markierten Plätze wieder frei.

Klingt gut. Dumm wäre jedoch, wenn der Kunde nach Ablauf der "gewissen Zeit" auf Kaufen drückt und eine Überweisung auslöst. Was machste da?

Dasselbe wie wenn beim Kunden gar kein JavaScript läuft:

Der Server prüft nach Abschicken des Formulars die Verfügbarkeit der Plätze. Wenn noch alle gewünschten verfügbar sind, kauft der Kunde diese.

Wenn nicht, erhält der Kunde einen entsprechenden Hinweis und das Formular erneut angezeigt; die noch verfügbaren gewünschten Plätze vorausgewählt, die nicht mehr verfügbaren gewünschten besonders gekennzeichnet.

LLAP 🖖

[roundturn]

Moin

Nein danke. Ich will mich nicht belügen lassen.

Das kann ich voll unterstützen

Ich auch!

Es ist bedauerlich, wie wenig Gedanken sich manche Entwicker immer noch um (perceived) performance machen.

Es ist bedauerlich, wieviele Frontend-Entwickler keine Ahnung von Client-Server-Techniken haben. Die erprobten Methoden werden durch ein paar neue bunte Begriffe nicht ungültig.

Response Code 409
roundturn

[Gunnar Bittersmann]

@@roundturn

Es ist bedauerlich, wie wenig Gedanken sich manche Entwicker immer noch um (perceived) performance machen.

Es ist bedauerlich, wieviele Frontend-Entwickler keine Ahnung von Client-Server-Techniken haben. Die erprobten Methoden werden durch ein paar neue bunte Begriffe nicht ungültig.

Es geht hier nicht um Techniken, sondern zuerst einmal um user experience. Die Technik hat sich dem Ziel unterzuordnen, gute UX zu erreichen.

Da sind wir wohl mal wieder bei dem Punkt, dass Entwicklung designgetrieben, nicht technologiegetrieben sein sollte, wenn was Vernüftiges bei rauskommen soll.

LLAP 🖖

[dedlfix]

Tach!

Da sind wir wohl mal wieder bei dem Punkt, dass Entwicklung designgetrieben, nicht technologiegetrieben sein sollte, wenn was Vernüftiges bei rauskommen soll.

Da sind offensichtlich einige anderer Meinung, wie sich "vernünftig" definiert. Ich kann auch nichts vernünftiges darin erkennen, den Anwender über den wahren Zustand zu belügen. Natürlich ist Warten keine schöne Nutzererfahrung, aber im Nachhinein eine Positiv-Meldung negiert zu bekommen, ist es erst recht nicht. Zumal ja auch noch versteckt werden soll, dass sich im Hintergrund erst noch ein Vorgang abschließen muss, damit das angezeigte OK auch wirklich OK ist, und man so gar nicht sieht, dass sich der Zustand noch ändern könnte.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Natürlich ist Warten keine schöne Nutzererfahrung, aber im Nachhinein eine Positiv-Meldung negiert zu bekommen, ist es erst recht nicht.

Der Punkt hier ist: Es gibt gar keine explizite Positivmeldung, die negiert werden müsste.

Es wird einfach davon ausgegangen, dass alles glattläuft. Falls nicht, kommt eine Fehlermeldung.

| | Optimistic UI | Not-so optimistic UI |---| | Normalfall | Die Übertragung läuft im Hintergrund, der Nutzer wird in seinem Workflow nicht aufgehalten. | Der Nutzer wird in seinem Workflow unterbrochen und muss warten, bis die Übertragung abgeschlossen ist. | Fehlerfall | Bei mit Fehler abgeschlossener bzw. abgebrochener Übertragung bekommt der Nutzer eine Fehlermeldung. | Bei mit Fehler abgeschlossener bzw. abgebrochener Übertragung bekommt der Nutzer eine Fehlermeldung.

Es ist ja nicht so, dass der Nutzer im Fehlerfall die Fehlermeldung beim optimistic UI später bekäme als beim not-so optimistic UI. Es ist einfach so, dass der Nutzer im Normalfall beim optimistic UI nicht aufgehalten wird.

LLAP 🖖

[dedlfix]

Tach!

Es ist ja nicht so, dass der Nutzer im Fehlerfall die Fehlermeldung beim optimistic UI später bekäme als beim not-so optimistic UI. Es ist einfach so, dass der Nutzer im Normalfall beim optimistic UI nicht aufgehalten wird.

Den Vorteil im Normalfall sehe ich auch, aber ich sehe auch einen gravierenden Nachteil im Fehlerfall. Besonders dann, wenn ich bereits weiterarbeite und dann unterbrochen werde, um den auf den Fehler zu reagieren. Oder wenn ich davon ausgehe, dass alles gut ist und nicht mehr mitbekomme, dass da noch eine Fehlermeldung hinterherkommt. Ich würde es lieber begrüßen, die Systeme wirklich schneller zu bekommen, als alternative Fakten aufgetischt zu bekommen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Den Vorteil im Normalfall sehe ich auch, aber ich sehe auch einen gravierenden Nachteil im Fehlerfall. Besonders dann, wenn ich bereits weiterarbeite und dann unterbrochen werde, um den auf den Fehler zu reagieren.

Ja, das kann ein Nachteil sein. Da ist die Abwägung zu treffen: Wie oft tritt der Fehlerfall auf? Gewinnt man zusammengenommen in den 999 Fällen, in denen alles glattläuft, mehr als man in dem einen, wo etwas schiefläuft, verliert? Ich denke: ja.

(Das Verhältnis ist natürlich an den Haaren herbeigezogen. Es kann auch 9999: 1 sein.)

Und dass es relevante Stellen gibt, an denen man nicht optimistisch sein darf (wenn’s bspw. um verbindliche Bestellung/Kauf geht), muss ich nicht mochmal wiederholen?

Ich würde es lieber begrüßen, die Systeme wirklich schneller zu bekommen

Durch optimistic UI wird das System schneller.

als alternative Fakten aufgetischt zu bekommen.

Hier von „belügen“ und „alternativen Fakten“ zu sprechen ist schierer Unsinn.

LLAP 🖖

[Mitleser]

Den Vorteil im Normalfall sehe ich auch, aber ich sehe auch einen gravierenden Nachteil im Fehlerfall. Besonders dann, wenn ich bereits weiterarbeite und dann unterbrochen werde, um den auf den Fehler zu reagieren. Oder wenn ich davon ausgehe, dass alles gut ist und nicht mehr mitbekomme, dass da noch eine Fehlermeldung hinterherkommt. Ich würde es lieber begrüßen, die Systeme wirklich schneller zu bekommen, als alternative Fakten aufgetischt zu bekommen.

+1 Der Gunnar vermengt hier einfach die Dinge. Das "optimistic UI" hat durchaus in der Güterabwägung Ihre Daseinsberechtigung, z.B. wenn ich bei Facebook irgendeine Statusmeldung ausblende. Wenn das schief läuft, dann sehe ich sie halt irgendwann nochmal und blende sie eben nochmals aus.

Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI".

[Gunnar Bittersmann]

@@Mitleser

Der Gunnar vermengt hier einfach die Dinge.

Welche?

Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI".

Warum nicht? Ganz konkret, bitte.

LLAP 🖖

[Mitleser]

Der Gunnar vermengt hier einfach die Dinge. Welche?

Optimistic UI zu pauschal als Mittel der Wahl zu betrachten. Es ist immer eine Güterabwägung, daher mein Beispiel mit dem Ausblenden irgendeines Facebook-Dingens. Die serverseitige Hinterlegung kann auch schiefgehen, trotzdem geht man das Risiko in der Abwägung gerne eine und wirft es sofort aus dem DOM.

Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI". Warum nicht? Ganz konkret, bitte.

Weil in der Güterabwägung der "Frustfall" hier einfach deutlich deftiger ist als bei dem obigen Beispiel. Guck Dir mal die Geschwindigkeit an, mit der Platzreservierungen bei begehrten Events teils für die guten Plätze ablaufen. Da kommt noch so viel mehr dazu, zum Beispiel der Zeitpunkt der Buchung. In der Mittagspause sieht die Welt wohl anders aus, als morgens um 03.00 Uhr.

Es gibt also viele Fälle, wo man bei einer Sitzplatzreservierung durchaus ein Optimistic-UI befürworten könnte. Auf der anderen Seite aber auch eine ganze Menge Fälle, in denen man in der Güterabwägung lieber davon absieht.

Also müsste man eine hochkomplexe Heuristik bauen, um insgesamt die jeweilige "best practice" zu erzielen. Bei einer Sitzplatzreservierung absoluter Overkill, IMHO.

Ich bin durchaus ein Fan von "Optimistic UI", aber in diesem Fall halte ich das Ansinnen für komplett überzogen und unsinnig.

[Gunnar Bittersmann]

@@Mitleser

Optimistic UI zu pauschal als Mittel der Wahl zu betrachten. Es ist immer eine Güterabwägung

Das sagte ich gefühlte dreißig Mal in diesem Thread.

Weil in der Güterabwägung der "Frustfall" hier einfach deutlich deftiger ist als bei dem obigen Beispiel. Guck Dir mal die Geschwindigkeit an, mit der Platzreservierungen bei begehrten Events teils für die guten Plätze ablaufen.

Wir sprechen hier ganz speziell von einem kleinen Theater.

Es gibt also viele Fälle, wo man bei einer Sitzplatzreservierung durchaus ein Optimistic-UI befürworten könnte.

Zum Beispiel bei einem kleinen Theater.

Auf der anderen Seite aber auch eine ganze Menge Fälle, in denen man in der Güterabwägung lieber davon absieht.

Zum Beispiel bei einem Bruce-Springsteen-Konzert. Darum ging es hier aber nicht.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Optimistic UI zu pauschal als Mittel der Wahl zu betrachten. Es ist immer eine Güterabwägung

Das sagte ich gefühlte dreißig Mal in diesem Thread.

Ich sehe das hier wie du, aber es tut mir leid, diese Botschaft ist bei mir definitiv nicht angekommen. Hier kam ein Allgemeinplatz als Botschaft an.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Optimistic UI zu pauschal als Mittel der Wahl zu betrachten. Es ist immer eine Güterabwägung

Das sagte ich gefühlte dreißig Mal in diesem Thread.

Ich sehe das hier wie du, aber es tut mir leid, diese Botschaft ist bei mir definitiv nicht angekommen. Hier kam ein Allgemeinplatz als Botschaft an.

Schon im allerersten Posting dazu verlinkte ich auf zwei in einem älteren Thread.

In dem einen heißt es: „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.“

Anstatt … nimmt man inkauf – mit anderen Worten: Abwägung.

In dem anderen heißt es: „Und die Abwägung kann an verschiedenen Stellen einer Anwendung durchaus unterschiedlich ausfallen.“

Abwägung, explizit.

Dass ich das einmal Gesagte hier nicht ständig wiederhole, kann man mir kaum zum Vorwurf machen, oder?

LLAP 🖖

[Mitleser]

Es gibt also viele Fälle, wo man bei einer Sitzplatzreservierung durchaus ein Optimistic-UI befürworten könnte.

Zum Beispiel bei einem kleinen Theater.

Ich bin nicht sicher, ob ich einem kleinem Theater die Entwicklung der komplexeren und damit teureren sowie fehleranfälligeren Lösung des Optimistic-UI hier empfehlen würde. Dafür ist der Gewinn gegenüber einer klassischen Herangehensweise hier einfach zu gering.

Oder hat das kleine Theater viele "Hardcorereservierer", die wirklich merklich davon profitieren werden?

Das ist ja schon wieder, die Güterabwägung.

[Camping_RIDER]

Aloha ;)

Ich klinke mich mal an der Stelle ganz random ein, um vielleicht einen weiteren Aspekt in die Abwägung mit einzubringen, der bisher unter den Tisch gefallen ist.

Als Vorwort: Ich bin nach der Lektüre vor allem von diesem Artikel (ja, derselbe Autor wie der von Gunnar verlinkte Vortrag, aber die Erklärungen sind weit besser als auf den Folien) durchaus von der Sinnhaftigkeit von "optimistic UI" überzeugt. Wie immer nicht als Allheilmittel, aber in seinen Grenzen.

Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI".

Warum nicht? Ganz konkret, bitte.

Ich möchte mal von der anderen Seite argumentieren. Dass "optimistic ui" da sinnvoll ist, wo ein User eine Eingabe tätigt, die der Server nur entgegennehmen muss, ist wahrscheinlich unstrittig. Klassisches Beispiel für eine solche Eingabe sind die auch im Artikel mehrfach zitierten Like-Buttons der verschiedenen sozialen Netzwerke.

Da kann etwas schiefgehen (zum Beispiel wenn der Client offline ist), aber es ist sehr unwahrscheinlich und handelt sich um den absoluten Fehlerfall. Die Funktion an sich ist so ausgelegt, dass sie selbst keinen Widerspruch erzeugt (Ich kann ein like abgeben wann und wo ich will, eine Plausibilitätsprüfung, die über das übliche wer-bist-du-und-darfst-du-das hinausgeht, findet nicht statt).

Die zentrale Frage für mich ist hier, ob diese Voraussetzungen auch im Fall unseres kleinen Theaters gegeben sind - und falls nein ist die Verwendung von optimistic ui vielleicht doch nochmal mehr Überlegung wert als im Fall der Like-Buttons.

Punkt 1: Wir haben hier an den Server die Anforderung, eine Vorreservierung vorzunehmen. Wir gehen davon aus, dass auch bei ordnungsgemäßem Funktionieren des Systems ein Fehlschlag auftreten kann - quasi by design dieses Features, da wir ja Kollisionen vermeiden müssen. Mir ist bewusst, dass der Fakt, dass es sich um ein kleines Theater handelt und nicht um Bruce Springsteen, dazu führt, dass dieses Argument in der Bedeutung schrumpft, weil die Größe des Systems nicht viele Kollisionen erwarten lässt. Aber dennoch sollten wir uns klarmachen, dass wir hier über ein im Vergleich zum Like-Button relativ gesehen deutlich erhöhtes failure-Risiko sprechen.

Diesen Aspekt kann man abtun wenn man möchte. Es gibt sicher extremere Beispiele, aber ganz grundsätzlich muss man die Größe des failure-Risiko eben in die Abwägung mit einbeziehen. Das mag man mit dem Verweis auf das kleine Theater in diesem Fall auch erfüllt haben. Folgender wiegt meiner Meinung nach ein wenig schwerer:

Punkt 2: Was der Server hier intern tut, ist, eine Vorreservierung vorzunehmen. Bei einem optimistic ui wird das nicht unbedingt klar. So kann der user wenn er auf einen Platz klickt, um diesen für sich auszuwählen, nicht unterscheiden, ob jetzt einfach nur der Platz im Formular angewählt wurde, das erst bei Abschicken auf Kollisionen überprüft wird, oder ob tatsächlich sofort eine Überprüfung auf Kollisionen stattfindet. Vielleicht ist das aber - als Designentscheidung - eine Information, die man dem user zukommen lassen möchte, damit er sich eben nicht extrem beeilen muss, weil seine Plätze noch frei sind. Wenn der User wegen optimistic ui denkt, dass keine Kollisionsprüfung stattfindet, kann es passieren, dass er in Stress gerät, weil er denkt, sich die guten Plätze, die er eben noch anwählen konnte, jetzt auch sichern zu müssen. Wenn man dem user visuell anzeigt, dass eine Interaktion mit dem Server stattfindet kann er sich daraus zusammenreimen, dass er diese eben angewählten Plätze eher nicht verlieren wird, wenn er das Formular nicht sofort nach Auswahl absendet. Mit optimistic ui kann man dem User nicht vermitteln, dass eine temporäre Vorreservierung stattfindet. Das kann durchaus an der Stelle - auch bei einem kleinen Theater - ein Grund sein, auf optimistic ui verzichten zu wollen.

Ein paar weiter Gedanken:

Auch im optimistic ui soll eine failure-Botschaft spätestens nach 2 Sekunden eintreffen. Das bedeutet im Umkehrschluss, dass im not so optimistic ui auch höchstens 2 Sekunden lang der Ladekringel auf dem eben angeklickten Platz zu sehen ist. Dadurch, dass man sich beim Plätze-Aussuchen die gesamte Zeit über auf diese Aufgabe fokussiert fällt das Warten wahrscheinlich weniger ins Gewicht. Aus meiner Warte stellt es sich so dar, dass das Warten auf die Serverantwort vor allem dann eine Belastung darstellt, wenn man sich direkt danach einem anderen Kontext zuwenden möchte - wie beim Like-Button, den man betätigt nachdem man ein Posting gelesen hat und nach dessen Betätigung man sich sofort ohne weiteres Ausharren dem nächsten Posting zuwenden möchte. Da stört ein Ladekringel und erzeugt Warten - wenn man sich sowieso noch ein paar Sekunden am selben Interaktionselement aufhält (z.B. um den Blick nochmal über die Sitzreihen schweifen zu lassen, um sich den ausgewählten Sitzplatz nochmal im Gesamtbild anzusehen) trifft dieser Effekt mMn lang nicht so stark zutage.

Gesetzt den Fall man möchte mehr als einen Sitzplatz reservieren kann optimistic ui auch beim kleinen Theater einen weiteren Nachteil haben: Ich klicke nacheinander auf vier nebeneinanderliegende Sitzplätze, die schalten sofort auf "ausgewählt" um und ich drücke zuversichtlich auf "buchen" ohne die zwei Sekunden abzuwarten, die der Server benötigt um mir zu sagen, dass der dritte von den vier Plätzen eben schon gebucht wurde. Also werde ich (falls das System sich richtig verhält) eine Fehlermeldung bekommen und nochmal zur Auswahl von Plätzen aufgefordert werden. Zu dem Zeitpunkt hab ich aber dann schon (wie CK das ansprach) das Vertrauen ins System verloren, aber dadurch, dass es gar kein Feedback über ein letztliches Okay des Servers gibt, hab ich auch gar keine letztendliche Kontrolle. Das fühlt sich nicht cool an. Um das mit Twitter zu vergleichen: Da geht der Counter erst hoch, wenn der Server mein Like akzeptiert, das Herz wird sofort bei Klick rot. Ich habe also, wenn es mir nicht wichtig ist, den Vorteil von optimistic ui und werde nicht zum Warten verdonnert - und habe gleichzeitig, wenn ich mich, beispielsweise aus Skepsis, zum Warten entscheide, auch ein visuelles Feedback über den definitiven Erfolg. Wenn man also optimistic ui hier an den Sitzplätzen machen möchte, dann bietet es sich an, irgendwo noch eine Möglichkeit einzubauen, die ermöglicht, den definitiven Erfolg der Auswahl zu überwachen und gleichzeitig subtil genug ist, um den User nicht zum Warten zu nötigen.

---

Konkreter Vorschlag:

Bei fetten Ladekringeln je Sitzplatz kann es passieren, dass der User jeden einzelnen Vorreservierungsvorgang abwartet. Das ist nicht sinnvoll. Deshalb würde ich auf jeden Fall auf optimistic ui setzen wollen. Allerdings in Form eines Kompromisses, den ich mir konkret so vorstellen könnte:

Der angewählte Sitzplatz soll sofort bei Klick auf "ausgewählt" umschalten (also sich optimistic verhalten).

Vor dem Button "buchen" gibt es einen Info-Satz, der lautet

Sitzplätze, die schon jetzt für Sie vorreserviert sind: 3 <<buchen>>

Dabei geht der Counter im Info-Satz erst bei tatsächlicher Bestätigung durch den Server nach oben. Der Client wird nicht eingeschränkt und der optische Änderungsvorgang ist so subtil, dass er nur dann zu einem Warten des users führt, wenn dieser spezifisch darauf achtet / Wert legt. Gleichzeitig werden die x möglichen Wartezeiten kumuliert und der user, dessen visueller Fokus während der Platzwahl eben nicht auf dem Info-Satz liegt, wird nicht dazu angehalten nach jeder Auswahl einzeln zu warten, sondern hält frühestens dann inne, wenn sich sein Fokus auf das "buchen" verschiebt und er auf eine Bestätigung aktiv Wert legt.

Ein ähnlicher Effekt würde auch zustande kommen, wenn man statt der Verwendung eines Info-Textes den Buchen-Button zwischen Platzwahl und Bestätigung sperrt (der ja auch nicht im visuellen Fokus ist und die Wartezeiten kumuliert). Davon rate ich aber ab, da gesperrte Buttons auch kein Zeichen einer guten UX sind und mit dem Info-Satz eine sinnvollere Möglichkeit besteht, die die Seite nicht unresponsiv macht.

Grüße,

RIDER

[roundturn]

Hallo Gunnar,

Du hast die falschen Paketgrößen im Auge. Außerdem solltest Du klassisches HTML-Client-Server-Verhalten und das Arbeiten mit XHR auseinanderhalten.

(1.) Beim klassischen Formular-POST würde man vermutlich erst alle Plätze markieren (z. B. mit Checkboxen) und dann den Form-Post komplett absenden. Während das Formular läuft und verarbeitet wird, hat der Client keinerlei Kontrolle über den Ausgang seines Posts. Er muss auf die Response warten. Er weiß noch nicht einmal, ob sein Begehren überhaupt beim Server angekommen ist.

(2.) Beim Arbeiten mit XHR würde man jeden einzelnen Teilwunsch per XHR absenden und markieren, dass noch eine Antwort aussteht. Wenn dann innerhalb von Millisekunden, oder auch erst nach Sekunden eine Antwort kommt, wird der neue Zustand im Client markiert. Der kann in diesem Falle "vorreserviert" oder "abgelehnt" (vielleicht sogar mit Toolbox) lauten. In der Zwischenzeit kann der User aber bereits mit den weiteren Plätzen weiterarbeiten. Die Übermittlung findet ja asynchron statt. Und es besteht kein Grund dafür, ein großes Requestpaket zu schnüren, wenn man die Aufgabe auch mit mehreren kleineren erledigen kann.

Und wenn man es so (2.) macht, braucht der User vermutlich auch nicht mehr als 5 Minuten Offenzeit zum abschließenden Buchen - er hat ja seine Personendaten bereits vorher eingegeben, weil erfahrungsgemäß nur Leute, die dazu bereit sind, auch wirklich buchen wollen. Die anderen wollen nur spielen.

Ich bin gespannt, welche Gründe Du nun vorkramen wirst...

roundturn

[roundturn]

Moin,

der Herr Bittersmann fährt hier scheinbar nur mit "UDP" und nicht mit "TCP". Damit hat er eindeutig das falsche Protokoll für die Aufgabe gewählt. Zur Sicherheit für die Wörtlichnehmer: das ist eine Analogie!

Request Method POST
roundturn

[Christian Kruse]

Hallo chorn,

und auch unbedingt das hier lesen:

Nein danke. Ich will mich nicht belügen lassen.

Nene, das sehe ich hier anders. Hier kann man durchaus optimistisch arbeiten, da sehe ich keine Probleme.

LG,
CK

[Robert R.]

ich würde jede Reservierung sofort einzeln per XHR ans Backend weitergeben (per POST). Wenn der Status 200 zurückkommt, dann erst im Frontend auf reserviert umschalten.

Nein; Rückmeldung im Frontend sofort. Optimistic user interface ☞ Folien 54 bis 64

Du hast offensichtlich den Status "XHR läuft" übersehen? Der wird mit dem Klick auf den Sitzplatz im Frontend angezeigt und der Request abgesendet.

Da in einer Multiuserumgebung, in der alle XHRs auf dieselbe Datenquelle angewiesen sind, schon mal eine Wartezeit auftreten kann, ist dieser Zwischenstatus ratsam.

LG
Robert

[Gunnar Bittersmann]

@@Robert R.

Nein; Rückmeldung im Frontend sofort. Optimistic user interface ☞ Folien 54 bis 64

Du hast offensichtlich den Status "XHR läuft" übersehen? Der wird mit dem Klick auf den Sitzplatz im Frontend angezeigt und der Request abgesendet.

Nein. Der ist auch auf Folie 59 kaum übersehbar.

Da in einer Multiuserumgebung, in der alle XHRs auf dieselbe Datenquelle angewiesen sind, schon mal eine Wartezeit auftreten kann, ist dieser Zwischenstatus ratsam.

Nicht wirklich. Nicht hier.

Ratsam wäre das bei einem großen Veranstalter, wo sich viele Nutzer gleichzeitig auf der Plattform befinden und Karten kaufen. Davon ist bei einem „kleinen Theater“ [OP] nicht auszugehen.

LLAP 🖖

[Robert B.]

Moin ReiniG,

erst einmal ein paar Anmerkungen zu deinem "View":

$counter = 0;
$file = 'seats.txt';
$line = file($file);

Du gehst im Folgenden davon aus, dass deine Datei exakt 14 Zeilen hat. Vielleicht möchtest du lieber über count($line) iterieren?

for($i=0;$i < 14;$i++){ 
	$counter = $counter + 1;

Wie du eine Zeile darüber siehst, geht das auch kürzer: ++$count.

	$string = $line[$i];

Ich würde auch gleich noch eine weitere Variable anlegen: $status = substr($string, 4, 1). Damit sparst du dir zwei weitere Aufrufe der Funktion im darauf Folgenden if-else.

Anstelle der Bitmaps, die IMHO unkomprimiert sind, würde ich je nach Anwendungsfall eher PNG, JPEG oder SVG verwenden. Dann fehlen da im einfachsten Fall entweder Semikoli oder CSS-Code – auf jeden Fall allerdings jeweils das alt-Attribut des img-Elements! Wobei passende CSS-Klassen für jeden möglichen $status eines Button oder gar eine entsprechend aktivierte SVG-Grafik deutlich besser wären.

	if($counter == 8) { echo "&nbsp &nbsp <img src='R1.bmp' /> &nbsp &nbsp &nbsp &nbsp"; } 
	if(substr($string,4,1) == "f") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_10.bmp' title='0' /> &nbsp &nbsp"; } 
	else if(substr($string,4,1) == "s") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_2.bmp' title='2' /> &nbsp &nbsp"; } 
	else if(substr($string,4,1) == "r") { 
		echo "<img id=$i onclick='myFunction(id)' src='chkBox_1.bmp' title='1' /> &nbsp &nbsp"; } 
	else {
    echo "<img id=$i onclick='myFunction(id)' src='chkBox_3.bmp' title='3' /> &nbsp &nbsp"; }
}
?>

Achso, hat es eigentlich einen Grund, warum der Wert des id-Attributs nicht in Anführungszeichen steht?

Wie bringe ich jetzt die ausgewählten Sitze (aus der client side Javascript Funktion) in den Warenkorb (event. auf eine neue Seite)?

Zu deiner Verarbeitungslogik: Die alert-Aufrufe brauchst du nicht, wenn du vorher mit einer Legende erläuterst, was das jeweilige Symbol bedeutet. Und die nicht verfügbaren Sitze würde ich gar nicht erst klickbar machen. Apropos klickbar: Ich denke, dass du in deinem Anwendungsfall wirklich lieber gestylte Buttons statt Bilder haben möchtest. Wenn du das ganze noch in ein Formular steckst, können auch Nutzer ohne JavaScript bei dir buchen.

Auf deinem Server brauchst du dann natürlich noch ein PHP-Programm, das die Formulardaten entgegen nimmt.

Viele Grüße
Robert

[dedlfix]

Tach!

Du gehst im Folgenden davon aus, dass deine Datei exakt 14 Zeilen hat. Vielleicht möchtest du lieber über count($line) iterieren?

foreach wäre dann die bessere Variante, wenn man über das gesamte Array laufen möchte. Das spart auch eine zusätzliche Laufvariable. Aber abgesehen davon wird es wohl er wohl davon ausgegangen sein, dass sich die Anzahl der Sitzreihen im Theater nicht verändert. Vielleicht ist das ja auch so. Wenn allerdings die Realität flexibler ist, empfiehlt es sich, die 14 nicht fest ins Programm zu schreiben, sondern die Datendatei für die jeweilige Aufführung anzupassen, und das Programm über alles laufen zu lassen, was da an Inhalt vorhanden ist.

dedlfix.

[Robert B.]

Moin dedlfix,

den Vorschlag foreach wollte ich auch erst machen, bis ich das $i mehrfach im Code gesehen habe.

Viele Grüße
Robert

[dedlfix]

Tach!

den Vorschlag foreach wollte ich auch erst machen, bis ich das $i mehrfach im Code gesehen habe.

Dafür kann man ja den $counter nehmen, der hat denselben Inhalt. Aber der sollte einen sprechenderen Namen bekommen, zum Beispiel $tier.

dedlfix.

[MudGuard]

Hi,

den Vorschlag foreach wollte ich auch erst machen, bis ich das $i mehrfach im Code gesehen habe. Dafür kann man ja den $counter nehmen, der hat denselben Inhalt.

nein, nicht denselben. Zu Beginn der Schleife ist das noch so, aber bereits die erste Anweisung in der Schleife ändert $counter. Trotzdem würde natürlich eins von beiden reichen, an den Stellen, an denen bisher der andere verwendet wird, kann man das ja mit einem + 1 bzw. - 1 versehen.

cu,
Andreas a/k/a MudGuard

[Julius]

Hallo ReiniG,

Robert hat ja bereits auf „Ajax“ hingewiesen, daher verlinke ich einfach mal zwei für dich wahrscheinlich interessante Seiten im Wiki:

1. JavaScript/Ajax Einführung in das Thema
2. JavaScript/XMLHttpRequest Anwendungsbeispiele

Ein paar allgemeine Anmerkungen zu deinem Code:

Verhinderst du in deinem Programm, dass nicht mehr als eine Instanz deines Scripts schreibend auf die Datei mit den Reservierungen zugreifen können? Siehe dazu Verlorenes-Update-Problem (Wikipedia) und die PHP-Funktion flock().

Du baust gerade die Funktionalität eines Formulars mit mehreren Buttons mit anklickbaren Bildern nach. Besser wäre es, gleich ein Formular zu nehmen und dann die Klicks auf die Buttons mit JavaScript auszuwerten. Das HTML dürfte dann so aussehen (und funktioniert im Gegensatz zur bisherigen Lösung auch ohne JavaScript):

<form>
  <button name="reservieren" value="123">
    <img src="grafik.png" alt="Reservieren">
  </button>
  <button>
    ...
  </button>
</form>

Beachte bitte auch den sinnvollen Alternativ-Text im alt-Attribut des Bildes – so ist das Formular auch für Nicht-Sehende (woher sollen die sonst wissen, was die Grafik und damit der Button bedeutet?) und auch dann, wenn das Bild (aus welchen Gründen auch immer) nicht geladen werden kann, bedienbar, weil dann der Alternativtext angezeigt wird.

Außerdem solltest du besser nicht mit dem onclick-Attribut arbeiten, es ist wesentlich besser, via addEventListener() auf Ereignisse zu lauschen.

Nachtrag: Robert war schneller :-)

Gruß
Julius

[Gunnar Bittersmann]

@@ReiniG

  echo "<img id=$i onclick='myFunction(id)' src='chkBox_10.bmp' title='0' /> &nbsp &nbsp"; } 

Fehler: alt-Text fehlt.

Fehler: img ist kein interaktives Element; man kann da nicht draufclicken. „man“ im Sinne von „alle“. Einige können das, andere nicht, bspw. diejenigen nicht, die mit der Tastatur navigieren.

Es ist falsch, darauf ein click-Event zu registrieren. Nicht interaktive Elemente dürfen nicht das Ziel von click-Events sein.

Wenn du etwas zum draufclicken haben willst, willst du i.d.R. buttons.

Hier eher nicht. Du willst Checkboxen.

Die schon belegten Plätze machst du für den Nuzter nicht wählbar durch <input type="checkbox" disabled=""/>.

Die Checkboxen packst du in ein Formular; (spätestens) beim Abschicken des Formulars werden die vom Nutzer ausgewählten Plätze zum Server übertragen.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Du willst Checkboxen.

Die du auch verstecken kannst. Die zugehörigen Labels sind clickbar und auch tastaurbedienbar und können auch den Status der jeweiligen Checkboxen anzeigen.

Die schon belegten Plätze machst du für den Nuzter nicht wählbar durch <input type="checkbox" disabled=""/>.

Das kann dann beispielsweise so aussehen.

LLAP 🖖

[Robert R.]

Guten Abend,

so ganz nebenbei gefragt: wieviele XMLHTTPRequests gehen denn aktuell parallel?

Google bringt mir dazu etliche Posts aus 2009 bis 2011, meistens von ehemaligen Selfern (z. B. Globe). Aber 2011 ist ja nun schon etwas her und Firefox 4 auch ;-)

CU
Robert R.

[Camping_RIDER]

Aloha ;)

so ganz nebenbei gefragt: wieviele XMLHTTPRequests gehen denn aktuell parallel?

Die Frage verstehe ich jetzt nicht wirklich. Jeder XMLHttpRequest kann genau eine Anfrage parallel ausführen. (Also nix mit parallel.)

Meiner naiven Auffassung nach ist die Anzahl der XMLHttpRequests demnach nur dadurch beschränkt, wie viele solcher Objekte gleichzeitig erstellt und im Speicher gehalten werden können - so wie jede Menge von Javascript-Objekten irgendwann ein Ende am Ende der Leistungsfähigkeit findet.

Eine konzeptionelle Beschränkung wäre mir da nicht bekannt.

Grüße,

RIDER

[Robert R.]

Hallo,

so ganz nebenbei gefragt: wieviele XMLHTTPRequests gehen denn aktuell parallel?

Die Frage verstehe ich jetzt nicht wirklich. Jeder XMLHttpRequest kann genau eine Anfrage parallel ausführen. (Also nix mit parallel.)

Schade. Es gibt dazu sogar was im Archiv, aber das ist auch schon acht Jahre alt.

LG
RR

[Camping_RIDER]

Aloha ;)

so ganz nebenbei gefragt: wieviele XMLHTTPRequests gehen denn aktuell parallel?

Die Frage verstehe ich jetzt nicht wirklich. Jeder XMLHttpRequest kann genau eine Anfrage parallel ausführen. (Also nix mit parallel.)

Schade. Es gibt dazu sogar was im Archiv, aber das ist auch schon acht Jahre alt.

Auch dort gibt es keine parallelen Anfragen innerhalb eines XHR-Objekts.

Die Anfragen werden zwar zeitlich parallel ausgeführt, es hat aber jede Anfrage ihr eigenes Objekt (und damit gelten nur die von mir genannten Constraints).

Grüße,

RIDER

[Robert R.]

Hallo,

so ganz nebenbei gefragt: wieviele XMLHTTPRequests gehen denn aktuell parallel?

Schade. Es gibt dazu sogar was im Archiv, aber das ist auch schon acht Jahre alt.

Auch dort gibt es keine parallelen Anfragen innerhalb eines XHR-Objekts.

Lies bitte nochmal genauer, was ich gefragt habe.
In seiner ausführlicheren Untersuchung hatte Globe damals herausgefunden, dass die Browser da noch nicht mitspielen. Von ein bis max. sechs parallelen XHRs war wohl allses dabei.

Ich suche nun eine neuere Übersicht zum Thema.

LG
Robert

[Camping_RIDER]

Aloha ;)

In seiner ausführlicheren Untersuchung hatte Globe damals herausgefunden, dass die Browser da noch nicht mitspielen. Von ein bis max. sechs parallelen XHRs war wohl allses dabei.

Im aktuellen Chrome sind es meinem Test nach 6, was nach dem was Globe schrieb ja auch der HTTP-Obergrenze für gleichzeitige Requests entspricht.

Grüße,

RIDER

[TS]

Hello,

ich habe in den letzten Tagen hier das Thema "Buchungssystem" aus diversen Threads zusammengestragen und als interessant für das Wiki angenommen, auch unter dem Aspekt "AJAX & Fallback". Ich bastele ja immer noch an einem Artikel zum Thema "Nachladen mit AJAX". Jetzt bin ich mir nicht mehr sicher, welche Aufgabe komplizierter ist.

Jedenfalls kommen doch etliche neue Detailprobleme auf mich zu:

• HTML: Definituion benutzerdefinierter Attribute
• CSS: Auswertung benutzerdefinierte Attribute
• CSS: Styling von Checkboxen
• Programmiertechnik: Buchungsalgorithmus => Stages
• Datenbank: Modellierung
• Integrität: Concurrent Requests, Relations, Constraints
• und weitere
• maximale Anzahl von parallelen Requests auf eine Domain
• maximale Anzahl von parallelen XmlHttpRequests auf eine Domain

In seiner ausführlicheren Untersuchung hatte Globe damals herausgefunden, dass die Browser da noch nicht mitspielen. Von ein bis max. sechs parallelen XHRs war wohl allses dabei.

Im aktuellen Chrome sind es meinem Test nach 6, was nach dem was Globe schrieb ja auch der HTTP-Obergrenze für gleichzeitige Requests entspricht.

Kannst Du bitte deine Untersuchung etwas genauer spezifizieren?

Im aktulellen Firefox unter WIN-8.1 sind jedenfalls 900 parallele Requests der Default.

da kann ich mir nicht vorstellen, dass nur sechs XmlHttpRequests gleichzeitig gehen können!

Ich bitte hier mal ALLE, neuere Erkenntnisse beizusteuern.

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Im aktuellen Chrome sind es meinem Test nach 6, was nach dem was Globe schrieb ja auch der HTTP-Obergrenze für gleichzeitige Requests entspricht.

Kannst Du bitte deine Untersuchung etwas genauer spezifizieren?

Klar. Das Fiddle hatte ich ja bereits verlinkt; dort werden 100 XHRs abgesetzt. Der Netzwerk-Tab in den Chrome-Entwicklerwerkzeugen zeigt, dass nur je 6 davon tatsächlich parallel bearbeitet werden:

Bei den ersten 12 Requests sieht man ganz deutlich die 6er-Pakete, die quasi gleichzeitig losgeschickt werden, während zu den nachfolgenden Requests ein deutlicher Abstand zu sehen ist (d.h. es werden nicht mehr als die 6 Requests gleichzeitig versendet, die anderen müssen die Antworten der ersten abwarten).

Im weiteren Verlauf der Requests "verschmiert" dieses Bild ein wenig, da die Requests unterschiedlich lange für eine Antwort brauchen und dementsprechend einzelne Requests schon losgeschickt werden, so dass sich kein so schönes Block-Bild mehr ergibt.

Im aktulellen Firefox unter WIN-8.1 sind jedenfalls 900 parallele Requests der Default.

da kann ich mir nicht vorstellen, dass nur sechs XmlHttpRequests gleichzeitig gehen können!

In meinem aktuellen Firefox meine ich auf die gleiche Art und Weise ein Muster mit je 9 XHRs entdecken zu können, da ist die Anzeige aber nicht so eindeutig interpretierbar wie in Chrome.

Grüße,

RIDER

[TS]

Hello,

Im aktuellen Chrome sind es meinem Test nach 6, was nach dem was Globe schrieb ja auch der HTTP-Obergrenze für gleichzeitige Requests entspricht.

Kannst Du bitte deine Untersuchung etwas genauer spezifizieren?

[...]

Schon mal danke für deine Mühe.
Es scheint also, dass man auf jeden Fall 6 aktive XHRs gleichzeitig haben kann?

Dann ist zumindest mein Bemühen um ein Buchungsmodul für PHP + AJAX nicht sinnlos.

Ich kämpfe gerade noch gegen die Frage, wie man :checked und :disabled gleichzeitig abfragen kann per CSS als Selektor für eine Checkbox

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Ich kämpfe gerade noch gegen die Frage, wie man :checked und :disabled gleichzeitig abfragen kann per CSS als Selektor für eine Checkbox

input[type=checkbox]:checked:disabled? (Pen)

Grüße,

RIDER

[TS]

Hello,

Ich kämpfe gerade noch gegen die Frage, wie man :checked und :disabled gleichzeitig abfragen kann per CSS als Selektor für eine Checkbox

input[type=checkbox]:checked:disabled? (Pen)

Tut's leider nicht. Kann aber auch am Browser liegen.

Ich habe als Desktop ja nur ein Museum. Ist aber zum Entwickeln gar nicht so blöd, habe ich festgestellt. Anders herum ist es lästiger. Wenn man auf der neuesten Plattform entwickelt und dann später die Praxis sieht, muss man meistens wieder irgendwelche Dinge zurücknehmen.

Liebe Grüße
Tom S.

[Gunnar Bittersmann]

@@TS

Ich habe als Desktop ja nur ein Museum. Ist aber zum Entwickeln gar nicht so blöd, habe ich festgestellt. Anders herum ist es lästiger. Wenn man auf der neuesten Plattform entwickelt und dann später die Praxis sieht, muss man meistens wieder irgendwelche Dinge zurücknehmen.

Nein. Einfach nur nein.

Progressive enhancment.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Ich kämpfe gerade noch gegen die Frage, wie man :checked und :disabled gleichzeitig abfragen kann per CSS als Selektor für eine Checkbox

input[type=checkbox]:checked:disabled? (Pen)

Tut's leider nicht. Kann aber auch am Browser liegen.

Die aktuellen Versionen von Chrome und Firefox tun's, und sogar der IE 11 tuts. Was läuft bei dir denn für ein Browser?

Ich habe als Desktop ja nur ein Museum.

Und inwiefern ist es auf einem Museum nicht möglich, einen aktuellen Browser zu installieren?

Ist aber zum Entwickeln gar nicht so blöd, habe ich festgestellt. Anders herum ist es lästiger. Wenn man auf der neuesten Plattform entwickelt und dann später die Praxis sieht, muss man meistens wieder irgendwelche Dinge zurücknehmen.

Ich würde mich nicht selber in meinen Möglichkeiten beschneiden wollen - zumal ja schon mehrfach ausdrücklich gesagt wurde, dass die Rücksichtnahme auf veraltete Browser durchaus in den meisten Fällen eher nur zweifelhaft sinnvoll ist.

Dazu kommt, was Gunnar richtigerweise angemerkt hat.

Und gerade bei der heutigen Geschwindigkeit, mit der neue technologische Mittel dazukommen würde ich mich bei einem Projekt zum Üben mit den aktuellen Möglichkeiten auseinandersetzen wollen - was bringt es, Konzepte zu lernen, die schon heute veraltet sind?

Ist natürlich komplett dein Ding, aber verstehen tu ichs eben nicht 😉

Grüße,

RIDER