Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mozilla.browser > #52808 > unrolled thread

Caching usw.

Back to article view | Back to de.comm.software.mozilla.browser

Contents

  Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-21 14:27 +0200
    Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-22 14:08 +0200
    Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-22 14:28 +0200
      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-24 07:44 +0200
        Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 01:51 +0200
        Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 01:53 +0200
          Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-27 05:38 +0200
            Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 20:54 +0200
              Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-02 09:01 +0200
                Re: Caching usw. usenetf2018.fwnsp@spamgourmet.com (Friedhelm Waitzmann) - 2018-05-02 14:42 +0000
                  Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-02 19:25 +0200
                    Re: Caching usw. Heiko Rost <heiko.rost@gmx.de> - 2018-05-02 20:03 +0200
                      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-03 09:43 +0200
                    Re: Caching usw. usenetf2018.fwnsp@spamgourmet.com (Friedhelm Waitzmann) - 2018-05-05 22:15 +0000
                    Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-12 23:13 +0200
                      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-13 13:47 +0200
                Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-12 23:09 +0200
                  Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-13 13:56 +0200
                    Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 15:03 +0200
                      Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-13 15:59 +0200
                        Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 17:35 +0200
                          Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-13 18:55 +0200
                            Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 20:00 +0200
                              Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-15 00:43 +0200
                              Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-17 07:50 +0200
                                Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-17 12:30 +0200
                                  Re: Caching usw. Erwin Penn <penn.er@unterderbruecke.de> - 2018-05-17 13:24 +0200
                                  Re: Caching usw. Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2018-05-17 17:16 +0200
                                    Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-06-10 13:00 +0200
                            Re: Caching usw. Heiko Rost <heiko.rost@gmx.de> - 2018-05-13 20:17 +0200

Page 1 of 2  [1] 2  Next page →

#52808 — Caching usw.

Ich betreue die Homepage eines kleinen Restaurants, das recht komische 
Öffnungszeiten hat: vom Ostermontag bis 3.10. eines Jahres hat es an 
Samstagen, Sonntagen und Feiertagen von 14.00 bis 18.00 Uhr geöffnet. 
Die Startseite ist nun so gestaltet, dass immer ein entsprechender 
Hinweis erfolgt. Z.B.
- außerhalb der "Saison":
Ab Ostermontag, den xx.xx.xx sind wir wieder für Sie da
- in der Saison mo-fr:
Heute geschlossen. Wir öffnen wieder am Samstag um 14.00
- an Samstagen, Sonntagen, Feiertagen vor 14.00:
Wir öffnen heute um 14.00 Uhr
- dann ab 14.00:
Wir haben geöffnet
usw.usf.

Es geht mir nun um das Caching. Was passiert, wenn ich in den Meta-Tags 
no-caching angebe, wird immer komplett neu geladen. Und wenn ich das 
nicht mache? Wird dann die Seite neu geladen und die Bilder werden gecacht?

Und wie ist das mit expires? Was passiert, wenn der angegebene Zeitpunkt 
erreicht wird?

Letztlich: refresh. Lädt FF die komplette Seite nach den angegebenen 
Sekunden neu? Oder sollte ich doch lieber ein Script einbauen?

Ich kenne die Definitionen, bin mir aber nicht sicher ob ich das richtig 
interpretiere und ob das wirklich alles so erfolgt.

Lothar Geyer

[toc] | [next] | [standalone]

#52809

Am 21.04.2018 um 14:27 schrieb Lothar Geyer:
> ...
> Letztlich: refresh. Lädt FF die komplette Seite nach den angegebenen 
> Sekunden neu? Oder sollte ich doch lieber ein Script einbauen?

also das mit dem refresh habe ich nun ausprobiert. Funktioniert. Ob mit 
oder ohne caching weiß ich noch nicht. Aber ich brauche nun nur mein 
PHP-Script etwas umbauen ...

Noch einen schönen Sonntag.
Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52811

Lothar Geyer:

[...]
> Es geht mir nun um das Caching. Was passiert, wenn ich in den Meta-Tags 
> no-caching angebe, wird immer komplett neu geladen. Und wenn ich das 
> nicht mache? Wird dann die Seite neu geladen und die Bilder werden gecacht?

Nur die Seite, da die Bilder ja eigene HTTP-Header für Caching und
Expires haben.

