Netiketa v e-mailovej komunikácii

27.10.2012 15:00 | Přečteno: 3582× | Rôzne | | poslední úprava: 29.10.2012 11:18

Dnešný blog bude niekoľkých pravidlách používaných kedysi v e-mailovej komunikácii. Možno som už stará vykopávka používajúca v dnešnej modernej dobe ako e-mailového klienta mutt. Napriek tomu si myslím, že pravidlá, o ktorých píšem majú zmysel aj v dnešnej dobe.

Venovať čas napísaniu predmetu

Predmet správy je to prvé, čo čitateľ uvidí. Ak zostane prázdny, alebo zle vyplnený Gandalf sa bude hnevať. A nie len to. Možno ten e-mail na základe predmetu ani neotvorí. Najskôr sa pozrime ako by predmet vyzerať nemal (zdroj: moja schránka):

• Fwd: RE: Re: Fwd: RE: PPT
• Fwd: RE: Re: Re: Fwd: RE: Poslané ďalej: aktualizace webu
• (Bez predmetu)
• …

Dobrý predmet by mal obsahovať informáciu o tom, čo čitateľ nájde v e-maili. Mal by slúžiť ako akási sumarizácia správy, pomocou ktorej sa dá správa ľahšie vyhľadať v množstve doručenej pošty. Predíde sa tak nepríjemným situáciám ako stratený / zabudnutý e-mail.

Ak správa vyžaduje nejakú akciu od čitateľa (otestovať, uploadnúť, schváliť …) nemalo by patričné sloveso chýbať v predmete.

Nepoužívať HTML maily

Toto pravidlo má pôvod ešte v dobách keď mailoví klienti nepodporovali formátovanie v HTML. V súčasnosti už málokto používa mailového klienta bez HTML (zo svojho okolia poznám takého blázna len seba).

O zobrazovanie HTML sa zvyčajne stará plnohodnotné jadro internetového prehliadača. V minulosti to spôsobovalo (a vlastne dodnes spôsobuje) nemalé bezpečnostné riziko. Takže aj napriek podpore nie je až taký zlý nápad renderovanie HTML vypnúť a používať čisté textové správy.

Pri používaní HTML mailov a tmavej farebnej schémy som sa stretával pomerne nepríjemným problémom, kedy boli správy zobrazené čiernym písmom na čiernom pozadí pretože mailový klient ignoroval nastavenie pozadia (body), ale podporoval nastavenie farby textu.

Pre niekoho možno nie moc významným problémom je zbytočné zvyšovanie veľkosti správy. Pri počte niekoľko desiatok denne už prestáva byť veľkosť len tak teoretickým problémom. Pre porovnanie veľkosť správy z thunderbirdu a tá istá správa napísaná v klientovi mutt (správa je skutočne 304x väčšia).

$ ls -lh sprava*
-rw------- 1 mirec users 11K okt 27 12:11 sprava-html
-rw------- 1 mirec users  36 okt 27 12:11 sprava-plain

Krátke pätičky

Pätička môže slúžiť rôznym účelom od pridania kontaktných informácií po rôzne citáty charakterizujúce pisateľa.

Dĺžka pätičky by mala byť taká, aby čitateľovi nijako pri čítaní neprekážala. Dlhé pätičky môžu odpútavať od samotného obsahu. Treba si uvedomiť, že to, čo čitateľa zaujíma je samotný e-mail, nie pätička. Obzvlášť vie naštvať situácia keď sa mám hrabať v dlhej preposielanej diskusii, kde 90% obsahu tvoria pätičky. Pre ukážku toho, ako pätička nemá vyzerať posielam našu firemnú:

<div style="margin: 0pt 0pt 2px;">
  <div dir="ltr">
    <div><span style="color: #2284c6; font-size: medium;"><strong>MENO
          MENO</strong></span><span style="color: #999999;"><span
          style="font-size: xx-small;"> <br>
          CEO & PARTNER</span></span><span style="color:
        #221e1f;"><span style="font-size: xx-small;"> <br>
        </span> <span style="font-size: x-small;"><img
            style="float: left;"
            src="cid:part2.07000501.04030800@creanet.sk" alt="">CREANET,
          s. r. o. , L. SAdresa ..., Slovakia</span><span
          style="font-size: x-small;"><br>
          <span style="color: #999999;">Phone:</span> +421 12 345
          4789=A0</span></span><span style="font-size: x-small;"><span
          style="color: #221e1f;"><span style="font-size:
            x-small;"><span style="font-size: x-small;"><span
                style="font-size: x-small;">-</span></span></span>
          <span style="color: #999999;">Mobile:</span> +421 12 345
          678 901</span><br>
        <span style="color: #999999;">E-Mail:</span> <a
          href="mailto:meno@creanet.sk" target="_blank">meno@creanet.sk</a>
        <br>
        <span style="color: #999999;">Web:</span> <a
          title="Domovsk=E1 str=E1nka Creanet.sk"
          href="http://creanet.sk/" target="_blank">creanet.sk</a><span
          style="font-size: x-small;"><br>
          <span style="color: #999999;">Soci=E1lne siete:</span></span>
        <span style="font-size: x-small;"><a title="Creanet na
            Facebooku" href="https://www.facebook.com/creanetsk"
            target="_blank">Facebook</a> <span style="font-size:
            x-small;">- <a title="Creanet na sieti Twitter"
              href="http://twitter.com/#%21/creanetsk"
              target="_blank">Twitter</a> <span style="font-size:
              x-small;"><span style="font-size: x-small;">- <a
                  title="Creanet na Google+"
                  href="https://plus.google.com/102068455097322179021/posts"
                  target="_blank">Google+</a></span></span></span></span><br
          style="font-size: x-small;">
      </span><span style="font-size: x-small;"><a
          href="https://www.facebook.com/creanetsk"><br>
        </a></span></div>
  </div>
</div>

Mailový klient opera zobrazuje túto pätičku takto (ešte, existujú filtre pre mutt):

Väčšina e-mailových klientov je schopná pri odpovedi odstrániť pätičky. Aby to fungovalo musí byť pätička od obsahu oddelená riadkom "-- " (pomlčka, pomlčka, medzera).

Nepoužívať funkciu odpovedať všetkým

Pomerne častým javom, s ktorým sa stretávam je odosielanie odpovede všetkým adresátom. Teraz nechcem povedať, že v každom prípade je to zlé. Pred odoslaním odpovede si však treba vždy skontrolovať, či je e-mail určite relevantný pre všetkých prijímateľov, alebo tým len niekomu spamujeme schránku.

Ľahko čitateľný text

Pred odosielaním by si mal každý uvedomiť, že e-mail bude s veľkou pravdepodobnosťou čítať človek. Text by mal byť napísaný podľa možnosti bez gramatických a pravopisných chýb. Vety majú byť krátke a jednoznačné. Mal by sa čítať príjemne a zbytočne nezdržiavať lúštením.

Každý, kto píše text by mal mať aspoň základné znalosti z typografie. Mal by vedieť používať správne medzeru za interpunkčnými znamienkami, odstavce … Tieto znalosti by mal samozrejme používať aj pri e-mailoch

Dĺžka riadkov maximálne 80 znakov

Táto konvencia pochádza z temných čias IBM PC a režimov 80x24 znakov. Šírka 80 znakov pri tomto grafickom režime bola zvolená (okrem iného) preto, lebo sa ľahko číta. Dnes síce môžme používať omnoho lepšie grafické režimy, ale na spôsobe vnímania textu sa pokiaľ viem nič nezmenilo.

Aktualizácia
Toto hádam v normálnych klientoch už nemá nejaké opodstatnenie, takže Content-Type: text/plain; charset=utf-8; format=flowed a nastavené zalamovanie na 72 znakov pri zobrazovaní.

Krátke maily a formátovanie odrážkami

Komunikácia pomocou e-mailu je rýchla. Takmer žiaden príjemca nechce čítať dlhý sloh. Ak sa teda niečo dá napísať vo forme odrážok treba to využiť. Čitateľovi sa budú informácie zo zoznamu extrahovať výrazne jednoduchšie než z nejakého slohu.

Používať e-mailového klienta podporujúceho vlákna

