Beiträge von Clemens-XS

    Betreffend der Rücksprungproblematik / Orientierung möchte ich noch ergänzen:


    Alle drei von mir beschriebenen Methoden führen letztlich zu einem Rücksprung an den Anfang eines Blog-Layout. Deshalb könnte die Orientierung des Users durch folgende Maßnahme erleichtert werden:

    Auf meiner derzeit noch betriebenen Website habe ich im BlogLayout die Kategoriebeschreibung dazu genutzt, wie bei einem Inhaltsverzeichnis für jeden Beitrag einen längeren Text-Link einzufügen, der zugleich auch wie eine Kurzbeschreibung des Beitrags wirkt.


    Da diese Links ja direkt in den Beitrag springen und somit die URL für den kompletten Beitrag enthalten, müsste darauf auch eine Suchmaschine positiv reagieren.


    Wenn ich aber die Google-Tools bemühe, sind zwar alle meine Seiten korrekt gelistet und zugänglich, sind aber dennoch mit den gewünschten Suchbegriffen in Verbindung mit der Ortsangabe in den Suchergebnissen nicht berücksichtigt, auch nicht in den ersten 100 Ergebnissen.

    Aber lieber setze ich diese Textlinks, damit der Besucher was davon hat, als dass ich den Wert der Suchmaschinen-Ergebnisse über Alles setze.

    Eigentlich wollte ich schon viel weiter mit dem Relaunch meiner neuen Website sein, aber gerade über das Thema Aufmerksamkeitsfokussierung und Usability (auch im Sinne von Orientierung der aktuellen Position innerhalb der Website) mache ich mir am meisten Gedanken. Da inzwischen meine Website von über 2/3 der Besucher mit Mobilgeräten besucht wird, habe ich mich dazu entschlossen, grundsätzlich die Navigation nur noch per Mobile-Menü anzubieten, zumal diese Menü-Art inzwischen für die meisten Besucher vertraut sein dürfte.

    Aus gleichem Grund (überwiegend Mobil-Besucher) bevorzuge ich auf Mobilgeräten ein Layout, bei dem sich der Content fast immer wie ein langes vertikales Band darstellt. Ein Blog-Layout würde also bei z.B. 15 Beiträgen diese nicht auf drei Blogseiten zu je 5 Beiträgen aufteilen, da dann der User auch "horizontal" denken muss. Zudem könnten so auch die Buttons wegfallen, mit denen zwischen den Beiträgen einer Kategorie direkt hin und her navigiert werden kann. Denn dabei kann der Besucher die hierarchische Übersicht über die Gruppierung und Kategorisierung des Content leicht verlieren. – Andererseits würde der Besucher nach Schließen eines Beitrags bei dieser Gestaltung immer an den Anfang des BlogLayout gelangen und nicht zu der Beitrags-Vorschau, von der er gerade ausgegangen ist. Er muss also suchen, was er schon aus der Kategorie gelesen hat und was er als nächstes lesen möchte.


    Hier drei Möglichkeiten der Gestaltung gemäß der vorigen Überlegungen, die ich zurzeit in Erwägung ziehe:


    a) Die bestmögliche Aufmerksamkeitsfokussierung erreiche ich offensichtlich durch die Verwendung von Modalboxen. Da wird alles überlagert und somit alle Ablenkungsmöglichkeiten vom Content vermieden. Zugleich wird der Platz auf dem Display maximal genutzt, da nicht mal mehr das Signet / Logo und die Breadcrumb-Zeile Platz weg nehmen. Auch wenn man den Content-Bereich der Modalbox auf z.B. 80% Höhe beschränkt, damit noch viel Platz für den "Schließen-Button" oder das Hineintippen in den Freiraum bleibt, ergibt sich ein platzmäßiger Vorteil gegenüber allen anderen Lösungen.

    Allerdings entsprichtdas Öffnen einer Modalbox, um einen Beitrag anzuzeigen, nicht der allgemeinen Erfahrung der User mit ihren Surfgewohnheiten und könnte daher auf Ablehnung stoßen.

    Geprüft habe ich allerdings schon verschiedene Ansichten, ob sich eine schon grundsätzliche Darstellung von Content in Modalboxen SEO-ungünstig auswirken könnte: Nein, tut es nicht! Die Links zum Content der Modalboxen müssen aber von Suchmaschinen wie üblich verfolgbar sein.

    Ein weiterer Vorteil von Modalboxen (und der Lösung b = Readmore): Der dahinter liegende Content bleibt stabil und erleichtert nach Schließen der Modalbox die Rückkehr zum Ausgangspunkt und somit die Orientierung innerhalb der gesamten Website, besonders, wenn es so viele Beiträge zu einem Menüpunkt bzw. zu einer Kategorie gibt, dass sie auf mehreren Seiten zu je 5 oder 10 Beitrags-Intros dargestellt werden. Noch ein Vorteil von Modalboxen: Über den Schließen-Button oder Klick / Tippen außerhalb der Box schließt sich diese. Man muss also nicht nach einer Rückspungmöglichkeit suchen (zurück-Button des Browsers oder Maustaste) sondern hat diese immer unbewusst präsent, falls man den evtl. längeren Beitrag nicht zu Ende lesen will.



    Dann habe ich noch zwei weitere Möglichkeiten, wie aus dem Blog-Layout heraus ein Beitrag (von vielen) geöffnet werden kann, nämlich:


    b) die übliche readmore-Methode, die in Joomla eingebaut ist. Hier besteht der Nachteil, dass die evtl. weiterhin eingeblendete Seitenspalte unnötig Ablenkung erzeugen kann und zudem Platz weg nimmt, vor allem, wenn der Beitrag länger ist und mit weiterem Scrollen die Spalte nur noch Leerfläche zeigt.

    Weiterer Nachteil: Ein Rücksprung zur Blogansicht kann nur über das (Mobile)Menü oder die Zurück-Taste des Browsers / Maustaste oder einen zusätzlich in den Beitrag am Ende eingefügten "Zurück-Button" erfolgen.

    Oder man lässt den "Zurück-Button" an einer fixen Position irgendwo am Rand über dem Content schweben. Und das wirkt nicht nur ablenkend, sondern evtl. wie eine Einladung, das Lesen abzubrechen.

    Dieser "Zurück-Button hätte aber den Vorteil, dass der Link in der Blog-Ansicht genau zu dem Beitrags-Intro führen könnte, den der Besucher gerade gelesen hat. (Wie dies technisch umsetzbar ist, weiß ich allerdings zurzeit nicht. Innerhalb eines Beitrags wäre das eine Sprungmarke und ob man solch eine auch in einem BlogLayout setzen kann, weiß ich nicht.)

    Dass ein User die Breadcrumb-Zeile zur "Zurück-Navigation" benutzt, habe ich durch Befragung im Bekanntenkreis noch nicht gehört.


    c) eine Variante davon, bei der z.B. bei einem Template mit Randspalte beim Öffnen des ganzen Beitrags die Randspalte wegfällt und der Beitrag unterhalb von Signet / Logo und Breadcrumb-Zeile in voller Seiten-Breite angezeigt wird. Damit werden Nachteile der "Readmore"-Lösung vermieden. Zudem wird der Vorteil der Aufmerksamkeitsfokussierung größtenteils erreicht – wenn man vom noch vorhandenen Logo / Signet und der Breadcrumb-Zeile mal absieht.. Die Problematik, das Lesen des Beitrags abzubrechen, um dann in die BlogLayout-Ansicht zurück zu springen, ist aber mit der bei "Readmore" identisch.

    Und die Breadcrumb-Zeile zur "Zurück-Navigation" zu benutzen, ist offensichtlich unpopulär / meist unbekannt.


    Aufgrund meiner detaillierten Beschreibung ist das Layout und dessen Funktionalität sicher auch ohne einen aktuellen Link zur Entwicklungs-Website vorstellbar. Denn dort habe ich teilweise Content drin, der noch nicht für die Öffentlichkeit bestimmt ist.


    Nun bin ich sehr gespannt auf Eure Meinungen und evtl. Anregungen dazu!

    Ja, das betrifft auch die anderen Felder zum Ausschluss con CSS und JS von der Komprimierung.


    Oberhalb von "deLuxe"-Komprimierung macht die Positionierung meines MobileMenü Probleme, wohl, weil das Script dann am Ende der Seite geladen wird, die Berechnung der Position aber schon früher erfolgen muss.


    Vielleicht hol ich mir die Lizenz ja doch noch. OK ich setz das mal auf gelöst.

    Doch, Lazy-Loading funktioniert auch in der kostenfreien Version. Aber weder beim LazyLoading noch beim Ausschluss von CSS oder JS-Dateien kann man etwas eintragen.


    Im HTML sieht ein LazyLoading-Bild ungefähr so aus:

    Code
    <p><img class="img-cl cover-cl jch-lazyload" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-src="/images/images/article-lead/975x325_20-06-15_prax-gelb.jpg" alt="Spaßvogel" /><noscript><img class="img-cl cover-cl" src="/images/images/article-lead/975x325_20-06-15_prax-gelb.jpg" alt="Spaßvogel" /></noscript></p>

    Es geht also nicht nur um die Klasse "jch-lazyload" sondern auch darum, dass das normalerweise vom Browser unter src="..." zu findende Bild nun unter "data-src" die URL bzw. den Pfad erhält, wohingegen das ebenfalls vorhandene src="..." jedenfalls nicht zum Bild führt.


    Daran etwas zu verändern, ist sicher nicht leicht (oder unmöglich). :)

    Um lediglich das im Titel genannte Ziel zu erreichen, ist mir die Lizenzierung zu teuer. Auf meiner Site habe ich im Header mein Signet eingefügt und zwar nicht über die Funktion im Template-Backend, sondern platziert über ein dort positioniertes Modul. Folglich habe ich volle Freiheit, hier ausnahmsweise ein Inline-CSS davor zu setzen, um das LazyLoading zu verhindern.

    Meine bisherigen Versuche dazu waren vergeblich. Wie müsste eine CSS-Anweisung aussehen, die wirklich wirksam wird?

    Bin gerade selbst drauf gekommen:

    der erste Pixelwert gibt den Offset des Schatten nach rechts und der zweite den nach unten an. Der dritte Pixelwert gibt den Durchmesser des Blur-Effekt an und der vierte Wert... ?


    In meinem Code ging es dem Erfinder des Code wohl darum, bei einer kleinen Breite des Schattens einen weicheren Verlauf hinzubekommen, indem er zwei Definitionen sich überlagern lässt.


    Da auch noch die gewählte Transparenz und zusätzlich auch die Farbintensität dabei eine Rolle spielt, bleibt nur, das Ganze auszuprobieren.


    Jedenfalls hab ich es geschafft, die weißen Linien zu setzen, ohne Schatten und die erwünschten Schatten haben jetzt einen leicht bläulichen Stich, der auf der eigentlich in warmen Farbtönen gehaltenen Website etwas Geheimnisvolles oder Spannendes geben mag.


    Hier mein Code jetzt:

    Code
    box-shadow:2px 2px 3px 0px rgba(0,0,250,0.15), 3px 3px 6px 0px rgba(0,0,250,0.15);
    border-top: 1px solid #fff;
    border-left: 1px solid #fff;
    border-radius: 6px;

    Danke für deine Unterstützung!

    Ja, ist mir klar und dafür setze ich diese Blocker ja auch selbst in meinen Browsern ein. Denn ich hasse Datensammelei und das ständige Nachladen von Schrott, den ich nicht im Browser haben will, erkenne aber auch an, dass manche Dinge sinnvoll und nötig sein können.


    Bei völliger Blockade kann ich dann allerdings gar keine Besuche mehr auswerten und erkennen, wie attraktiv und interessant meine Website und einzelne Beiträge darauf sind. Das kann es ja auch nicht sein!

    Das Folgende ist für jeden wichtig, der zwei oder mehr Joomla-Websites mit einer einzigen Installation der Analysesoftware Matomo erfassen will. Sehr viele Besucher werden nicht erfasst, wenn man die "SAme-Origin-Policy" vergisst.


    Folgende Situation:

    Die bekannte Analyse-Software Matomo, die ich auf einer eigenen Domain laufen habe, soll natürlich auch für die Analyse meiner anderen Websites genutzt werden. Diese Websites liegen aber auf anderen Domains. Also muss das Script, das auf der zu analysierenden Site liegt, auf die Domain mit Matomo zugreifen können.


    Man kann das Matomo-Script nun als Inline-Script in die template.php einfügen oder aber das Script in eine separate JS-Datei packen und in der template.php includieren. Aber das löst das Problem leider nicht.


    Denn es stehen zwei andere Dinge im Weg:

    1.) auf meiner htaccess habe ich die X-FRame-Options auf "SAMEORIGIN" gesetzt und die X-Permitted-Cross-Domain-Policies auf "none"


    2.) Immer mehr Besucher haben in ihren Browsern PlugIns / Addons installiert, wie uBlockOrigin und uMatrix. Diese verhindern logischer Weise, dass in der geöffneten Webseite Scripte gestartet oder Inhalte heruntergalden werden, die auf einer anderen Domain liegen.


    Die htaccess kann ich ändern und die URL zu meiner Matomo-Domain durch lasse:

    Code
    Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://meine-matomo-domain.de

    und

    Code
    Header set X-Permitted-Cross-Domain-Policies https://meine-matomo-domain.de

    Bei der o.g. Zeile zu X-Permitted... bin ich aber im Zweifel, ob dies im Sinne von CORS eine Ausnahmeregel darstellt oder ob ich zwingend noch Parameter angeben muss. Die Hilfen zur korrekten Syntax sind für mich ziemlich schwer heraus zu finden: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS


    Aber ich überlege gerade auch, dass ich mir den Aufwand betr. CORS in der htaccess sparen kann, wenn ich wüsste, dass trotz CORS Freigabe der Matomo-Domain immer noch uBlockOrigin oder ähnliche PlugIns die Ausführung des Matomo-Script verhindern würden.


    Ich weiß, dass meine Frage hier schon etwas sehr speziell ist und nur indirekt mit Joomla zu tun hat. Da aber die meisten hier sich eine funktionierende Matomo-Analyse wünschen, werden viele ein ähnliches Problem haben. Und so gesehen ist meine Frage im Joomla-Forum vielleicht doch eine gute Idee oder diese Schwierigkeit schon für sich gut lösen können?

    Sorry, die Test-Website ist inhaltlich in einem Zustand, in dem ich den Link nicht geben möchte.

    In deinem Beispiel sehe ich unten eine orange und links weißlich erscheinende Linie am Bildrand. Beim Hover erhält das Bild links, unten und rechts einen Schatten mit Verlauf. Oben bleibt es dabei, dass keine Linie oder Schatten auftritt.

    Ich möchte keinen Hover-Effekt sondern rein statisch, dass nur ein Schatten am linken und unteren Rand der Box erzeugt wird und eine 1px Linie weiß am oberen und linken Rand, wobei dann grundsätzlich links und oben kein Schatten erscheinen darf.

    Was ist an meiner Beschreibung unklar, sodass du ein Beispiel / Link brauchst?

    Aus einem vorhandenen Template habe ich abgeguckt, wie ich einen Schatten erhalte und hab den noch in der Breite, dem Verlauf und der Farbe angepasst:

    Code
        box-shadow:0 4px 4px 0 rgba(0,0,255,0.2),0 4px 6px 0 rgba(0,0,255,0.18);
        border-radius: 6px;
        padding: 0.1em 1em 0.2em 1em;

    Schon bei der Anpassung der Breite der Schatten und Verläufe stellte ich fest, dass ich gar nicht nachvollziehen kann, was welche Werte beeinflussen. Es erscheint mir einfach unklar, obwohl ich z.B. bei W3CSS versucht hatte, mich schlau zu machen. Also schreibe ich lieber, was ich denn bewirken möchte:

    • Die obigen Schattendefinitionen sollen nur einen Schatten nach rechts und unten erzeugen.
    • Ergänzen möchte ich diese Schatten so, dass oben und links ein weißer Rand ohne Verlauf entsteht, so als ob Licht auf einer Kante reflektiert wird.

    Gibt mir bitte jemand einen CSS-Schnippsel dafür?

    Hab den Fehler gefunden: War ne ganz andere Baustelle: JCH Optimize hatte mit seinem LazyLoading zugeschlagen und so das Bild im Header der Seite stark verzögert aufgebaut.

    Und das Matomo-Script wird zurzeit von uBlockOrigin und uMatrix geblockt, egal ob ich es als Inline-Script oder als separate Scriptdatei (wie hier anfangs gefragt) einbinde. Und das liegt evtl. an CORS in der htaccess.


    OT: Wenn ich in der htaccess mittels CORS die externe Verbindung der Website mit dem Matomo-Server zulasse, wird dann dennoch uBlock und uMatrix diese Verbindung blockieren?

    Ich danke dir herzlich, es scheint zu funktionieren. Ich beobachte aber immer noch eine unangenehme Verzögerung, die mit dem Script zusammen hängt. Die Ausführung des Script wird je nach Browser-PlugIn (uBlockOrigin und uBlockMatrix) an der Ausführung gehindert. Dennoch wartet der Browser ca. 1 Sekunde, "ob da noch was kommt".

    Jedenfalls wird das png-Bild, das eigentlich als Header auf meiner Website erscheinen soll, erst nach dieser Zeit dargestellt. In der Konsole von Firefox unter Netzwerkanalyse ist auch deutlich zu sehen, dass das Script blockiert wird und erst nach einer Pause dieses Bild geladen wird, obwohl es doch ziemlich oben im Seitenquelltext geladen wird.

    Ziel war aber für mich, dass auch (und gerade) dieses Bild zusammen mit der ganzen Site geladen wird und das Script wirklich erst ganz zuletzt einen Einfluss haben darf. Deshalb ja "defer".

    Im Seitenquelltext steht das Header-Bild ziemlich weit oben, so wie es ja auch richtig ist. Erstaunlich, warum es dann so spät geladen wird.


    Leider ist die Test-Website inhaltlich in einem Zustand, dass ich sie hier nicht verlinken kann.

    Ich hatte jemanden mit der Anpassung meiner Website beauftragt. Bsis der Site ist das Joomla-Standard-Template Protostar. In dessen index.php hat der Programmierer ziemlich zu Beginn mittels PHP die nötigen Scripte includiert in der Form:

    Code
    JHtml::_('script', 'plyr.min.js', array('version' => 'auto', 'relative' => true));
    JHtml::_('script', 'template.js', array('version' => 'auto', 'relative' => true));
    JHtml::_('script', 'custom.js', array('version' => 'auto', 'relative' => true));
    JHtml::_('script', 'inline-box.js', array('version' => 'auto', 'relative' => true));

    Nun möchte ich ein weiteres Script anfügen, mit dem meine Matomo Anlytics den Besuch der Seite registrieren. Das ist auch gelungen mit:

    Code
    JHtml::_('script', 'matomo-id-3.js', array('version' => 'auto', 'relative' => true));

    Leider benötigt dieser JS-Aufruf eine ziemliche Laufzeit, in der der Seitenaufbau in Teilen sehr verzögert wird. Deshalb möchte ich in diese Zeile die Eigenschaft "defer" einfügen, damit der Browser nicht auf die Ausführung des Scripts warten muss.


    Frage: Wie / wo muss ich die Eigenschaft "defer" in den oben zitierten Code einfügen?

    Auf meiner neuen Website möchte ich jeden Beitrag mit einem Foto beginnen. Das Foto alleine wäre aber zu wenig attraktiv. Und so möchte ich, dass sobald der Beitrag mit seinem Foto im Viewport erscheint, eine kurze Animation startet wie z.B. dass eine gezeichnete Katze durch das Bild / Foto läuft.

    Hierzu muss nicht nur die Animation starten, sobald die Bedingung erfüllt ist "Bild im Viewport", sondern auch berücksichtigt werden, dass die Grafik in der Größe an das Foto angepasst werden muss – notfalls über @media screenwidth, besser aber über "object-fit: cover", denn die Fotos lade ich in drei Größen und manipuliere sie zusätzlich mittels "object-fit: cover".


    Meine Fragen:

    Wie kann ich mein Ziel am einfachsten erreichen? – oder: Was benötigt technisch den geringsten Aufwand? CSS oder Scripting oder…

    Wie lade ich überhaupt das Foto und darüber liegend das animierte GIF?

    Soeben fand ich diese Test-Website hier:

    Webcam Testen

    Dort wird die Bildgröße genau so angezeigt, wie meine Kamera ihre Daten liefert, also gemäß meiner Standard-Einstellung 720p @ 30 fps.


    Das bestätigt mir, dass die Bildabmessungen inclusive Seitenverhältnis usw. sehr wohl durch ein Script oder ähnliches manipuliert werden können.


    Leider sehe ich aufgrund lediglich dieser Erkenntnis keinen Ansatz zur Optimierung in meinem Sinne z.B. bei Videokonferenzen. Oder auch auf meiner eigenen Test-Webseite.

    Bei einigen Videokonferenzen bemängelten die Kommunikationspartner, dass das Bild meiner Webcam lediglich im 4:3-Format und anscheinend nur mit der Minimal-Bildgröße von 640 x 480 px dargestellt wurde. Meine Webcam kann aber 720p bei 30 fps liefern.

    Nun habe ich sicher gestellt, dass meine Webcam systemweit (Manjaro-Linux) auf 720p und 30 fps fix eingestellt ist (mittels Guvcview settings) und diese Qualität immer liefert, solange kein weiteres Programm diese Einstellungen ändert.


    Da ich nicht immer wieder mit einem Kommunikationspartner die Webcam-Qualität prüfen kann bis die Sache geklärt ist, habe ich eine eigene Test-Webseite erstellt und den verwendeten Code (JS und CSS) darauf geprüft, dass die Bildgröße nicht skaliert oder sonstwie manipuliert wird. Die Übertragung erfolgt per WebRTC. Hier ist der Link:

    Das Bild meiner Kamera wird offensichtlich grundsätzlich auf 640 x 480 herunter skaliert oder verändert. Ein Mechanismus, der bei WebRTC auf meinen PC zurück wirken kann, um die Kamera auf 640 x 480 zurück zu setzen, ist mir unbekannt. Der ist aber anscheinend über den Browser sehr wohl vorhanden:

    Denn nachdem ich die Webcam über den o.g. Link getestet habe und den Stream der Webcam dann über ein anderes Programm auf dem Desktop öffne, hat dieser ebenfalls 640 x 480 als Standard eingestellt.


    Was muss ich tun, damit der Stream meiner Webcam in der von mir gewünschten Bildgröße übertragen wird und nicht durch andere Einflüsse zurück gesetzt wird?

    Ist die Ursache doch in dem von mir verwendeten Code für Web-RTC zu finden? Und wieso erscheint mein Webcam-Bild bei anderen Konferenzteilnehmer (z.B. bei Zoom aber auch bei Redconnect) ebenfalls in der kleinen Bildgröße (also ohne dass "mein Code" dies bewirken würde?