Programátor vs. uživatel vol. 6 - úkolníček

... aneb sám sobě pokusným králíkem. Nebo také dvě definice blbuvzdornosti.

Naprogramoval jsem aplikaci. Pak jsem ji začal používat. Můj pohled na ni se diametrálně změnil.

Jak to začalo

Dalo by se říci, že na počátku bylo vzájemné hecování v kanceláři. Ale ještě dříve tomu předcházel projekt NEXA. Kolegové z Vídně tenkrát přidělovali úkoly způsobem, že je prostě "poslali do Brna," a nějak se o to podělte. Přišlo, co přijít mělo: ztratil jsem přehled, co už je hotovo a co ještě ne (kolega, který se mnou na projektu pracoval, ztratil přehled ještě dříve než já). Server, na kterém by bylo možno rozjet systém pro servisní tikety, k dispozici tenkrát nebyl, takže jsem použil nůž švýcarák pro manažery: Excel. Tabulka to byla mimořádně povedená, ale už v té době se začaly rodit myšlenky, že by se ten úkolník mohl zcela regulérně naprogramovat.

Projekt NEXA záhy skončil a my jsme byli převeleni na "projekt IDLE" - práce sice nebyla, ale firma si nás chtěla ponechat pro budoucí projekty. A v tom čase se zrodila aplikace TaskList - desktopový systém pro servisní tikety. Základní požadavek na aplikaci byl, aby uměla to, co uměla má excelovská tabulka: přiřadit více lidí na jeden úkol (tiketové systémy, které jsem tenkrát znal, uměly přiřazovat na úkol pouze jednoho člověka), aby bylo možno libovolně přidávat sloupce (v jednom okamžiku vznikla potřeba evidovat, kde práce vázne: jestli kolega čeká na odpověď z Vídně a ta nepřichází, nebo dělá něco urgentnějšího) a už nevím přesně, co jsem ještě chtěl, ale jednim z požadavků bylo, aby aplikace uměla komunikovat ve více jazycích.

V současné době je to mrtvý projekt, další vyvoj nemám v plánu. Ikdyž - nikdy neříkej nikdy. Když se na aplikaci dívám nyní po cca deseti letech, říkám si, že jsem ji tenkrát během těch dvou měsíců práce dost dobře vymazlil...

Programátor ...

Při programování jsem sledoval ještě jeden cíl: naučit se novinky, které přinesla tenkrát aktuální Java 5. Ale to už je myslím off-topic.

Začal jsem datovým modelem. Udělal jsem správu pracovníků, správu atributů (free text nebo výběr ze seznamu), vlastní seznam úkolů pak šel snadno. Poté jsem se soustředil na konzistentnost dat: co se stane, když je odstraněn pracovník a má přiřazeny úkoly? Co když někdo změní typ atributu z textu na seznam nebo obráceně? Prostě co když uživatel provede změnu, která bude mít vliv na všechny již existující úkoly? A tak dále, každopádně zbývající nedodělky na seznamu měly společného jmenovatele: stabilitu a konzistentnost dat, tedy aby aplikace byla blbuvzdorná.

... a uživatel

Aplikace ještě nebyla hotová, když jsem ji začal používat: projekt IDLE skončil a já jsem si v aplikaci začal evidovat svou práci. A začal jsem si klást úplně jiné otázky: proč musím lézt do menu vždycky, když chci úkolník uložit? A jak vlastně poznám, jestli mám nebo nemám úkolník uložený? Když ještě vezmu v potaz, že se při zavření hlavního okna aplikace ukončí bez ptaní a já tak mohu přijít o změny, které jsem v úkolníku udělal, bylo používání aplikace dost nepohodlné. Pořád jsem musel myslet na to, jestli je úkolník uložený. Funkce, které jsem předtím tak usilovně programoval, jsem však ani jednou nepoužil. Jak jsem na začátku nadefinoval uživatele a atributy, tak jsem je beze změny nechal.

Požadavky na aplikaci se tedy změnily: tlačítko pro ukládání umístit na toolbar, do záhlaví udělat hvězdičku, že úkolník není uložený, a při zavírání upozornit na případný neuložený úkolník. Tedy aby aplikace byla blbuvzdorná.

Co z toho plyne

Která definice blbuvzdornosti je tedy lepší?

Kdybych měl rozhodnout, na které straně je pravda, rozhodnutí bude těžké: pravda je totiž na obou stranách. Ikdyž větší důraz bych dal na stranu uživatele. Přece jenom je to uživatel, kdo rozhoduje o úspěchu aplikace. Na druhou stranu, nekonzistentnost a nestabilita je také něco, co může uživatel vnímat jako své nepohodlí. Každopádně vyzkoušet si sám na sobě a porovnat, jak vnímá programátor a jak uživatel, to je dobrá zkušenost.