
Jak jsme si postavili TestBench
…aneb proč nepotřebujete celý mikroskop, když chcete otestovat firmware
Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání
Čtení uživatelského manuálu je často bráno jako poslední, někdy až potupný, krok. S novými technologiemi ho ale často dokážeme nahradit googlením a dnes už také dotázáním AI. Má tedy vůbec v dnešní době smysl uživatelské manuály vytvářet?
Můj kolega navrhuje API pro řízení elektronového mikroskopu tak, aby uživatel nepotřeboval manuál k tomu, aby mohl něco provést. Názvy všech funkcí a metod jsou tak často trochu delší, ale perfektně vystihují, co dělají.
UX by nemělo být sprosté slovo a UX designér chápán jako někdo, kdo maluje tlačítka. Pokud je vše srozumitelné a jasné, uživatelé budou naši aplikaci používat mnohem raději a efektivněji. Správný návrh uživatelského rozhraní tak může být klíčový při rozhodování, jakou aplikaci používat nebo zakoupit. Uživatelé jsou přece jenom lidi s emocemi a pokud je hned ze začátku naštveme nebo zaženeme do kouta, už se k nám příště nemusí vrátit.
Stejně jako samotná aplikace, i manuál by měl být uživatelsky přívětivý. Uživatel by měl snadno najít, co hledá – ať už pomocí odkazů nebo vyhledávání.
Měli bychom se vyvarovat složitým formulacím a pochopit, že na „druhém konci“ může být často člověk, který si neví rady nebo plně nechápe, jak daná věc funguje. Nebo naopak dané věci rozumí, ale nedokáže se zorientovat v námi napsaných zkratkách a termínech.
Struktura samotného manuálu nebo jeho stránek je klíčová. Používání základního formátování, jako jsou nadpisy, odstavce nebo odrážky, beru jako samozřejmost. Někdy je vhodnější místo odstavce textu využít například tabulku nebo obrázek.
S používáním obrázků bych byl ale opatrný. Obrázek sice řekne více než tisíc slov, ale může přinést také nečekané komplikace.
Spousta aplikací nebo webových stránek dnes umožňuje tmavý a světlý režim nebo přímo možnost používání různých barevných schémat, či dokonce kompletní přenastavení uživatelského rozhraní. Obrázek aplikace v manuálu tak vůbec nemusí odpovídat skutečnosti.
Jak moc detailní má manuál být? Někoho stačí pobídnout jednoduchým “otevřete soubor” a někdo potřebuje vést krok po kroku: “klikněte na nabídku ‘Soubor’ v horním menu aplikace a poté vyberte možnost ‘Otevřit’”. Hranici mezi jednoduchostí a účelem bude vždy těžké stanovit. Je dobré vyházet z profilu našich uživatelů případně z obecných zvyklostí. Mysleme ale na to, že my jsme “ajťáci” a náš pohled může být v tomto ohledu velmi pokroucený.
S obrázky v manuálech souvisí také další problém. Změna popisu tlačítka může vést například k tomu, že je potřeba vyměnit desítky obrázků v manuálu. Doporučoval bych tedy obrázky používat jen tehdy, pokud je to nezbytně nutné – například pro vysvětlení toku dat v aplikaci nebo propojení jednotlivých modulů. Obrázkům uživatelského rozhraní bych tak doporučoval se úplně vyhýbat. Všimněte si například, že dokumentace společností jako Google nebo Microsoft žádné obrázky neobsahují. Jejich uživatelské rozhraní se mění tak často, že by údržba obrázků v podstatě nebyla možná.
Samotný manuál by měl být dobře a snadno udržovatelný. Neměl by to být proces, při kterém oprava překlepu zaměstná jednoho člověka na půl dne.
Pokud bereme uživatelský manuál jako součást dokumentace našeho produktu, výrazně to pomáhá zvyšovat jeho význam. V ideálním případě je tedy jeho zdroj součástí projektového repositáře nebo dokumentačního systému.
A kdo má na starosti psaní manuálu? Často si tuto zodpovědnost mezi sebou členové týmu přehazují jako horký brambor. Měla by to být ale zodpovědnost celého týmu. Vytváření a správa manuálu by také měla být běžnou součástí vývoje.
Důležité je také to, že neaktualizovaný manuál je špatný manuál. V našem týmu je například aktualizace manuálu součástí dodávky, stejně jako dodání samotného zdrojového kódu a testů.
Ano. A potřebujeme je mnohem více než kdy předtím. AI se učí z dat. A uživatelský manuál je skvělý zdroj dat. Jako vývojáři bychom tento fakt měli brát v potaz. Měli bychom uživatelské manuály vytvářet tak, aby se z nich AI mohla učit nebo je přidat do svého kontextu. V ideálním případě by tak uživatelský manuál měl být strojově čitelný – například ve formátu HTML nebo ideálně Markdown. AI agenti si ale v dnešní době poradí i s jinými formáty, v případě uživatelských manuálů to tak nejčastěji může být například PDF.
Uživatelský manuál je tedy podle mě důležitou součástí software. Měl by být kvalitní, udržitelný a přínosný, a tedy splňovat stejná kritéria jako software.
Vývojářům by neměl přitěžovat a vývojáři by na oplátku měli přemýšlet nad jeho formou. Mělo by se jednat o živý dokument (současně ale zakonzervovaný například pro danou verzi aplikace), se kterým je možno také dále pracovat například pomocí AI.

…aneb proč nepotřebujete celý mikroskop, když chcete otestovat firmware

Jak probíhá organizace game jamu, od prvotních kroků až po finální vyhlášení? V čem se náš game jam lišil od těch tradičních a proč je vlastně super nápad takový game jam ve firmě zorganizovat?

Každý projekt, ve kterém se používají LLM pro generování kódu, testů nebo dokumentace, by měl obsahovat i nějakou harness – sadu pravidel, podle které se má agent chovat. Konfigurace těchto pravidel je bohužel stále rozdílná; jednotlivé cloudové AI nástroje (Copilot, Codex, Claude) mají různé formáty. Náš tým je složen z lidí z různých organizací, proto se snažíme vytvořit harness, která by byla pro všechny nástroje společná a vedla by k podobnému chování agentů.
Děkujeme za váš zájem o odběr našeho newsletteru! Pro dokončení registrace je potřeba potvrdit vaše přihlášení. Na zadaný e-mail jsme vám právě zaslali potvrzovací odkaz. Klikněte prosím na tento odkaz, aby bylo vaše přihlášení dokončeno. Pokud e-mail nenajdete, zkontrolujte prosím složku nevyžádané pošty (spam) nebo složku hromadné pošty.
