Oldtimer will von HTML WYSIWYG nach Responsive Webdesign umsteigen

[Anselm Rapp]

Hallo,

mal sehen, ob diese Gruppe nur scheintot ist.

Ich bin schon eine halbe Ewigkeit im Ruhestand. Beruflich habe ich mich
neben vielem anderem auch mit HTML-Programmierung befasst, habe ein
Intranet unseres Konzernbereichs initiiert und anfangs selbst am Rechner
Hand angelegt. Nach meinem Ausscheiden konnte ich das Erstellen und
Pflegen von Webseiten natürlich nicht lassen, betreibe noch rund ein
halbes Dutzend davon, über Familiäres, Hobbys und andere Themen.

Mir ist klar, dass MS Expression Web, das ich vorzugsweise noch
verwende, längst nicht mehr aktueller Stand ist (für die ältesten Seiten
verwende ich sogar noch MS FrontPage). Was ich da bereitstelle, sieht
auf PC-Bildschirmen noch ganz manierlich aus, ist auf
Smartphone-Displays nicht vernünftig lesbar.

Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
umsteigen. Klar, dass ich dazulernen muss, dazu bin ich auch bereit, nur
sollte der Aufwand sich in Grenzen halten, und die Bedienung der
Software für die Webseitengestaltung sollte nicht zu kompliziert sein.
Wenn möglich, würde ich ganz gerne, wo nötig, auch ein paar Zeilen HTML,
CSS, eventuell auch PHP einfügen können.

Auf meiner Suche habe ich den MAGIX Web Designer Premium* entdeckt und
als Testversion installiert. Er scheint mir nicht schlecht, aber ich
stelle fest, dass der Umstieg so grundsätzlich ist, dass ich ungern nach
einer Weile merken würde, dass ich auf ein lahmes Pferd gesetzt habe.

Kann mir jemand hier raten?

Danke im Voraus und Gruß, Anselm

* https://www.magix.com/de/web/web-designer/

--
Sämtliche Rechte mich zu irren vorbehalten. ;-)

[Arno Welzel]

Anselm Rapp, 2022-09-22 09:12:

[...]

> Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
> umsteigen. Klar, dass ich dazulernen muss, dazu bin ich auch bereit, nur
> sollte der Aufwand sich in Grenzen halten, und die Bedienung der
> Software für die Webseitengestaltung sollte nicht zu kompliziert sein.
> Wenn möglich, würde ich ganz gerne, wo nötig, auch ein paar Zeilen HTML,
> CSS, eventuell auch PHP einfügen können.

Was man als "Responsive Webdesign" versteht, ist im Wesentlich die
Nutzung von Media Queries in CSS, um für unterschiedliche
Bildschirmbreiten angepasste Layouts anzubieten.

Die Idee dabei ist, dass Smartphones und Tables in der Regel auch
deutlich schmalere Displays haben und man dann genau dafür auch das
Layout anpasst - z.B. nur einspaltige Ansicht statt Inhalt und
Navigationsbereich nebeneinander.

Konkret:

----------------------------------------

/* Hier alle globalen Layout-Vorgaben */

@media only screen and (min-width: 40em) {
/* Layout-Vorgaben für Desktop-Darstellung ab 40em Breite */
}

@media only screen and (max-width: 40em) {
/* Layout-Vorgaben für mobile Geräte bis 40em Breite */
}

----------------------------------------

Man kann die Angaben auch kombinieren und mehrere Bereiche definieren:

@media only screen and (min-width: 40em) and (max-width: 60em)

Ebenso kann man die Ausrichtung des Gerätes als Kriterium nehmen:

@media only screen and (orientation: landscape)