> Und wie ist das mit expires? Was passiert, wenn der angegebene Zeitpunkt 
> erreicht wird?

Der Browser betrachtet die betroffene Ressource als nicht mehr aktuell
und wird sie vom Server neu laden.

> Letztlich: refresh. Lädt FF die komplette Seite nach den angegebenen 
> Sekunden neu? Oder sollte ich doch lieber ein Script einbauen?

Du meinst wohl <<meta http-equiv="refresh" ...>.

Dabei lädt der Browser selber die Seite nach der angegebenen Zeit neu.
Das ist unschön, da der Nutzer sowas nicht kontrollieren kann und die
"Zurück"-Taste im Browser faktisch ausser Funktion gesetzt wird.

Wenn Du sicherstellen willst, dass Besucher immer die aktuelle Version
der Seite zu sehen bekommen, setze die expires-Header so, dass sie
jeweils bis 23:59 des aktuellen Tages gelten oder alternativ maximal 8
oder 12 Stunden - das wird wohl auch ausreichen.

z.B. bei Apache per .htaccess - Expires-Header für Ablauf nach 8 Stunden
ab Abruf der Seite durch den Besucher:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 8 hours"
</IfModule>

Ggf. muss man noch prüfen, ob das Expires-Modul verfügbar ist und es
ggf. aktivieren.



-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52818

Guten Morgen Arno,

Am 22.04.2018 um 14:28 schrieb Arno Welzel:
> Lothar Geyer:
> 
> [...]
>> Es geht mir nun um das Caching. Was passiert, wenn ich in den Meta-Tags
>> no-caching angebe, wird immer komplett neu geladen. Und wenn ich das
>> nicht mache? Wird dann die Seite neu geladen und die Bilder werden gecacht?
> 
> Nur die Seite, da die Bilder ja eigene HTTP-Header für Caching und
> Expires haben.

kann ich das cachen für Bilder auch steuern? Falls ja: wie?

>> Und wie ist das mit expires? Was passiert, wenn der angegebene Zeitpunkt
>> erreicht wird?
> 
> Der Browser betrachtet die betroffene Ressource als nicht mehr aktuell
> und wird sie vom Server neu laden.

Das macht also was ähnliches wie das refresh.

>> Letztlich: refresh. Lädt FF die komplette Seite nach den angegebenen
>> Sekunden neu? Oder sollte ich doch lieber ein Script einbauen?
> 
> Du meinst wohl <<meta http-equiv="refresh" ...>.

ja

> Dabei lädt der Browser selber die Seite nach der angegebenen Zeit neu.
> Das ist unschön, da der Nutzer sowas nicht kontrollieren kann und die
> "Zurück"-Taste im Browser faktisch ausser Funktion gesetzt wird.

Wenn Du meinen ersten Post liest, wann welche Inhalte gezeigt werden: 
die "Zurück"-Taste ist uninteressant. Das was vor einem Refresh war, ist 
vorbei und soll auch nicht mehr gezeigt werden.

> Wenn Du sicherstellen willst, dass Besucher immer die aktuelle Version
> der Seite zu sehen bekommen, setze die expires-Header so, dass sie
> jeweils bis 23:59 des aktuellen Tages gelten oder alternativ maximal 8
> oder 12 Stunden - das wird wohl auch ausreichen.

An Samstagen/Sonntagen ändert sich der Inhalt auf jeden Fall um 0:00 
Uhr, 14:00 und 18:00 Uhr. Von Montag 0:00 Uhr bis Freitag 24:00 bleibt 
alles gleich (sofern kein Feiertag in der Woche ist).

> z.B. bei Apache per .htaccess - Expires-Header für Ablauf nach 8 Stunden
> ab Abruf der Seite durch den Besucher:
> 
> <IfModule mod_expires.c>
> ExpiresActive On
> ExpiresByType text/html "access plus 8 hours"
> </IfModule>

Wie soll ich das machen? Die .htaccess-Datei per PHP-Script ändern? Da 
müsste ich ja einen eigenen Prozess auf dem Server starten. Denn die "8 
hours" sind ja zu jedem Zeitpunkt anders.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52825

Lothar Geyer:

