duben 2020
Dokumentace není potřebná, když je všem hned jasné, jak daný produkt funguje, co je s ním možné provádět, a co si počít, když zase tak dobře nefunguje.
Tedy:
- věc lze použít jediným způsobem
- vždy to dopadne stejně
- nikdy se to nerozbije, nebo alespoň ne tak, aby nebylo jasné, že se to rozbilo a proč.
Takže? Třeba džbán? Ale věděli jste, že tak dlouho se chodí se džbánem pro vodu, až se ucho utrhne?
Nevěříte?
Za rok 2019 bylo průměrně cca 70000 hledání za vteřinu. Proč to tak je?
Jaké informace ale vlastně lidé na internetu nejvíce hledají?
Podle https://trends.google.com hledali Češi a Češky nejvíce následující informace:
- Jak se plete pomlázka
- Jak zamrazit houby
- Jak vyndat klíště
- Jak ochladit byt
- Jak vyfouknout vejce
- Jak na octomilku
- Jak vyvolat menstruaci
- Jak vyplnit daňové přiznání
- Jak vydělat peníze
- Jak začít běhat
- Jak naladit
- Jak vyrobit sliz
- Jak vyplnit daňové přiznání
- Jak volit prezidenta
- Jak zhubnout břicho
- Jak vyndat klíště
- Jak vyplnit přihlášku na střední školu
- Jak volili vaši sousedé
- Jak uvázat kravatu
- Jak zhubnout stehna
- Jak uplést pomlázku
- Jak zamrazit houby
- Jak volit
- Jak upéct husu
- Jak vyplnit daňové přiznání
- Jak vyfouknout vejce
- Jak vyrobit máslo
- Jak stahovat z YouTube
- Jak naladit Prima Love
- Jak zhubnout stehna
Je možné, že lidé s přístupem na internet
- raději hledají na internetu než ve svém okolí?
- spoléhají se, že tam tyto informace najdou?
- věří, že jsou internetové informace správné?
- neradi si pamatují?
... protože život je zkrátka příliš složitý.
- Návody k použití
- Popis vlastností
- Seznam částí
A takovou dokumentací se budeme zabývat.
- YouTube
- diskusní servery a blogy
- infografiky
- vysvětlivky
- školní výuka a učebnice
- rada od přátel
- a mnoho dalších
Existují čtyři základní přístupy k dokumentaci:
-
konceptuální
-
procedurální
-
referenční
-
výukový
Konceptuální dokumentace se snaží vysvětlit uživatelům danou problematiku (koncept) tak, aby tito pochopili princip fungování a potřebné souvislosti.
Například:
-
na jakém principu funguje Wankelův motor
-
jaký rozdíl je mezi vektorovou a rastrovou grafikou
-
jak pracuje rekuperace v elektromobilu
-
jak zhubnout stehna
Procedurální dokumentace poskytuje jasný návod, většinou rozdělený na jednotlivé kroky (procedura), ke splnění uživatelského záměru (user case). Mimo jiné:
-
jak nainstalovat aplikaci X.
-
jak vytvořit nového uživatele v systému Fedora
-
jak si vyjednat slevu u mobilního operátora
-
jak upéct husu
Referenční dokumentace nabízí ucelený přehled (referenci) vlastností, voleb, nastavení a způsobů použití, aby si uživatel mohl sám objevit vlastní přístup a sestavit si své vlastní postupy:
-
manuálové stránky v Linuxu
-
přehled typů žárovek pro osvětlení vozidla
-
přehled voleb příkazu
dnf
ve Fedoře -
vysvětlení významu jednotlivých polí daňového přiznání
Výuková dokumentace, tzv. tutoriály, je spojení konceptuální a procedurální stránky dokumentace, takže výsledkem není jenom splněný uživatelský záměr, ale také částečné pochopení problematiky a kontextu.
Je velmi důležité, abychom z konceptuálního hlediska vysvětlili pouze tolik, kolik je nezbytně nutné. Chceme-li pomocí tutoriálů vysvětlit širší problematiku, pak volíme několik na sebe navazujících.
-
jednoznačné výrazy
-
jednoduché a krátké formulace
-
neutrální výrazy
-
genderově neutrální prvky
-
v případě pochybností je lepší více informací než méně
-
rozkazovací způsob (procedury)
-
estetické formy jazyka (metafory, přirovnání, nadsázka)
-
hovorové výrazy
-
ironie a sarkasmus
-
humor
-
zlehčování problémů
-
utěšování uživatelů
Někdy můžeme uznat za vhodné pravidla porušit a získáme tak jinou formu dokumentace, jež je
-
zajímavá
-
neotřelá
-
vtipná
-
parodická
Je však nutné si uvědomit, kdo budou čtenáři naší dokumentace a jsou-li tito ochotni takový přístup snášet.
Dokumentaci můžeme psát ve spoustě různých formátů. Záleží, co přesně od dokumentace očekáváme:
-
obtížnosti tvorby dokumentace (WYSIWYG, markdown, markup, . . . )
-
metody zobrazení (web, čtečka, tištěné médium, audiovizuální metody)
-
možnosti spolupráce (žádná, cvs, git, Google)
-
možnosti publikace (ručně, automaticky (CI))
-
dostupnosti metadat textu (sémantický markup)
Dále se budeme zabývat pouze psanou dokumentací.
To je popisování textu tak, abychom kromě formálních znaků zapsali také významové a funkční souvislosti.
Například:
** tučné **
(Markdown)<b>tučné</b>
(HTML)\textbf{tučné}
(LaTeX)* tučné *
(Asciidoc)
Například:
<b class="command">rm -rf *</b>
(HTML)<command>rm -rf *</command>
(DocBook)'command':*ls -a *
(Asciidoc)\begin{enumerate}
(LaTeX)
Pokud se v souvislosti s dokumentací mluví o formátech, pak máme na mysli v podstatě dva typy a to:
-
zdrojové formáty, tedy ty, ze kterých se dokumentace překládá
-
cílové formáty, tedy ty, do kterých se překládá
Některé souborové formáty mohou být jak zdrojové, tak cílové (HTML).
-
čistý text
-
markdown (Markdown, AsciiDoc)
-
markup (HTML, XML, DocBook, Mallard, reST, LaTeX)
-
nativní formáty WYSIWYG aplikací (doc, docx, fm, odt, indd)
-
HTML (web)
-
epub, mobi a další (ebooky)
-
pdf (tiskárna)
-
Markdown (Github)
-
AsciiDoc (Red Hat)
-
reST (Python)
-
Mallard (Gnome)
-
TeX, LaTeX (vydavatelské domy)
-
DocBook (SuSE, IBM)
Před výběrem formátu pořádně zamyslet, co od něj přesně chceme, neboť špatný výběr formátu může celou tvorbu dokumentace zkomplikovat. Ptejme se na:
-
formu spolupráce
-
obtížnost psaní
-
automatizované testování a publikování
-
formy výstupu
-
přenositelnost do jiných formátů
-
budoucnost projektu
Obecně platí, že čím složitější formát, tím více možností použití.
Dokumentace obvykle vzniká následujícím postupem:
-
zjišťování potřeb uživatelů
-
plánování a alokace zdrojů
-
stanovení formy spolupráce a formátu
-
tvorba zdrojových dokumentů
-
překlad do cílových dokumentů
-
publikování
-
vyhledání a opravení chyb
-
znovu přeložení a publikování (nová subverze)
Red Hat v současné době udržuje mnoho dokumentačních projektů. Organizační struktura dokumentačního oddělení má několik pilířů:
-
obsahový stratég (content strategist)
-
technický manažer (pillar lead)
-
manager pro lidské zdroje (people manager)
-
programový manažer (document program manager)
-
dokumentátor (technical writer)
Každý z nich je zodpovědný za jinou oblast vývoje dokumentace.
-
Většina dokumentačních projektů v Red Hatu používá AsciiDoc jako hlavní syntaxi pro vytváření zdrojových textů.
-
Totéž se týká dokumentace Fedory.
-
Mnoho projektů používá tzv. modulární přístup a upřednostňuje jej před klasickým přístupem.
-
Systém Docs-as-code
-
výstup lze poskládat pro každého jinak (customizace)
-
jednou napsaný modul lze použít na více místech textu (reusability)
-
lepší orientace v textu
-
naprogramovat mechanismus pro customizaci není jednoduché a v současné době se žádný takový nepoužívá
-
použít modul na více různých místech je obtížné až nemožné bez řádných metadat, avšak psaní metadat velmi prodlužuje dobu vývoje modulu
-
bez systémů, které dokážou mezi moduly hledat, je ruční hledání zdlouhavé
-
modularizace dělaná ručně není škálovatelná
-
lidské ego se nerado dělí --- je v povaze člověka zkoušet vynalézat neustále kolo s myšlenkou, že to moje bude teprve to pravé.
Tohle je poměrně moderní, ale už dost rozšířený, způsob, kdy s dokumentací zacházíme jako s kódem a používáme:
-
popisovací jazyk (Markdown, AsciiDoc, LaTeX, Docbook)
-
sdílený repozitář (Gitlab, Github)
-
správu verzí (Git, SVN)
-
kontinuální integraci (CI)
-
automatické publikování (web)
GitHub (github.com) dokáže překládat soubor README.md
příslušného projektu a ten zobrazovat v HTML formátu na adrese uzivatel.github.io/repositar
.
Tato prezentace je také na Githubu jako repozitář cvutkurz
a je mimojiné dostupná přímo na http://dokumentarista.github.io/cvutkurz.
-
Klonování Git repozitáře
git clone https://github.com/dokumentarista/cvutkurz.git
-
Vytvoření lokální větve pro vývoj
git checkout -b novy_slide
-
Změny v nové větvi
-
Přidat změny do gitu
git add .
git commit -m "Provedene zmeny"
-
Nahrát změny na server.
git push [--set-upstream origin novy_slide]
-
Pokračovat ve změnách a opakovat kroky 4 a 5 dle potřeby.
-
Verze se uchovávají ve větvích (branch)
-
V nich probíhá vývoj.
-
Posléze se změny převedou do
master
větve (merge).git merge novy_slide
-
Nahrání upraveného masteru na server
git push --force
-
Za chvilku se změny projeví (tzv. continuous integration) a v hlavní větvi se objeví obsah vývojové větve.
Správné použití vzduchového kompresoru:
-
Zajeďte s autem co nejblíže kompresoru, abyste tlakovou hadici dosáhli na každé kolo.
-
Odšroubujte kryt ventilku.
-
Rozmotejte tlakovou hadici a připojte ji na ventilek.
-
Z manometru na kompresoru odečtěte současný tlak v pneumatice.
-
Stisknutím a přidržením tlačítka Plus zvyšte tlak na požadovanou hodnotu, nebo jej pomocí tlačítka Minus snižte.
-
Odpojte hadici od kola a smotejte ji ke kompresoru.
-
Našroubujte kryt ventilku.
Fedora je komunitní distribuce Linuxu, na jejímž vývoji se může podílet kdokoliv. Tak i na její dokumentaci.
-
repozitáře na pagure.io (Git)
-
využívá projekt Antora (antora.org)
-
vydána na docs.fedoraproject.org
Přispět můžete po přečtení návodu https://docs.fedoraproject.org/en-US/fedora-docs/contributing/
Proč, když líná pes, tak mu padají chlupy, ale když líná huba, tak je holé neštěstí a ne ta huba, která líná?