Občas sa stáva, že diskusia trvá niekoľko mesiacov. Neraz v takej situácii potrebujem vyhľadať správu zo začiatku diskusie pretože obsahuje prílohu.

Moderní mailoví klienti by sa mali bez problémov vysporiadať s touto situáciou pretože vlákna sú skladané pomocou štandardnej hlavičky In-Reply-To:. Teória je síce pekná, ale bežne sa mi v mojej schránke ocitne otázka bez korektne nastavenej hlavičky. Dobrú podporu vlákien môžme nájsť aj v mojich obľúbených klientoch mutt a opera.

Odpoveď pod pôvodnú správu

Jedna z prvých vecí, ktoré som sa musel pri prechode do firemného prostredia naučiť bolo čítanie mailov odspodu pretože používame tzv. top-posting. Požičiam si jeden rozhovor od neznámeho autora:

• A: Pretože prehadzuje poradie, v ktorom bežne ľudia čítajú text.
• Q: Prečo je top-posting tak zlá vec?
• A: Top-posting.
• Q: Čo je najhoršia vec na e-mailoch?

Ako takýto zoznam e-mailov vlastne čítať? Ja som si vyvinul vlastnú metódu kedy prečítam prvú správu a potom pokračujem správami odspodu. Ako príklad si požičiam firemný mail. Hlavičky a pätičky sú šedou farbou, aby moc vo výpise neprekážali. Zelenou farbou je informácia pre mňa, zvyšok je vlastne len nejaký šum typu "prepošli to prosím …", "schváľ to prosím" …

Mnohí ľudia obhajujú odosielanie odpovede pred pôvodnú správu pretože odpoveď je to prvé, čo príjemca uvidí. Ak však príjemca nepotrebuje vedieť pôvodnú správu načo ju vôbec vkladať do e-mailu?

Účelom vkladania pôvodnej správy do e-mailu je uviesť čitateľa do kontextu. Ak žiaden kontext nie je potrebný bude vkladanie pôvodnej správy len zbytočne zdržiavať čitateľa. Ak je ešte medzitým vkladaných mnoho hlavičiek a pätičiek, ktoré niektorý z mailových klientov previedol z html na text stáva sa čítania mailu prácou aj na niekoľko hodín.

Prekladané odpovede

V prípade, že pôvodný e-mail obsahoval niekoľko otázok pekne oddelených odstavcami je najlepším spôsobom odpovede prekladanie, kedy sa každá odpoveď vkladá priamo pod otázku. Prekladaná odpoveď vyzerá nasledovne:

> Otázka číslo 1...

Odpoveď na prvú otázku.

> Otázka číslo 2...

Odpoveď na druhú otázku.

Orezanie komunikácie

V prípade použitia moderných mailových klientov je odosielanie celej doterajšej komunikácie v každom e-maili zbytočné. Pomocou vlákien je možné sa jednoducho dostať ku každej z predchádzajúcich správ.

Pôvodný text správy by mal čitateľa len uviesť do kontextu. Na to postačí zvyčajne pár podstatných riadkov. V prípade, že tých pár riadkov pochádza z viacerých správ je možné urobiť veľmi krátku sumarizáciu predchádzajúceho rozhovoru a pokračovať bez zbytočného balastu.

Ako to funguje u nás?

V našej firme sa pri e-mailovej komunikácii porušujú kompletne všetky body, o ktorých som písal. Mám taký pocit, že to v poslednej dobe tak trochu patrí ku korporátnemu štandardu. Ja sa ako taký posledný dinosaurus snažím vzdorovať, ale nie je to moc jednoduché.

Ak máte sami nejaké pozitívne / negatívne skúsenosti s e-mailovou komunikáciou budem rád, ak sa prejavíte v diskusii .

       

Komentáře

[Michal Fecko]

:D Skvelé. Ja mám nastavené pravidlo ze "FWD: FWD: FWD:" v predmete frčí priamo do /dev/null

[Fluttershy, yay!]

Dĺžka riadkov maximálne 80 znakov

Nesouhlasím. Dynamické zalamování funguje dobře a obvykle vypadá líp.

Orezanie komunikácie

Nesouhlasím. Celá historie se občas hodí.

Ak máte sami nejaké pozitívne / negatívne skúsenosti s e-mailovou komunikáciou budem rád, ak sa prejavíte v diskusii .

Přidal bych jeden bod: slepá kopie.

[mirec]

Nesouhlasím. Dynamické zalamování funguje dobře a obvykle vypadá líp.

Záleží od situácie. Na iphone je pravda, že 80 znakov (alebo skôr 72 + nejaké tie zobáčiky pre citáciu) vyzerá hrozne. Na druhej strane zvyknem mať okná maximalizované a keď mi v mailovom klientovi vychádza 250 znakov monospace textu na šírku tak sa to číta jednoducho.

Celá historie se občas hodí.

No občas ... ak s niekym komunikujem tak mám všetky odoslané a prijaté správy pokope vďaka vláknam, takže nejakú potrebu posielať celú históriu v každom e-maili nemám. Skôr mi vadí keď mi niekto pošle celú internú komunikáciu z inej firmy a ja v tom mám nájsť čo vlastne mám robiť.

Přidal bych jeden bod: slepá kopie.

Čo je na nich vlastne zlé? Teda nie že by som sa s nimi nejako často stretával, používam ich len vtedy, keď potrebujem niečo rozposlať hromadne (mám taký pocit, že naposledy PF 2012 som takto rozposielal).

[anonymator]

Záleží od situácie. Na iphone je pravda, že 80 znakov (alebo skôr 72 + nejaké tie zobáčiky pre citáciu) vyzerá hrozne. Na druhej strane zvyknem mať okná maximalizované a keď mi v mailovom klientovi vychádza 250 znakov monospace textu na šírku tak sa to číta jednoducho.

A nemôžeš si dať veľkosť okna na čítanie správ tak, aby sa to dobre čítalo? Podobným neduhom predsa musia trpieť aj iné programy, ktoré používaš...

[Fluttershy, yay!]

Záleží od situácie. Na iphone je pravda, že 80 znakov (alebo skôr 72 + nejaké tie zobáčiky pre citáciu) vyzerá hrozne. Na druhej strane zvyknem mať okná maximalizované a keď mi v mailovom klientovi vychádza 250 znakov monospace textu na šírku tak sa to číta jednoducho.

Na telefonu se mi to zalomí, na desktopu se mi to zalomí podle velikosti okna. Dynamické zalamování obvykle vypadá líp (mj. stejně jako ve zbytku prostředí) než statické zalomení, které dělal nesazeč.

Čo je na nich vlastne zlé?

Právě naopak — a lidi je nepoužívají. Typické jsou školní e-maily od externistů nebo řetězovky.

No občas ... ak s niekym komunikujem tak mám všetky odoslané a prijaté správy pokope vďaka vláknam, takže nejakú potrebu posielať celú históriu v každom e-maili nemám. Skôr mi vadí keď mi niekto pošle celú internú komunikáciu z inej firmy a ja v tom mám nájsť čo vlastne mám robiť.

Mně to např. pomáhá, když komunikuju s někým, kdo má odpovídání rozbité, takže mi sype nové zprávy s předmětem "Re: Re: Re: (...)".

[mirec]

Mně to např. pomáhá, když komunikuju s někým, kdo má odpovídání rozbité, takže mi sype nové zprávy s předmětem "Re: Re: Re: (...)".

Mailový klient by nemal usporiadavať správy podľa titulkov, ale podľa hlavičiek Message-ID a In-Reply-To. Kedysi som to bral ako samozrejmosť u každého mailového klienta, ale ... no je pravda, že v súčasnosti paradoxne narážam aj na také, ktoré to nepodporujú

K preposielaniu celej histórie ... dal som do blogu ako ukážku jednu ukážku takého mailu preposielaného cez asi 3 mailových klientov. Kvôli tomu majú správy úplne rozhodený text, hlavičky, pätičky ... Ešte niektorí klienti pekne škaredo zalamujú text ak prekračuje 80 znakov aj so zobáčikmi, radosť to čítať. Iná situácia je keď je komunikácia kultivovaná, správy majú pár riadkov a každý má klienta, ktorý zbytočné pätičky odstráni, takže zostane len obsah.