Die Einschränkung "only screen" ist sinnvoll, wenn man für den Druck ein
angepasstes Layout haben will (siehe auch meine Website
<https://arnowelze.de>, die auch ein Druck-Layout anbietet).

Um das zu vereinfachen ist ein wesentliches Mittel <DIV>-Elemente, die
via CSS entweder nebeneinander oder untereinander angeordnet werden.

Siehe dazu auch:

<https://css-tricks.com/snippets/css/complete-guide-grid/>
<https://css-tricks.com/snippets/css/a-guide-to-flexbox/>

> Auf meiner Suche habe ich den MAGIX Web Designer Premium* entdeckt und
> als Testversion installiert. Er scheint mir nicht schlecht, aber ich
> stelle fest, dass der Umstieg so grundsätzlich ist, dass ich ungern nach
> einer Weile merken würde, dass ich auf ein lahmes Pferd gesetzt habe.
>
> Kann mir jemand hier raten?
>
> Danke im Voraus und Gruß, Anselm
>
> * https://www.magix.com/de/web/web-designer/

Na ja - das ist halt für Leute, die sich mit HTML und CSS eigentlich
nicht befassen möchten. Da kann man dann auch gleich WordPress mit
Gutenberg oder Elementor o.Ä. nehmen, wenn es nur darum geht, eine
Website mit Responsive Layout zu bauen.

Wenn Du aber selber noch HTML-Dokumente erstellen möchtest und versehen
willst, wie Responsive Layout mit CSS funktioniert, würde ich generell
gar keine Software dieser Art nutzen, sondern mich direkt mit HTML und
CSS befassen. Editoren, die den Umgang mit HTML-Quellen und CSS
erleichtern, gibt es ja diverse - z.B. Visual Studio Code, was auch
kostenlos ist:

<https://code.visualstudio.com/docs/languages/html>

Sublime Text 3 ist noch besser, aber nicht mehr kostenlos, man kann es
aber als Testversion ausprobieren:

<https://www.sublimetext.com/3>

--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Arno Welzel, 2022-09-22 12:41:

[...]

> Die Einschränkung "only screen" ist sinnvoll, wenn man für den Druck ein
> angepasstes Layout haben will (siehe auch meine Website
> <https://arnowelze.de>, die auch ein Druck-Layout anbietet).

Natürlich <https://arnowelzel.de> - da fehlte ein "l". Diese Website hat
neben Druck-Layout auch eine für mobile Geräte angepasste Darstellung.

[Anselm Rapp]

Am 22.09.2022 um 12:41 schrieb Arno Welzel:

> [...]

>
> Na ja - das ist halt für Leute, die sich mit HTML und CSS eigentlich
> nicht befassen möchten. Da kann man dann auch gleich WordPress mit
> Gutenberg oder Elementor o.Ä. nehmen, wenn es nur darum geht, eine
> Website mit Responsive Layout zu bauen.
>
> Wenn Du aber selber noch HTML-Dokumente erstellen möchtest und versehen
> willst, wie Responsive Layout mit CSS funktioniert, würde ich generell
> gar keine Software dieser Art nutzen, sondern mich direkt mit HTML und
> CSS befassen. Editoren, die den Umgang mit HTML-Quellen und CSS
> erleichtern, gibt es ja diverse - z.B. Visual Studio Code, was auch
> kostenlos ist:
>
> <https://code.visualstudio.com/docs/languages/html>
>
> Sublime Text 3 ist noch besser, aber nicht mehr kostenlos, man kann es
> aber als Testversion ausprobieren:
>
> <https://www.sublimetext.com/3>

Vielen Dank für die ausführliche Antwort. Nun weiß ich, dass ich mich
von HTML und CSS nicht verabschieden muss. Mit dem Magix Webdesigner
habe ich etwas experimentiert, aber es kommt bisher nicht immer das
dabei raus, was ich wollte, insbesondere im Smartphone-Format. Bis ich
mich entscheide, wie ich weitermache, wird es noch eine Weile dauern.
Direkt HTML habe ich bisher höchstens ausnahmsweise programmiert, da
müsste ich ziemlich umlernen. (Mein erster "richtiger" WYSIWYG-Editor
war HoTMetaL Pro.)

Gruß, Anselm

[Peter J. Holzer]

On 2022-09-22 07:12, Anselm Rapp <Ansel...@mailueberfall.de> wrote:
> Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
> umsteigen. Klar, dass ich dazulernen muss, dazu bin ich auch bereit, nur
> sollte der Aufwand sich in Grenzen halten, und die Bedienung der
> Software für die Webseitengestaltung sollte nicht zu kompliziert sein.
> Wenn möglich, würde ich ganz gerne, wo nötig, auch ein paar Zeilen HTML,
> CSS, eventuell auch PHP einfügen können.

Ich sage gleich, dass ich keine "Software für die Webseitengestaltung"
verwende. Ich schreibe HTML und CSS von Hand (oder schreibe Software,
die HTML und oder CSS generiert, gerne unter Verwendung existierender
Komponenten[1]). Mit WYSIWYG-Software konnte ich mich nie anfreuden.

Prinzipiell ist HTML ohne CSS responsive. Es passt sich dem Output-
Device an. Manchmal vielleicht ein bisschen zu sehr. Unresponsiv wird es
erst dadurch, dass man mittels CSS (oder der Handvoll HTML-Parameter die
kurz vor CSS eingeführt wurden und die heute hoffentlich zum Großteil
vergessen sind) fixe Größen vorgibt. Das sollte man also vermeiden.

Also keine fixen Größen, sondern Minimal- und Maximalgrößen, eventuell
in Abhängigkeit von der Viewportgröße. Flexboxen bieten sich an, wenn
Dinge je nach Viewportgröße neben- oder untereinander stehen sollen.

Wenn man Dinge bei unterschiedlichen Größen sehr unterschiedlich
gestalten will (z.B. Hamburger-Menü bei kleinen Schirmen,
Navigationsleiste bei großen), muss man zu Media-Queries greifen. Ich
versuche damit eher sparsam umgehen, ganz ohne komme ich aber nicht aus.

Meist wird "mobile first" empfohlen, nicht nur weil die meisten User
heute Handys verwenden (jedenfalls allgemein, nicht unbedingt auf meinen
Seiten), sondern vor allem auch, weil ein Design, das auf einem kleinen
Schirm gut ausschaut, auch auf einem großen zumindest lesbar ist,
während das umgekehrt nicht unbedingt der Fall ist. Mit "Mobile first"
baut man also die Seite so, dass sie für alle erst mal funktioniert, und
schöner kann man sie für Leute mit großen Bildschirmen dann immer noch
machen.

Keine Ahnung, was derzeit als Literatur (ob toter Baum oder Online)
empfehlenswert ist. Ich sehe mir gern die Youtube-Videos von Kevin
Powell an, da lerne ich auch immer noch was dazu[2], aber er erklärt
auch Basics. Problematisch bei einem Youtube-Channel ist halt, das nicht
einer pädagogischen Linie folgt - er macht halt jede Woche ein Video
über ein Thema, das er gerade interessant findet und Youtube präsentiert
Dir das dann in zufälliger Reihenfolge. Das könnte für jemanden, der
systematisch lernen will, frustrierend sein. Er bietet meines Wissens
auch Online-Kurse an, aber über die kann ich nichts sagen.

hp

[1] Nicht einmal ich muss jedes Rad neu erfinden.
[2] In CSS hat sich nicht nur in den letzten 20+ Jahren viel getan, es
wird immer noch wie wild weiterentwickelt.

[Anselm Rapp]

Am 22.09.2022 um 23:46 schrieb Peter J. Holzer:

> [...]

>
> Meist wird "mobile first" empfohlen, nicht nur weil die meisten User
> heute Handys verwenden (jedenfalls allgemein, nicht unbedingt auf meinen
> Seiten), sondern vor allem auch, weil ein Design, das auf einem kleinen
> Schirm gut ausschaut, auch auf einem großen zumindest lesbar ist,
> während das umgekehrt nicht unbedingt der Fall ist. Mit "Mobile first"
> baut man also die Seite so, dass sie für alle erst mal funktioniert, und
> schöner kann man sie für Leute mit großen Bildschirmen dann immer noch
> machen.

"Mobile first" habe ich von Dir zum ersten Mal gehört. Das Konzept
leuchtet mir ein, und ich vermute rückblickend schon entsprechend
programmierte Websites gesehen zu haben. Damit will ich mich eingehender
beschäftigen.

> Keine Ahnung, was derzeit als Literatur (ob toter Baum oder Online)
> empfehlenswert ist. Ich sehe mir gern die Youtube-Videos von Kevin
> Powell an, da lerne ich auch immer noch was dazu[2], aber er erklärt
> auch Basics. Problematisch bei einem Youtube-Channel ist halt, das nicht
> einer pädagogischen Linie folgt - er macht halt jede Woche ein Video
> über ein Thema, das er gerade interessant findet und Youtube präsentiert
> Dir das dann in zufälliger Reihenfolge. Das könnte für jemanden, der
> systematisch lernen will, frustrierend sein. Er bietet meines Wissens
> auch Online-Kurse an, aber über die kann ich nichts sagen.

Ich habe in ein Youtube-Video von Kevin Powell reingeschaut. Was er
präsentiert, sieht gut aus, allerdings spricht er ziemlich schnell. Ich
werde mal nach (deutschsprachigen) Büchern suchen, die bevorzuge ich
beim Lernen.

Hier bietet er übrigens "Courses" an:
https://scrimba.com/learn/responsive

Danke für alle Informationen und Tipps.

Gruß, Anselm

[Stefan Froehlich]

On Fri, 23 Sep 2022 15:33:06 Anselm Rapp wrote:
> Ich habe in ein Youtube-Video von Kevin Powell reingeschaut. Was
> er präsentiert, sieht gut aus, allerdings spricht er ziemlich
> schnell.

Wenn's nur das ist, kann man bei YouTube die Wiedergabe auch
langsamer stellen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Ein Paradies schon auf Erden. Mit Stefan. Ein weisses Vergnügen!
(Sloganizer)

[Thomas Hochstein]

Anselm Rapp schrieb:

> Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
> umsteigen. Klar, dass ich dazulernen muss, dazu bin ich auch bereit, nur
> sollte der Aufwand sich in Grenzen halten, und die Bedienung der
> Software für die Webseitengestaltung sollte nicht zu kompliziert sein.

Ich würde davon abraten, eine "Software für Webseitengestaltung" zu
verwenden, die irgendetwas wie WYSIWYG versucht. Weit vorzugswürdig ist
ein spezialisierter Editor, der ein bequemes Arbeiten an Texten jeder Art
(Programmcode, Webseiten, $whatever) ermöglicht, Schlüsselbegriffe (bei
HTML und CSS also bspw. die Elemente) farblich hervorhebt und ggf. auch
automatisch schließt usw. Das kann das bereits erwähnte Sublime-Text (4),
das ich sehr gerne verwende, das kann aber auch jeder andere vergleichbare
Editor bzw. Entwicklungsumgebung, wie das schon genannte Visual Studio
Code, Atom <https://atom.io/>, Komodo Edit bzw. Komode IDE
<https://www.activestate.com/products/komodo-ide/> usw. Dazu ein
Webbrowser, in dem die Datei, an der man arbeitet, offen ist, und man muss
sie nur mit F5 neu laden und sieht jede Änderung, wie sie wirklich
aussieht - und kann das Browserfenster anpassen an kleinere Bildschirme
wie Tablets und Smartphones.

Als sehr hilfreich empfinde ich ebenfalls Templates oder fertige
Frameworks, die HTML, CSS und ggf. Javascript schon mitbringen und "mobile
first" bzw. "responsive" bereits unterstützen, so dass man das CSS dafür
nicht (komplett) selbst schreiben muss, sondern nur vorhandene Muster
anpassen. Je nachdem sind damit auch bereits viele fertige Elemente für
eine optisch ansprechende Webseitengestaltung verbunden, die mit wenig
Aufwand ein nicht nur responsives, sondern auch optisch ansprechbares
Layout ermöglichen (um den Preis, dass - je weniger man anpasst - alle
Webseiten auf dieser Grundlage optisch vergleichbar wirken).

Ich stand vor acht, neun Jahren vor denselben Fragen wie Du und habe
damals eine Serie von Blogbeiträgen veröffentlicht, die hier verlinkt ist:
<https://th-h.de/net/web/authoring/#authoring>

Vielleicht gibt das einige Anregungen.

2017 gab es hier übrigens schonmal einen Thread zu diesem Thema, wobei
damals auch nach Content-Management-Systemen (CMS) gefragt war. Ich hatte
damals einige Beispiele für Bücher zum Thema und für Template-Systeme oder
Frameworks gepostet; mein Beitrag ist unter
<dciwam.170...@meneldor.ancalagon.de> bzw.
<https://groups.google.com/groups?as_umsgid=dciwam.1704291310.247%40meneldor.ancalagon.de>
abrufbar, aber auch der ganze Thread ist sicherlich für Dich hilfreich.

Beste Grüße,
-thh
--
Do not go gentle into that good night.
Rage, rage against the dying of the light.

[Thomas Hochstein]

Stefan Froehlich schrieb:

> Wenn's nur das ist, kann man bei YouTube die Wiedergabe auch
> langsamer stellen.

Wichtiger noch: man kann sie auch schneller stellen.

(Ich verstehe sowieso nicht, warum man zunehmend Videos statt Texten
findet, die etwas erläutern, berichten, ... --- Doch, ich verstehe schon,
dass der Aufwand für ein Video - oder eine Sprachnachricht - für den
Sender üblicherweise geringer ist als für einen Text, aber die Nachteile
für den Empfänger sind so massiv, dass mir die zunehmende Verbreitung
unverständlich ist.)

[Peter J. Holzer]

On 2022-09-24 15:49, Thomas Hochstein <t...@thh.name> wrote:
> (Ich verstehe sowieso nicht, warum man zunehmend Videos statt Texten
> findet, die etwas erläutern, berichten, ... --- Doch, ich verstehe schon,
> dass der Aufwand für ein Video - oder eine Sprachnachricht - für den
> Sender üblicherweise geringer ist als für einen Text,

Das bezweifle ich. Für ein Video muss man zuerst ein Script schreiben
(oder zumindest einen groben Ablaufplan), dann muss man das filmen
(missglückte Szenen vielleicht mehrfach) und am Schluss schneiden. Das
ist insgesamt ziemlich sicher mehr Aufwand als einen Blog-Eintrag zu
schreiben.

(Ich habe nie Videos gemacht, aber gelegentlich Vorträge gehalten - und
die Vorbereitungszeit war immer ein Mehrfaches der 30 oder 50 oder 90
Minuten, die ich da auf der Bühne stand. Dabei waren das immer Themen,
bei denen ich mich gut auskannte und eigentlich eh nur das Thema in x
Minuten verständlich darstellen musste.)

Die von Stefan erwähnte Monetarisierungs-Möglichkeit ist sicher ein
Faktor.

> aber die Nachteile für den Empfänger sind so massiv, dass mir die
> zunehmende Verbreitung unverständlich ist.)

Ich gewöhne mich langsam daran. Das wirkliche Problem ist es, irgendeine
Information wiederzufinden. In einer Handvoll Blog-Einträge nach
Stichworten suchen, ist einfach. Aber wie mache ich das in einer Serie
von 50-Minuten-Videos? (Theoretisch sollte es gehen, weil meistens eh
Untertitel vorhanden sind, aber wie durchsuche ich die?)

hp

[Stefan Froehlich]

On Sat, 24 Sep 2022 17:49:55 Thomas Hochstein wrote:
> Stefan Froehlich schrieb:
>> Wenn's nur das ist, kann man bei YouTube die Wiedergabe auch
>> langsamer stellen.

> Wichtiger noch: man kann sie auch schneller stellen.

Das ist die einzige Richtung, die ich bisher verwendet habe :-)

> (Ich verstehe sowieso nicht, warum man zunehmend Videos statt
> Texten findet, die etwas erläutern, berichten,

Wie bereits erwähnt, hat man nur damit die Chance auf Einnahmen,
während Texte, so wie sie unsereiner im Usenet zum besten gibt, mit
etwas Glück ein paar dankende Worte einbringen, aber sonst nichts.
Ist halt die Frage, wo man hin möchte.

Für mich als "Kunde" ist das maximal lästig: Zum ersten findet man
wahrscheinlich viele passende Videos gar nicht erst, weil die paar
Schlagworte in der Beschreibung naturgemäß nicht so umfangreich sind
wie der Volltext. Zum zweiten finde ich, wenn ich denn auf das Video
aufmerksam werde, die entscheidenden 10 Sekunden nicht, auf die es
mir ankommt - sondern muss mir endloses Getratsche anhören,
inklusive mehrfacher Hinweise darauf, Likes zu geben und auch bitte
noch alle anderen Videos des Autors zu konsumieren. Ja, freilich.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für übernatürliche Schmerzen in schmerzlichen Stürmen!
(Sloganizer)

[Thomas Hochstein]

Peter J. Holzer schrieb:

> On 2022-09-24 15:49, Thomas Hochstein <t...@thh.name> wrote:
> > (Ich verstehe sowieso nicht, warum man zunehmend Videos statt Texten
> > findet, die etwas erläutern, berichten, ... --- Doch, ich verstehe schon,
> > dass der Aufwand für ein Video - oder eine Sprachnachricht - für den
> > Sender üblicherweise geringer ist als für einen Text,
>
> Das bezweifle ich. Für ein Video muss man zuerst ein Script schreiben
> (oder zumindest einen groben Ablaufplan), dann muss man das filmen
> (missglückte Szenen vielleicht mehrfach) und am Schluss schneiden. Das
> ist insgesamt ziemlich sicher mehr Aufwand als einen Blog-Eintrag zu
> schreiben.

Das kann ich nach eigener Erfahrung nicht bestätigen. Den Aufwand für das
Filmen und ggf. Schneiden kann ich schlecht abschätzen (meist scheint es
mir aber schlicht ein durchlaufendes Video, ggf. mit eingeblendetem
Bildschirm und mitlaufendem Kommentar) zu sein, aber der Aufwand für einen
mündlichen Vortrag eines Themas ist um Größenordnungen kleiner als für
einen inhaltlich ansprechenden und sinnvoll gegliederten und formatierten
entsprechenden Text, selbst dann, wenn man sich für den mündlichen Vortrag
einen einigermaßen aufwendingen Foliensatz baut.

> (Ich habe nie Videos gemacht, aber gelegentlich Vorträge gehalten - und
> die Vorbereitungszeit war immer ein Mehrfaches der 30 oder 50 oder 90
> Minuten, die ich da auf der Bühne stand. Dabei waren das immer Themen,
> bei denen ich mich gut auskannte und eigentlich eh nur das Thema in x
> Minuten verständlich darstellen musste.)

Natürlich. Die Zeit für die Ideensammlung, Durcharbeitung des Themas,
Gliederung, ggf. ergänzender Recherche und dann Erstellung eines
stichwortartigen Konzepts brauchst Du üblicherweise sowohl für einen
Vortrag / ein Video als auch für die Abfassung eines schriftlichen Textes;
sie ist regelmäßig deutlich länger als die Vortragszeit. Und jetzt schreib
mal statt des Vortrags einen entsprechenden Text - ich garantiere Dir, das
dauert _deutlich_ länger als die Vortragszeit. So jedenfalls meine
Erfahrung.

> Die von Stefan erwähnte Monetarisierungs-Möglichkeit ist sicher ein
> Faktor.

Mag sein. Das erklärt vielleicht Youtube, aber nicht unbedingt, warum man
an vielen Orten Erklärungs-Videos statt erklärenden Texten hat.

> > aber die Nachteile für den Empfänger sind so massiv, dass mir die
> > zunehmende Verbreitung unverständlich ist.)
>
> Ich gewöhne mich langsam daran.

Ich nicht.

> Das wirkliche Problem ist es, irgendeine
> Information wiederzufinden. In einer Handvoll Blog-Einträge nach
> Stichworten suchen, ist einfach. Aber wie mache ich das in einer Serie
> von 50-Minuten-Videos? (Theoretisch sollte es gehen, weil meistens eh
> Untertitel vorhanden sind, aber wie durchsuche ich die?)

Das ist das eine.

Hinzu kommt die Schwierigkeit, festzustellen, ob überhaupt die gesuchten
Inhalte enthalten sind; ich kann große Textmengen schnell querlesen oder
überfliegen, aber das funktioniert bei Videos nur sehr begrenzt und mit
deutlich höherem Aufwand.

Und dann ist die Aufnahme von Inhalten über ein Video zudem deutlich
weniger komfortabel als durch das Lesen eines Textes; das Video läuft so,
wie es eingesprochen ist, und vorspulen ist nur begrenzt sinnvoll, einen
Text hingegen kann ich überfliegen und dann, wenn die relevante Stelle
kommt, genauer lesen - und das auch immer wieder, wenn ich mich noch
einmal vergewissern muss. Es macht wenig Freude, inm einem Video immer
wieder zurückzuspringen ...

[Thomas Hochstein]

Stefan Froehlich schrieb:

> On Sat, 24 Sep 2022 17:49:55 Thomas Hochstein wrote:
> > (Ich verstehe sowieso nicht, warum man zunehmend Videos statt
> > Texten findet, die etwas erläutern, berichten,
>
> Wie bereits erwähnt, hat man nur damit die Chance auf Einnahmen,
> während Texte, so wie sie unsereiner im Usenet zum besten gibt, mit
> etwas Glück ein paar dankende Worte einbringen, aber sonst nichts.
> Ist halt die Frage, wo man hin möchte.

Das betrifft aber doch primär Youtube (und ggf. vergleichbare Plattformen,
die Werbung schalten); ich sehe aber immer wieder auch Erklärungsvideos an
anderen Orten, wo Werbung allenfalls aus eingeblendeten Anzeigen auf der
Seite besteht, und das ginge auch bei Text.

Und es gibt ja durchaus blog-ähnliche Publikationssysteme und Newsletter,
bei der nur ein Schnupper-Angebot oder eine halbe Handvoll Beiträge pro
Monat kostenlos sind und der Rest ein Abo erfordert ...

> Für mich als "Kunde" ist das maximal lästig: Zum ersten findet man
> wahrscheinlich viele passende Videos gar nicht erst, weil die paar
> Schlagworte in der Beschreibung naturgemäß nicht so umfangreich sind
> wie der Volltext. Zum zweiten finde ich, wenn ich denn auf das Video
> aufmerksam werde, die entscheidenden 10 Sekunden nicht, auf die es
> mir ankommt - sondern muss mir endloses Getratsche anhören,
> inklusive mehrfacher Hinweise darauf, Likes zu geben und auch bitte
> noch alle anderen Videos des Autors zu konsumieren. Ja, freilich.

Exakt. Und wenn Du die 10 Sekunden hast, dann musst Du das Video ggf.
mehrfach anhalten und zurückfahren, um den Text zu verstehen, zu zitieren
oder schlicht die Hinweise anzuwenden.

[Thomas Hochstein]

Andreas Kohlbach schrieb:

> On Sat, 24 Sep 2022 17:49:55 +0200, Thomas Hochstein wrote:
> >
> > (Ich verstehe sowieso nicht, warum man zunehmend Videos statt Texten
> > findet, die etwas erläutern, berichten, ... ---
>

> Ich auch nicht. Es ist bei einigen Nachrichtenportalen schon eine Seuche:
> Da gibt es einen Link zu einem IMO interessanten Text mit dem Hinweis,
> ein Video zu sein. Geklickt, steht dort ein oder zwei Sätze, dann das
> Video, was zumindest meinen alten Computer sehr ausgebremst hat, dass es
> stotterte.

Das Problem habe ich nicht, aber üblicherweise ist Werbung von bis zu
30-45 Sekunden vorgeschaltet, erst dann kommt das Video - und regelmäßig
ist es eher inhaltsleer. Bei einem Text habe ich das schneller
festgestellt (oder ihn sogar zur Gänze überflogen) als bei dem Video die
Werbung durchläuft.

[Stefan Froehlich]

On Sun, 25 Sep 2022 14:10:25 Thomas Hochstein wrote:
> Stefan Froehlich schrieb:
>> On Sat, 24 Sep 2022 17:49:55 Thomas Hochstein wrote:
>> > (Ich verstehe sowieso nicht, warum man zunehmend Videos statt
>> > Texten findet, die etwas erläutern, berichten,

>> Wie bereits erwähnt, hat man nur damit die Chance auf Einnahmen,
>> während Texte, so wie sie unsereiner im Usenet zum besten gibt,
>> mit etwas Glück ein paar dankende Worte einbringen, aber sonst
>> nichts. Ist halt die Frage, wo man hin möchte.

> Das betrifft aber doch primär Youtube (und ggf. vergleichbare
> Plattformen, die Werbung schalten); ich sehe aber immer wieder
> auch Erklärungsvideos an anderen Orten, wo Werbung allenfalls aus
> eingeblendeten Anzeigen auf der Seite besteht, und das ginge auch
> bei Text.

Ok, die entgehen mir offenbar, womit wir beim ersten der weiter
unten aufgeführten Nachteile angelangt sind.

> Und es gibt ja durchaus blog-ähnliche Publikationssysteme und
> Newsletter, bei der nur ein Schnupper-Angebot oder eine halbe
> Handvoll Beiträge pro Monat kostenlos sind und der Rest ein Abo
> erfordert ...

Ja, auch das. Einige hiesige Medien veröffentlichen nur noch Teaser,
hinter deren Link dann ein 5-Minütiges Referat des Chefredakteurs
steht. Möglicherweise steht da tatsächlich Arbeitsminimierung im
Vordergrund, vielleicht auch, dass man das Video nicht einfach
kopieren kann, auch nicht in Ausschnitten. Oder man rechnet mit
einer höheren Anzahl von Konsumenten, die während irgendeiner
anderen Beschäftigungen ins Ohr geredet haben möchte, als mit
solchen wie uns, die bei Videos gleich wegklicken.

> [...] Und wenn Du die 10 Sekunden hast, dann musst Du das Video

> ggf. mehrfach anhalten und zurückfahren, um den Text zu
> verstehen, zu zitieren oder schlicht die Hinweise anzuwenden.

Ja, das kommt auch noch dazu (ist aber im Vergleich zum Finden der
Stelle noch das kleinere Problem, wenigstens auf YouTube).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Schmatzen ist deine Welt. Stefan, so eigenhändig wie die Moral.
(Sloganizer)

[Arno Welzel]

Andreas Kohlbach, 2022-09-22 15:37:

> Jup, sieht auch im Textbrowser gut aus. Was man nicht (mehr) von jeder
> Webseite heute sagen kann.

Ja - ich teste meine Websites auch in Lynx. Das Menü am Anfang ist halt
etwas länglich, aber mit "Zum Inhalt springen" kann man es leicht
überspringen. Das ist auch für Screenreader als Hilfe vorhanden, damit
man nicht jedesmal das komplette Menü durchgehen muss.

Moderne Technologien und Barrierefreiheit müssen sich nicht widersprechen.

[Arno Welzel]

Peter J. Holzer, 2022-09-22 23:46:

> On 2022-09-22 07:12, Anselm Rapp <Ansel...@mailueberfall.de> wrote:
>> Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
>> umsteigen. Klar, dass ich dazulernen muss, dazu bin ich auch bereit, nur
>> sollte der Aufwand sich in Grenzen halten, und die Bedienung der
>> Software für die Webseitengestaltung sollte nicht zu kompliziert sein.
>> Wenn möglich, würde ich ganz gerne, wo nötig, auch ein paar Zeilen HTML,
>> CSS, eventuell auch PHP einfügen können.
>
> Ich sage gleich, dass ich keine "Software für die Webseitengestaltung"
> verwende. Ich schreibe HTML und CSS von Hand (oder schreibe Software,
> die HTML und oder CSS generiert, gerne unter Verwendung existierender
> Komponenten[1]). Mit WYSIWYG-Software konnte ich mich nie anfreuden.
>
> Prinzipiell ist HTML ohne CSS responsive. Es passt sich dem Output-
> Device an. Manchmal vielleicht ein bisschen zu sehr. Unresponsiv wird es
> erst dadurch, dass man mittels CSS (oder der Handvoll HTML-Parameter die
> kurz vor CSS eingeführt wurden und die heute hoffentlich zum Großteil
> vergessen sind) fixe Größen vorgibt. Das sollte man also vermeiden.

Ähm - nein. Mobile Browser stellen HTML *ohne* entsprechende Regeln,
konkret:

<meta name="viewport" content="width=device-width, initial-scale=1" />

so dar, als wäre es für Desktop-Systeme geschrieben, d.h. es wird in
virtueller Viewport im 4:3-Format verwendet, der dann herunterskaliert
wird. Um das Dokument dann in der normalen Größe zu sehen, muss man erst
die Anzeige vegrößeren.

[Arno Welzel]

Stefan Ram, 2022-09-24 20:48:

> Anselm Rapp <Ansel...@mailueberfall.de> writes:
>> Obwohl Oldtimer, will ich möglichst noch auf Responsive Webdesign
>> umsteigen.
>

> Eine Zeitlang gingen Browser von Mobilgeräten wohl von einer
> fiktiven Bildschirmbreite ("Viewport") von 980px aus. Dadurch
> wurde das normale HTML erst "unresponsive" gemacht! Man sollte
> "width=device-width" verwenden, wenn man das nicht will.

Das tun sie immer noch. Deshalb diese Zeile im <head> einfügen:

<meta name="viewport" content="width=device-width, initial-scale=1" />

> Heute haben aber einige Hersteller wohl wieder davon Abstand
> genommen.

Nein.

Nur so sind Website sinnvoll auf mobilen Geräten darstellbar, wenn die
Anbieter mobile Geräte nicht explizit berücksichtigt haben. Kaum eine
Website funktioniert mit lediglich 320px verfügbarer Breite, wenn der
Anbieter das Layout dafür nicht explizit so gebaut hat. Und 320px ist
die Standardbreite für mobile Geräte, egal wieviel Pixel das Display
real hat. Ggf. wird 1px eben auf 2 oder 3 echte Pixel umgerechnet, was
auch für Bilder gilt. Hier kann man mit srcset dann auch mehrere
Versionen angeben, damit je nach Geräte-Pixeldichte ein passendes Bild
verwendet wird und man nicht unnötig hochauflösende Bilder an Geräte
ausliefert, die das ohnehin nicht nutzen können.

Zur Skalierung siehe auch:

<https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio>

<https://web.dev/codelab-density-descriptors/>

[Peter J. Holzer]

On 2022-09-25 15:03, Arno Welzel <use...@arnowelzel.de> wrote:
>> Prinzipiell ist HTML ohne CSS responsive. Es passt sich dem Output-

^^^^^^^^^^^^^

>> Device an. Manchmal vielleicht ein bisschen zu sehr. Unresponsiv wird es
>> erst dadurch, dass man mittels CSS (oder der Handvoll HTML-Parameter die
>> kurz vor CSS eingeführt wurden und die heute hoffentlich zum Großteil
>> vergessen sind) fixe Größen vorgibt. Das sollte man also vermeiden.
>
> Ähm - nein. Mobile Browser stellen HTML *ohne* entsprechende Regeln,
> konkret:
>
><meta name="viewport" content="width=device-width, initial-scale=1" />

Das ist HTML ohne CSS.

Auch ohne diese Zeile passt es sich an. Was das Device vorgibt, ist halt
für uns alte Knacker nicht mehr sonderlich augenfreundlich. Über Sinn
und Unsinn dieser Entscheidung haben wir m.E.n. schon das eine oder
andere Mal diskutiert, das müssen wir nicht wieder aufrollen. Die Zeile
ist halt Boilerplate, so wie <!DOCTYPE html> oder <meta charset="utf-8">.

> so dar, als wäre es für Desktop-Systeme geschrieben, d.h. es wird in
> virtueller Viewport im 4:3-Format verwendet,

Nein. Es gibt einen virtuellen Viewport in einer fixen Breite
(irgendwas knapp unter 1000 Pixel, genauen Wert kann ich bei Bedarf
raussuchen, hängt aber vielleicht auch vom Browser ab), die Höhe hängt
vom Device ab und ist ziemlich sicher nicht 3/4 der Breite.

hp

[Arno Welzel]

Peter J. Holzer, 2022-09-26 18:37:

> On 2022-09-25 15:03, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Prinzipiell ist HTML ohne CSS responsive. Es passt sich dem Output-
> ^^^^^^^^^^^^^
>>> Device an. Manchmal vielleicht ein bisschen zu sehr. Unresponsiv wird es
>>> erst dadurch, dass man mittels CSS (oder der Handvoll HTML-Parameter die
>>> kurz vor CSS eingeführt wurden und die heute hoffentlich zum Großteil
>>> vergessen sind) fixe Größen vorgibt. Das sollte man also vermeiden.
>>
>> Ähm - nein. Mobile Browser stellen HTML *ohne* entsprechende Regeln,
>> konkret:
>>
>> <meta name="viewport" content="width=device-width, initial-scale=1" />
>
> Das ist HTML ohne CSS.
>
> Auch ohne diese Zeile passt es sich an. Was das Device vorgibt, ist halt

Nein, eben nicht.

Ohne diese Zeile stellen mobile Browser unter Androider oder iOS die
Seiten *immer* mit einer festen Breite dar, egal wir breit das Display
wirklich ist und skalieren dann das Ergebnis soweit herunter, dass es in
der Breite in's Display passiert.

[...]

>> so dar, als wäre es für Desktop-Systeme geschrieben, d.h. es wird in
>> virtueller Viewport im 4:3-Format verwendet,
>
> Nein. Es gibt einen virtuellen Viewport in einer fixen Breite
> (irgendwas knapp unter 1000 Pixel, genauen Wert kann ich bei Bedarf

Eben! Das mit dem Viewport in einer fixen Breite meinte ich ja.

[Peter J. Holzer]

On 2022-10-08 20:27, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-09-26 18:37:
>> On 2022-09-25 15:03, Arno Welzel <use...@arnowelzel.de> wrote:
>>>> Prinzipiell ist HTML ohne CSS responsive. Es passt sich dem Output-
>> ^^^^^^^^^^^^^
>>>> Device an. Manchmal vielleicht ein bisschen zu sehr. Unresponsiv wird es
>>>> erst dadurch, dass man mittels CSS (oder der Handvoll HTML-Parameter die
>>>> kurz vor CSS eingeführt wurden und die heute hoffentlich zum Großteil
>>>> vergessen sind) fixe Größen vorgibt. Das sollte man also vermeiden.
>>>
>>> Ähm - nein. Mobile Browser stellen HTML *ohne* entsprechende Regeln,
>>> konkret:
>>>
>>> <meta name="viewport" content="width=device-width, initial-scale=1" />
>>
>> Das ist HTML ohne CSS.
>>
>> Auch ohne diese Zeile passt es sich an. Was das Device vorgibt, ist halt
>
> Nein, eben nicht.
>
> Ohne diese Zeile stellen mobile Browser unter Androider oder iOS die
> Seiten *immer* mit einer festen Breite dar, egal wir breit das Display
> wirklich ist und skalieren dann das Ergebnis soweit herunter, dass es in
> der Breite in's Display passiert.

Ja, aber das HTML (d.h. die Darstellung desselben) passt sich an diese
Breite an. Diese Breite ist keine Eigenschaft des HTML-Files, sondern
des Browsers. Genauso wie die Fensterbreite am Desktop eine Eigenschaft
des Browsers ist. Oder die 80 Zeichen Breite, wenn ich Lynx auf einem
vt100 aufrufe. In allen Fällen wird der Browser HTML so formatieren,
dass es in die zur Verfügung stehende Breite reinpasst.

hp

[Arno Welzel]

Peter J. Holzer, 2022-10-08 23:02:

> On 2022-10-08 20:27, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>>>> <meta name="viewport" content="width=device-width, initial-scale=1" />

[...]

>> Ohne diese Zeile stellen mobile Browser unter Androider oder iOS die
>> Seiten *immer* mit einer festen Breite dar, egal wir breit das Display
>> wirklich ist und skalieren dann das Ergebnis soweit herunter, dass es in
>> der Breite in's Display passiert.
>
> Ja, aber das HTML (d.h. die Darstellung desselben) passt sich an diese
> Breite an. Diese Breite ist keine Eigenschaft des HTML-Files, sondern

Na ja "sich anpassen" tut HTML nicht - der Text wird halt in der
verfügbaren Breite ausgegeben, wenn möglich. Aber schon breite Bilder
oder <pre>-Abschnitte können das verhindern.

> des Browsers. Genauso wie die Fensterbreite am Desktop eine Eigenschaft
> des Browsers ist. Oder die 80 Zeichen Breite, wenn ich Lynx auf einem
> vt100 aufrufe. In allen Fällen wird der Browser HTML so formatieren,
> dass es in die zur Verfügung stehende Breite reinpasst.

Nein, er *versucht* es nur. Ob ihm das immer zufriedenstellend gelingt,
hängt von diversen Faktoren ab. Siehe oben. Genau deshalb gibt es
"responsive design".