Ako suvisi problem nahirovat 5 devops ludi v SKITe s dizajn manualom prosim? Naozaj mi to nedocvakava.
Túto časť by som bral s rezervou. “Odpor” vo využívaní nespočíva v tom, že to je alebo nie je gov.uk. Som si docela istý, že aj ID-SK 3.0 aj keby bolo napísané od základu, tak sa stretne s “odporom”.
“Odpor” spočíval aj v nereflektovaní ich potrieb. Viď issue backlog na githube. Bez silného a akčného vlastníka a rozvojového tímu za ID-SK sa to nikdy nezlepší.
Preto je ideálne, z môjho pohľadu, dobehnúť gov.uk.
Súhlasím s @jsuchal a @filip že gov.uk je výhodná cesta pre všetky zúčastnené strany.
Ako dodávateľ sme vytvorili niekoľko design systémov. Boli porovnateľne veľké ako gov.uk, trvalo nám to roky a naši klienti zaplatili nemalé náklady.
8 Likes
Príde mi to také… Slovenské… 
Stojí a padá to na tých posledných troch bodoch.
Ako chceme mať stabilný tím pre dlhodobý rozvoj ID SK 3, keď to zjavne nejde ani pre soft fork z gov.uk… 
Hm, zase ja ocenujem, ze tu diskutujes, aj ked uprimne, mam pocit, ze tato diskusia je uz len taka ozdoba a uz si sa rozhodol. Rad sa budem mylit. To, ze ta vyhodili za diskutovanie s komunitou nie je ok.
1 Like
Tu sa asi nerozumieme. MIRRI kontroluje a schvaluje implementaciu standardov podla vyhlasky 78/2020, ktorej sucastou je aj ID-SK. Nasou ulohou casto byva zhodnotenie pouzitia ID-SK komponentov(aktualne platnych) este vo faze analyza a dizajn.
Toto konzultujeme casto s biznis vlastnikmi alebo dizajnermi = chodia k nam navrhy, prototypy a pod. od roznych dodavatelov. Tito ludia casto vobec nevedia, ze sa jedna o nejake gov.uk. Precitali si par riadkov na webe ID-SK, pozreli nejake komponenty a uz navrhuju. O githube nemaju ani potuchy.
Hlasku “panovi ministrovi sa to nepaci” som pocul snad na kazdom stretnuti. A ked sa to panovi ministrovi nepaci je problem! Preto si to potom kadejak ohybaju a my sa ich snazime sekat aby to nebolo uz uplne mimo. Niekedy si daju povedat, inokedy nie.
Do vyvoja sa tieto veci dostavaju az neskor.
Diskusia sa vyvija. To cim som zacal je roadmapa dalsich aktivit. Cim by som sa k nej rad vratil 
Toto tu bolo pred idsk a bude to aj s idsk3.0. Kazdy kto ma v zadku dieru chce “logo vacsie a zelensie”. Akykolvek povinny dizajn manual samozrejme tieto debaty ukoncuje velmi rychlo, ovela rychlejsie ako predtym, ked si isli vsetci freestyle a tieto pingpongy boli len interne.
1 Like
Za to ja nemozem.
Ahojte,
este tu dlzime vyjadrenie za nas (SUXA/LB). Tema nie je uplne jednoducha, takze sme sa museli poradit a premysliet si reakciu. Najhodnotnejsie vstupy som ziskal od Adama Mockora, ktore sa budem snazit nizsie sumarizovat v nasom vyjadreni. Dakujem aj Ferovi Kocurikovi.
Vychadzame hlavne z vlastnych skusenosti a vstupov z komunity okolo dizajn systemov.
Co prinasa tvorit dizajn system po vlastnom:
- Zodpovednost za plny support – je nutne prebrat uplnu zodpovednost za spravu dizajn systemu, napr. v githube by nemali stat issues, pretoze to nebude riesit GDS, ale cela zodpovednost pada na nas. Stracame silu velkeho vyvojoveho timu, ktory tento support poskytuje.
- Zodpovednost za udrziavanie kvality – komponenty, ktore pribudaju musia mat vysoku kvalitu. Dnes to nie je uplne tak. Vnimame priestor na zlepsenie v kode, v dokumentacii aj v dizajne komponentov.
Kanadsky DS robilo v peaku okolo 50 ludi. V GDS su stovky zamestnancov. DS, na ktorom robime my pre vacsieho klienta, stoji len na externych nakladoch 1mil/rocne. Slovensko uplne nema taketo moznosti a pravdepodobone ani v najblizsej dobe nebude mat, ibaze by sme tam smerovali nas plny focus a aspon ciastocne sa priblizili.
DS sa ubral smerom, ze si robime zmeny po svojom, zasahuje sa do existujuceho kodu, vznika vela konfliktov a up-stream sa nam stale viac a viac vzdaluje.
Otazka je – aky benefit ziskavame IDSK 3.0 pristupom? My sme neprisli na iny benefit ako “vizualne zlepsenie”.
Vizualny aspekt DS je iste dolezity, ale ma velmi otaznu hodnotu. Jednak je to velmi subjektivny aspekt (o 2 roky to bude skarede) a pri dizajn systeme ma nizku hodnotu voci dalsim pridanym hodnotam akymi su efektivita (setrenie nakladov), kvalita, konzistentnost, pristupnost, skalovatelnost. Podla nas – najma v tomto pripade – je vizualita len dosledok pristupnosti.
Aky je aktualny biznis problem DS? Adopcia. Riesime adopciu vizualitou? Nie.
Tym, ze sme sa rozhodli riesit vizualitu v zasade nicomu nepomozeme, akurat to nebude skarede (subjektivne). Vsetky ostatne problemy zostanu a budu sa multiplikovat ruka v ruke s tym, ako sa bude dopad DS rozsirovat.
Nasa skusenost hovori – nie je jednoduche spravit funkcny dizajn system na zelenej luke. Napr. v Dovere sme ho tvorili na zelenej luke. Po inicialnom projekte nam rozsirenie o 1 novy projekt trvalo 1/2 roka. V tomto kontexte je super, ze DS robite na zaklade UPVS, ale stale plati – ustalit ho bude stat vysoke statisice / nizke miliony EUR.
Robili sme DS Orange, Dovery, Nay. Dnes robime na DS Skody, robime na DS Europskeho Patentoveho Uradu – to su obrovske projekty a vidime ake su tam velke vyzvy aj v priestore, kde mame “pouzivatelov DS” ako-tak pod kontrolou. V priestore statu to je nasobne zlozitejsie. Len ciastocne to riesi legislativa, ale to je fakt len drobna naplast.
Predpokladajme aktualny kontext – ownership na MIRRI, silni dodavatelia, nizka adopcia. Mame za to, ze v tomto kontexte potrebujeme hlavne stabilitu DS.
Govuk poskytuje kvalitu nad formularmi. To, ze neobsahuje weby pre OVM nie je dolezite; to su marginalne prvky v zakaznickom zazitku obcana.
Pri riadeni produktu budeme mat dost vela starosti so supportom – s manazmentom kvality, pracou s prispievatelmi, riesenim implementacnych issues – byt tam pre pouzivatelov v case adopcie.
V aktualnom momente si teda myslime, ze je lepsie vratit sa k upstreamovani nasich komponentov do gov.uk. Chapeme, ze je to narocne, ale je to mozne. V SKITe sa mozu okolo toho dobudovavat kniznice.
Venovali by sme energiu:
- stavbe timu,
- definicii produktoveho vlastnika (rola + osoba),
- podpore.
6 Likes
@michalblazej pozrel si toto? Ja tam vidim ovela viac ako len vizual. Za mna je klucova uloha DS konzistencia.
Pokial chcete DS pouzivat len na tvorbu formularov (ktorych sa mimochodom chceme optimalizaciou ZS zbavit) kludne sa vratme ku gov.uk. Za mna su vsak sluzby statu o uplne niecom inom. V tom pripade vsak prestanme nutit pouzivat OVMka DS, ktory nie je pre ich potreby vhodny.
Ked chces mozme dat k tomuto vo stvrtok diskusiu - pokial viem budes v KE na UX pive. Pozyvam na kavu, obed, pripadne len tak na navstevu SKITu.
DS (gov.uk) sluzi primarne na sluzby a tych sa tak skoro (asi nikdy) nezbavime. Predstava, ze stat nebude potrebovat ziadny formular je podla mna utopia a rozhodne sa to nestane najblizsich 5-10 rokov.
To, ze sa zacal OVM nutit pouzivat DS na nieco ine ako sluzby je odkial? Resp. kto ich to nuti pouzivat? A ked sme pri tom, tak vlastne preco by mali mat OVM vlastne webiky?
Ahojte @jsuchal , @michalblazej ,
ako otcov myslienky prebrat DS gov.uk a najvacsich podporovatelov tohoto pristupu by som chcel poznat vas nazor na nasledujuce otazky. Poprosim o jednoznacne odpovede (idealne ano/nie):
- ma byt portal slovensko.sk navrhnuty podla DS gov.uk?
- ma byt osobna zona obcana moje.slovensko.sk (“internet banking” obcana - obsahuje aj el. schranku) navrhnuta podla DS gov.uk?
- ma byt aplikacia SVM ako jeden z klucovych pristupovych kanalov komunikacie s obcanom navrhnuty podla DS gov.uk?
- ma byt web akehokolvek OVM (napr. SP. MZV, … ) navrhnuty podla DS gov.uk?
- ma byt elektronicka sluzba (napr. ohlasenie zivnosti) navrhnuta podla DS gov.uk?
- ma byt informacny system UVO IS eForms, ktory sluzi registrovanym pouzivatelom na odosielanie a spravu oznameni o VO a dalsich formularov navrhnuty podla DS gov.uk?
- ma byt administracne rozhranie UPVS (urcene pre spravu UPVS) navrhnute podla DS gov.uk?
doplnujuce otazky:
- aky je hlavny ciel dizajn systemu ID-SK?
- ako by ste zmenili/doplnili gov.uk?
- ked urobi MIRRI rozhodnutie, ste ochotni ho respektovat?
- pokial by sa islo cestou ID-SK 3, ste ochotni participovat na jeho aktivnom rozvoji?
- aky tim bude potrebny na preberanie gov.uk, pripadne rozvoj a udrziavanie vlastnych komponentov?
Nenúti ich tak trocha vyhláška o UX aj s prílohou 12, kde bolo povedané, že IDSK je povinné? Aj keď ani v čase soft fotku sme s ním nemali veľmi veľa skúseností, aj napriek tomu sme povedali, že je to nutná podmienka.
Pekný príklad sme videli na zjednodušenom založení s.r.o., kde väčšina sedela s DS, ale aj tak sa vo formulári našlo viac miest, kde si tvorca vymyslel niečo vlastné…
Tu som úplne na strane Milana. Zároveň si nemyslím, že má MIRRI kapacitu a silu spraviť tak veľkú revolúciu, že dokáže “zobrať” OVMkám webové sídla pod nejaký unifikovaný priestor. To by musela celá vetva MIRRI a sekcie na jednotlivých ministerstvách a OVM úplne inak fungovať a rozmýšľať.
Ta ORSR sluzba je sluzba, IDSK je povinne pre sluzby, lebo tam to ma zmysel, aby to vyzeralo rovnako a do seba zapadalo. Weby sa tam zacali tahat ovela neskor a myslim, ze povinne to nie je dodnes.
Toto vsak na zaciatku nikto nechcel (teda chcel, ale vsetci chapali, ze DS je o inom), to az z prichodom SKIT zacali vyrabat unifikovane webiky. Toto vsak nutne neznamena, ze by sme mali vyrabat vsetko odznova.
V skutocnosti hovoris, ze by si chcel vyrobit vizualnu identitu komplet digitalnej komunikacie statu a prepac, ale na toto v SKITe podla mna fakt nemate. Ani kapacitne, ani referenciami. Sudim podla vystupov, nic osobne.
Ak chceme urobit poriadny DS, tak na to treba spravit normalne velku sutaz pre top dizajnerov na dizajn systemy, nie to zadat SKITu. Kolko je tam vlastne dizajnerov? 2-3?
Takto si predstavujem koncept ID-SK ja: https://www.systemflow.co/ (samozrejme s HTML komponentami - webflow je optional).
- jednoduchy navrh a dizajn webov statnej spravy a elektronickych sluzieb vdaka kvalitnej kniznici komponentov a predpripravenym vzorom a sablonam.
- jednoduchy vyvoj vdaka predpripravenym kodom (klasicke kniznice HTML, React, … + kludne integracia s low code, no code platformami)
- ID-SK univerzita, ktora vysvetli ako navrhovat a vyvijat weby a sluzby v ID-SK
- Prehladna dokumentacia
- Showcases (Best praticies)
- Blog s inspiraciami, novinkami, …
Toto vsetko zvladne firma, ktora ma podla linkedinu az dvoch ludi. Preco by to rovnako nemohol urobit stat?
PS:
Webflow kniznica: https://systemflow-marketplace.webflow.io/
Figma kniznica: SystemFlow (FREE Version) | Figma Community
Youtube intro: Welcome to SystemFlow - YouTube
Tak to kupme a vybavene. Zvladne to stat za menej ako 1000 eur? Pripadne zoberme govuk za 0 eur. Ci zvladnete to v SKITe za menej? Preco vymyslame (hranate) koleso?
1 Like
My takuto kniznicu uz mame! A nie je to ziadne vymyslanie hranateho kolesa - vzali sme gov.uk, material dizajn a zopar dalsich kniznic a mergli sme to do jedneho dizajn systemu, ktory vyhovuje potrebam statu - toto sme si uz overili v ramci, mUPVS (slovensko.sk, moje.slovensko.sk), v ramci KSDR, v ramci webu https://ua.gov.sk/sk.html (schvalne si to pozrite, to je ID-SK 3!) a dalsich projektov.
To, co nemame je:
- kvalitne kniznice (Figma, HTML, …)
- kvalitnu dokumentciu
- kvalitny web
- kvalitne vzdelavanie (univerzitu)
- kvalitnu komunikaciu
toto si za 1000 eur nekupis a budes to potrebovat v akomkolvek pripade (aj ked vezmes gov.uk za 0).
Presne preto sme tymto veciam vytvorili jasnu roadmapu, ktorou to tu cele zacalo.
A urcite sa opytas, kolko to teda stat stalo? No presne tolko kolko by stalo keby tu dizajnovy tim sedel na riti a nepohol ani prstom (vyplatu by sme asi dostali tak ci tak). Pytal si sa este kolko nas tu vlastne je - Ja + 3xUI + 3xUX Research = 7 (+ externy konzultant na pristupnost z Unie nevidiacich a slaborakych).
V skutocnosti ste nic nemergli, ak by ste nieco mergli, tak netreba vyrabat celu technicku cast DS nanovo.
Ako tu mozes s plechovym xychtom dokazes tvrdit, ze to je to iste? Proste kazdy kto si otvori navrhovanu prilohu 12 a dizajny vidi, ze z gov uk tam ostali tak mozno radio + checkboxy.
Schvalne som si to pozrel. Ukaz mi tam nejaku sluzbu a mozeme hladat rozdiely oproti idsk3.0. Nie je tam ziadna, ze? A preco teda ideme vyrabat nanovo cele html/css ked toto je podla teba idsk3.0?
Takto otazka naozaj nestoji. Vy ste mali robit to, co po vas chcela komunita od zaciatku a ako to bolo schvalene (na MIRRI!), prediskutovane na PS a vsetci to cakali. Robit nad govuk nove komponenty, sync s upstream, fixovat bugy na githube. Toto by malo pridanu hodnotu. Vase sedenie na zadku by v skutocnosti bolo ovela lacnejsie, ako to, co teraz idete sposobit.
Inak mimochodom, ak sa zmeni priloha 12, neexistuje tam ziadne prechodne obdobie (ak spravne citam) a to znamena, ze pokial sa neurobi nove prechodne obdobie, tak okamzite po schvaleni vyhlasky pojde pri vsetkych el. sluzbach zverejnenych po 31.12.2021 (nie je preklep) - o porusenie vyhlasky.
https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2020/78/20220101.html#paragraf-54a.odsek-7
Dodavatelia investovali dost casu do naucenia sa IDSK2, maju tam ludi co s tym vedia robit, pouzivaju komponenty a vy odrazu vyhodite kody, poviete, ze govuk- prefix je fujky, chcete to gulate a to je ono? Preto to idete cele stavat odznova (ano idete, cele html/css a sablony idete stavat uplne odznova). No nie.
Pocuj, nie je toto uz trochu schyzofrenia?
Na jednu stranu tvrdis, ze sme nic nemergli, na druhu stranu si otvoris web ktory je navrhnuty v ID-SK3 (napr. accordion, typografia, …) ale pouziva kody gov.uk kniznice a pytas sa preco ideme robit nieco na novo aj napriek tomu, ze ti stale tvrdim, ze sa gov.uk da jednoducho prestylovat.
Ad formulare/sluzby:
Dokumentacia Gov.uk vs navrh prilohy cislo 12
Az jednu nulu v CSS bolo treba prepisat na 5px (border-radius) aby bol z gov.uk kniznice ID-SK3 komponent. A ano, validacie sme prebrali z material dizajnu:
No nic, ja ti uz fakt nerozumiem. Je vidiet, ze toto zdruzenie malo na MIRRI fakt velky vplyv. Zdrzovanie rozvoja, nedovera, rozdelovanie, demotivovacia …