[David Jaša]

Mailový klient by nemal usporiadavať správy podľa titulkov, ale podľa hlavičiek Message-ID a In-Reply-To. Kedysi som to bral ako samozrejmosť u každého mailového klienta, ale ... no je pravda, že v súčasnosti paradoxne narážam aj na také, ktoré to nepodporujú

Nechcete někdo vypálit všechny pisálky klientů pro android, co na In-Reply-To zvysoka serou?

(pekelně nasranej smajlík)

[mirec]

Mno android to je kapitola sama o sebe. Vlastne celkovo mobilné aplikácie. V poslednej dobe fušujem trochu aj do tejto oblasti i keď nie až tak primárne ako vývojár, skôr len upravujem trochu to, čo vypracovali externé firmy.

Ono sa toho už na tému kvality programátorov popísalo dosť. Žiaľ situácia je taká, že dnes sa za vývojára považuje každý, kto vie napatlať nejaké UI v javascripte s monštróznym frameworkom na pozadí a pritom nemá ani najzákladnejšie teoretické vedomosti. U e-mailov je to celkom dosť viditeľný problém pretože tam frameworky zvyčajne neriešia hlavičky a keď si človek, ktorý to implementuje ani nepreštuduje príslušné RFC tak to tak vyzerá. Hot jeden z dôvodov prečo radšej pošlem svoje peniaze na nejaký kvalitný open source projekt než by som mal kupovať 20 patlaníc za 2€ z ktorých každá stojí za ...

[j AM]

Celá historie se občas hodí.

No občas ... ak s niekym komunikujem tak mám všetky odoslané a prijaté správy pokope vďaka vláknam, takže nejakú potrebu posielať celú históriu v každom e-maili nemám. Skôr mi vadí keď mi niekto pošle celú internú komunikáciu z inej firmy a ja v tom mám nájsť čo vlastne mám robiť.

Celá historie se hodí např. v případě že po pár vyměněných mailech je třeba do komunikace přidat někoho dalšího.

[Franta]

To mi přijde jako předčasná „optimalizace“ – pro případ, že bychom někdy chtěli přibrat do diskuse někoho dalšího, budeme v každém e-mailu posílat kopu hnoje… Místo abychom při přibrání nového člověka vzali to vlákno, vložili do přílohy a přeposlali mu ho.

[j AM]

Vtip je v tom že ty maily neposíláš jenom ty ale i protistrana a nikdy nevíš kdo a kdy tam bude chtít někoho přidat. Kdo chce má historii dole, kdo nechce tak si čte jenom to nové nahoře.

[Prcek]

No spíš mi přijde občas chyba, že se funkce "Odpovědět všem" zapomene použít, než že se používá zbytečně. Když ji člověk nepoužije, a další člověk si nevšimne, že se seznam příjemců zmenšil jen na něj, tak má zbytek příjemců smůlu a už si nic nepřečte.

Mně třeba při nástupu do zaměstnání chvíli dělalo problém odpovídat všem, tak si na to teď dávám pozor .

[pavlix]

No spíš mi přijde občas chyba, že se funkce "Odpovědět všem" zapomene použít, než že se používá zbytečně.

Naprosto souhlasím.

Mně třeba při nástupu do zaměstnání chvíli dělalo problém odpovídat všem, tak si na to teď dávám pozor .

To mi povídej.

[Martin]

Asi záleží na firemní kultuře, ale já dostávám rok od roku více mailů, ale odpovědí dávám pořád skoro stejně. Odpovědět všem pak spousta lidí používá jako budoucí alibismus, protože přeci jsi "měl tu informaci na straně pět, fontem číslo osm" a je tvůj problém, že jsi se k tomu neprokousal.

Docela by mě zajímalo kolik kdo z vás dostává za rok emailů...

[xkucf03]

Odpovědět všem pak spousta lidí používá jako budoucí alibismus,

Alibismus je bohužel na obou stranách – když je moc příjemců, tak si řada lidí řekne, že oni to číst, schvalovat nebo se k tomu vyjadřovat nemusí, že to udělá někdo za ně. A když si tohle řeknou všichni, je těžké z takového kolektivu dostat nějakou kloudnou odpověď.

Trochu pomáhají dvě věci:

• dávat lidi, od kterých chceme odpověď, do pole „Komu“ (ne do „Kopie“)
• napsat osobní oslovení: ahoj + jméno/jména,

Docela by mě zajímalo kolik kdo z vás dostává za rok emailů...

V jedné práci cca 2500-3500, osobních tak kolem 4000, v jiné práci kolem tisícovky.

[Martin]

Já mám cca 15000 mailů/rok :)

Souhlasím s tím, co píšeš. Jak je mail, kde jsem v Kopii, moc to neřeším.
Pokud po někom něco chci, píšu k tomu jeho jméno a případně datum očekávané odpovědi.

[vencour]

Přidal jsem do výběru.

[M-train]

Topic je docela zajímavý, trochu jsem nepochopil, jestli jsi myslel tím souhrnem spíš na sebe (ujasnit si, jak to vlastně vypadá), nebo na ostatní (trochu je vyškolit), nebo si jen tak uvolnit přetlak .

Většina mé komerční činnosti začíná právě prostřednictvím e-mailů, takže tebou zmiňované body pochopitelně sleduju taky. Když teď vynechám ty základní, spíše technické, tak s tebou musím souhlasit, že údernost a účinnost e-mailu je ve stručnosti a srozumitelnosti. Tam se bohužel někdy nechám unést, když dělám nabídku v jiných jazycích, a přenesu do té mutace čechismy - tj. ve chvatu je sice můj text gramaticky správně, ale nikoliv v duchu toho jazyka. A to zahraniční zákazníci SAKRA nemají rádi . A stejným problémem je pro mne, když někdo vysype do blogu třeba i zajímavé postřehy, ale buď z důvodu spěchu, nebo z důvodu chybějící gramotnosti (objevuje se takový autor i na ábíčku) je materiál ke čtení nepříjemný, až iritující.

[mirec]

Skôr ostatných. V podstate mi ide o to aby som zistil, či má niečo také zmysel presadzovať a ak áno tak asi sa budem snažiť biť za zmenu. Pravdu povediac nebaví ma pol dňa lúštiť čo to mám vlastne robiť (síce nie som platený za výkon ale aj tak).

[ewew]

Niekedy je chuťovka lúšťiť email s iným kódovaným ako cieľový systém.

Uvítal by som konverziu kódovania ak je má cieľový PC nastavené iné kodovanie ako napríklad webmail.

[mirec]

So zlým kódovaním som sa už pomerne dlho nestretol. Je ešte v dnešnej dobe mailový klient, ktorý neodosiela zdrojové kódovanie?

[pavlix]

Špatně mi kódování odesílal jen a pouze claws mail.

[mirec]

Zaujímavé, práve nad týmto klientom som rozmýšľal v práci. No nič, asi zostanem pri mutt-e keďže nič väčšie sa mi nezmestí do RAM.

[Michal Fecko]

keďže nič väčšie sa mi nezmestí do RAM

??? 128MB RAM?

[mirec]

Niečo také.

[SPM]

Ono se dá dneska na desktopu dělat s méně než 8GB RAM? :))

[mirec]

Neviem, mne je to ukradnuté, ja som platený za čas Okrem toho mám obsadené všetky sloty na RAM maximálnou kapacitou, takže s tým aj tak nič neurobím.

Ale inak vážne, myslím, že do tých 2GB sa zmestím s tým molochom javou, android 4 emulátorom, cups, mysql, postgresql, nginx, php-fpm, redis, celery, redmine (rails), thin, pár vlastných kravín na djangu, skype, mailový klient, editor, ... samozrejme na 64 bitovom systéme.

[Bystroushaak]

Zaujímavé, práve nad týmto klientom som rozmýšľal v práci.

Nedoporučuji. Osobně mě na něm nejvíc štvalo, jak při každé operaci zasekne celý klient. Tzn zprávy se stahují a ty nic neuděláš, nehrozí, že bys třeba napsal odpověď či si přečetl něco už staženého.

[mirec]