> Guten Morgen Arno,
> 
> Am 22.04.2018 um 14:28 schrieb Arno Welzel:
>> Lothar Geyer:
>>
>> [...]
>>> Es geht mir nun um das Caching. Was passiert, wenn ich in den Meta-Tags
>>> no-caching angebe, wird immer komplett neu geladen. Und wenn ich das
>>> nicht mache? Wird dann die Seite neu geladen und die Bilder werden gecacht?
>>
>> Nur die Seite, da die Bilder ja eigene HTTP-Header für Caching und
>> Expires haben.
> 
> kann ich das cachen für Bilder auch steuern? Falls ja: wie?

Bei Apache z.B. mit folgenden Regeln in .htaccess - hier für PNG und
JPEG jeweils Caching für eine Woche ab dem Zeitpunkt, wo die Bilder vom
Besucher abgerufen werden:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
</IfModule>

Genaueres dazu siehe:
<http://httpd.apache.org/docs/current/mod/mod_expires.html>

>>> Und wie ist das mit expires? Was passiert, wenn der angegebene Zeitpunkt
>>> erreicht wird?
>>
>> Der Browser betrachtet die betroffene Ressource als nicht mehr aktuell
>> und wird sie vom Server neu laden.
> 
> Das macht also was ähnliches wie das refresh.

Ja, aber eben nicht automatisch, sondern nur dann, wenn die URL auch
explizit geladen werden soll. Die Expire-Angabe führt nicht dazu, dass
die URL zum angegebenen Zeitpunkt neu geladen wird, sondern nur, dass
der Browser den Cache ab diesem Zeitpunkt nicht mehr als gültig ansieht
und beim nächsten Zugriff neu laden wird.

[...]
>> <IfModule mod_expires.c>
>> ExpiresActive On
>> ExpiresByType text/html "access plus 8 hours"
>> </IfModule>
> 
> Wie soll ich das machen? Die .htaccess-Datei per PHP-Script ändern? Da 

Nein.

> müsste ich ja einen eigenen Prozess auf dem Server starten. Denn die "8 
> hours" sind ja zu jedem Zeitpunkt anders.

Dann musst Du ein PHP-Script schreiben, dass die Expires-Header selber
entsprechend mitsendet und statt einer statischen HTML-Datei das
PHP-Script verlinkten, was den Inhalt mit entsprechenden Expires-Angaben
im HTTP-Header sendet.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52826

Lothar Geyer:

> Guten Morgen Arno,
[...]
>> <IfModule mod_expires.c>
>> ExpiresActive On
>> ExpiresByType text/html "access plus 8 hours"
>> </IfModule>
> 
> Wie soll ich das machen? Die .htaccess-Datei per PHP-Script ändern? Da 
> müsste ich ja einen eigenen Prozess auf dem Server starten. Denn die "8 
> hours" sind ja zu jedem Zeitpunkt anders.

Ergänzung: nein, die 8 Stunden sind immer gleich. Wer die Seite um 23
Uhr aufruft, erhält spätestens um 7 Uhr morgens eine neue Version. Wenn
das nicht ausreicht, dann eben die Zeit kürzer einstellen - z.B. nur 2
Stunden oder nur 1 Stunde, wenn man sichergehen will, dass die Seite bei
jedem Besucher maximal eine Stunde alt ist.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52829

Guten Morgen,

Am 27.04.2018 um 01:53 schrieb Arno Welzel:
> [...]
>>> <IfModule mod_expires.c>
>>> ExpiresActive On
>>> ExpiresByType text/html "access plus 8 hours"
>>> </IfModule>
>>
>> Wie soll ich das machen? Die .htaccess-Datei per PHP-Script ändern? Da
>> müsste ich ja einen eigenen Prozess auf dem Server starten. Denn die "8
>> hours" sind ja zu jedem Zeitpunkt anders.
> 
> Ergänzung: nein, die 8 Stunden sind immer gleich. Wer die Seite um 23
> Uhr aufruft, erhält spätestens um 7 Uhr morgens eine neue Version. Wenn
> das nicht ausreicht, dann eben die Zeit kürzer einstellen - z.B. nur 2
> Stunden oder nur 1 Stunde, wenn man sichergehen will, dass die Seite bei
> jedem Besucher maximal eine Stunde alt ist.

