Chybaju mi tam spomenute mobilne aplikacie a zasada, ze sa budu vzdy vytvarat s ohladom na specificke UX/UI guidelines jednotlivych OS (Apple HIG a Google Material Design). Ohladom funkcionalit, asi by som tam rad videl zasadu, ze sa budu v prvom rade implementovat nativne API, nie custom riesenia.
Priklad je to sice extremny, ale triafa jeden “pain point” celeho staneho IT: zle zvladnute prevadzkovanie systemov:
- aktualne, zle: ked sa vyfakturuje a odovzda, konci drviva vacsina “prace so zdrojakmi” (naschval nechcem napisat “vyvoj”) a nanajvys sa patchuju CRITICAL bugy
- chcene/navrhovane, dobre: fakturovanim a odovzdavkou sa to praveze este iba zacina, projekt musi reagovat na hlasene problemy, dopyty, zmeny v realite ci legislative, atd.
V kontexte programatorov, aj zo sukr. sfery: Zejme sme vsetci uz videli projekty, kde su dependencies na verzie libiek spred X rokov a so znamymi (aj security) bugmi. T.j. vieme, ze ci (=ano) a ako (=sledovat, matr na to scanner, atd.) take veci udrziavat, nic nove. Dizajn manual je (bude) len jedna z X libiek/zavislosti, ktoru treba menezovat na tom ktorom IT systeme.
Samozrejme libka pre dizajna manual este nie je, ale bude. (A bude ich zrejme X, al nie z titulu “lebo mame X statnych projektov” ale len z titulu “lebo mame X DEV stackov”.) Logika ale aj novy zakon o ISVS a aj NKIVS spominaju vyssi re-use kodu vramci ISVS. A uz mame aj Slovensko.IT, t.j. logickeho (aj ked nie nevyhnutneho) kandidata na “maintainera”.
Súhlasím, že je to v podstate len jedna vrstva v systéme. No z toho zápisu mám osobne pocit, že väčšina ľudí zatiaľ nevie čo a ako. Vidím to tak, že MIRRI/SKIT/BRISK… bude potrebovať veľa “ambasádorov IDSK” (vo všetkých verziách), aby sa kombinácia UX vyhlášky a IDSK nestala úzkym hrdlom viacerých projektov - zrazu musíme v projekte pridať niečo, čo tu pred tým nikto nerobil.
Osobne ak by som riadil viacero projektov a niekto prišiel s takouto (nie malou) zmenou, tiež by som z toho bol na začiatku nervózny a pýtal by som sa podobné otázky (kedy tam mám to UX dať, ako mám pracovať s IDSK, kto s tým vie robiť, ako mám postupovať, ak tam niečo chýba…)
Opat trefa, opat nie len v kontexte “dizajn manual”. Priklad: Open Data v SR riesime od cca 2011 a niektorym az teraz doslo, ze napr. “objednavky, zmluvy a faktury” su (open) data a ze to by sa dalo automaticky publikovat exportom z back-endu. T.j. velke +1 k:
MIRRI je sef informatizacie, t.j. IMHO ja “ambasadorovanie” maju v popise prace a maju (reps. teda sme v SR, tak “mali by mat, aj ked asi nemaju dost”) na to rozpocet a ludi.
Presne tak. A na tie otazky by MIRRI malo reagovat. Ak nie, ujde vlak a dalsia dobra idea skonci zle.
Myslim ze “cela tato scenka tu” je o tom, ze volakedy boli mnohi dodavatelia zvyknuti na “sbal prachy a vypadni”. Nuz ale teda “dnes” by sme chceli “viac” nez len “uspesne vycerpat miliardu eurofondov”. A teda je pochopitelne, ze pre pankov typu “sbal prachy a vypadni” je normalny SW engineering “nezelana novinka”.
Toto vnimam ako velmi peknu ukazku a zaroven skvely pilotny projekt, lebo ak sa teda bavime o IT systemoch za radovo desiatky az stovky milionov, tak “dizajn manual” je “promile” v niecom takom velkom. T.j. ak je problem dat dizajn manual, je to indilkacia dalsich nedostatkov.
A v com je problem, ved kazdy OPII projekt ma supoport na minimalne 5 rokov aj jeho rozvoj a je to tendrovany budget ???
v detailoch. rozvoj a upravy treba objednat, nie su automaticke.
v normalne fungujucej prevadzkovej zmluve je predplateny aj rocny pocet MD na drobne upravy, ktore sa len vykazuju a presuvaju v ramci roka (take zmluvy su bezne v EU) a na to nemusi ist objednavka, plus je rozvoj v ramci prevadzaky na definovany pocet MD napr. na 5 rokov a tie sa musi objednavat (request-ponuka-objednavka), ale to su rychle objednavky ktore sa daju sprocosovat za 10 dni. Tak to fuguje v sukromnom sektore,m v statnom EU sektore, akurat Slovensko je vynimka?
nie je, ale chcem tym povedat ze upravy designu nemaju u zadavatelov vysoku prioritu a je plno ineho co to predbehne. Nie je to vec co robi dodavatel automaticky. Pri projekte to to je v pohode, zoberie sa IDSK a pouzije sa ( ak to spravne chapem, tak to je pre weby, nie pre stand alone. ) Pre interne web aplikacie sa ale vytvoria zrejme custom casti a tie nebudu v zavaznom IDSK, A ked sa tam dostanu podobne a uz zavazne, tak nikto dobrovolne nebude menit fungujuce interne veci, ktore aj tak verejnost nevidi. Ani pravidelne testovanie ci web je v sulade s IDSK nebude velka priorita.
Ale otazka je ci to je problem co treba zasadne riesit, podla mna ani nie. Pocas projektu je potrebne ustrazit grafika, ktory je presvedceny ze IDSK je cele zle a on to spravi ovela lepsie. Ale menit design v prevadzke ma zmysel az ked sa robi nieco zasadnejsie, nie pri kazdej zmene IDSK.
Ak teda MIRRI nebude zamestnavat niekoho, kto to bude kontrolovat
To je teoria. Prax je taka, ze napr. data.gov.sk z OPIS-oveho projektu Open Data 1.0 mal odovzdavku koncom 2015 a “udrzatelnost” do 2020. K tomuto mesiacu sme tam vsak natrafili na CKAN bug (v spojitosti s datami RA - vid Register Adries - Register vchodov - #5 by hanecak ) pricom teda:
- na data.gov.sk je aktualne CKAN 2.2.3 (vid https://data.gov.sk/api/3/action/status_show)
- spominany bug nasli v marci 2018 vo verzii 2.7.2
- opravene bolo v 2.7.4
- posledny release z 2.2 branche je 2.2.4 z 16.12.2015
- k 2020/12 boli dostupne CKAN verzie 2.9.1, 2.8.6 a 2.7.9
T.j. minimalne v pripade tohto OPIS projektu 5-rocna udrzatelnost v praxi znamenala “udrzat verziu 2.2.3” naprek tomu, ze upstream support vetvy 2.2 skoncil v 2015/12 a da sa predpokladat, ze je tam teda X znamych a davno opravenych bugov.
Budget na udrzatelnost teda bol, ale nevydal na slusnejsiu udrzbu, t.j. updaty 2.2 → 2.3 → 2.4 → … Aj ked treba povedat, ze to nie je uplne mrtvy kod/projekt, lebo teda (a tu musim velmim velmi pochvalit, kedze “pouzity Open Source” a … najma … pozor …
“zdrojaky na GitHub-e: microcomp · GitHub !!!”) vidno commity aj po 2015/12. Cize v tomto ohlade este povazujem data.gov.sk za jeden z vydarenejsich projektov.
Tot konkretny priklad. Pokial ide potom o zovseobecnenie, tak sa opieram o to, ze aj projekty o ktorych viem menej vykazuju podobne znamky “minimalistickej udrzby”. Ale teda nejake tvrde cisla ci kvalitnu studiu nemam a zrejme nema ani MIRRI (nejako ucelene) ci stat (ako rozdrobena mnozina organizacii, ktora obstaravala konkretne veci) - kedze napr. napady typu “statna Jira” zatal nepresli. (Jedini, co teda mozu mat prehlad su asi len konkretni dodavatelia a ti sa zatial takymito metrikami nechvalia.)
Zadrhel pri udrzatelnosti je zrejme ten, ze kym samotnu implementaciu platia eurofondy, tak udrzatelnost uz ide “z vlastneho”. A vyzera to tak, ze minimalne v OPIS-e slo najma o “cerpat, vela” co znamenalo, ze mnohi asi sli s cenou projetu vysoko (“z cudzieho krv netecie”), ale az tak, ze na naslednu udrzatelnost vlastne nemali dost svojich zdrojov. Pricom ale zakladna fyzika/IT realie nepustia: cim vacsi system si naimplementujem, tym drahsia prevadzka. T.j. kto prestrelil, nema na riadnu prevadzku.
Hovorit, ze nebol budget su lsine slova, takme kazdy OPIS a OPII projekt za vlady komcov, bol predrazeny o 15-30%, takez take, ze nebol budget, radsej nepis
Ale ved som napisal:
To, ze ho pouzili na cosi ine nez “udrzanie” (resp. ze pripadne dokonca zavadzali alebo klamali, ze je), to je druha vec.
T.j.: ???
no ale to jasne hovori, ze IT projekty sa nemaju robit preto, aby sa cerpalo (, ale ze ich je treba) … a po 5 rokoch zhasla fajka …
Napriklad na VHU/VHA sa robil Long Term Archive … zo zadania a nazvu to ma byt na 50-100 rokov … inac to nie je LTA …
Ale po 5 rokoch ked ubehla EU udrzatelnost uz po tom ani pes nestekne … a hardver uz nik nikdy nevymeni, ak odijde najaka suciastka, alebo sa zaplni diskove pole tak to skonci…
Myslim ze europski danovnici by sa velmi cudoval az protestovali na ake hovadiny idu ich peniaze a v akych jachtach nakoniec skoncia …
A toto je presne jeden z bodov, ktoré som pripomienkoval v UX vyhláške - pravidelné auditovanie (1x mesačne) bez vysvetlenia, čo by to malo zahŕňať.
To je ďalšia z vecí, pri ktorej by mi pri vedení projektu preplo červenú kontrolku do režimu laseru a znova by som sa pýtal čo to znamená, ako to má vyzerať, akú to má prioritu.
Z finančného/MD hľadiska je to ďalší tlak na rozpočet projektu. Ak sa UX, zapojenie IDSK atď. neodflákne, tak tá návratnosť bude ok. Ak to ale bude v režime “rýchlo to nejako spravme, lebo musíme” tak to bude robiť dosť problémov. Preto hovorím, že MIRRI a všetci okolo budú musieť veľa vysvetľovať, vzdelávať ostatných a mať dobrú stratégiu “predaja” UX a IDSK.
Mozeme teda zavadzanie IDSK brat ako skolenie na to, ako sa ma SW robil poriadne(-jsie).
Tot aby neskor zvladli re-use aj vacsich SW komponentov.
Tak, tak. Aa nie len "IDSK. To iste bolo konstatovane pre v PS Open Data a urcite aj inde pri inych temacha podtemach eGov.
Prepáčte prosím, to naozaj sme museli okopírovať anglický dizajn? nemáme vlastných grafikov a tiež ten čierny morbídny banner na vrchu stránok má byť prosím nový štandard?
Nie, neozaj nemame. Roky rokuce sa tu rozpravalo o grafikej identite statu a jedine co sa podarilo je prevziat hotove riesenie z UK. Je to smutne, ale je to tak. Nas stat jednoducho dlhodobo nie je schopny nieco taketo udrziavat.
Mozeme sa bavit o farbickach a hlavickach, ale prosim zachovajme to, co funguje a zacalo sa po rokoch pokusov aj pouzivat. Debata o tom, ze ci sme prevzali dobre bola relevantna 2-3 roky dozadu.
žiaľ, tu práve sa obávam, že touto vyhláškou sa práve bude tlačiť na všetky inštitúcie, aby všetko prerábali… či je toto cesta na to, aby ľudia viacej používali elektronické služby, to ukáže čas.
dalšou vecou s praktického hladiska môže byť, že ak vezmeme do úvahy technologickú rôznorodosť portálov na slovensku, môže to byť dosť drahá zmena.
tiež by som sa chcel opýtať, či naozaj musí si každá inštitúcia vytvárať skupinu ľudí, riešiacich UX a JDSK.Ak si vezmeme, koľko ľudí by si mali vytvárať aj pre dátový manažment, architektov, bezpečákov, projekťákov, prevadzkových manažérov, metodikou a pod., môže to byť celkom pekný záhul pre každú inštitúciu. a ďalší štátny úradníci musia byť platený z našich daní…
Osobne som presvedceny, ze pokial by mal stat poriadne UX oddelenie tak bude kruto ekonomicky pozitivne lebo dokaze v zarodku zabit vsetky sproste napady na projekty, ktore nemaju “zakaznika”.
no tak vyššie niekto písal, že BRISK si bude JDSK udržiavať. či teda nebude ??
Asi by teda ten dizajn aj princípy mohol skôr vychádzať z SK dizajnu, je veľa pekných stránok ktoré sú aktuálne už implementované v štátnych systémoch (aj fonty, menu, typové stránky, farby, buttony a pod.). Ten rozťahaný dizajn stránok podľa IDSK je pre ľudí dosť otravný, ťažko sa tam pri zložitejších stránkach niečo hľadá a napr. ak treba niečo vyplniť viacej, tak veľmi ďaleko od súčasných papierových žiadostí, ako ich poznajú dnes… je to skúsenosť z reality. tiež si treba uvedomiť, že súčasťou koncovej služby sú aj el.formuláre, ktorých sú tisíce a všetky musí niekto prerobiť, čo je zase kopec penazí.