Rovnako ak nie horšie je na tom mutt ;) Nepoužívam ho však z ideologických dôvodov, ale kvôli RAM. Chcel by som aspoň klienta, ktorého by som 5x denne nekilloval pretože sa zasekol pri čakaní na socket (často u nás vypadáva sieť a vždy po výpadku musím zabiť mutt).

[SPM]

Nepomůže na to používat nějaký fetchmail/offlineimap/syncimap a muttem zobrazovat jenom lokální zprávy?

[mirec]

Pomôže, fetchmail používam pre redmine. Ale zatiaľ sa mi nechcelo to nakonfigurovať keďže by som chcel rovno aj notmuch.

[xkucf03]

Problém není v používání různých kódování. Problém je v tom, že někteří debilní klienti nedeklarují správné kódování v hlavičkách při odesílání, nebo si toho kódování nepřečtou při zobrazování přijaté zprávy a předpokládají, že zbytek světa používá stejné kódování, jako oni (asi nemusím uvádět, jaká firma má tohle na svědomí)

[Martin Šebek]

Disputací na téma bottom-posting vs. top-posting jsem už vedl nepočítaně. Bohužel s nulovými výsledky. Nepamatuju se, že bych byť jednoho člověka přesvědčil o výhodách bottom-postingu.

Dokonce se mi několikrát stalo, že mi zákazník zavolal s tím, že jsem poslal "prázdnou" odpověď. Problém byl v tom, že očekával odpověď nahoře a vůbec se neobtěžoval s přečtením celé zprávy.

Myslím, že velkou vinu na tom nese MS Outlook, ve kterém je bottom-posting prakticky nepoužitelný.

Zachovávání kompletní komunikace vidím také jako velký nešvar. Já už jsem asi svůj boj s větrnými mlýny prohrál. Píšu emaily tak, abych se za ně nemusel stydět, ale ostatní se už vychovávat nesnažím.

[mirec]

No ja som na tom ešte horšie, ja mám dokonca klávesovú skratku na prepínanie do outlook kompatibilného formátu nech na mňa nikto nepozerá ako na mimozemšťana. Akosi nerozumiem tomuto svetu

[pavlix]

Disputací na téma bottom-posting vs. top-posting jsem už vedl nepočítaně. Bohužel s nulovými výsledky. Nepamatuju se, že bych byť jednoho člověka přesvědčil o výhodách bottom-postingu.

Myslím, že k tomu, aby člověk někoho mohl smysluplně přesvědčovat o výhodách bottom-postingu je nutné pochopit výhody top-postingu.

Dokonce se mi několikrát stalo, že mi zákazník zavolal s tím, že jsem poslal "prázdnou" odpověď. Problém byl v tom, že očekával odpověď nahoře a vůbec se neobtěžoval s přečtením celé zprávy.

Na to zpravidla pomáhá pozdrav zařazený těsně pod jeho pozdrav. Pak by to neměl přehlédnout.

Zachovávání kompletní komunikace vidím také jako velký nešvar. Já už jsem asi svůj boj s větrnými mlýny prohrál. Píšu emaily tak, abych se za ně nemusel stydět, ale ostatní se už vychovávat nesnažím.

+1

Tedy pokud to není vyloženě extrém. Jednu dobu jsem pravidelně dostával firemní komunikaci bez předmětu.

[Martin Šebek]

Myslím, že k tomu, aby člověk někoho mohl smysluplně přesvědčovat o výhodách bottom-postingu je nutné pochopit výhody top-postingu.

Výhody top-postingu jsem zatím neobjevil. Ale možná je to úplně stejné jako se všemi dalšími věčnými boji (za všechny např. VI vs. Emacs) a ve finále mají všichni pravdu. :) Na druhou stranu si říkám, že když tenkrát bottom-posting vymysleli, věděli co dělají.

Na to zpravidla pomáhá pozdrav zařazený těsně pod jeho pozdrav. Pak by to neměl přehlédnout.

Pozdrav píšu vždy úplně na první řádek a pak už následuje citace a pod ní odpověď. Uváděl jsem to jako příklad, jak moc je top-posting mezi lidmi zakořeněný.

Tedy pokud to není vyloženě extrém. Jednu dobu jsem pravidelně dostával firemní komunikaci bez předmětu.

V takové komunikaci pak něco hledat, to je radost. Mnohem častěji se mi ale stává, že je předmět naprosto hloupý. Raději ani nebudu počítat, kolik mám v archivu zpráv s předměty "dotaz", "žádost", "prosba" apod.

[xkucf03]

Výhody top-postingu jsem zatím neobjevil.

Výhoda spočívá v tom, že hned po otevření e-mailu vidím, co mi píší – nemusím se prodírat historií komunikace a hledat kdesi dole novou zprávu.

Otázka samozřejmě je, jestli je nutné citovat všechno (ať už nad nebo pod). Většinou není. Většinou má smysl buď žádná citace nebo „in-line“ citace.

V některých případech je to něco mezi – adresát citaci vyloženě nepotřebuje (nebudeme ho tedy obtěžovat tím, že ji strčíme na začátek e-mailu a budeme ho nutit ji číst nebo přeskakovat), ale mohla by se mu hodit (adresátů může být víc a mohla by se hodit některým). Pak má „bottom-posting“ smysl. Ale ještě lepší by bylo vložit původní zprávu do přílohy (jako se to někdy dělá u přeposílání). Prostě to nematlat do textu a nenechat různé zprávy splývat v jedné MIME části, ale hezky (a strojově čitelně) to oddělit a dodat i všechny hlavičky (kdo, kdy, komu… a mj. message ID – což umožňuje odpovědět na citovanou zprávu i někomu, kdo ji původně nedostal).

[Martin Šebek]

Výhoda spočívá v tom, že hned po otevření e-mailu vidím, co mi píší – nemusím se prodírat historií komunikace a hledat kdesi dole novou zprávu.

Asi to bude také souviset s povahou zpráv. Když zpráva, na kterou dostanu odpověď top-postingem, obsahuje více otázek, může snadno dojít k nedorozumění, jaká odpověď patří k jaké otázce. Když se jedná o krátkou odpověď na jednu jedinou otázku, pak je na první pohled odpověď vidět jak při top-postingu, tak při bottom-postingu.

Otázka samozřejmě je, jestli je nutné citovat všechno (ať už nad nebo pod). Většinou není. Většinou má smysl buď žádná citace nebo „in-line“ citace.

Souhlasím. Vždycky se snažím ponechat pouze relevantní část zprávy. Tady zase vidím výhodu bottom-postingu v tom, že adresáta uvedu do obrazu, čeho se vlastně má odpověď týká a pak si přečte samotnou odpověď.

Ne každá odpověď na email přichází okamžitě a může se stát, že adresát si už nepamatuje, co přesně napsal v původní zprávě. Sám nemám rád, když se musím odspodu probírat tunou balastu, tak k tomu nenutím ostatní.

[pavlix]

Asi to bude také souviset s povahou zpráv.

Proto je důležité pochopit výhody top-postingu než někomu začnu vysvětlovat nevýhody.

[Ash]

Ne každá odpověď na email přichází okamžitě a může se stát, že adresát si už nepamatuje, co přesně napsal v původní zprávě.

V případě že tohle hrozí, nechám tam původní zprávu raději celou :) Mně osobně nevadí ani top ani bottom posting, ale vadí mi, když mi někdo odpoví, původní zprávu odmaže nebo nevloží, a odpoví mi na něco jiného, než jsem se ptal, nebo mi odpoví jen na jeden dotaz ze dvou či část dotazu s tím, že druhý či druhou část prostě ignoruje, a ani se nezmíní, že ji ignoroval :) Z tohoto důvodu jsem někdy skoro raději, když se preventivně nechává celá historie. Nikdo mne ji číst nenutí, ale je tam na případné omlácení o hlavu.

[xkucf03]

Nepamatuju se, že bych byť jednoho člověka přesvědčil o výhodách bottom-postingu.

A to je dobře – „bottom-posting“ je zvěrstvo. Aneb proč obtěžovat druhé tím, že jim na začátek zprávy (nejdůležitější místo, které vidí jako první) budeš cpát nějaký starý text, který už četli, nebo dokonce sami psali?