wenn ich keinen fixen Zeitpunkt angeben kann sondern nur eine Differenz, 
ist das klar. Deshalb hatte ich ja gedacht, ich könnte die .htaccess per 
PHP ändern, z.B. alle 5 Minuten.

Aber die Lösung über refresh ist natürlich die bessere. Da kann ich die 
Zeit bis zum Refresh auf die Sekunde genau beim Abruf der Seite einbauen.

Danke Dir für Deine Erklärungen.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52840

Lothar Geyer:

> Guten Morgen,
> 
> Am 27.04.2018 um 01:53 schrieb Arno Welzel:
>> [...]
>>>> <IfModule mod_expires.c>
>>>> ExpiresActive On
>>>> ExpiresByType text/html "access plus 8 hours"
>>>> </IfModule>
>>>
>>> Wie soll ich das machen? Die .htaccess-Datei per PHP-Script ändern? Da
>>> müsste ich ja einen eigenen Prozess auf dem Server starten. Denn die "8
>>> hours" sind ja zu jedem Zeitpunkt anders.
>>
>> Ergänzung: nein, die 8 Stunden sind immer gleich. Wer die Seite um 23
>> Uhr aufruft, erhält spätestens um 7 Uhr morgens eine neue Version. Wenn
>> das nicht ausreicht, dann eben die Zeit kürzer einstellen - z.B. nur 2
>> Stunden oder nur 1 Stunde, wenn man sichergehen will, dass die Seite bei
>> jedem Besucher maximal eine Stunde alt ist.
> 
> wenn ich keinen fixen Zeitpunkt angeben kann sondern nur eine Differenz, 
> ist das klar. Deshalb hatte ich ja gedacht, ich könnte die .htaccess per 
> PHP ändern, z.B. alle 5 Minuten.
> 
> Aber die Lösung über refresh ist natürlich die bessere. Da kann ich die 
> Zeit bis zum Refresh auf die Sekunde genau beim Abruf der Seite einbauen.

Nein, diese Lösung ist nicht besser, weil dann die Seite ohne Aktion des
Benutzers einfach zu irgendeinem Zeitpunkt vom Browser neu geladen wird,
ohne dass der Benutzer versteht, warum. Ich stelle mir gerade vor, wie
ich als Besucher den Text der Seite lese und etwas scrolle und plötzlich
verschwindet alles und lädt neu, weil der Refresh zuschlägt - sowas
würde mich als Benutzer extrem nerven.

Dann doch lieber einfach per PHP einen Expire-Header senden, der immer
exakt um 23:59 des aktuellen Tages gesetzt ist.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52896

Hallo Arno,

Am 27.04.2018 um 20:54 schrieb Arno Welzel:
> Nein, diese Lösung ist nicht besser, weil dann die Seite ohne Aktion des
> Benutzers einfach zu irgendeinem Zeitpunkt vom Browser neu geladen wird,
> ohne dass der Benutzer versteht, warum. Ich stelle mir gerade vor, wie
> ich als Besucher den Text der Seite lese und etwas scrolle und plötzlich
> verschwindet alles und lädt neu, weil der Refresh zuschlägt - sowas
> würde mich als Benutzer extrem nerven.

genau das ist aber der Sinn. Der Unterschied machts ja aus. Vor 14.00 
Uhr wird angezeigt:
"Wir haben heute von 14.00 bis 18.00 Uhr geöffnet"
Und danach:
"Wir haben geöffnet"
Der Rest der Seite ist identisch.
Und um 18.00 Uhr wird nachgeladen
"Wir haben geschlossen. Wir öffnen wieder am ..."

> Dann doch lieber einfach per PHP einen Expire-Header senden, der immer
> exakt um 23:59 des aktuellen Tages gesetzt ist.

Das bringts nicht. Der Leser soll ja immer den aktuellen Zustand sehen.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52902

Lothar Geyer:
>Am 27.04.2018 um 20:54 schrieb Arno Welzel:

>Vor 14.00 
>Uhr wird angezeigt:
>"Wir haben heute von 14.00 bis 18.00 Uhr geöffnet"
>Und danach:
>"Wir haben geöffnet"
>Der Rest der Seite ist identisch.
>Und um 18.00 Uhr wird nachgeladen
>"Wir haben geschlossen. Wir öffnen wieder am ..."

