Pozývam Vás na stretnutie, na ktorom zástupcovia Úradu podpredsedu vlády SR pre investície a informatizáciu a Slovenskej User Experience asociácie predstavia výsledok svojej niekoľkomesačnej spolupráce – jednotný dizajn manuál elektronických služieb ID-SK .
Predstavenie ID-SK sa bude konať 18. októbra v priestoroch FIIT STU (poschodie -1, miestnosť 27). Bude spojené s prednáškou o dizajn manuáloch a panelovou diskusiou so zástupcami ÚPVII, SUXA a Slovensko.Digital.
Harmonogram:
9:00 privítanie
9:15 prednáška: Čo je to dizajn manuál?
9:45 panelová diskusia
Stretnutie je určené najmä pre odbornú verejnosť – zadávateľov projektov (úradníkov), IT firmy a iné odborné entity. Vítaný je však každý občan, ktorému záleží na dobrej použiteľnosti štátnych služieb. Vstup je voľný, z kapacitných dôvodov Vás však prosím o zaregistrovanie.
Tymto chcem aspon ja SUXA podakovat za to, ze to vlastne cele tahaju na UPVII. Bez nich by sme tento manual nemali. Skoda, ze ich v reportazii ani nespomenuli.
Na upvii vznikla podskupina k egov dizajn manualu, za SD tam budem chodit ja. Za SUXA predpokladam @michalblazej. Budem tu informovat o tom co sa tam deje.
FYI skupina bola prvý krát zvolana na tento štvrtok. Ak sú nejaké témy, ktoré chcete otvoriť sem s nimi. Ohlásené témy sú:
update kódu
priorizácia tém (zber podnetov, rozvoj)
predstavíme novo vydávané Metodické usmernenie Princípy používateľsky kvalitných služieb, ktoré rovnako ako JDM vychádzajú z Gov UK a nadväzujú na ňho, pričom by mohli tvoriť základ pre ďalšiu diskusiu k rozvoju JDM
Za mňa bude zaujímavé, či bude spolupráca aj s oficiálnym gov UK (patche do upstreamu, komunikácia) a k prioritam by som zaradil redizajn kritickej cesty (end2end) scenár pre podania. Čo zahŕňa napríklad redizajn podpisovania a prihlasovania lebo úprimne je to z ux pohľadu hrozné.
Mali sme take male stretnutie v ramci developerov od dodavatelov ISVS na prelome rokov, mali sme z toho zopar vystupov (navrhov), ktore sme komunikovali na @michalblazej. Jednoznacne a jednohlasna myslienka z toho je, ze IDSK nam vyrazne zjednodusuje zivot aj co sa tyka komunikacie na OVM pri dodavkach systemov.
Leitmotiv vsetkych odporucani je, ze je nevyhnutne zadefinovat proces rozvoja (update-y z Gov UK, nove prispevky a ich proces tvorby a schvalovanie), pricom viaceri dodavatelia sme prejavili zaujem prispievat nasimi kapacitami aj pro bono, kedze nam IDSK ulahcuje zivot.
Pred stretnutim bola distribuovana schvalena metodika. Pracovala na nej SUXA a UPVII. Upozornil som, ze sa nam nepozdava tento sposob, kedze od tohto by mala byt PS a malo by to byt pripomienkovatelne pred schvalenim.
vysvetlene bolo to narychlo lebo uz idu VO a chcu, aby sa s tym ratalo, takze preto to rovno schvalili
chcu to dostat, aby to bolo zavazne do konca roka (plus prechodne obdobie pre stare systemy)
navrhol som, ze pre kriticku cestu (prihlasenie, slovensko.sk, podpisovac, odoslanie) by malo byt riesene prioritne
mozeme posielat pripomienky
chybaju tam napr. proaktivne sluzby
Odvolavky na standardy v dokumente - Pytal som sa ci boli nejako opatovne validovane. Napr. “sledovanie pokroku, pocet procesnych krokov” - je v rozpore s gov.uk, niekedy sa ani neda urobit, europska unia to hodnoti. - co s tym?
dizajn manual
pripomienky od MHSR, SUXA, Nases, MSSR (niektore vyriesene)
kratkodobo
prechod na novy kod (nutnost co najskor)
pro-bono (strazca kvality kodu) - upozornil som, ze toto dlhodobo nebude fungovat (napr. na udrzbu)
strednodobo
dovysvetlit aplikaciu dizajn manualu (vysvetlit co je ok a co nie je ok nedodrzat)
webstranka pre vystupy prace BRISK (behavioralne inovacie)
dlhodobo
interny technicky tim
upozornil som, ze urcite ma zmysel pred vyvojom kompoenntu otvorit diskusiu na gov.uk a pripadne nase komponenty tlacit hore
Bude stretnutie k technickym veciam + fork
Standarizacia URL
kazde ministerstvo to ma inak, skratky, anglictina…
Za nas by mala byt uzsia spolupraca s upstream teamom gov.uk, nie sme jediny co to forkli (napriklad aj Holandsko), snazit sa tam otvarat diskusiu o komponentoch a pull requesty (outsourcovat udrzbu)
Doplnil som do dokumenty pripomienky. Je to celkom dobre citanie, avsak problematicka cast je ku koncu, kde sa to nejako cele snazi napasovat do vodopadoveho modelu, spomina sa DFS… to bude este vyzva.
Dakujeme @vojtob za pripomienky. Zasielam na UPVII.
Pridané prevzaté komponenty z GOV.UK Frontend a ich dokumentácia (v anglickom jazyku).
Pridané prevzaté vzory z GOV.UK Frontend a ich dokumentácia (v anglickom jazyku).
Pridané prevzaté ukážky stránok z GOV.UK Frontend a ich dokumentácia (v anglickom jazyku).
Pridaná developerská SaaS dokumentácia (v angličtine).
Ďalšie kroky:
Je potrebné zrevidovať texty slovenskej verzie – toho čo sa menilo oproti verzi 1.0.
Pripravujeme change log (zoznam zmien v2.0 oproti v1.0).
Zabezpečiť formálne interné schválenie zmien.
Preklopiť ID-SK v 2.0 na stránku vicepremier.gov.sk.
Ošetriť v kóde prístupnosť, pretože časť stránky je v anglickom jazyku.
Orientačný termín publikácie: polovica decembra 2019.
Predstavenie návrhu novej vyhlášky k paragraf 31 písmeno j zákona č. 95/2019 Z.z.
(Vyhláška nadväzuje na písmeno J - spôsob a postupy pri elektronizácii agendy verejnej správy orgánu riadenia na účely zabezpečenia riadneho výkonu poskytovania služieb verejnej správy, služieb vo verejnom záujme a verejných služieb a zabezpečenia riadnej prevádzky informačných technológií verejnej správy, názov Vyhlášky ešte nie je vytvorený)
Diskusia:
Pre, ktoré OVM má byť tento postup záväzný? Je to potrebné dostatočne vyšpecifikovať.
Pre, ktoré projekty má byť tento postup záväzný?
Je potrebná lepšia definícia „Informačnej architektúry“ v texte Vyhlášky, Informačná architektúry vzťahujúca sa na front end je mätúce pomenovanie, nakoľko v IT oblasti sa používa rovnaké pomenovanie
Dávajú sa ďalšie povinnosti na OVM z pohľadu ľudských zdrojov, budú tieto povinnosť doplnené do Koncepcie ľudských zdrojov? (UPVII: poznámku odovzdáme vlastníkom materiálu).
Iný prístup by sme mali zvoliť ak elektronizujeme niečo voči občanom/podnikateľom a voči interným používateľom, interná agenda ktorá sa elektronizuje by nemusela mať takýto dôraz na UX princípy, pravidlá, ktoré sú teraz definované vo Vyhláške sú momentálne veľmi striktné a zrejme nebudú pre interných používateľov naplniteľné (UPVII poznámka – používateľsky výskum je z pravidla jednoduchší na interných používateľov, sú dostupnejší a je to menej nákladné, súhlasíme ale, že je vhodné tam mať tieto dve prostredia zvlášť zašpecifikované, v tejto téme sa venuje aj ďalší bod).
Ako vyriešiť UX pri nákupe „krabicového“ SW?
Čo sa týka out of the box a „krabicových“ riešení - UX kritéria napríklad pre interných používateľov by mali byť v tomto prípade zadefinované v rámci výberu predtým ako sa kúpi krabicové riešenie; postup, ktorý je momentálne vo Vyhláške riešení sa hodí skôr v prípade kedy sa vyvíja vlastné out of the box riešenie (UPVII – vyjadrilo záujem o zaslanie možných prípadov z praxe kedy je zvyčajné, že je lepšie krabicové riešenie od členov pracovnej skupiny); pri „krabicových“ riešeniach vendor UX už v toole má (pozn. UPVII: keď sa pozeráme do budúcnosti, väčšina nových vendorských softwarov je už robených tak, že sa dá ten architektúra „rozrezať“ tak, aby sa dal front-end vymeniť a postaviť nanovo –- je potrebné, ale zohľadniť to, že „rozrezanie“ architektúry je spojené s navýšením ceny riešenia; UPVII: zohľadníme rozlišné prostredia pre interného a externého používateľa, pri „krabicových“ riešeniach je možné napríklad „len“ zauditovať dizajn a uistiť sa, že je dostatočne použiteľný, použiteľnosť by mala byť jedna z kritérií výberového konania; je vhodné tam mať tieto dve prostredia zvlášť zašpecifikované).
Prototypovanie – čiernobiele skice – len ako minimálny level, ponechať alebo zaniesť len do metodiky? Je to príliš špecifiké.
Je to čo sa popisuje vo Vyhláške (mapovanie používateľskej cesty) niečo nové oproti biznis model procesov? (UPVII: je to popis mapovaný z pohľadu používateľa, tak ako situáciu potrebuje zrealizovať používateľ, sú tam konkrétne vyjadrenia používateľa v konkrétnych krokoch).
Ako sa spraví customer journey pre slovensko.sk keď každý orgán je zodpovedný za svoju agendu? (UPVII – chceme sa pozrieť na komunikáciu aj z pohľadu ŽS, každé OVM je zodpovedné za svoju službu, mapovanie je prvý krok k optimalizácii).
Na začiatku, vychádzajúc zo strategických dokumentov, by mali byť zadefinované aj podmienky ako elektronizovať/cez aké kanály:
Všetky dôležité princípy, ktoré sú v strategických dokumentoch by mali byť vo Vyhláške, napríklad Multikanál strategická priorita je oveľa širší (ako grafická časť popísaná v aktuálnej verzii Vyhlášky), jeden z princípov multikanálu je, že nie všetko by malo skončiť službou štátu/štátnou aplikáciou (napr. FS – ekonomické softwari by štát nemal robiť, to by mal robiť trh), malo by vyjsť z toho, že sa otvorí API. Z Multikánalový prístupu by sa malo vychádzať - ktorým kanálom služba má ísť.
OVMs by sa mali najprv pozrieť do Optimalizačného projektu, či služba má zmysel, či má existovať alebo má ísť automatizovaným riešením.
V stratégických dokumentoch je napríklad zadefinované, aby sa nerobili mobilné natívne aplikácie pokým neexistuje API alebo responzívny web.
Dopracovať je potrebné prepojenie na Vyhlášku o riadení projektov v jednotlivých fázach.
Princ2 riešiť hlavne nové projekty, na to treba myslieť keďže riešime aj rozvoj existujúcich služieb.
Všetky uvedené poznámky a postrehy budeme ďalej zvažovať a rozpracovávať.
Vyhláška bola zverejnená v MetaIS na uvedenom linku:
Prototypovanie – čiernobiele skice – len ako minimálny level, ponechať alebo zaniesť len do metodiky? Je to príliš špecifiké.
My napr. používame pri práci moqups. Kde sme z id-sk a govuk spravili dizajn manuál a potom pri návrhu nového projektu využívame komponenty z dizajn manuálu (toto vychádza ešte z IDSK 1.0). Musím ešte prejsť všetky komponenty (máme hodne custom, treba to pretriediť), ale spravil som mini demo (vykopíroval z interného projektu, preto tie logá): Sign Up & Log In - Moqups App Keď má používateľ oprávnenie editovať projekt, vie si skopírovať vybrané stránky dizajn manuálu do svojho nového projektu, kde môže stavať UI/UX už v dizajn manuále. Akurát sa to neaktualizuje cross projekty a ešte len teraz pridali v moqups componenty, tak to ešte nie je úplne to orechové. Teoreticky by sa to dalo využiť aj ako platforma pre návrh nových komponentov, user testing prípadne úpravy existujúcich komponentov. Nepáči sa mi moc, že je to pre plnú funkcionalitu platená vec, pomerne dosť uzavretá a nie vždy sa s tým robí ideálne, @jsuchal@michalblazej čo si o tom myslíte ? Viem vám tam dať aj invite aby ste si to skúsili, prípadne máte nejaký dobrý návrh ako by sa to dalo lepšie ?
Osobne si myslim, ze toto treba nechat na dodavatela. On najlepsie vie ktory nastroj je pre neho najlepsi. Bezne sa wireframes robia aj uplne “low-fidelity” perom a papierom.
To je samozrejmosť. Ja som myslel, že cieľom komunity je aj vytvárať nástroje a riešenia, z ktorých si potom konkrétny riešiteľ môže vybrať. Pero a papier je povedzme šrobovák a moqups je automatická “vrtačka”. Kde stačí dotiahnuť skrutku netreba automatickú vŕtačku, ale keby som mal skrutkovať 400 šróbikov zvolím automatickú “vŕtačku”.
Rovnako tak dizajn manuál popísaný je šrobovák a javascriptová libka je zase o niečom inom.