Když už, tak „in-line“ citace – tam cituješ větu nebo část odstavce a nikomu se nestane, že by přehlédl tvoji odpověď (což se klidně stát může, když bude úplně dole za devatero obrazovkami při „bottom-postingu“).

[Martin Šebek]

A to je dobře – „bottom-posting“ je zvěrstvo. Aneb proč obtěžovat druhé tím, že jim na začátek zprávy (nejdůležitější místo, které vidí jako první) budeš cpát nějaký starý text, který už četli, nebo dokonce sami psali?

Právě kvůli uvedení do kontextu (jak už jsem napsal jinde). Co když odpověď přichází s časovým zpožděním a není vlastně jasné, na co člověk odpovídá? Při top-postingu je pak třeba odskrolovat dolů, podívat se, čeho se odpověď týká a pak začít číst odpověď shora.

Když už, tak „in-line“ citace – tam cituješ větu nebo část odstavce a nikomu se nestane, že by přehlédl tvoji odpověď (což se klidně stát může, když bude úplně dole za devatero obrazovkami při „bottom-postingu“).

Teď možná budu za blbce, ale já říkám bottom-posting právě tomu, o čem píšeš jako o „in-line citaci“. Mé odpovědi jsou tedy pod textem, na který reaguji. Když odpověď obsahuje jediný bod, vypadá to jako „ bottom-posting“.

[xkucf03]

Právě kvůli uvedení do kontextu (jak už jsem napsal jinde). Co když odpověď přichází s časovým zpožděním a není vlastně jasné, na co člověk odpovídá?

Myslím, že je tu dost velká „šedá zóna“, kdy prostě nevíš, jestli je adresát v obraze a pamatuje si, nebo ne – pak je dobré tam tu historii nechat dole nebo v příloze, pro případ, že by v obraze náhodou nebyl a mohl si to dohledat a připomenout – ale zase mu ji necpat na začátek pro případ, že by v obraze byl a jen by ho to obtěžovalo.

já říkám bottom-posting právě tomu, o čem píšeš jako o „in-line citaci“

Už si asi rozumíme. V tom případě nejsme ve sporu

Přijde mi dobré rozlišovat tři styly:

• „top-posting“ – nové nahoře, kompletní citace dole
• „bottom-posting“ – nové dole, kompletní citace nahoře
• „in-line“ citace – citované jen nutné minimum (pár slov, věta, relevantní část odstavce) a odpověď hned pod tím. Typicky je to rozsekané na víc částí: otázka/odpověď/otázka/odpověď/…

[mirec]

Potom je definícia „bottom-posting“ chybná pretože vôbec neznamená celú históriu hore. Bottom posting si doslova vyžaduje skrátenie celej diskusie na najnutnejšie minimum tak aby sa nikto neprehrabával 10 stranami dole kým zistí o čom to bolo. V takom prípade chápem rozhorčeie nad „bottom posting“om.

[xkucf03]

A jak se to potom liší od „in-line“ citací? Ono i když citaci zkrátíš, ale odpovíš až dolů, je tam toho textu moc. V tomhle je „in-line“ styl lepší.

[mirec]

V počte otázok.

[Franta]

Bottom posting si doslova vyžaduje skrátenie celej diskusie na najnutnejšie minimum tak aby sa nikto neprehrabával 10 stranami dole kým zistí o čom to bolo.

Diskuse se často vlečou a máš tam desítky odpovědí. I když z každé vybereš to nejnutnější, stejně toho po pár iterací bude tolik, že se to nevejde na obrazovku a aktuální zpráva nebude na první pohled viditelná a bude potřeba "scrollovat".

A když to zestručníš moc, tak tam zase ta historie chybí pro případ, že by někdo potřeboval ten kontext -- proto je lepší dát staré zprávy dolů nebo ideálně do přílohy a přečte si je ten, kdo si je přečíst chce a ostatní to neotravuje.

[sss]

Tohle by se melo tesat do kamene.

Diky osvezeni netikety pro mladsi...

[asdf]

bottom posting je nelogická píčovina, kterou používaj pouze asociálové co sou zvyklý na konzolej. normální je vkládat zprávu tam, kde ji příjemce uvidí jako první, to jest nahoru. v korporátní sféře je to naprostý standard, v úřední taky. jediné k čemu je to dobré je, že hned příjemce vidí (když už nevidí zprávu), že má tu čest s asociálním kreténem, kterej musí všechno dělat alternativně, i přesto že má zastoupení nižší jak statistická chyba.

[mirec]

RFC 1855

Prečo mimochodom na abclinuxu.cz nie je najnovšia správa prvá?

[xkucf03]

Diskuse zobrazená na webu je něco jiného než zpráva, která právě dorazila do tvojí schránky. Snad si chceš přečíst to, co zrovna přišlo, a ne něco starého, co už jsi četl, ne? Diskusi si otevřeš celou a celou si ji projdeš (nebo přeskakuješ na nepřečtené příspěvky), ale u e-mailu chceš číst to nové.

„Bottom-posting“ je zlo. Když už, tak (stručné) „in-line“ citace nebo (uvážlivě) „top-posting“.

[Fluttershy, yay!]

U diskuze mě obvykle zajímají nové příspěvky. Zpravidla jsou dole — nebo rozházeny v případě stromové struktury, ale stejně je na stejné úrovni novější komentář pod starším. Prostě všude¹ je bottom posting.

¹ výjimkou jsou některé blogovací systémy, kde mě to taky docela sere, a systémy s prioritami dle hodnocení

[xkucf03]

Analogií diskuse na webu je výpis seznamu zpráv/vláken v e-mailovém klientovi – nikoli okno se zobrazením jedné konkrétní zprávy – jeho analogií je naopak jeden (typicky) div element zobrazující jeden komentář na webu – a ten citace neobsahuje buď vůbec (je navázaný do stromu, podobně jako e-maily jsou navázané přes In-Reply-To a References) nebo výjimečně jako „in-line“ (nikdo normální nedělá „bottom-posting“ – i když v některých „BB“ webových fórech se takový prasata občas najdou).

[Martin Mareš]

Pravil ten, kdo porušuje vůbec první pravidlo vší korespondence, totiž že je slušné se podepsat. Tolik k asociálnosti a kretenismu ;)

[Senior Database Programmer]

prisposobujem sa situacii.. top posting - ked je tema jednoducha, nerozvetvuje sa, je jasne o com si piseme, je to taky "chat" bottom posting - ked sa rozobera viac tem naraz aby bolo vidiet na co reagujem, je to strukturovany text

[xkucf03]

Venovať čas napísaniu predmetu

Souhlas. Ty hrůzy typu RE: Re: Fwd: RE: tady teprve nějaký předmět je potřeba opravit. Nezřídka přepisuji i vlastní předmět, aby to dávalo smysl.

Nepoužívať HTML maily

Doba už se posunula (rychlosti sítí, softwarové vybavení) a tohle pravidlo už IMHO ztrácí smysl. Rozumně použité (X)HTML považuji za výhodu. Nicméně i tak je dobré psát v prostém textu a (X)HTML si zapnout až tehdy, kdy ho skutečně potřebuji. A i tehdy je dobré to poslat jako multipart/alternative a vložit i verzi v prostém textu (o to se samozřejmě má postarat e-mailový klient).

Za smysluplné považuji:

• odrážky a číslování
• zvýraznění: tučné/kurzíva
• ukázky kódu: <pre/>
• odkazy (neposílat však šmírovací a podvodné odkazy)
• citace – <blockquote/>
• ve výjimečných případech tabulky (pokud skutečně chceme vložit tabulková data)
• ve výjimečných případech obrázky (samozřejmě v příloze, ne stahované ze Sítě – šmírování)

E-mail by měl obsahovat minimální nebo žádné styly (písma, barvy…). Styl by měl záviset na nastavení klienta příjemce.

Aby to fungovalo musí byť pätička od obsahu oddelená riadkom "-- " (pomlčka, pomlčka, medzera).

Ano, tak to funguje. Jen mne udivuje, jak někteří lidé cpou „-- “ i do (X)HTML e-mailů. Podobně „vtipné“ je, když odesílatel vloží do zprávy odkaz na přílohu v nějakém svém č(l)oudu nebo file:///… – to si adresát fakt nepřečte