Statt die Benutzer zu gängeln – »Wann der aktuelle Zustand
nachgeladen wird, bestimmen wir!« – informiere sie lieber
umfassend, indem Du zum aktuellen Zustand dazuschreibst, von wann
der ist, und den gesamten Öffnungszeitenstundenplan.  Dann kann
jeder Leser selbst beurteilen, ob er eine Aktualisierung will
oder nicht.


Friedhelm

[toc] | [prev] | [next] | [standalone]

#52911

Hallo Friedhelm,

Am 02.05.2018 um 16:42 schrieb Friedhelm Waitzmann:
> Statt die Benutzer zu gängeln – »Wann der aktuelle Zustand
> nachgeladen wird, bestimmen wir!« – informiere sie lieber

der aktuelle Zustand ist Geschäftspolitik. Sa/So/Feiertag 14.00 bis 
18.00 Uhr. Das ist kein "Gängeln".

> umfassend, indem Du zum aktuellen Zustand dazuschreibst, von wann
> der ist, und den gesamten Öffnungszeitenstundenplan.  Dann kann

Bei mir ist der aktuelle Zustand eben aktuell. Und von wann der ist, 
interessiert keinen. Wenn aber um 15.00 Uhr dort steht: "Wir öffnen um 
14.00 Uhr", muss der Leser manuell neu laden. Viele Kunden sind 
Radfahrer (das Lokal liegt unweit eines sehr frequentierten Radwegs), 
die ihr Smartphone an der Lenkstange befestigt haben.

> jeder Leser selbst beurteilen, ob er eine Aktualisierung will
> oder nicht.

Bei "normalen" Webseiten stimme ich Dir vollkommen zu. Aber diese Seite 
besteht nur aus einem Banner und dem einen Satz. Dazu evtl. drei Bilder 
des aktuellen Kuchen-Angebots. Da gibt's also nicht viel zum Lesen.

Bisher ist die Zustimmung zu dem automatischen Refresh sehr hoch. Es 
gibt sogar Gäste, die rufen die Seite extra 5 Minuten vor 18.00 Uhr ab 
und checken dann: "Jetzt hat er umgeschaltet"

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52912

Lothar Geyer schrieb:

> der aktuelle Zustand ist Geschäftspolitik. Sa/So/Feiertag 14.00 bis 
> 18.00 Uhr. Das ist kein "Gängeln".

Nur als Hinweis und abgesehen von der Frage des Nachladens: Steht das
auch so auf der Seite? Bei der Version mit einem "geöffnet ab..." und
"gerade geöffnet" hat jemand, der freitags eine Tour für den Sonntag
plant, keine Möglichkeit, die Öffnungszeiten zu erfahren.

Gruß Heiko
-- 
Faule Engel taugen weniger als fleißige Teufel.
                                                                   Emil Gött

[toc] | [prev] | [next] | [standalone]

#52920

Hi Heiko,

Am 02.05.2018 um 20:03 schrieb Heiko Rost:
> Nur als Hinweis und abgesehen von der Frage des Nachladens: Steht das
> auch so auf der Seite? Bei der Version mit einem "geöffnet ab..." und
> "gerade geöffnet" hat jemand, der freitags eine Tour für den Sonntag
> plant, keine Möglichkeit, die Öffnungszeiten zu erfahren.

natürlich steht das auf dieser Startseite - genauso wie das Impressum. 
Es sind zwar noch weitere Seiten geplant, aber noch nicht realisiert - 
da wird an den Bildern und dem Text noch gefeilt. Und es soll auch eine 
Kontaktseite geben, auf der man reservieren und vorbestellen kann. Diese 
Seiten sind dann auch statisch - im Gegensatz zur Startseite.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52937

Lothar Geyer:

>Am 02.05.2018 um 16:42 schrieb Friedhelm Waitzmann:
>> Statt die Benutzer zu gängeln – »Wann der aktuelle Zustand
>> nachgeladen wird, bestimmen wir!« – informiere sie lieber

>der aktuelle Zustand ist Geschäftspolitik. Sa/So/Feiertag 14.00 bis 
>18.00 Uhr. Das ist kein "Gängeln".

