Wie sieht das unter MacOS X aus? Was benutzen die E-Mailprogramme
dort um HTML anzuzeigen?
Hat Apple Mail den Webkit (von Safari) drin?
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
>
> Hat Apple Mail den Webkit (von Safari) drin?
Ja.
--
Dirk Kring
> Wie sieht das unter MacOS X aus? Was benutzen die E-Mailprogramme
> dort um HTML anzuzeigen?
Das Spektrum verwendeter Engines ist vergleichbar breit zu Windows.
Warum willst du das wissen?
Mit besten Gr��en,
Mike Nolte
--
E-Mail an newsg...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Antwort auf Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:newsg...@mikenolte.de?subject=Antwort auf Usenetartikel>
Rechtschreibfehler sind ungewollt und d�rfen gerne korrigiert werden.
Mike Nolte <newsgrou...@mikenolte.de> wrote:
> Stefan Scholl <ste...@no-spoon.de> wrote:
>
>> Wie sieht das unter MacOS X aus? Was benutzen die E-Mailprogramme
>> dort um HTML anzuzeigen?
>
> Das Spektrum verwendeter Engines ist vergleichbar breit zu Windows.
>
> Warum willst du das wissen?
Nur um abzusch�tzen ob Tests und Validierung eines
HTML-Newsletters (+ Textversion) wenigstens 90 % aller Empf�nger
(Plattform unbekannt) abdeckt.
(Jaja, nur Gesch�ftsadressen mit Firmen zu denen Kontakt besteht
und die sich auch wieder austragen d�rfen.)
> Nur um abzusch�tzen ob Tests und Validierung eines
> HTML-Newsletters (+ Textversion) wenigstens 90 % aller Empf�nger
> (Plattform unbekannt) abdeckt.
Warum nicht nur Text und einen Verweis auf die Internetseite?
MfG, Metti.
> Nur um abzuschätzen ob Tests und Validierung eines
> HTML-Newsletters (+ Textversion) wenigstens 90 % aller Empfänger
> (Plattform unbekannt) abdeckt.
Ich weiß nicht, was MS Entourage dafür verwendet, aber wenn Du das und
Webkit abdeckst, dann paßt das wohl locker für mehr als 90% der
Mac-User. Wenn es Dir nur um 90% *aller* Empfänger geht, kannst Du die
Mac-User wohl getrost ignorieren...
Ansonsten muß man sich natürlich schon fragen, wie komplex das Layout
eines Newsletters sein muß, um daraus ein Problem zu machen. Und wenn
dann noch eine Textversion dabei ist, würde ich nicht 90% sondern 100%
anstreben.
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
Lernresistenter Kunde. :-(
Oh, ein gro�er Name.
Rendert der HTML schlechter als IE 5.5 auf Windows?
> Webkit abdeckst, dann pa�t das wohl locker f�r mehr als 90% der
> Mac-User. Wenn es Dir nur um 90% *aller* Empf�nger geht, kannst Du die
> Mac-User wohl getrost ignorieren...
Zielgruppe hat h�heren Mac-Anteil als sonst �blich.
Aber am Ende wird weniger als 1 Promille ein Darstellungsproblem
haben und �rger f�r 100 machen.
> Jochem Huhmann <j...@gmx.net> wrote:
>> Ich weiß nicht, was MS Entourage dafür verwendet, aber wenn Du das und
>
> Oh, ein großer Name.
>
> Rendert der HTML schlechter als IE 5.5 auf Windows?
Dass kann ich Dir so genau nicht sagen, zumal das wohl vom HTML abhängt
und vielleicht auch noch von der Entourage-Version... Ich gehe aber
davon aus, dass das der einzige Mail-Client ist, der neben Mail.app noch
eine nennenswerte Verbreitung hat, gerade im Businessbereich, von daher
würde ich den Newsletter sicherlich damit testen. Und natürlich
Thunderbird, aber der ist nicht plattformspezifisch.
>> Webkit abdeckst, dann paßt das wohl locker für mehr als 90% der
>> Mac-User. Wenn es Dir nur um 90% *aller* Empfänger geht, kannst Du die
>> Mac-User wohl getrost ignorieren...
>
> Zielgruppe hat höheren Mac-Anteil als sonst üblich.
>
> Aber am Ende wird weniger als 1 Promille ein Darstellungsproblem
> haben und Ärger für 100 machen.
Logisch.
>> Warum nicht nur Text und einen Verweis auf die Internetseite?
>
> Lernresistenter Kunde. :-(
:-(
Bedauerlicherweise ist es immer seltener, dass man sich die Kunden
aussuchen kann :-)
MfG, Metti.
> Nur um abzusch�tzen ob Tests und Validierung eines
> HTML-Newsletters (+ Textversion) wenigstens 90 % aller Empf�nger
> (Plattform unbekannt) abdeckt.
Verwende valides XHTML 1.0 Strict und CSS 2.1.
Teste Gecko, WebKit und Entourage.
Biete alternativ den gleichen Inhalt als Webseite online an.
Mehr kannst du letztlich nicht tun.
> Bedauerlicherweise ist es immer seltener, dass man sich die Kunden
> aussuchen kann :-)
Man kann Auftr�ge ablehnen.
Ich lebe schon seit 1991 hervorragend damit, dass ich nur Auftr�ge
annehme, deren zu erwartende Ergebnisse ich f�r vertretbar halte.
> Aber am Ende wird weniger als 1 Promille ein Darstellungsproblem
> haben und �rger f�r 100 machen.
Naja, ich informiere in solchen F�llen einfach den Absender, dass er mir
entweder eine Textversion schickt, oder es ganz l��t. Wenn er mir
partout nichts verkaufen will, kann ich damit leben.
Hier in Bremen haben wir so ein lernresistentes Kino, wo ich fr�her
gerne hingegangen bin. Seit sie den Programm-Newsletter nur noch per
HTML anbieten haben sie einen Kunden weniger. Nicht wirklich mein
Problem. :-)
Der letzte bekannte Entourage-User wechselte vor ein paar Wochen
nach Thunderbird. :-}
> Biete alternativ den gleichen Inhalt als Webseite online an.
Wenn dieses "Konzept" in einem Manager-Magazin "erkl�rt" wird,
k�nnte das klappen.
Geh�rte zu den Dingen in meiner "Was man eigentlich machen
sollte"-Liste.
> E-Mail an newsg...@mikenolte.de wird nur zugestellt, wenn die
> Betreffzeile "Antwort auf Usenetartikel" ohne Anführungszeichen lautet.
> <mailto:newsg...@mikenolte.de?subject=Antwort auf Usenetartikel>
> Rechtschreibfehler sind ungewollt und dürfen gerne korrigiert werden.
Sorry für das Signaturquoten, aber sehe ich das richtig, dass Du Mail an
die blanke Adresse ohne spezielles Subject nicht annimmst, aber dafür
eine praktische URL einfügst, die es dem blödesten Bot ermöglicht, die
Adresse automatisiert zuzuspammen? Irgendwie erschließt sich mir nicht
so richtig, wo da der Sinn liegt...
Rechtschreibfehler habe ich auf die Schnelle keine gefunden ;-)
> Hier in Bremen haben wir so ein lernresistentes Kino, wo ich früher
> gerne hingegangen bin. Seit sie den Programm-Newsletter nur noch per
> HTML anbieten haben sie einen Kunden weniger. Nicht wirklich mein
> Problem. :-)
Ich habe in solchen Fällen Mails schonmal via procmail durch lynx
geschickt, um Text draus zu machen. Wenn ich irgendwas nicht mehr lesen
mag, was ich eigentlich lesen will, dann ist ja schon auch mein Problem.
Aber ich finde ja auch, dass ich Newsletter immer dann lese, wenn was
lesenswertes drinsteht und nicht weil sie toll aussehen.
Trotzdem frage ich mich immer noch, ob sowas heute wirklich noch ein Problem
sein muß. Von vornherein einen HTML-Newsletter so zu gestalten, dass er
keinen Browser überfordert und trotzdem noch anständig aussieht, kann
doch nicht so schwer sein? Ich meine, wenn man schon den Aufwand treiben
will, das zu testen, dann kann man es doch auch gleich so machen, dass
Tests sehr wahrscheinlich positiv ausfallen? Es sei denn, die Tests
macht nicht derjenige, der den Newsletter gestaltet...
Ich werde mir erlauben, diesen Satz als Signatur zu verwenden.
Gruss,
J�rg
--
Postings mit den Domainen @gmail.com, @googlemail.com, @hotmail.com,
@mail.com oder @yahoo.com werden ungelesen entsorgt.
> > E-Mail an newsg...@mikenolte.de wird nur zugestellt, wenn die
> > Betreffzeile "Antwort auf Usenetartikel" ohne Anf�hrungszeichen lautet.
> > <mailto:newsg...@mikenolte.de?subject=Antwort auf Usenetartikel>
> > Rechtschreibfehler sind ungewollt und d�rfen gerne korrigiert werden.
>
> Sorry f�r das Signaturquoten, aber sehe ich das richtig, dass Du Mail an
> die blanke Adresse ohne spezielles Subject nicht annimmst, aber daf�r
> eine praktische URL einf�gst, die es dem bl�desten Bot erm�glicht, die
> Adresse automatisiert zuzuspammen? Irgendwie erschlie�t sich mir nicht
> so richtig, wo da der Sinn liegt...
Ja, das siehst du ganz richtig. Interessanterweise hat es bisher noch
kein einziger Bot geschafft den Link zu benutzen.
Und danke, dass du mich darauf angesprochen hast, ich wollte die
E-Mail-Adresse seit einiger Zeit schon ge�ndert haben, hab aber
irgendwie nie in einem passenden Moment daran gedacht.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Antwort auf Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:newsg...@mikenolte.de?subject=Antwort auf Usenetartikel>
> Von vornherein einen HTML-Newsletter so zu gestalten, dass er
> keinen Browser �berfordert und trotzdem noch anst�ndig aussieht, kann
> doch nicht so schwer sein?
Ersetze "HTML-Newsletter" durch Webseite und geh mit der Frage mal nach
dciwam.
Meine Theorie dazu ist, dass HTML-Newsletter m�glicherweise deswegen so
beschissen aussehen, weil diejenigen, die genug Plan von HTML und CSS
haben um den Newsletter brauchbar zu machen, gleichzeitig auch
diejenigen sind, die Unfug wie HTML in E-Mail erst gar nicht versenden
w�rden, weil sie wissen woran HTML in E-Mail typischerweise scheitert.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
> Jochem Huhmann <j...@gmx.net> wrote:
>
>> > E-Mail an newsg...@mikenolte.de wird nur zugestellt, wenn die
>> > Betreffzeile "Antwort auf Usenetartikel" ohne Anführungszeichen lautet.
>> > <mailto:newsg...@mikenolte.de?subject=Antwort auf Usenetartikel>
>> > Rechtschreibfehler sind ungewollt und dürfen gerne korrigiert werden.
>>
>> Sorry für das Signaturquoten, aber sehe ich das richtig, dass Du Mail an
>> die blanke Adresse ohne spezielles Subject nicht annimmst, aber dafür
>> eine praktische URL einfügst, die es dem blödesten Bot ermöglicht, die
>> Adresse automatisiert zuzuspammen? Irgendwie erschließt sich mir nicht
>> so richtig, wo da der Sinn liegt...
>
> Ja, das siehst du ganz richtig. Interessanterweise hat es bisher noch
> kein einziger Bot geschafft den Link zu benutzen.
Was darauf hindeuten könnte, dass die Spammer nur die paar Header
auswerten, die sie per NNTP direkt abrufen können und nicht den Body
jedes Artikels. Dann aber kann man eine funktionierende Adresse auch in
den Reply-To Header schreiben -- um den zu kriegen, muß man nämlich auch
den kompletten Artikel holen...
> Und danke, dass du mich darauf angesprochen hast, ich wollte die
> E-Mail-Adresse seit einiger Zeit schon geändert haben, hab aber
> irgendwie nie in einem passenden Moment daran gedacht.
Gern geschehen. ;-)
> Jochem Huhmann <j...@gmx.net> wrote:
>
>> Von vornherein einen HTML-Newsletter so zu gestalten, dass er
>> keinen Browser überfordert und trotzdem noch anständig aussieht, kann
>> doch nicht so schwer sein?
>
> Ersetze "HTML-Newsletter" durch Webseite und geh mit der Frage mal nach
> dciwam.
Bloß nicht...
> Meine Theorie dazu ist, dass HTML-Newsletter möglicherweise deswegen so
> beschissen aussehen, weil diejenigen, die genug Plan von HTML und CSS
> haben um den Newsletter brauchbar zu machen, gleichzeitig auch
> diejenigen sind, die Unfug wie HTML in E-Mail erst gar nicht versenden
> würden, weil sie wissen woran HTML in E-Mail typischerweise scheitert.
Ja, kann schon sein. Das ist aber in der Tat ein Kampf gegen
Windmühlenflügel.
> >> Sorry f�r das Signaturquoten, aber sehe ich das richtig, dass Du Mail an
> >> die blanke Adresse ohne spezielles Subject nicht annimmst, aber daf�r
> >> eine praktische URL einf�gst, die es dem bl�desten Bot erm�glicht, die
> >> Adresse automatisiert zuzuspammen? Irgendwie erschlie�t sich mir nicht
> >> so richtig, wo da der Sinn liegt...
> >
> > Ja, das siehst du ganz richtig. Interessanterweise hat es bisher noch
> > kein einziger Bot geschafft den Link zu benutzen.
>
> Was darauf hindeuten k�nnte, dass die Spammer nur die paar Header
> auswerten, die sie per NNTP direkt abrufen k�nnen und nicht den Body
> jedes Artikels. Dann aber kann man eine funktionierende Adresse auch in
> den Reply-To Header schreiben -- um den zu kriegen, mu� man n�mlich auch
> den kompletten Artikel holen...
Es gibt Spam an E-Mail-Adressen, die nur in der Signatur eines
Usenet-Artikels vorgekommen sind.
Nat�rlich kann ich nicht mit letzter Sicherheit bestimmen, wie die
E-Mail-Adresse aus der Signatur eines Usenet-Artikels extrahiert wurde.
Es existieren Sch�dlinge, die E-Mail-Adressen aus einem befallenen
Windows-PC ernten. Beispielsweise Mimail und Sober sind seit Jahren
bekannte ganze Familien von Sch�dlingen, die auf diese Weise arbeiten.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Antwort auf Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Antwort auf Usenetartikel>
> Dann aber kann man eine funktionierende Adresse auch in
> den Reply-To Header schreiben -- um den zu kriegen, mu� man n�mlich auch
> den kompletten Artikel holen...
Ich kriege so gut wie keinen SPAM auf meine Reply-To, aber 'ne Menge auf
meine From (da schaue ich 2mal im Monat rein).
--
In a world without walls and fences,
who needs windows and gates?
Danke. Du mich auch. :-)
Am 12.05.09 15:49 schrieb "Stefan Scholl" unter <ste...@no-spoon.de> in
1T5vejmhIsv2Nv8%ste...@parsec.no-spoon.de:
> Mike Nolte <newsgrou...@mikenolte.de> wrote:
>> Meine Theorie dazu ist, dass HTML-Newsletter m�glicherweise deswegen so
>> beschissen aussehen, weil diejenigen, die genug Plan von HTML und CSS
>> haben um den Newsletter brauchbar zu machen, gleichzeitig auch
>> diejenigen sind, die Unfug wie HTML in E-Mail erst gar nicht versenden
>> w�rden, weil sie wissen woran HTML in E-Mail typischerweise scheitert.
>
> Danke. Du mich auch. :-)
>
Meine Praxis dazu: Ach ja, die Glaubensfrage(n). Hunderte Pressestellen
m�ssen irren und Geld rauswerfen, Copy-Tests ignorieren. Und sie
besch�ftigen nur Irregeleitete. Klingt f�r mich wie radikale
Fahrradfraktion. Bavaria libera - leben und leben lassen.
> Meine Praxis dazu: Ach ja, die Glaubensfrage(n). Hunderte Pressestellen
> m�ssen irren und Geld rauswerfen, Copy-Tests ignorieren. Und sie
> besch�ftigen nur Irregeleitete.
Meine pers�nliche Erfahrung ist da etwas anders. Zumal ich als jemand,
der viel unterwegs ist und darum oft seine Mails per H�ndi abholt, immer
wieder bei Pressestellen r�ckfrage, warum sie nicht einfachen Text
senden k�nnen.
Aus den Antworten und mit etwas Hintergrundwissen �ber die personelle
Besetzung beim Absender ergibt sich daraus als grobe Richtschnur: Dort,
wo Journalisten mit entsprechender Berufserfahrung die ma�geblichen
Entscheider sind, gibt es Nur-Text-Mails. Liegt die Verantwortung
dagegen bei PR-Menschen oder gar beim Marketing, trifft man gelinde
gesagt auf v�lliges Unverst�ndnis f�r sein Anliegen. Die verstehen nicht
einmal, warum man nicht jubelt, wenn sie einem ungefragt vier jeweils
�ber f�nf Megabyte gro�e JPEG-Bilddateien mit den neuen Fotos von den
K�pfen des Vorstands schicken. Die Bilddateien m�ssen, am Rande bemerkt,
nicht etwa deshalb so gro� sein, weil die Adressaten (=Redaktionen)
�blicherweise diese K�pfe f�r W�nde f�llende Starschnitte verwenden,
sondern, ihr ahnt es, "weil die Dateien sonst keine 300 dpi haben".
Beispiele f�r Begr�ndungen, warum man keine Nur-Text-Mails senden kann:
* "Unsere Corporate Identity verlangt, dass in allen Aussendungen unser
Unternehmenslogo enthalten ist." (Nein, PDF schicken w�re viel zu
umst�ndlich, es muss ein eingebundenes TIFF sein ...)
* "Unser CMS kann nur Word-Dateien versenden."
* "Wir machen das, damit es f�lschungssicher ist." (Darum verschickt man
Word-Dateien, aus denen die Empf�nger sich lustige Musterbriefb�gen
basteln k�nnten)
* "Also bei uns sieht das gut aus." (Schade nur, dass auf meinem Rechner
deren absonderliche Haus- und Schmuckschriften nicht installiert sind)
* "Hier haben alle Word auf dem Rechner." <seufz>
usw. usf.
Ich will jetzt gar nicht klagen �ber Pressestellen, bei denen die reine
Versandarbeit an Praktikanten delegiert wird. Dass die Mails dann mit
st�ndig wechselnden Absendern verschickt werden, ist sicher erprobt
("macht neugierig", oder so). Okay, ab und zu kommen die Mails schon mal
ohne den Anhang oder mit der falschen Version der Meldung. Bisschen
Schwund ist immer. Allemal besser als Newsletter, die auf zum Download
unter "c:\$LANGER_PFAD" bereitstehende Dokumente verweisen.
Gr��e vom Niederrhein,
Frank
> <mailto:news...@mikenolte.de?subject=Antwort auf Usenetartikel>
Jedenfalls ist dies keine g�ltige URL. Daran �ndern auch die
Klammern < > nichts. Leerzeichen m�ssen durch %20 maskiert werden.
Also: subject=Antwort%20auf%20Usenetartikel
--
� superscript 1 � fraction 1/4 � D stroke � d stroke
� superscript 2 � fraction 1/2 � Thorn � thorn
� superscript 3 � fraction 3/4 � Y acute � y acute
� multiply sign � broken bar
> Glaubensfrage(n). Hunderte Pressestellen m�ssen irren und Geld rauswerfen,
> Copy-Tests ignorieren. Und sie besch�ftigen nur Irregeleitete.
Wenn es wenigstens nur noch hunderte w�ren, dann w�re das schon ein
riesiger Fortschritt.
"F�r Paralele bietet Google fast eine Million Treffer, es kann also gar
nicht sein, dass das die falsche Schreibweise ist."
Und bevor du mich das n�chste mal ebenso grundlos wie unqualifiziert
anfeindest, wirst du freundlicherweise zur Kenntnis nehmen, dass es
hierbei keineswegs um eine Glaubensfrage geht und der OP von mir in
<1izdw9e.kn...@www.mike-nolte.de> bereits letzte Woche die
L�sung f�r sein Problem genannt bekam.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Antwort auf Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Antwort auf Usenetartikel>
> > <mailto:news...@mikenolte.de?subject=Antwort auf Usenetartikel>
>
> Jedenfalls ist dies keine g�ltige URL. Daran �ndern auch die
> Klammern < > nichts. Leerzeichen m�ssen durch %20 maskiert werden.
> Also: subject=Antwort%20auf%20Usenetartikel
Mit welcher Norm begr�ndest du diese Behauptung?
Hier draufklick...
<mailto:news...@mikenolte.de?subject=Leerzeichen%20muessen%20via%20%2520%20maskiert%20werden&body=Auch%20wenn%20Du%20es%20nicht%20glaubst>
--> <mfwpnp0g...@news.southcity.de>
F�r Benutzer Offline-Newsreader:
<http://groups.google.com/groups?as_umsgid=mfwpnp0g...@news.southcity.de>
(Google zickt mal wieder)
Somit auf
<http://groups.google.com/group/de.comm.software.mozilla.browser/topics>
nach Thread
| Subject: Leerzeichen in URL
| Date: Sun, 10 May 2009 11:16:45 +0200
| From: J�rgen Schmadlak <news-so...@arcor.de>
| Organization: A South City Site
| Newsgroups: de.comm.software.mozilla.browser
suchen.
Gruss Markus
--
Dieser Beitrag entstand durch hirnloses Herumtippen auf der Tastatur.
Jeglicher Sinn und Zusammenhang darin waere rein zufaellig und nicht
beabsichtigt.
DVD-Sammlung: http://www.howalgonium.ch/dvdsammlung.html
Am 12.05.09 19:12 schrieb "Mike Nolte" unter
<newsgrou...@mikenolte.de> in
1izm9nt.13l...@www.mike-nolte.de:
>
> Und bevor du mich das n�chste mal ebenso grundlos wie unqualifiziert
> anfeindest, wirst du freundlicherweise zur Kenntnis nehmen, dass es
> hierbei keineswegs um eine Glaubensfrage geht und der OP von mir in
> <1izdw9e.kn...@www.mike-nolte.de> bereits letzte Woche die
> L�sung f�r sein Problem genannt bekam.
>
Sorry, nicht pers�nlich gemeint. Es dreht sich ja nicht mehr um das Problem
des OP - und sch�n dass Du ihm gehofen hast - sondern einmal mehr um die
Glaubensfrage HTML. Indes trau keiner Statistik, die du nicht selbst
gef�lscht hast. Diese puren im Zahlenmeiereien sind interessegeleitet und
spiegeln nicht die berufliche Realit�ten wider. Derartige Ergebnisse, das
mag im IT-Bereich gelten, in Bereichen wie PR und �ffentlichkeitsarbeit,
Graphik, Film, Verlagen etc. ist HTML usus. Egal was selbstreferenzierte und
nicht hinterfragte Zahlenspielereien aus den Weiten des Netzes suggerieren.
Ich bin von Berufs wegen Informationen aus dem Netz als einziger Quelle
generell misstrauisch, da qualitativ in vielen Bereichen (Recht, Medizin)
abseits des eigenes Sujets oft schlecht - und unprofessionell. Und ein Link,
nochmals sorry, verursacht bei mir ein H�steln; schlie�lich wird Unwahrheit
auch dadurch nicht wahrer, indem hunderte Blogs aufeinander verweisen. Sie
kochen dadurch immer noch im eigenen Saft.
Wenn Dich methodisch gut belegte Untersuchungen zum Mediennutzungsverhalten
interessieren: Die findest Du - vermutlich mit Ausnahme von IT und
Verwandten - nicht im Netz, sondern in Fachzeitschriften,
z.B.Querschnittsanalysen und Langzeituntersuchungen bei den Werbeateilungen
der �R-Sendeanstalten wie die AV Massenkommunikation - abgedruckt in Media
Perspektiven. (sp�ter dann einige auch als pdf)
Gru�
radulph
RFC 1738 Uniform Resource Locators (URL)
Dort steht das mit den Leerzeichen.
RFC 2368 The mailto URL scheme
Mit Beispielen die Leerzeichen als %20 kodieren.
> RFC 2368 The mailto URL scheme
Die Passage bez�glich des Space war mir bisher entgangen. Danke f�r den
Hinweis, ich habe eine entsprechende �nderung vorgenommen.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
> in Bereichen wie PR und �ffentlichkeitsarbeit, Graphik, Film, Verlagen
> etc. ist HTML usus
Und weil es deiner Meinung nach hinreichend viele Leute machen wird
richtig?
> in Bereichen wie PR und �ffentlichkeitsarbeit, Graphik, Film, Verlagen
> etc. ist HTML usus
Und weil es deiner Meinung nach hinreichend viele Leute machen wird
richtig?
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
Am 13.05.09 10:43 schrieb "Mike Nolte" unter
<newsgrou...@mikenolte.de> in 1iznhsm.s3...@www.mike-nolte.de:
> Radulph Kader <radulp...@web.de> wrote:
>
>> in Bereichen wie PR und �ffentlichkeitsarbeit, Graphik, Film, Verlagen
>> etc. ist HTML usus
>
> Und weil es deiner Meinung nach hinreichend viele Leute machen wird
> richtig?
>
Ja!
Viele technischen Argumente von fr�her wie Bandbreite sind antiquiert. HTML
und PDF erleichtern in der t�glichen Arbeit die Orientierung, Selektion. In
dieser G�terabw�gung stehen technisch interdependierte Argumente dagegen
hintenan.
Gru�
Radulph
> >> in Bereichen wie PR und �ffentlichkeitsarbeit, Graphik, Film, Verlagen
> >> etc. ist HTML usus
> >
> > Und weil es deiner Meinung nach hinreichend viele Leute machen wird
> > richtig?
> >
> Ja!
Selber schuld.
> Viele technischen Argumente von fr�her wie Bandbreite sind antiquiert. HTML
> und PDF
Dann nimm PDF und nicht HTML.
> In dieser G�terabw�gung stehen technisch interdependierte Argumente dagegen
> hintenan.
Ganz vorne sollte aber die Sicherheit stehen. Die ist bei den
M�glichkeiten, die HTML in Emails bietet nicht gegeben. F�r mich der
Hauptgrund eine Emailprogramm zu nutzen, dass mit HTML gar nicht erst
anzeigt.
MfG, Metti.
Am 14.05.09 13:18 schrieb "Stefan Mettenbrink" unter
<stefan.me...@web.de> in gugv7b$t57$1...@news.albasani.net:
>
> Dann nimm PDF und nicht HTML.
>
>> In dieser G�terabw�gung stehen technisch interdependierte Argumente dagegen
>> hintenan.
>
> Ganz vorne sollte aber die Sicherheit stehen. Die ist bei den
> M�glichkeiten, die HTML in Emails bietet nicht gegeben. F�r mich der
> Hauptgrund eine Emailprogramm zu nutzen, dass mit HTML gar nicht erst
> anzeigt.
>
Ist doch halbwegs gegeben - Serververbindungen erlaubt Entourage nur auf
manuellen Klick, komlexes HTML aus. Ein gutes Anti-Spam-Programm wie
SpamSieve. Die Gefahren im Browser sind doch viel komplexer - oder? Ich
meine, da wird aus Netzhistorie immer noch drauf rumgeritten, weil ein paar
Gurus das mal predigten.
Und Versicherer nennen das schlicht Risikofolgenabsch�tzung - Pro und
Contra, Chancen und Risiken einer Innovation (da wird z.B. Handystrahlung
gef�hrlicher wahrgenommen als die Fahrt im eigenen Auto - so viel zur
subjektiven Einsch�tzung, die nat�rlich - gen�hrt will sie sein - f�r gute
Gesch�ftsmodelle taugt).
Gerade heute haben sogar die Gr�nen auf HTML umgestellt. Das ist nicht mehr
aufzuhalten und hat genau diese Vorteile, wie beim Zeitungslayout ab ca.
1890 auf mehr Lesefreundlichkeit mit Bildern und weniger Umlauf umgestellt
wurde: Boulevard - Nachrichteninhalt schnell erfassbar machen.
Dann wird man nicht umhinkommen an der Sicherheitsstelle nachzubessern. Da
ist mit Sicherheit was dran. Trotz aller Gefahren: HTML-E-Mail ist da, die
Leute werden es benutzen. Mit dem Flieger, dem Auto war's nicht anders
(empirisch gesehen verunfallten fr�her das zigfache mehr Menschen/Flieger
als heute). Das l�sst auch in Sachen HTML hoffen :)
Gru�
Radulph
Entourage konnte noch aufgetrieben werden. Auf Windows-Seite auch
mit IE 5.5 getestet. Validiertes HTML 4.01 und CSS 2.1.
Textversion drin (mit mutt getestet). Firefox, Safari, Google
Chrome 2, IE 5.5 bis IE 8, ..., Outlook, Thunderbird, Entourage
auf Mac, ...
Und am Ende bekommt man ein Fax(!) von einem Empf�nger gezeigt,
bei dem es fehlerhaft aussieht. Ohne Hinweis auf verwendete
Software. Kein Screenshot, also kann man auch nicht erraten
welche Software es ist.
Selbst im Netscape Navigator 4.7 sah es nicht so kaputt (aber
trotzdem kaputt :-) aus. Auch ein �berempfindliches Amaya hat
keine Probleme.
> Und am Ende bekommt man ein Fax(!) von einem Empf�nger gezeigt,
> bei dem es fehlerhaft aussieht. Ohne Hinweis auf verwendete
> Software. Kein Screenshot, also kann man auch nicht erraten
> welche Software es ist.
Lotus Notes ist immer ein guter Kandidat, wenn's darum geht, dass etwas
nicht funktioniert. :-)
Tja, HTML in E-Mail halt. Ich habe nie behauptet, dass das eine gute
Idee ist.
Ja, Notes-Usern w�rde man zutrauen E-Mails auszudrucken und dann
zu faxen. Aber alles nur Spekulation.
> Tja, HTML in E-Mail halt. Ich habe nie behauptet, dass das eine gute
> Idee ist.
Mich fragt auch keiner. Rund 20 Jahre E-Mail. Privat verwende ich
Mutt f�r E-Mail und Tin f�r News.
> > Tja, HTML in E-Mail halt. Ich habe nie behauptet, dass das eine gute
> > Idee ist.
>
> Mich fragt auch keiner. Rund 20 Jahre E-Mail. Privat verwende ich
> Mutt f�r E-Mail und Tin f�r News.
Meine Rede. Wer genug _Erfahrung_ mit dem Medium E-Mail hat, der wei�
auch warum seine Softwareauswahl so (oder so �hnlich) ausf�llt.
> Wie sieht das unter MacOS X aus? Was benutzen die E-Mailprogramme
> dort um HTML anzuzeigen?
Warum sollte in E-Mail-Client HTML anzeigen k�nnen?
Verlangst Du von der Post auch, da� sie Dir Strom liefert und deinen
M�ll abholt?
Gerhard
--
"Ich habe ja nichts zu verbergen".
Nunja:
<http://daten-speicherung.de/wiki/index.php/
F�lle_von_Datenmissbrauch_und_-irrt�mern>
> ist HTML usus.
Na und?
Gef�hrlich ist es trotzdem.
Oder nenne mir mal einen Mailclient mit eingebautem Werbefilter,
Spamblocker, Phishingschutz und Flashblocker.
> Gerade heute haben sogar die Gr�nen auf HTML umgestellt. Das ist nicht mehr
> aufzuhalten und hat genau diese Vorteile, wie beim Zeitungslayout ab ca.
> 1890 auf mehr Lesefreundlichkeit mit Bildern und weniger Umlauf umgestellt
> wurde: Boulevard - Nachrichteninhalt schnell erfassbar machen.
HTML hat nichts mit Layout zu tun.
> Und am Ende bekommt man ein Fax(!) von einem Empf�nger gezeigt,
> bei dem es fehlerhaft aussieht.
Mit reinem Text w�re das nicht passiert. ;-)
Am 14.06.09 16:06 schrieb "Gerhard Torges" unter <deaf...@hotmail.com> in
1j1b62t.j0xgjj1p9rr97N%deaf...@hotmail.com:
> Radulph Kader <radulp...@web.de> wrote:
>
>> Gerade heute haben sogar die Gr�nen auf HTML umgestellt. Das ist nicht mehr
>> aufzuhalten und hat genau diese Vorteile, wie beim Zeitungslayout ab ca.
>> 1890 auf mehr Lesefreundlichkeit mit Bildern und weniger Umlauf umgestellt
>> wurde: Boulevard - Nachrichteninhalt schnell erfassbar machen.
>
> HTML hat nichts mit Layout zu tun.
Heute wieder von Apple die neuesten Angebote bekommen - in HTML.
>
Ho ho - Ho-Chi-Minh ;)
> > Wie sieht das unter MacOS X aus? Was benutzen die E-Mailprogramme
> > dort um HTML anzuzeigen?
>
> Warum sollte in E-Mail-Client HTML anzeigen k�nnen?
Das spielt doch keine Rolle. Mail-Clients k�nnen nunmal HTML anzeigen,
und der OP hat dazu eine Frage.
Willkommen in der Gegenwart.
Gru�, Nils
> Oder nenne mir mal einen Mailclient mit eingebautem Werbefilter,
> Spamblocker, Phishingschutz und Flashblocker.
Gibt's keinen. Und Flash h�ttest du noch aufz�hlen k�nnen.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anf�hrungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
> Heute wieder von Apple die neuesten Angebote bekommen - in HTML.
> >
> Ho ho - Ho-Chi-Minh ;)
<http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink
=on§Hdr=on&spellToler=std&search=markup>
;-)))
> Und Flash h�ttest du noch aufz�hlen k�nnen.
www.fielmann.de. ;-)
> Mail-Clients k�nnen nunmal HTML anzeigen,
Manche, ja.
> und der OP hat dazu eine Frage.
Weil er von falschen Voraussetzungen ausgeht.
Au�erdem ist seine Frag zu ungenau.
> > > Flashblocker
> >
> > Und Flash h�ttest du noch aufz�hlen k�nnen.
>
> www.fielmann.de. ;-)
Da kannst du mal sehen wie gr�ndlich ich Flash filtern lasse. ;-)
> Heute wieder von Apple die neuesten Angebote bekommen - in HTML.
Was nichts daran �ndert, dass HTML nichts mit Layout zu tun hat.
> Was nichts daran �ndert, dass HTML nichts mit Layout zu tun hat.
Im Falle von Newslettern per Mail stimmt das leider nicht.
Wei� Nils (der ab und zu HTML-Mails f�r Outlook-Nutzer bauen muss)
> > Was nichts daran �ndert, dass HTML nichts mit Layout zu tun hat.
>
> Im Falle von Newslettern per Mail stimmt das leider nicht.
HTML mhat nichts mit Layout zu tun. Das stimmt immer. Wenn du etwas
anderes glaubst, dann unterliegst du leider vermutlich einem
Missverst�ndnis.
> Oder nenne mir mal einen Mailclient mit eingebautem Werbefilter,
> Spamblocker, Phishingschutz und Flashblocker.
Mozilla Seamonkey?
http://www.seamonkey-project.org/
Die Add-ons sind jedenfalls alle verf�gbar, und ich w�rde doch annehmen,
dass sie dann auch zum Filtern von HTML-Mail verwendet werden.
Adblock Plus:
https://addons.mozilla.org/de/seamonkey/addon/1865
Flashblock:
https://addons.mozilla.org/de/seamonkey/addon/433
Mozilla Thunderbird:
http://www.mozillamessaging.com/en-US/thunderbird/
Adblock Plus:
https://addons.mozilla.org/de/thunderbird/addon/1865
Viele Gr��e,
Hartmut
> > Oder nenne mir mal einen Mailclient mit eingebautem Werbefilter,
> > Spamblocker, Phishingschutz und Flashblocker.
>
> ?
>
> ich w�rde doch annehmen
Der Fragesteller suchte nach der Nennung eines E-Mail-Clients, nicht
nach einer Spekulation.
> Nils Hott <ma...@nilshott.com> wrote:
>
>> > Was nichts daran ändert, dass HTML nichts mit Layout zu tun hat.
>>
>> Im Falle von Newslettern per Mail stimmt das leider nicht.
>
> HTML mhat nichts mit Layout zu tun. Das stimmt immer. Wenn du etwas
> anderes glaubst, dann unterliegst du leider vermutlich einem
> Missverständnis.
Nur dass diesem Missverständnis ungefähr 99% aller User unterliegen und
wenn man das auf HTML plus CSS erweitert, dann ist das noch nicht einmal
mehr ein Missverständnis. In der Praxis ist Layout und hübsches Aussehen
die zentrale Daseinsberechtigung von HTML in Email. Wer ernsthaft etwas
anderes behaupten will, der versteift sich bestimmt auch darauf, dass
man mit Computern nur rechnen kann und sonst nix. Das ist etwa auf der
gleichen Ebene richtig...
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
> > HTML mhat nichts mit Layout zu tun. Das stimmt immer. Wenn du etwas
> > anderes glaubst, dann unterliegst du leider vermutlich einem
> > Missverst�ndnis.
>
> In der Praxis ist Layout und h�bsches Aussehen die zentrale
> Daseinsberechtigung von HTML in Email.
Dem habe ich nichts mehr hinzuzuf�gen. Leider. ;)
Gru�, Nils
> > HTML mhat nichts mit Layout zu tun. Das stimmt immer. Wenn du etwas
> > anderes glaubst, dann unterliegst du leider vermutlich einem
> > Missverst�ndnis.
>
> Nur dass diesem Missverst�ndnis ungef�hr 99% aller User unterliegen
Gl�cklicherweise stimmt auch das nicht.
> HTML mhat nichts mit Layout zu tun.
Allerdings hat CSS etwas mit Layout zu tun.
Die ganze Diskussion ist etwas... elit�r. Tatsache ist, dass
HTML/CSS-Mails von Kunden auch *verlangt* werden.
Ich werde mir das Gesch�ft nicht kaputt machen, indem ich die Kunden
beschimpfe.
Was wirklich unn�tig ist: die Interpretation sogenannter aktiver Inhalte
in Mails. Javascript und anderer eingebetteter Unsinn ist wirklich
gef�hrlich (ja, auch Bilder).
Servus,
Konni
--
"Die Unmenschlichkeit des praktizierten Atheismus haben im ver-
gangenen Jahrhundert die gottlosen Regime des Nationalsozialismus
und des Kommunismus mit ihren Straflagern, ihrer Geheimpolizei und
ihren Massenmorden in grausamer Weise bewiesen" -- Bischof Mixa
> Der Fragesteller suchte nach der Nennung eines E-Mail-Clients, nicht
> nach einer Spekulation.
Ich habe zwei genannt, und Add-Block steht f�r beide zur Verf�gung.
Hartmut
Nein. CSS hat was mit Darstellungsstilen zu tun. Lass dir einfach mal
von einem Drucker (nicht die grauen Kaesten, sondern die Leute, deren
Beruf es ist, Layouts zu Papier zu bringen) den Unterschied erklaeren.
Auserdem ist CSS *prinzipiell* dazu da, vom Benutzer durch eigene CSS
Stile ausgetauscht zu werden. Die schwachsinnige Annahme einiger
infantiler Webdesignerschwachmaten, Benutzer wuerden ihr CSS in IE
6.0053.0000 (Deutsch, Standardeinstellungen) bei 1280x1024
Bildpunkten Bildschirmaufloesung und Taskleiste unten, 30 pixel hoehe
verwenden, ist halt so realtiaetsfremd wie die Annahme, die Erde sei
eine Scheibe, der Mond bestehe aus Emmentaler Kaese und die Sonne geht
morgens nur deswegen auf, weil irgend ein Vogel singt.
Realitaet ist keine Demokratie: Unsinn wird nicht deswegen wahr, nur weil
genug Idioten daran glauben.
> Die ganze Diskussion ist etwas... elitᅵr. Tatsache ist, dass
> HTML/CSS-Mails von Kunden auch *verlangt* werden.
... sucht man sich einen anderen Kunden, wenn man ihm den Schwachsinn
nicht ausreden kann. Aber ich vergessse, ich bin ja auch Berater, kein
Erfuellungsknecht.
> Ich werde mir das Geschᅵft nicht kaputt machen, indem ich die Kunden
> beschimpfe.
> Was wirklich unnᅵtig ist: die Interpretation sogenannter aktiver Inhalte
> in Mails. Javascript und anderer eingebetteter Unsinn ist wirklich
> gefᅵhrlich (ja, auch Bilder).
Wie waere es, dem Kunden auf seine Kosten zu erklaeren, warum er falsch
liegt, und wie er es besser machen kann?
Wenn ein Kunde A will, das aber technischer Schwachsinn ist, dann
erklaere ich ihm, warum A technischer Schwachsinn ist, dass sein
Problem, dass er mit A versucht zu loesen mit B oder C loesbar ist,
bennenne die Vor- und Nachteile und lasse ihm dann Entscheiden, ob er
mit Loesung A und jemand anderem ein Projekt gegen die Wand fahren
moechte, oder ob er doch lieber B oder C machen will.
Ein unzufriedener Kunde "Warum haben Sie mir das nicht ausgeredet!"
kann dir dein Geschaeft mehr kaputt machen als ein Nichtkunde.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Realitaet ist keine Demokratie: Unsinn wird nicht deswegen wahr, nur weil
> genug Idioten daran glauben.
/signed
> Wenn ein Kunde A will, das aber technischer Schwachsinn ist, dann
> erklaere ich ihm, warum A technischer Schwachsinn ist, dass sein
> Problem, dass er mit A versucht zu loesen mit B oder C loesbar ist,
> bennenne die Vor- und Nachteile und lasse ihm dann Entscheiden, ob er
> mit Loesung A und jemand anderem ein Projekt gegen die Wand fahren
> moechte, oder ob er doch lieber B oder C machen will.
Das mache ich seit Jahren so und ich habe damit beste Erfahrungen
gemacht. Gerade bei HTML in E-Mail ist es bisher immer besonders leicht
gewesen zu demonstrieren wie das Vorhaben des Kunden durch HTML
scheitern wird.
> Nein. CSS hat was mit Darstellungsstilen zu tun.
*seufz*
> Auserdem ist CSS *prinzipiell* dazu da, vom Benutzer durch eigene CSS
> Stile ausgetauscht zu werden.
Wie hoch sch�tzt du den Anteil der User, die das tats�chlich tun?
> Die schwachsinnige Annahme einiger
> infantiler Webdesignerschwachmaten, Benutzer wuerden ihr CSS in IE
> 6.0053.0000 (Deutsch, Standardeinstellungen) bei 1280x1024
> Bildpunkten Bildschirmaufloesung und Taskleiste unten, 30 pixel hoehe
> verwenden, ist halt so realtiaetsfremd wie die Annahme, die Erde sei
> eine Scheibe, der Mond bestehe aus Emmentaler Kaese und die Sonne geht
> morgens nur deswegen auf, weil irgend ein Vogel singt.
Trotzdem ist es eine, in Grenzen, vern�nftige N�herung an die Natur.
Dass die V�gel bei Sonnenaufgang singen, ist eine vern�nftige Annahme,
ebenso, dass ein gro�er Teil der Nutzer den PC wie aus der Schachtel
nutzt.
Wir, insbesondere hier[tm], wissen nat�rlich dass das alles hm.. eine
sehr begrenzte Sicht auf die Realit�t ist. Trotzdem kommt man mit dieser
Einstellung erstaunlich weit.
> Realitaet ist keine Demokratie: Unsinn wird nicht deswegen wahr, nur weil
> genug Idioten daran glauben.
Das sind nicht unbedingt Idioten. Ich mag auch nicht gerne meine Kunden
beleidigen (manche schon, aber das ist eine andere Story).
> > Die ganze Diskussion ist etwas... elit�r. Tatsache ist, dass
> > HTML/CSS-Mails von Kunden auch *verlangt* werden.
>
> ... sucht man sich einen anderen Kunden, wenn man ihm den Schwachsinn
> nicht ausreden kann. Aber ich vergessse, ich bin ja auch Berater, kein
> Erfuellungsknecht.
Mir brauchst Du das nicht erkl�ren.
> > Ich werde mir das Gesch�ft nicht kaputt machen, indem ich die Kunden
> > beschimpfe.
> > Was wirklich unn�tig ist: die Interpretation sogenannter aktiver Inhalte
> > in Mails. Javascript und anderer eingebetteter Unsinn ist wirklich
> > gef�hrlich (ja, auch Bilder).
>
> Wie waere es, dem Kunden auf seine Kosten zu erklaeren, warum er falsch
> liegt, und wie er es besser machen kann?
Du hast das Argument "Die anderen k�nnen es doch auch!" schon einmal
geh�rt?
> Wenn ein Kunde A will, das aber technischer Schwachsinn ist,
Es ist kein technischer Schwachsinn.
> dann
> erklaere ich ihm, warum A technischer Schwachsinn ist, dass sein
> Problem, dass er mit A versucht zu loesen mit B oder C loesbar ist,
> bennenne die Vor- und Nachteile und lasse ihm dann Entscheiden, ob er
> mit Loesung A und jemand anderem ein Projekt gegen die Wand fahren
> moechte, oder ob er doch lieber B oder C machen will.
Genau so mache ich es auch. Will der Kunde trotzdem A, dann kriegt er
A.
> Ein unzufriedener Kunde "Warum haben Sie mir das nicht ausgeredet!"
> kann dir dein Geschaeft mehr kaputt machen als ein Nichtkunde.
M�glich.
> > Wie waere es, dem Kunden auf seine Kosten zu erklaeren, warum er falsch
> > liegt, und wie er es besser machen kann?
>
> Du hast das Argument "Die anderen k�nnen es doch auch!" schon einmal
> geh�rt?
Nach einer kleinen Demonstration eines Teils der m�glichen Gr�nde f�r
das scheitern von HTML in E-Mail, wollte mir gegen�ber bisher niemand
diese Behauptung aufrecht halten.
> Nach einer kleinen Demonstration eines Teils der m�glichen Gr�nde f�r
> das scheitern von HTML in E-Mail, wollte mir gegen�ber bisher niemand
> diese Behauptung aufrecht halten.
Es gibt aber auch Kunden, die sagen: Solange es in Outlook 2003 gut
aussieht ist unsere Zielgruppe bedient. Und die schon seit Jahren
HTML-Mails verschicken. Wenn du die nicht bedienst, dann macht jemand
anders den Job und du bist als Dienstleister gestorben.
In meinem Falle sind das sehr wichtige Kunden, auf die ich trotz
besseren Wissens, was HTML ist und was man damit eigentlich besser nicht
machen sollte, nicht verzichten wollen w�rde.
Also baue ich munter HTML-Newsletter, und alle bis auf ein paar
Verfechter der reinen Lehre sind happy.
Gru�, Nils
> Mike Nolte <newsgrou...@mikenolte.de> wrote:
>
> > Nach einer kleinen Demonstration eines Teils der m�glichen Gr�nde f�r
> > das scheitern von HTML in E-Mail, wollte mir gegen�ber bisher niemand
> > diese Behauptung aufrecht halten.
>
> Es gibt aber auch Kunden, die sagen: Solange es in Outlook 2003 gut
> aussieht ist unsere Zielgruppe bedient. Und die schon seit Jahren
> HTML-Mails verschicken.
Das sind genau die, die am peinlichsten ber�hrt sind, sobald sie sehen,
wie beschissen ihre Aussendungen pl�tzlich aussehen, wenn jemand etwas
anderes benutzt, als das Outlook, dass sie irrt�mlich als allgegenw�rtig
vermuteten. Dementsprechend sauer sind die auch immer auf den
Vollidioten, der es seit Jahren unterlassen hat sie hinreichend zu
warnen.
> In meinem Falle sind das sehr wichtige Kunden, auf die ich trotz
> besseren Wissens, was HTML ist und was man damit eigentlich besser nicht
> machen sollte, nicht verzichten wollen w�rde.
>
> Also baue ich munter HTML-Newsletter
Bleibt nur zu hoffen, dass du akribisch darauf achtest, dass der
obligatorische Textteil der E-Mail ordentlich aussieht, und dass deine
niemals merken, wie du sie f�r dumm verkaufst.
> Bleibt nur zu hoffen, dass du akribisch darauf achtest, dass der
> obligatorische Textteil der E-Mail ordentlich aussieht, und dass deine
> niemals merken, wie du sie f�r dumm verkaufst.
Was Leute wie du leider nie verstehen ist: Es gibt Kunden, die weder
dumm sind noch als dumm verkauft werden. Und die trotzdem das haben
wollen, was du so schei�e findest.
Soll mir nat�rlich recht sein. Ich lebe gut davon, und du kannst gut
schlafen, weil du mich als Idioten bezeichnen kannst.
Wie gesagt, allen ist gedient.
Gru�, Nils (f'up)
> > Bleibt nur zu hoffen, dass du akribisch darauf achtest, dass der
> > obligatorische Textteil der E-Mail ordentlich aussieht, und dass deine
> > niemals merken, wie du sie f�r dumm verkaufst.
>
> Was Leute wie du leider nie verstehen ist: Es gibt Kunden, die weder
> dumm sind noch als dumm verkauft werden. Und die trotzdem das haben
> wollen
Nur so lange sie es nicht besser wissen, wozu du nicht beitr�gst,
weshalb du hoffen solltest.
> Ich lebe gut davon, und du kannst gut schlafen, weil du mich als Idioten
> bezeichnen kannst.
Ich habe nicht vor dich als irgendetwas zu bezeichnen. Ich blicke jedoch
auf Leute zur�ck, die so handelten wie du, deren ehemalige Kunden von
mir mal etwas gezeigt bekommen haben.
BTDT, Antwort darauf: "Schoen fuer Sie, von uns werden sie nicht
verarscht." Meistens bedeutet das lediglich einen Aufschub des
Projekts um die Zeitspanne, die der Kunde braucht um zu merken,
dass der andere das Projekt gegen die Wand gefahren hat.
>> Wenn ein Kunde A will, das aber technischer Schwachsinn ist,
>
> Es ist kein technischer Schwachsinn.
Doch. Wenn aber /du/ das schon nicht weist, kannst du den Kunden
natuerlich nicht davon ueberzeugen.
>> dann
>> erklaere ich ihm, warum A technischer Schwachsinn ist, dass sein
>> Problem, dass er mit A versucht zu loesen mit B oder C loesbar ist,
>> bennenne die Vor- und Nachteile und lasse ihm dann Entscheiden, ob er
>> mit Loesung A und jemand anderem ein Projekt gegen die Wand fahren
>> moechte, oder ob er doch lieber B oder C machen will.
>
> Genau so mache ich es auch. Will der Kunde trotzdem A, dann kriegt er
> A.
Ich lasse A dann von jemand anderen machen, der kein Problem hat,
seinen Ruf zu ruinieren. Ich will Kunden, bei denen ich immer wieder
Projekte machen kann, und bei deren bekannten Unternehmen man auch
Chancen haben will.
>> Ein unzufriedener Kunde "Warum haben Sie mir das nicht ausgeredet!"
>> kann dir dein Geschaeft mehr kaputt machen als ein Nichtkunde.
>
> Mᅵglich.
BTST.
Juergen
> Konni Scheller <ksch...@ochs.franken.de> wrote:
> > Du hast das Argument "Die anderen k�nnen es doch auch!" schon einmal
> > geh�rt?
Du hast bestimmt auch schon mal das Gegenargument: "Scheisse muss gut
schmecken. 1000 Fliegen k�nnen sich nicht irren" geh�rt. ;-)
> Nach einer kleinen Demonstration eines Teils der m�glichen Gr�nde f�r
> das scheitern von HTML in E-Mail, wollte mir gegen�ber bisher niemand
> diese Behauptung aufrecht halten.
So mache ich das auch. Einmal gezeigt wie der potentielle Empf�nger den
HTML-Zeichensalat u.U. angezeigt bekommt und schon kam sinngem�� die
Ansage "Lassen wir das lieber sein".
Ich w�rde ernsthaft Bauchschmerzen haben, mein Geld mit etwas zu
verdienen, von dem ich weiss, das es eigentlich Bl�dsinn ist.
Zugegeben: wenn man vor der Wahl "Arbeitslos" oder "f�r Geld Mist bauen"
steht, mag die Entscheidung nicht leicht sein. Gl�cklicherweise bin ich
von dieser Entscheidung bisher verschont geblieben. Das muss dann
wirklich jeder f�r sich selbst abmachen.
> Du hast bestimmt auch schon mal das Gegenargument: "Scheisse muss gut
> schmecken. 1000 Fliegen k�nnen sich nicht irren" geh�rt. ;-)
;-)
> > Nach einer kleinen Demonstration eines Teils der m�glichen Gr�nde f�r
> > das scheitern von HTML in E-Mail, wollte mir gegen�ber bisher niemand
> > diese Behauptung aufrecht halten.
>
> So mache ich das auch. Einmal gezeigt wie der potentielle Empf�nger den
> HTML-Zeichensalat u.U. angezeigt bekommt und schon kam sinngem�� die
> Ansage "Lassen wir das lieber sein".
"Meine Kunden haben $TECHNISCHE_AUSSTATTUNG". Ja. Ich wei�, dass man
Zielgruppen schlecht �ber technische Ausstattung definieren kann.
Konkret: welcher E-Mail-Client kann denn *kein* HTML anzeigen?
> Ich w�rde ernsthaft Bauchschmerzen haben, mein Geld mit etwas zu
> verdienen, von dem ich weiss, das es eigentlich Bl�dsinn ist.
Es kommt hier stark auf die Definition von "eigentlich" an.
> > Ich w�rde ernsthaft Bauchschmerzen haben, mein Geld mit etwas zu
> > verdienen, von dem ich weiss, das es eigentlich Bl�dsinn ist.
>
> Es kommt hier stark auf die Definition von "eigentlich" an.
Lass gut sein. Die Jungs sind Windm�hlen. ;)
Gru�, Nils
> Konkret: welcher E-Mail-Client kann denn *kein* HTML anzeigen?
Abgesehen von den E-Mail-Clients, die es schon l�nger gibt als HTML
selbst, nat�rlich auch jeder E-Mail-Client, der konfiguriert wurde kein
HTML darzustellen, worauf der betroffene Benutzer wiederum gelegentlich
keinen Einfluss hat, weil er seinen Rechner selbst konfigurieren nicht
kann oder nicht darf.
In diesem Zusammenhang ist die viel wertvollere Information, dass jeder
E-Mail-Client reinen Text kann, weil reiner Text der obligatorische Teil
der E-Mail ist.
Reiner Text geht immer, und zwar v�llig unabh�ngig wie hoch man den
Anteil derjenigen einsch�tzt, die HTML ganz oder teilweise darstellen
k�nnen.
> Konkret: welcher E-Mail-Client kann denn *kein* HTML anzeigen?
Meiner.
... und das ist auch gut so.
MfG, Metti.
> Abgesehen von den E-Mail-Clients, die es schon l�nger gibt als HTML
> selbst,
Die da w�ren?
Ich kann mich noch dunkel an Claris Emailer erinnern, der kein HTML
konnte.
> nat�rlich auch jeder E-Mail-Client, der konfiguriert wurde kein
> HTML darzustellen, worauf der betroffene Benutzer wiederum gelegentlich
> keinen Einfluss hat, weil er seinen Rechner selbst konfigurieren nicht
> kann oder nicht darf.
Oder es m�glicherweise gar nicht kann oder nicht wei�, dass man das
�berhaupt konfigurieren kann. Oder dass derjenige noch nie etwas von
HTML geh�rt hat.
> In diesem Zusammenhang ist die viel wertvollere Information, dass jeder
> E-Mail-Client reinen Text kann, weil reiner Text der obligatorische Teil
> der E-Mail ist.
Reiner Text geht immer und sollte immer als Alternativversion dabei
sein.
> > In diesem Zusammenhang ist die viel wertvollere Information, dass jeder
> > E-Mail-Client reinen Text kann, weil reiner Text der obligatorische Teil
> > der E-Mail ist.
>
> Reiner Text geht immer und sollte immer als Alternativversion dabei
> sein.
Leider missachten diese Tatsache viele Versender von HTML.
Der obligatorische Textteil fehlt auff�llig oft, wenn der HTML-Teil dazu
entwickelt wurde, den Empf�nger auszuspionieren.
Gleichzeitig ist HTML in seri�sen E-Mail-Aussendungen auff�llig gering.
> Lass gut sein. Die Jungs sind Windm�hlen. ;)
In dieser Metapher liegt m�glicherweise viel mehr Wahrheit, als du
beabsichtigt hattest. Allerdings leider zum Nachteil deiner bisherigen
Argumentationsversuche.
> Von vornherein einen HTML-Newsletter so zu gestalten, dass er
> keinen Browser überfordert und trotzdem noch anständig aussieht, kann
> doch nicht so schwer sein?
Stimmt. Aber anscheinend ist es schwer ein Web-Interface zu bauen an
welchem man E-Mails abfragt und nach Standard auch angezeigt bekommmt.
Die Nutzer von web.de / gmx / hotmail (browserbasierte Abfrage) sind
IMHO am schlimmsten. Benutzen Scheiße, beschweren sich aber in der
sauberen Umgebung über den Gestank.
Ich habe einmal -- gegen meinen eigentlichen Willen -- mich zeitweilig
mit einem HTML-Newsletter beschäftigt. Grausam…
ClemiSan
> Jochem Huhmann <j...@gmx.net> wrote:
>
>> Von vornherein einen HTML-Newsletter so zu gestalten, dass er
>> keinen Browser überfordert und trotzdem noch anständig aussieht, kann
>> doch nicht so schwer sein?
>
> Stimmt. Aber anscheinend ist es schwer ein Web-Interface zu bauen an
> welchem man E-Mails abfragt und nach Standard auch angezeigt bekommmt.
Nun gut. Aber was genau hat das jetzt mit HTML-Newslettern zu tun?
> Ich habe einmal -- gegen meinen eigentlichen Willen -- mich zeitweilig
> mit einem HTML-Newsletter beschäftigt. Grausam…
Verstehe ich jetzt nicht. Ich habe im Laufe der Jahre wirklich verdammt
viele Newsletter gesehen. Darunter waren viele in HTML, die genervt
haben und einige in schlichtem Text, die genauso genervt haben. Ich kann
sehr wohl verstehen, dass typografisch schlecht strukturierter Text
suboptimal ist. Eine anständige Gliederung mit erkennbaren Titeln (und
bei längeren Newslettern sogar einem klickbaren Inhaltsverzeichnis),
Tabellen, die samt Spalten- und Zeilenbeschriftungen auf einen Blick
lesbar sind, unterschiedliche Schriftgrade für unterschiedlich wichtige
Teile des Textes, abgesetzte Fußnoten, eingebundene Grafiken und auch
sowas wie Wiedererkennbarkeit in Layout und Gestaltung sind Dinge, die
in reinem Text nur sehr schwierig (wenn überhaupt) machbar sind. Das
wird sehr leicht ein Äquivalent zur klassischen Bleiwüste und das will
mit guten Gründen niemand.
Bloss warum das angeblich nur machbar sein soll, wenn man
browerspezifische Feinheiten bis zum Letzten ausreizt, so dass man das
dann erstmal gegen zwei Dutzend Mail-Clients austesten muß, ist mir
schleierhaft. Denn all das ist auch mit strunzdoofem HTML machbar, das
*jeder* Client darstellen können sollte. Es sei denn, der Gestalter
besteht darauf, das mit irgendwelchen Tools zu erstellen, die selber nur
gegen IE in der Version X.x getestet sind. Das ist das eigentliche
Problem und gewiß nicht die Frage HTML oder Text. HTML für Newsletter
ist IMHO *eigentlich* nicht nur völlig in Ordnung, sondern sogar sehr
naheliegend. Wer 2009 noch unbedingt schreibmaschinengetippte
Matrizenabzüge in die Briefkästen werfen will, der hat einen Knall. Dass
diejenigen, die alternativ unbedingt komisch gefaltete dreispaltige
Zettel mit fünf bunten Schriftschnitten in acht Größen machen müssen,
genauso einen Knall haben, ändert daran nix.
Irgendwie hat man da scheinbar nur die Wahl, weltfremd oder bekloppt zu
sein, glaube ich. Oder beides. Die Alternative, einfach nur vernünftig
die verfügbaren Mittel mit Sinn und Verstand einzusetzen, scheint
irgendwie nicht in Frage zu kommen. Woran das liegt, weiß ich auch
nicht, sorry.
> Irgendwie hat man da scheinbar nur die Wahl, weltfremd oder bekloppt zu
> sein, glaube ich. Oder beides. Die Alternative, einfach nur vern�nftig
> die verf�gbaren Mittel mit Sinn und Verstand einzusetzen, scheint
> irgendwie nicht in Frage zu kommen.
Aber nat�rlich. Nur sind die extremen meistens auch die lautesten...
diejenigen, die das einfach nur (vern�nftig) einsetzen, haben vielleicht
nicht die Lust, hier mitzudiskutieren.
Konni,
der trotzem einfachen Text schickt.
> >> Von vornherein einen HTML-Newsletter so zu gestalten, dass er
> >> keinen Browser überfordert und trotzdem noch anständig aussieht, kann
> >> doch nicht so schwer sein?
> >
> > Stimmt. Aber anscheinend ist es schwer ein Web-Interface zu bauen an
> > welchem man E-Mails abfragt und nach Standard auch angezeigt bekommmt.
>
> Nun gut. Aber was genau hat das jetzt mit HTML-Newslettern zu tun?
Es handelt sich um eines der zahlreichen Probleme, die für jede
Versendung von HTML per E-Mail zutreffen und die somit alle auch bei
HTML-Newslettern zu beachten sind.
> > Ich habe einmal -- gegen meinen eigentlichen Willen -- mich zeitweilig
> > mit einem HTML-Newsletter beschäftigt. Grausam…
>
> Verstehe ich jetzt nicht. Ich habe im Laufe der Jahre wirklich verdammt
> viele Newsletter gesehen. Darunter waren viele in HTML, die genervt
> haben und einige in schlichtem Text, die genauso genervt haben.
Eine schlecht geschriebene E-Mail wird auch nicht besser, wenn man deren
Autor auf die Idee bringt HTML zu verwenden. Wenn er schon mit Text
überfordert ist, dann wird das mit HTML erst recht nichts.
> Eine anständige Gliederung mit erkennbaren Titeln (und
> bei längeren Newslettern sogar einem klickbaren Inhaltsverzeichnis),
> Tabellen, die samt Spalten- und Zeilenbeschriftungen auf einen Blick
> lesbar sind, unterschiedliche Schriftgrade für unterschiedlich wichtige
> Teile des Textes, abgesetzte Fußnoten, eingebundene Grafiken und auch
> sowas wie Wiedererkennbarkeit in Layout und Gestaltung sind Dinge, die
> in reinem Text nur sehr schwierig (wenn überhaupt) machbar sind. Das
> wird sehr leicht ein Äquivalent zur klassischen Bleiwüste und das will
> mit guten Gründen niemand.
In HTML ist das noch schwieriger (wenn überhaupt) machbar, denn es
erfordert zusätzlich zum begabten Texter auch noch einen begabten
Techniker, der fähig ist die zahllosen Tücken von per E-Mail versendetem
HTML zu vermeiden.
> Bloss warum das angeblich nur machbar sein soll, wenn man
> browerspezifische Feinheiten bis zum Letzten ausreizt, so dass man das
> dann erstmal gegen zwei Dutzend Mail-Clients austesten muß, ist mir
> schleierhaft.
Das behauptet niemand. Man muss jedoch gegen die zahlreichen
Einstellungsmöglichkeiten ankämpfen, die der Benutzer hat.
> Denn all das ist auch mit strunzdoofem HTML machbar, das
> *jeder* Client darstellen können sollte.
Du gehst leider von dem Irrtum aus, dass ein E-Mail-Client in der Lage
sein sollte HTML in irgendeiner Form darzustellen. E-Mail-Clients
brauchen HTML aber nicht darzustellen. Nur reiner Text ist für
E-Mail-Clients obligatorisch. HTML ist nur einer von vielen möglichen
E-Mail-Anhängen, der jedoch zufällig von einigen E-Mail-Clients mit
Hilfe einer externen Rendering-Engine dargestellt werden kann.
Übrigens hat mir bisher noch kein einziger HTML-Mail-Apologet erklären
können, warum bei unidirektionaler Kommunikation wie Newslettern nicht
gleich ein PDF verwendet wird. Ein PDF wäre im Gegensatz zu HTML nämlich
durchaus in der Lage sämtliche visuelle Formatierung ordentlich zu
transportieren. In PDF können beispielsweise völlig problemlos alle
gewünschten Schriften eingebettet werden, selbst wenn der Empfänger
diese Schriften nicht hat, HTML kann das nicht, denn HTML wurde dazu
niemals konzipiert. E-Mail-Clients, die HTML halbwegs darstellen können
laufen normalerweise auf Betriebssystemen, die PDF schon deutlich länger
darstellen können als HTML in E-Mail.
Mit besten Grüßen,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anführungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
> Du gehst leider von dem Irrtum aus, dass ein E-Mail-Client in der Lage
> sein sollte HTML in irgendeiner Form darzustellen. E-Mail-Clients
> brauchen HTML aber nicht darzustellen. Nur reiner Text ist für
> E-Mail-Clients obligatorisch. HTML ist nur einer von vielen möglichen
> E-Mail-Anhängen, der jedoch zufällig von einigen E-Mail-Clients mit
> Hilfe einer externen Rendering-Engine dargestellt werden kann.
In welchem Jahrhundert lebst Du?
Zwar verstehe ich durchaus was Du meinst, aber der Softwarebestand, den
man in üblichen kommerziellen Zusammenhängen voraussetzen kann, kann
HTML in Emails darstellen und das gewiß nicht zufällig oder in
Einzelfällen. Ernsthaft, in der Praxis sehe ich mehr Probleme mit der
Darstellung von falsch kodierten Umlauten oder sonstigen "Sonderzeichen"
in reinem Text als Clients, die Probleme mit HTML haben.
> Übrigens hat mir bisher noch kein einziger HTML-Mail-Apologet erklären
> können, warum bei unidirektionaler Kommunikation wie Newslettern nicht
> gleich ein PDF verwendet wird. Ein PDF wäre im Gegensatz zu HTML nämlich
> durchaus in der Lage sämtliche visuelle Formatierung ordentlich zu
> transportieren. In PDF können beispielsweise völlig problemlos alle
> gewünschten Schriften eingebettet werden, selbst wenn der Empfänger
> diese Schriften nicht hat, HTML kann das nicht, denn HTML wurde dazu
> niemals konzipiert. E-Mail-Clients, die HTML halbwegs darstellen können
> laufen normalerweise auf Betriebssystemen, die PDF schon deutlich länger
> darstellen können als HTML in E-Mail.
PDF ist seitenorientiert und vorrangig zum Ausdruck auf tote Bäume
konzipiert. Wenn die Zielgruppe den Inhalt am Bildschirm lesen will,
dann ist PDF völlig daneben.
> > Du gehst leider von dem Irrtum aus, dass ein E-Mail-Client in der Lage
> > sein sollte HTML in irgendeiner Form darzustellen. E-Mail-Clients
> > brauchen HTML aber nicht darzustellen. Nur reiner Text ist f锟絩
> > E-Mail-Clients obligatorisch. HTML ist nur einer von vielen m锟絞lichen
> > E-Mail-Anh锟絥gen, der jedoch zuf锟絣lig von einigen E-Mail-Clients mit
> > Hilfe einer externen Rendering-Engine dargestellt werden kann.
>
> In welchem Jahrhundert lebst Du?
Offensichtlich in einem neueren Jahrhundert als die ewig-gestrigen
HTML-Mail-Apologeten, die immer noch nicht verstanden haben, dass sie
von Anfang an auf dem Holzweg waren.
> Wenn die Zielgruppe den Inhalt am Bildschirm lesen will, dann ist PDF
> v锟絣lig daneben.
Eine v锟絣lig unsinnige Behauptung, da bekanntlich die visuelle
Formatierung des Inhalts die Bildschirmlesbarkeit eines Dokuments
ausmacht und nicht das Dateiformat des Dokuments.
Literatur-Empfehlung: Eric Michael Weisenmiller, A STUDY OF THE
READABILITY OF ON-SCREEN TEXT, Virginia Polytechnic Institute and State
University, 1999: <http://is.gd/198ln>
Mit besten Gr锟斤拷en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anf锟絟rungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
Am 22.06.09 13:30 schrieb "Mike Nolte" unter
<newsgrou...@mikenolte.de> in
1j1pr5b.1e9...@www.mike-nolte.de:
> Offensichtlich in einem neueren Jahrhundert als die ewig-gestrigen
> HTML-Mail-Apologeten, die immer noch nicht verstanden haben, dass sie
> von Anfang an auf dem Holzweg waren.
Hm... erinnert mich sehr stark an eine Passage im "Leben des Brian". Oder
die K-Gruppen, die auf andere mit Fingern zeigten und Spalter riefen...
>
> Literatur-Empfehlung: Eric Michael Weisenmiller, A STUDY OF THE
> READABILITY OF ON-SCREEN TEXT, Virginia Polytechnic Institute and State
> University, 1999: <http://is.gd/198ln>
Nicht gerade neueste Literatur - aber immerhin. Halt von der technischen
Seite. Psychologische Wahrnehmungsstudien, kommunikationswissenschaftliche
Publikumsforschungsstudien sind zu anderen Ergebnissen gekommen. So ist halt
Wissenschaft. Man sucht sich das aus, was einem zupass kommt - ohne einem
wirklichen Diskurs zugeneigt zu sein. Der gerade verstorbene Lord Dahrendorf
hat das auch Dutschke und Co vorgeworfen.
Diese Diskussion ist nur noch ideologisch.
Gru�
Radulph
> spam...@bluehash.de (Clemens Beier) writes:
[...]
> > Ich habe einmal -- gegen meinen eigentlichen Willen -- mich zeitweilig
> > mit einem HTML-Newsletter besch�ftigt. Grausam...
>
> Verstehe ich jetzt nicht. Ich habe im Laufe der Jahre wirklich verdammt
> viele Newsletter gesehen. Darunter waren viele in HTML, die genervt
> haben und einige in schlichtem Text, die genauso genervt haben.
Hm, ich habe gerade �berrascht festgestellt, dass ich regelm��ig um die
6 Newsletter bekomme, die reiner Text sind und die ich aus beruflichen
Gr�nden sogar lese (sourceforge z.B.). Das war mir gar nicht bewu�t,
weil ich sie unbewu�t unter Mailinglisten-Digests eingeordnet habe.
Dann noch ein oder zwei von Firmen die lesbares HTML sind und die ich ab
und zu, wenn ich Lust habe, �berfliege.
Und dann noch jede Menge in unlesbarem HTML, teilweise einfach nur aus
Bildern bestehend (Linienfluggesellschaften z.B.) - die werden nach dem
ersten Mal nur noch genutzt, um den UCE-Filter zu trainieren. Darunter
sind auch viele, die ich nie angefordert habe, obwohl sie das Gegenteil
behaupten...
So, also in welchem Umfeld h�ttet ihr gerne, da� ich eure Newsletter
wahrnehme?
Ingo.
> Hm, ich habe gerade überrascht festgestellt, dass ich regelmäßig um die
> 6 Newsletter bekomme, die reiner Text sind und die ich aus beruflichen
> Gründen sogar lese (sourceforge z.B.). Das war mir gar nicht bewußt,
> weil ich sie unbewußt unter Mailinglisten-Digests eingeordnet habe.
Witzigerweise finde ich immer, dass genau solche oft ellenlange
Text-Newsletter von ein bißchen mehr Struktur und visueller Gliederung
sehr profitieren könnten...
> Dann noch ein oder zwei von Firmen die lesbares HTML sind und die ich ab
> und zu, wenn ich Lust habe, überfliege.
>
> Und dann noch jede Menge in unlesbarem HTML, teilweise einfach nur aus
> Bildern bestehend (Linienfluggesellschaften z.B.) - die werden nach dem
> ersten Mal nur noch genutzt, um den UCE-Filter zu trainieren. Darunter
> sind auch viele, die ich nie angefordert habe, obwohl sie das Gegenteil
> behaupten...
Während die wiederum so oder so weitestgehend überflüssig sind, egal in
welchem Format. Eingebettete Bilder in Mails lade ich nur selten nach
und wenn da außer Bildern nix drin ist, ist da auch nix zu lesen.
Dass die meisten HTML-Newsletter deshalb aufwendigst gestaltet sind, um
davon abzulenken, dass nix drinsteht, streite ich ja gar nicht ab.
> Witzigerweise finde ich immer, dass genau solche oft ellenlange
> Text-Newsletter von ein bi�chen mehr Struktur und visueller Gliederung
> sehr profitieren k�nnten...
Ich finde kurze, knackige Anreissertexte und ein Link (zu einer wie auch
immer gestalteten HTML-Seite) eine recht gute Kombination.
> Dass die meisten HTML-Newsletter deshalb aufwendigst gestaltet sind, um
> davon abzulenken, dass nix drinsteht, streite ich ja gar nicht ab.
:-)
Servus,
Konni
Du hast gerade die Konzepte von RSS und (zumindest teiweise) Twitter
beschrieben.
>> Dass die meisten HTML-Newsletter deshalb aufwendigst gestaltet sind, um
>> davon abzulenken, dass nix drinsteht, streite ich ja gar nicht ab.
>
>:-)
Ich bekomme @work ueberladene Designed-For-IE 5.3400 in 1024x768 von
einer Firma, fuer deren Leistungen ich mich beruflich eigentlich
ineterssieren wuerde. Da deren Newsletter aber mit einem anderen
zwar prinzipiell HTML-Faehigen aber aufgrund von Sicherheitseinstellungen
(im Mailreader sowie im System und auf dem Proxy) aus dem Hause
Microsoft statt einem kunterbunten wasauchimmer nur Muell anzeigt,
wandern per Regel alle E-Mails dieser Idiotenklitsche in den
Muelleimer, und Auftraege bekommt die Konkurrenz, die ueber die
mentalen Faehigkeiten von Grundschuelern verfuegen und ihre Inhalte in
geschriebener Sprache darstellen koennen.
BTDTMT. In diesem Fall hat der Schwachsinn mit HTML muell in
Newslettern und anderer E-Mail korrespondenz tatsaechlich zu
realem Umsatzverlust gefuehrt.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Konni Scheller <ksch...@ochs.franken.de>:
> > Ich finde kurze, knackige Anreissertexte und ein Link (zu einer wie auch
> > immer gestalteten HTML-Seite) eine recht gute Kombination.
>
> Du hast gerade die Konzepte von RSS und (zumindest teiweise) Twitter
> beschrieben.
Was ja auch sinnvoll ist. Newsletter sind eh gef�hrdet, man darf sich
dauernd gedanken machen, wie man es vermeidet, im Spamfilter h�ngen zu
bleiben.
> Ich bekomme @work ueberladene Designed-For-IE 5.3400 in 1024x768 von
> einer Firma, fuer deren Leistungen ich mich beruflich eigentlich
> ineterssieren wuerde. Da deren Newsletter aber mit einem anderen
> zwar prinzipiell HTML-Faehigen aber aufgrund von Sicherheitseinstellungen
> (im Mailreader sowie im System und auf dem Proxy) aus dem Hause
> Microsoft statt einem kunterbunten wasauchimmer nur Muell anzeigt,
> wandern per Regel alle E-Mails dieser Idiotenklitsche in den
> Muelleimer, und Auftraege bekommt die Konkurrenz, die ueber die
> mentalen Faehigkeiten von Grundschuelern verfuegen und ihre Inhalte in
> geschriebener Sprache darstellen koennen.
Tja, wer nich kann, der kann nicht... woran h�ngt's denn in dem
konkreten Fall, was ist die Ursache? Aktive Inhalte (brr)?
> BTDTMT. In diesem Fall hat der Schwachsinn mit HTML muell in
> Newslettern und anderer E-Mail korrespondenz tatsaechlich zu
> realem Umsatzverlust gefuehrt.
Zu Recht.
> > > Wenn die Zielgruppe den Inhalt am Bildschirm lesen will, dann ist PDF
> > > v�llig daneben.
> >
> > Eine v�llig unsinnige Behauptung, da bekanntlich die visuelle
> > Formatierung des Inhalts die Bildschirmlesbarkeit eines Dokuments
> > ausmacht und nicht das Dateiformat des Dokuments.
> >
> > Literatur-Empfehlung: Eric Michael Weisenmiller, A STUDY OF THE
> > READABILITY OF ON-SCREEN TEXT, Virginia Polytechnic Institute and State
> > University, 1999: <http://is.gd/198ln>
>
> Psychologische Wahrnehmungsstudien, kommunikationswissenschaftliche
> Publikumsforschungsstudien sind zu anderen Ergebnissen gekommen.
Ach, wirklich? HTL ist am Bildschirm deiner Meinung nach also besser
lesbar als ein PDF, ja?
Mit dir m�chte ich Gesch��fte machen.
Mit besten Gr��en,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
> > Witzigerweise finde ich immer, dass genau solche oft ellenlange
> > Text-Newsletter von ein bi�chen mehr Struktur und visueller Gliederung
> > sehr profitieren k�nnten...
>
> Ich finde kurze, knackige Anreissertexte und ein Link (zu einer wie auch
> immer gestalteten HTML-Seite) eine recht gute Kombination.
Womit du Datensammlern wie dem Focus voll auf den Leim gehst.
Warum die Links immer ellenlang sind und an irgendeiner Stelle eine
kryptische Zeichenkette gemeinsam haben, die wiederum im gleichen
Newsletter an eine andere E-Mail-Adresse anders aussieht, ist dir aber
schon klar, oder?
> to...@ingokeck.de (Ingo Keck) writes:
>
> > Hm, ich habe gerade �berrascht festgestellt, dass ich regelm��ig um die
> > 6 Newsletter bekomme, die reiner Text sind und die ich aus beruflichen
> > Gr�nden sogar lese (sourceforge z.B.). Das war mir gar nicht bewu�t,
> > weil ich sie unbewu�t unter Mailinglisten-Digests eingeordnet habe.
>
> Witzigerweise finde ich immer, dass genau solche oft ellenlange
> Text-Newsletter von ein bi�chen mehr Struktur und visueller Gliederung
> sehr profitieren k�nnten...
Nichts, was man nicht ggf mit ein paar Leerzeilen l�sen k�nnte.
[...]
> Dass die meisten HTML-Newsletter deshalb aufwendigst gestaltet sind, um
> davon abzulenken, dass nix drinsteht, streite ich ja gar nicht ab.
Bl�derweise sticht der eine gute HTML-Newsletter alle heilige Zeiten
nicht aus dem ganzen M�ll drumrum heraus...
Ingo.
> Am 22.06.09 13:30 schrieb "Mike Nolte" unter
> <newsgrou...@mikenolte.de> in
> 1j1pr5b.1e9...@www.mike-nolte.de:
[...]
> > Literatur-Empfehlung: Eric Michael Weisenmiller, A STUDY OF THE
> > READABILITY OF ON-SCREEN TEXT, Virginia Polytechnic Institute and State
> > University, 1999: <http://is.gd/198ln>
>
> Nicht gerade neueste Literatur - aber immerhin.
Ja, sowas wie Buchdruck und Zeitungen gibts ja auch erst seit letztem
Jahr.
Ingo.
> Ach, wirklich? HTL ist am Bildschirm deiner Meinung nach also besser
> lesbar als ein PDF, ja?
Falls Du HTML meinst: -> unbedingt ja.
> Mit dir m�chte ich Gesch��fte machen.
Aber langsamer, damit nicht so viele Tippf�hler auftauchen ;-)
Servus,
Konni
> > Ich finde kurze, knackige Anreissertexte und ein Link (zu einer wie auch
> > immer gestalteten HTML-Seite) eine recht gute Kombination.
>
> Womit du Datensammlern wie dem Focus voll auf den Leim gehst.
Nat�rlich.
> Warum die Links immer ellenlang sind und an irgendeiner Stelle eine
> kryptische Zeichenkette gemeinsam haben, die wiederum im gleichen
> Newsletter an eine andere E-Mail-Adresse anders aussieht, ist dir aber
> schon klar, oder?
Die IDs - und um nichts anderes handelt es sich bei diesen kryptischen
URL-Bestandteilen - dienen zum Usertracking und zum Erstellen von
Bewegungs- und vermuteten Interessenmustern. M�glicherweise bekommt der
User dann "angepasste" Newsletter.
Man kann diese Links aber sehr gut von "normalen" Links unterscheiden.
Und draufklicken muss man nicht.
(Im Gegensatz �brigens zu den "HTML-Mails", in denenen Links zu Bildern
auf diese Weise codiert sind. Da kommt man um einen Serverzugriff kaum
herum.)