Nepoužívať funkciu odpovedať všetkým … Pred odoslaním odpovede si však treba vždy skontrolovať, či je e-mail určite relevantný pre všetkých prijímateľov, alebo tým len niekomu spamujeme schránku.

Tohle je hlavně odpovědnost toho, kdo to vlákno založil – musí pečlivě vybrat adresáty. Ti, kdo odpovídají, už toho tolik nezmůžou – jednak nemají „pravomoc“ do toho zasahovat (bylo by hloupé, kdyby z příjemců vyřadili někoho důležitého) a jednak ani všechny nemusí znát a nemusí vědět, jak moc se jich to týká.

Důležité tak spíš je rozlišovat příjemce v „Komu“ a „Kopie“ – do první skupiny dáme ty, kdo by si e-mail měli určitě přečíst nebo od kterých dokonce očekáváme odpověď, a do druhé ten zbytek. (jako příjemce si pak zprávy můžu třídit a věnovat větší pozornost těm, kde jsem v poli „Komu“).

Dĺžka riadkov maximálne 80 znakov

Přežitek a archaismus. Navíc, o tohle se má postarat e-mailový klient – má naformátovat odstavce podle velikosti okna.

Máme tu format="flowed", díky kterému lze poslat libovolně dlouhé řádky, resp. zalomení odstavců není závislé na technických omezeních (zalomení MIME zprávy při přenosu – logické vs. fyzické řádky). Je totiž pěkná otrava, když řádky nějak fixně zalomí klient odesílatele a pak ještě klient příjemce (např. kvůli malému displeji nebo v důsledku větší hloubky několikanásobné citace: >>> …) a řádky jsou pak zlámané nadvakrát.

Podobného efektu dosáhneme u (X)HTML zpráv – text logicky členíme do odstavců <p/>, ale zalomení je plně v moci příjemce – odesílatel mu nevnucuje svoji představu o ideální délce řádku.

Odpoveď pod pôvodnú správu

Rozhovor od neznámého autora je sice pěkný, ale osobně ho řadím spíš mezi ajťácké vtipy než mezi nějaké normy a doporučení, kterými by se měl člověk řídit.

• Primárně by člověk neměl citovat nic, protože máme e-mailové hlavičky odkazující na původní zprávu.
• Člověk čte e-mail odshora a právě proto je dobré dát nahoru tu novou zprávu (ty staré už všichni četli a nepotřebují se jimi prodírat znovu a znovu při každé zprávě). Kompletní citace má smysl např. v případě, kdy e-mail přeposíláme nebo přidáváme do adresátů někoho nového, kdo ty zprávy ještě nemá. Kompletní citaci vložíme také když odpovídáme na hodně starý e-mail – příjemce ho mohl smazat nebo si ho už nepamatuje a hodí se připomenout, na co reagujeme.
• V diskusích je nejlepší používat „in-line“ citace – citovat jen větu nebo pár slov a pod to přidat svoji odpověď. Což je ale diametrálně jiný případ než „bottom-posting“, u kterého se člověk musí nejdřív prokousat kilometrem hnoje (historie, kterou už četl) a pak se teprve dostane k aktuální zprávě, která ho zajímá.

[Fluttershy, yay!]

Doba už se posunula (rychlosti sítí, softwarové vybavení) a tohle pravidlo už IMHO ztrácí smysl. Rozumně použité (X)HTML považuji za výhodu. Nicméně i tak je dobré psát v prostém textu a (X)HTML si zapnout až tehdy, kdy ho skutečně potřebuji. A i tehdy je dobré to poslat jako multipart/alternative a vložit i verzi v prostém textu (o to se samozřejmě má postarat e-mailový klient).

Platí totéž co níže:

Dĺžka riadkov maximálne 80 znakov

Navíc, o tohle se má postarat e-mailový klient – má naformátovat odstavce podle velikosti okna.

Nechť e-maily obsahují formátování např. v Markdownu a klient se podle toho zařídí. Nebude problém s primitivnějšími klienty (či strojovým zpracováním) a může to vypadat přehledně. Např. Gmail citace se zobáčkem na začátku barevně odlišuje.

Primárně by člověk neměl citovat nic, protože máme e-mailové hlavičky odkazující na původní zprávu.

Kušuj.

Člověk čte e-mail odshora a právě proto je dobré dát nahoru tu novou zprávu (ty staré už všichni četli a nepotřebují se jimi prodírat znovu a znovu při každé zprávě).

Slušný klient umí historii konverzace sbalit.

[David Jaša]

Nechť e-maily obsahují formátování např. v Markdownu

To by se to muselo nějak sjednotit, standardizovat a hlavně alespoň trochu stejně implementovat.

Slušný klient umí historii konverzace sbalit.

Včetně inline citací? Který?

[xkucf03]

Včetně inline citací? Který?

Na tom je vtipné, že na sbalení XHTML citací v blockquote stačí kousek triviálního JavaScriptu – zatímco pro správné sbalování textových citací je potřeba poměrně složitý kód + nějaké vykreslovací jádro.

[mirec]

zatímco pro správné sbalování textových citací je potřeba poměrně složitý kód

Ak je regulárny výraz zložitý tak asi áno. Inak prevod na HTML je triviálna vec, ktorú s regulárnymi výrazmi a funckiou na prevod entít napíšem v C++ za neskutočne dlhý čas asi 5 minút.

nějaké vykreslovací jádro

Na renderovanie HTML nie je potrebné jadro? Ako jednoducho sa v HTML prerušia citácie tak aby som mohol medzi ňu niečo napísať? Žeby som využil tie relatívne nové javascriptové metódy na manipuláciu s výbermi (document.createRange()), odstránil celý uzol, rozdelil na 2 s príslušným ukončením tagov a modlil sa, aby zase tento týždeň nezmenili API? S HTML a JS mám dosť skúsenosti, babral som do všeličoho od patchovania browserov po užívateľské rozhranie a za dobré to jednoducho nemôžem považovať.

[Franta]

Ak je regulárny výraz zložitý tak asi áno. Inak prevod na HTML je triviálna vec, ktorú s regulárnymi výrazmi a funckiou na prevod entít napíšem v C++ za neskutočne dlhý čas asi 5 minút.

Schválně si to zkus v praxi místo teoretizování S těmi regulárními výrazy bych tě chtěl vidět (nezapomínej na několikanásobně vnořené citace). Já to psal a povedlo se. Není to nějaká věda, ale je to prostě řádově složitější problém než spárovat maily podle jejich hlaviček.

Na renderovanie HTML nie je potrebné jadro?

Jistě že potřebuješ, ale když už používáš takové jádro, můžeš rovnou ty e-maily posílat v (X)HTML. Což ti mj. umožní napsat třeba:

Podívejte se na program konference.

místo:

Program konference naleznete zde: <http://www.example.com/xxx/yyy/nejake/silene/url/program>

Nebo takovou banalitu jako je přidání bodu do číslovaného seznamu, aniž bys musel všechny následující položky přečíslovat. Já vím, jsou to drobnosti, ale zpříjemňují život. Nebo tučně a skloněné písmo, které je skutečně tučné a skloněné a ne jen obložené *nějakými* /paznaky/, což připomíná spíš éru psacích strojů a různá nouzová řešení té doby (z typografického hlediska prasárny), než 21. století.

Ako jednoducho sa v HTML prerušia citácie tak aby som mohol medzi ňu niečo napísať?

Najedeš kurzorem na požadované místo a stiskneš Enter.

Existují hotové WYSIWYG/WYSIWYM editory. Ale zatím jsem neviděl textový editor, který by mi při rozdělení citace doplnil znak > na nový řádek.

Trochu jsi tu smíchal dva problémy do jednoho -- já psal o sbalování/rozbalování citací u přijatých e-mailů. Tvorba odpovědí a úprava citací je jiný problém, ale s nějaký hotovým editorem (napsaným třeba v JS) snadno řešitelný.

[Martin Mareš]

Ale zatím jsem neviděl textový editor, který by mi při rozdělení citace doplnil znak > na nový řádek.

Vim :)

Stačí ho požádat o přeformátování odstavce.

[Fluttershy, yay!]

...což připomíná spíš éru psacích strojů a různá nouzová řešení té doby (z typografického hlediska prasárny), než 21. století.