Doch, das sehe ich durchaus als Gängeln, nämlich ein Beschneiden
der Freiheit, selber zu entscheiden, ob Datenverkehr stattfindet
oder nicht.

>Bei mir ist der aktuelle Zustand eben aktuell. Und von wann der ist, 
>interessiert keinen. Wenn aber um 15.00 Uhr dort steht: "Wir öffnen um 
>14.00 Uhr", muss der Leser manuell neu laden.

Ja.  Das tritt dann auf, wenn ich die Seite vor 14:00 Uhr
aufgerufen habe.  Wenn ich dann um 15:00 Uhr nochmal einen Blick
drauf werfe, ohne neu zu laden, kann ich mich dann schon noch
daran erinnern.

>Viele Kunden sind 
>Radfahrer (das Lokal liegt unweit eines sehr frequentierten Radwegs), 
>die ihr Smartphone an der Lenkstange befestigt haben.

Smartphones also.  Wenn ich mich nicht irre, hat man da eher
teure Tarife.  Ein Website, das für nichts und wieder nichts von
meinem monatlichen Datenvolumen zehrt, bekäme da von mir einen
Malus.

>Bisher ist die Zustimmung zu dem automatischen Refresh sehr hoch. Es 
>gibt sogar Gäste, die rufen die Seite extra 5 Minuten vor 18.00 Uhr ab 
>und checken dann: "Jetzt hat er umgeschaltet"

Das Umschalten zu beobachten, ist also eine Spielerei.  Das
Interesse daran legt sich irgendwann.


Friedhelm

[toc] | [prev] | [next] | [standalone]

#52973

Lothar Geyer:

[...]
> Bei mir ist der aktuelle Zustand eben aktuell. Und von wann der ist, 
> interessiert keinen. Wenn aber um 15.00 Uhr dort steht: "Wir öffnen um 
> 14.00 Uhr", muss der Leser manuell neu laden. Viele Kunden sind 
> Radfahrer (das Lokal liegt unweit eines sehr frequentierten Radwegs), 
> die ihr Smartphone an der Lenkstange befestigt haben.

Deswegen ist es viel sinnvoller eine Liste der Öffnungszeiten
hinzuschreiben. Der Besucher will ja vielleicht auch wissen, wie es z.B.
am nächsten Tag aussieht.

>> jeder Leser selbst beurteilen, ob er eine Aktualisierung will
>> oder nicht.
> 
> Bei "normalen" Webseiten stimme ich Dir vollkommen zu. Aber diese Seite 
> besteht nur aus einem Banner und dem einen Satz. Dazu evtl. drei Bilder 
> des aktuellen Kuchen-Angebots. Da gibt's also nicht viel zum Lesen.

Um so unsinniger ist es, da mit Informationen zu sparen und nicht
einfach die komplette Liste der Öffnungszeiten hinzuschreiben.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52979

Hallo Arno,

Am 12.05.2018 um 23:13 schrieb Arno Welzel:
> [...]
> Um so unsinniger ist es, da mit Informationen zu sparen und nicht
> einfach die komplette Liste der Öffnungszeiten hinzuschreiben.

die Liste der Öffnungszeiten gibt es natürlich, unten auf der Startseite 
und auch auf einer weiteren Seite, auf der noch mehr über das Lokal zu 
lesen ist.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52972

Lothar Geyer:

> Hallo Arno,
> 
> Am 27.04.2018 um 20:54 schrieb Arno Welzel:
>> Nein, diese Lösung ist nicht besser, weil dann die Seite ohne Aktion des
>> Benutzers einfach zu irgendeinem Zeitpunkt vom Browser neu geladen wird,
>> ohne dass der Benutzer versteht, warum. Ich stelle mir gerade vor, wie
>> ich als Besucher den Text der Seite lese und etwas scrolle und plötzlich
>> verschwindet alles und lädt neu, weil der Refresh zuschlägt - sowas
>> würde mich als Benutzer extrem nerven.
> 
> genau das ist aber der Sinn. Der Unterschied machts ja aus. Vor 14.00 
> Uhr wird angezeigt:
> "Wir haben heute von 14.00 bis 18.00 Uhr geöffnet"
> Und danach:
> "Wir haben geöffnet"
> Der Rest der Seite ist identisch.
> Und um 18.00 Uhr wird nachgeladen
> "Wir haben geschlossen. Wir öffnen wieder am ..."