(...)

Trochu jsi tu smíchal dva problémy do jednoho -- já psal o sbalování/rozbalování citací u přijatých e-mailů.

Pán ráčí být pokrytec?

[Franta]

Díky za rýpnutí – nainstaloval jsem si svoje rozložení klávesnice i na tento počítač, takže už tu nejsem „sto let za opicemi“ a nemusím psát jako v éře psacích strojů…

[Franta]

P.S. Nicméně není to totéž: -- opticky splývá v –, zatímco hvězdička nebo lomítko prsknuté do textu spíš ruší a je potřeba znát danou konvenci a v mozku mít interpret této „syntaxe“.

[Fluttershy, yay!]

Nicméně není to totéž: -- opticky splývá v –

Platí to i pro uvozovky v #70?

[Franta]

Ty "programátorské" uvozovky jsou nouzové řešení (doma je na klávesnici samozřejmě mám – teď už i tady), teď už píši správné „české“.

[David Jaša]

Ale zatím jsem neviděl textový editor, který by mi při rozdělení citace doplnil znak > na nový řádek.

Evolušní pisátko tohle umí.

[mirec]

Celkom slušne je implementované zvýrazňvoanie textu (*asdf*, _asdf_). Zvyšok moc implementovaný nie je, ale ... myslím, že takýmto formátom by som nemal uraziť nikoho ani keď mu to klient nezvýrazní:

Nadpis
======

Text odstavca ...

* položka zoznamu
* ďalšia položka
* tretia položka

Číslovaný zoznam

1. prvá položka
2. druhá
3. tretia aj s nejakým odkazom [1]

> citácia ...

podnadpis
---------

Tu ešte niečo o čom som chcel napísať

[1] http://www.abclinuxu.cz

-- 
veľmi kreatívna pätička

[luky]

Slušný klient umí historii konverzace sbalit.

Včetně inline citací? Který?

KMail v KDE3

[Fluttershy, yay!]

To by se to muselo nějak sjednotit, standardizovat a hlavně alespoň trochu stejně implementovat.

fap-fap-fap... standardizovat... fap-fap-fap...

Ono už to prosazování v zásadě probíhá — G+, GitHub, Reddit,... a zvýrazňování syntaxe je celkem triviální.

[xkucf03]

Nechť e-maily obsahují formátování např. v …

Mělo by to být v něčem standardizovaném, stabilním a uznávaném – ne v jednom z mnoha různých formátů, které si někdo jen tak pro sebe implementoval.

v Markdownu a klient se podle toho zařídí

Zrovna Markdown by byl dost konfliktní s konvencemi používanými v textových e-mailech – např. *tučné* /kurzíva/ zatímco v Markdownu: *emphasis* **tučné**. Odkazy se v e-mailech tradičně píší do <http://www.example.com/stranka.xhtml>, zatímco v Markdownu se používají hranaté závorky. Společné jsou asi jen citace uvozené >, ale ty zrovna Markdown neimplementuje moc dobře.

A ať už se vybere cokoli, určitě by ten formát měl chodit se správným MIME typem, aby klient příjemce věděl, jak to interpretovat.

Proto jsem taky psal o tom multipart/alternative – e-mail obsahuje i verzi v prostém textu pro zařízení, která ten pokročilejší formát nepodporují.

Kušuj.

Vkládat hlavičky In-Reply-To a References (a následně je interpretovat) je celkem triviální a podle mého je to základní funkcionalita, kterou by měl disponovat každý e-mailový klient.

(pokud jde o případy, kdy příjemce ty relevantní zprávy ve schránce nemá – např. přeposílání nebo přidání nového adresáta do vlákna – dá se ta zpráva do přílohy, případně dolů pod text typu „Tady ti přeposílám naši konverzaci:“)

Slušný klient umí historii konverzace sbalit.

Zatímco prolézat text zprávy, vyhledávat v něm citace a pak nabídnout nějaké GUI pro jejich rozbalení/sbalení, zase tak jednoduché není a považuji to spíš za nadstandardní vlastnost.

[Fluttershy, yay!]

Zrovna Markdown by byl dost konfliktní s konvencemi používanými v textových e-mailech – např. *tučné* /kurzíva/ zatímco v Markdownu: *emphasis* **tučné**.

Právě Markdown je v zásadě založen právě na syntaxi používané v e-mailech.

Odkazy se v e-mailech tradičně píší do <http://www.example.com/stranka.xhtml>

Vidím prvně.

Vkládat hlavičky In-Reply-To a References (a následně je interpretovat) je celkem triviální a podle mého je to základní funkcionalita, kterou by měl disponovat každý e-mailový klient.

Žij dál mimo realitu.

[David Jaša]

Vkládat hlavičky In-Reply-To a References (a následně je interpretovat) je celkem triviální a podle mého je to základní funkcionalita, kterou by měl disponovat každý e-mailový klient.

Žij dál mimo realitu.

Tu androidí? Zbytek světa ta vlákna umí aspoň nekurvit, když už je neumí rovnou i zobrazit.

[Franta]

Právě Markdown je v zásadě založen právě na syntaxi používané v e-mailech.

Tak proč je to tam jinak? **...** a *...* vs. *...* a /.../

Žij dál mimo realitu.

Většina klientů - a každý slušný klient - s tím nemá problém. Ale hlavně jde o srovnání s tím sbalováním citací -- přečíst si e-mailovou hlavičku a spárovat ji s jinou hlavičkou jiného e-mailu je jednoduché. Interpretovat text zprávy, hledat v něm citace a umožnit jejich rozbalování/sbalování je podstatně složitější, nemluvě o tom, že existují různé styly citací a jen jeden je standardizovaný (bohužel ne všichni ho dodržují). Řešilo se to tady: Citace v e-mailech, konvence a RFC 3676 a ještě jeden odkaz k tématu: Převod formátovaného textu na prostý text

[David Jaša]

Ty hrůzy typu RE: Re: Fwd: RE: tady teprve nějaký předmět

Co ty hrůzy typu Re: [strašně dlouhý název listu1] [strašně dlouhý název listu2] [PATCH ...] předmět?

[xkucf03]

Tyhle hrůzy jsou přežitek – e-mail obsahuje hlavičku List-Id, která identifikuje konferenci a podle které si je příjemce může třídit. Cpát to ještě do předmětu je nadbytečné a obtěžující.

Číslo patche relevantní je, ale asi by stačilo v první zprávě – odpovědi na ni budou navázané (In-Reply-To/References) a měly by mít předmět vystihující danou odpověď (třeba „díky, začleněno“ nebo „máš to blbě“) ne celé vlákno (to je redundantní informace).

[mirec]

Nejako som včera odpovedal narýchlo takže ešte jedna vec, ktorá ma napadla k top vs. bottom postingu.

Což je ale diametrálně jiný případ než „bottom-posting“, u kterého se člověk musí nejdřív prokousat kilometrem hnoje (historie, kterou už četl) a pak se teprve dostane k aktuální zprávě, která ho zajímá.

S touto situáciou sa práve stretávam u top postingu kde prvú správu mám v tvare "Prosím ťa pozri sa na to" a potom začínam čítať odspodu. Najskôr nájdem dole pätičku, potom smerom nahor hľadám správu, potom hľadám začiatok správy, čítam správu smerom dole po pätičku, potom hľadám smerom nahor začiatok správy, ktorú som prečítal, potom sa snažím preskočiť hlavičku (to čo outlook vkladá, proste 10-riadková kopa bordelu), potom preskakujem pätičku, hľadám začiatok ďalšej správy ... a takto sa to opakuje povedzme 10x. Ak vynechám hlavičky a pätičky ktoré tvoria 90% mailu vyzerá komunikácia nejako takto:

• Prosím ťa pozri sa na to
• Máte to schválené
• Môžte urobiť ... toto ma zaujíma
• Prístupové údaje sú ...toto ma zaujíma
• Potrebujeme prístupové údaje na ...
• Pošlite to ... oddeleniu nech to schália

Ak by som si pri takejto správe mal vybrať medzi top a bottom postingom tak budem preferovať bottom posting už len preto, lebo sú správy v prirodzenom poradí a nemusím stále hľadať začiatky správy. Tým nechcem obhajovať že je to dobré, jedno aj druhé je samo o sebe zlo.

Dôvod prečo si myslím (a nie len ja, ale aj RFC o netikete to hovorí, inak som si text nevycucával len tak z prsta), že je bottom posting lepší je to, že pisateľa núti skrátiť text na rozumnú mieru. Ak jednoducho vidím, že preto aby som sa dostal k písaniu odpovede musím scrollovať tak je to jednoznačne zlé.

Nepamätám si, že by mi niekto, kto používa bottom posting poslal kopu hnoja. Jednoducho sa to nestáva lebo vidí ten bordel, ktorý predchádza samotnú správu a automaticky urobí sumár toho, čo už bolo napísané a je podstatné. Naopak u bottom postingu je takmer každý mail hrozný pretože sa preposiela celá komunikácia aj s úplne irelevantnými správami, cez ktoré sa musím prehrabávať. Myslím si, že je dôležité starať sa o to, čo posielam a jednoducho pozrieť aj na citácie či sú dobre čitateľné. V poslednej dobe sa mi napr. stáva, že niekde v tej reťazi správ ma niekto super android klienta, ktorý správu zúži na 80 znakov a ešte medzi každý riadok vloží medzeru. Čítanie niečoho takého keď sú medzitým 10-riakdové hlavičky a 10-riadkové pätičky a všetko vyzerá rovnako, bez odstavcov je jednoducho na psychiatra. Ak by boli otázky nad odpoveďou tak by to ten, ktorý taký bordel odosiela jednoducho musel vidieť.

Takže ak by som to mal zhrnúť .. je mi fuk či mi niekto pošle top alebo bottom posting ak je primerane krátky. Dokonca mám klávesové skratky na prepínanie štýlu odpovede v mailovom klientovi, takže odpoviem rovnakým štýlom. Ak je ale niekto prasa a dá celú komunikáciu nad odpoveď tak, to budem považovať za rovnakú blbosť ako dať celú irelevantnú diskusiu dole a medzi ňu jednu správu, ktorá nesie nejakú informačnú hodnotu. Moje skúsenosti však hovoria, že top-posteri sú zvyčajne prasce a bottom posteri zvyčajne upratujú diskusiu.

[David Jaša]

Dôvod prečo si myslím (...), že je bottom posting lepší je to, že pisateľa núti skrátiť text na rozumnú mieru.

Teorie. Na mailing listech se typicky posílá všechno bez ohledu na to, kam dotyčný odpovídá a kolik toho napíše.

[mirec]

Ja mám s usenetom presne opačné skúsenosti. Vidím tam väčšinou také vykopávky ako ja, ktoré sa snažia o to, aby diskusia vyzerala prehľadne.

[Franta]

Od toho by tam měl být nějaký správce, který tam zařídí pořádek. U e-mailových konferencí jsou kompletní citace extrémní prasárna (víc než v obyčejných e-mailech), protože tu máme archivy, kde se ta historie dá hezky dohledat, jsou tam stromy/vlákna, fulltextové vyhledávání atd.

Takovou prasáckou konferenci znám jen jednu -- jinak mám asi dost štěstí, protože v těch ostatních se necituje vůbec, nebo je "in-line" nutné minimum. A tak je to správně, tak to má být.

[David Jaša]

Od toho by tam měl být nějaký správce, který tam zařídí pořádek. U e-mailových konferencí jsou kompletní citace extrémní prasárna (víc než v obyčejných e-mailech), protože tu máme archivy, kde se ta historie dá hezky dohledat, jsou tam stromy/vlákna, fulltextové vyhledávání atd.

To je u neveřejných listů spravovaných čistokrevným mailmanem taky teorie. Správcové mají dost jiné práce a najít něco v defaultních mailmaních archivech bez externího fulltextu (který z různých důvodů není) se dá jen metodou najdi to ve svém MUA a pak jdi v archivu najisto.

Jinak hlavní důvod nemazání historie je jednoduchý: poměrně často je do konverzace zatažen někdo, kdo list nečte - bez pohodlného způsobu, jak ho odkázat na archiv, je vložená citace tím nejlepším, co je k dispozici.

[Franta]

bez pohodlného způsobu, jak ho odkázat na archiv, je vložená citace tím nejlepším, co je k dispozici.

Nikoli. Nejlepším způsobem je přeposlat mu tu zprávu/zprávy v příloze -- pak má totiž k dispozici nejen celý text, ale i hlavičky (kdy, kdy komu to posílal) a může taky odpovědět na některou z těch zpráv z historie a příjemcům se tato odpověď zařadí na správné místo ve stromu, protože se spáruje pomocí Message-ID.

[David Jaša]

Evolůšn tu přílohu je schopen zobrazit hezky inline, skoro jako by šlo o top-posting:

zpráva

[v] 			E-mailová zpráva příloha, "předmět"

příloha

ale není schopen na ni odpovědět. Zimbří webxicht na ni umí odpovědět, ale vyžaduje pop-up okno, které se s trochou štěstí napodruhé i načte. Ani jedno z toho neumí přibalit celé vlákno chronologicky.

Tedy opět, v praxi je to co píšeš čirá teorie.

[Franta]

Proč posuzovat praxi podle dvou okrajových klientů? Např. v Thunderbirdu si označím vlákno nebo vybrané zprávy, přetáhnu je myší do okna s novou zprávou a vloží se jako přílohy. Na straně příjemce je pak vidím pod zprávou (není je potřeba rozklikávat), tzn. jako „top-posting“. Přiložené zprávy si můžu rozkliknout a pak na ně odpovědět nebo si je uložit na disk. Pak si je můžu natáhnout do nějaké schránky a rekonstruovat si z nich původní strom/vlákna.

Když se ale zprávy převedou na prostý text, splácnou dohromady, hranice mezi nimi se rozpliznou a metadata se ztratí.

Pokud bych měl stanovit nějaké pořadí obecné (pro konkrétní případy se může lišit) vhodnosti, pak by to bylo:

1. „in-line“ citace
2. zprávy v příloze
3. „top-posting“
4. „bottom-posting“

[Franta]

resp. na prvním místě: „in-line“ citace nebo žádné citace

[David Jaša]

Proč posuzovat praxi podle dvou okrajových klientů?

Praxi posuzuju podle těch desítek až nízkých stovek mailů, co mi denně přistávají ve schránce. Chování MUA je jen pro ilustraci.

Např. v Thunderbirdu si označím vlákno nebo vybrané zprávy,

Jo, když označím vlákno, tak evo taky pošle všechno - ale už v těch přílohách není hned viět informace o vláknu.

Když se ale zprávy převedou na prostý text, splácnou dohromady, hranice mezi nimi se rozpliznou a metadata se ztratí.

Můj do mozku integrovaný parser zobáčky zvládá, pokud nejsou podrbané tak, jak to svého času uměl enigmail (to byl mimochodem můj důvod pro zdrhnutí od tbirdu).

Pokud bych měl stanovit nějaké pořadí obecné (pro konkrétní případy se může lišit) vhodnosti, pak by to bylo:

mě je to celkem jedno, co mi přijde, pokud to obsahuje In-Reply-To.

[otula]

Sice s některými věcmi nesouhlasím (zalamování řádků nebo zahazování citace - mohu totiž odpověď číst na úplně jiném počítači, než z něhož jsem původní mail posílal), ale jinak naprosto souhlasím. Z mailové "kultury" některých osob se mi otevírá příslovečná kudla v kapse.

[kyytaM]

Ved to...mam tu smolu, ze sa ku mne obcas dostane preposielana posta od ministerskych ludi a vacsinou, cim vyssia funkcia, tym vacsi deficit inteligencie a schopnosti komunikovat.

[Franta]

To s funkcemi nemá moc co dělat – jednou jsem psal do jakéhosi autoservisu úplně jednoduchý dotaz (kolik to stojí a kdy to můžou dodat) a jako odpověď přišel prázdný e-mail + příloha ve Wordu, kde bylo jejich úžasné sdělení (cena vysoko nad konkurencí a termín dodání neznámý). Takové e-maily je lepší házet rovnou do koše.

[otula]

Třeba se tím chtěli propracovat také na vysoké posty