Man könnte die Öffnungszeiten auch einfach als Liste hinschreiben.

>> Dann doch lieber einfach per PHP einen Expire-Header senden, der immer
>> exakt um 23:59 des aktuellen Tages gesetzt ist.
> 
> Das bringts nicht. Der Leser soll ja immer den aktuellen Zustand sehen.

Das ist ja nur dann ein Problem, wenn jemand direkt vor dem Ende der
Öffnungszeit reinschaut und dann den Browser mehrere Stunden offen
stehen lässt, ohne jemals auf eine andere Seite eures Angebotes zu
wechseln. Ist das wirklich ein *reales* Anwendungsszenario? Wie oft sind
Leute deswegen in das Restaurant gekommen, weil sie dachten, es wäre
noch geöffnet, obwohl es schon zu hatte?


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52981

Hi Arno,

Am 12.05.2018 um 23:09 schrieb Arno Welzel:
> [...]
> Man könnte die Öffnungszeiten auch einfach als Liste hinschreiben.

wie schon gerade geantwortet: das gibt es natürlich auch.

> Das ist ja nur dann ein Problem, wenn jemand direkt vor dem Ende der
> Öffnungszeit reinschaut und dann den Browser mehrere Stunden offen
> stehen lässt, ohne jemals auf eine andere Seite eures Angebotes zu
> wechseln. Ist das wirklich ein *reales* Anwendungsszenario? Wie oft sind
> Leute deswegen in das Restaurant gekommen, weil sie dachten, es wäre
> noch geöffnet, obwohl es schon zu hatte?

Der Fall tritt nicht ein. Ich hatte das (glaube ich) schon geschildert.
An allen Tagen vor einem Tag, an dem geöffnet ist:
"Wir haben geschlossen, wieder offen am t.m.y von 14-18.00"
An einem Tag mit Öffnung, vor der Öffnung
"Wir haben heute von 14-1800 geöffnet"
Ab Öffnung:
"Wir haben bis 1800 geöffnet"
Nach Öffnung:
"Wir haben geschlossen. Am d.m.y sind wir ab 1400 wieder für sie da
Am Tag nach der Öffnung (siehe oben):
"Wir haben geschlossen, wieder offen am t.m.y von 14-18.00"

Also ist jeder Zeitraum abgedeckt und der Wechsel der Anzeige erfolgt 
über meta refresh automatisch. Ist ja auch nur interessant, wenn jemand 
den Tab mit der Seite offen lässt. Ansonsten wird je sowieso neu geladen.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52983

Am 13.05.2018 um 13:56 schrieb Lothar Geyer:

> Also ist jeder Zeitraum abgedeckt und der Wechsel der Anzeige erfolgt 
> über meta refresh automatisch. Ist ja auch nur interessant, wenn jemand 
> den Tab mit der Seite offen lässt. Ansonsten wird je sowieso neu geladen.

Ich lese jetzt nicht den ganzen Thread, aber warum über Meta Refresh?
JavaScript dürfte das doch deutlich einfacher machen.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
            - Sei eine Möwe: Scheiss drauf -

[toc] | [prev] | [next] | [standalone]

#52985

Maik Koenig:

> Am 13.05.2018 um 13:56 schrieb Lothar Geyer:
> 
>> Also ist jeder Zeitraum abgedeckt und der Wechsel der Anzeige erfolgt 
>> über meta refresh automatisch. Ist ja auch nur interessant, wenn jemand 
>> den Tab mit der Seite offen lässt. Ansonsten wird je sowieso neu geladen.
> 
> Ich lese jetzt nicht den ganzen Thread, aber warum über Meta Refresh?
> JavaScript dürfte das doch deutlich einfacher machen.

Nö - denn das erfordert JavaScript. Ein Meta Refresh geht auch ohne
JavaScript. Deswegen halte ich es ja für fragwürdig, weil der Benutzer
das automatische Neuladen der Seite nicht verhindern kann.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comm.software.mozilla.browser

csiph-web