Bloomberg - Ameriška banka Citigroup je lanskega avgusta hedge skladom nakazala 900 milijonov dolarjev. Naslednji dan jim je sporočila, da so naredili napako, in da lepo prosijo, če jim lahko denar vrnejo. Skladi so dejali, v resnici ste nam bili ta denar dolžni. Banka je rekla, teoretično res, ampak zgodba je komplicirana, se vidimo na sodišču. In po najnovejši razsodbi sodišča so imeli skladi prav. A zgodba je zanimiva predvsem zato, ker se je bizarna napaka zgodila zaradi katastrofalnega uporabniškega vmesnika na zanič programski opremi, ki jo uporablja Citigroup. To je v resnici zgodba o pomenu načrtovanju uporabniških vmesnikov.
Citigroup je koordiniral sindicirano posojilo podjetju Revlon, ki je bilo odobreno leta 2016 za sedem let. Ker je imel Revlon nekaj finančnih težav, so posojilo reprogramirali, tako da so nekateri posojilodajalci dobili zavarovani dolg, drugi pa ne, zaradi česar so želeli podjetje tožili. Potem pa jim je en dan pred vložitvijo tožbe od Citigroupa prejeli 900 milijonov dolarjev, torej poplačilo celotne glavnice in vseh obresti. To je bilo nekoliko nenavadno, še bolj nenavadno pa je bilo obvestilo Citigroupa, da gre za pomoto, in da Revlon ni plačal ničesar, zato naj nakazila vrnejo Citigroupu. Nekdo v Citigroupu je kliknil narobe.
Zgoditi bi se moralo tole. Posojilodajalci v novi shemi bi morali dobiti poplačane natečene obresti, potem pa bi se glavnica reprogramirala. Citigroup zaradi omejitev programske opreme ni mogel izplačati natečenih obresti le nekaterim posojilodajalcem, saj bi moral to storiti ročno, zato je uspel prepričati Revlon, naj plačajo vseh 7,8 milijona dolarjev, kolikor so vse obresti. To je neverjetno amatersko po sebi, a Revlon je plačal, tako da so vsi upniki dobili poplačane obresti. Toda zgodba se tu šele zakomplicira.
Eden izmed upnikov (oziroma upniki, katere je zastopalo eno podjetje) bi moral dobiti izplačano tudi glavnico, ker bi potem vstopili v drugo posojilno shemo za Revlon, ostali pa ne. Tako tudi za tega upnika v resnici ne bi šlo za denarno transakcijo, temveč knjigovodsko operacijo - poplačilo njihovega dela v tem sindiciranem posojilu in vstop v drugo posojilno shemo. Sindicirano posojilo bi se tako zmanjšalo za njihov delež, hkrati pa bi se relativni deleži vseh ostali sorazmerno povečali. To je naloga, ki jo zna izračunati vsak dijak, očitno pa ne Citigroup. Edini praktični način, da se to izvede, je da v programski opremi Flexcube izvedejo poplačilo vsem upnikom, a izplačilo izvedejo na poseben račun znotraj Citigroupa (wash account), s katerega denar ne zapusti banke. Torej pretvarjati se je treba, da je posojilo poplačano, da lahko izračunajo nove deleže.
Še bolj bizaren pa je način, ko se to izvede. Privzeta možnost v Flexcubu je seveda dejansko izplačilo, zato je treba pri vnosu naloga odkljukati polje Overwrite default settlement instruction. Trojka, ki je to plačilo izvedla, je to vedela, zato je pri vnosu PRINCIPAL (glavnica) odkljukala to možnost. In to je bil razlog za katastrofo. Nakazilo je šlo v izvedbo, denar pa iz banke. Ko so se takoj obrnili na tehnični podporo, češ da je očitno nekaj zelo narobe s programom, so dobili hladen odgovor. Ne, vse deluje normalno, le da bi morali isto okence odkljukati še pri poljih FUND in FRONT (glej sliko). To je povsem neintuitivno. Brez treh kljukic denar ne potuje na delovni račun, temveč v resnici zapusti banko. Res, s priloženega posnetka to sploh ni očitno.
Zgodba je epilog dobila na sodišču. Čeprav je treba napak prejeta nakazila vrniti (neupravičena obogatitev), v tem primeru sodišče ni bilo tega mnenja. Ker je Citigroup dejansko dolgoval ta denar upnikom (kot posrednik pri sindiciranem posojilu), upniki pa niso naredili nič, s čimer bi Citigroup spravili v zmoto ali kako drugače povzročili izplačilo, lahko sredstva obdržijo. Sodišče je zavzelo stališče, da kadar nam nekdo nekaj dolguje, potem pa to izplača, tega ne more več terjati nazaj niti se upniku ni treba ukvarjati z vprašanjem, ali je prišlo do kakšne napake. Še več, šele ko je Citigroup naslednji dan poslal obvestilo o napaki, so se upniki začeli med seboj norčevati iz Citigroupa(na Bloombergu). To kaže, da ob prejemu nakazila niso vedeli in niso mogli vedeti, da je kaj narobe. Z njihovega zornega kota se je pač Revlon pred tožbo odločil, da vrne dolgovano.
A zdej smo pršli tako daleč, da kurčevi fdv ekonom dizajnerji serjejo po "nam", kako bi mi morali ubrati moderne ux/ui responsive mobile first smernice??
Vsi, ki ste po izobrazbi fdv/ekonomisti, spokite ven iz računalništva, ker tuki delate samo štalo in škodo.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
to je tisti problem, ko večina ljudi misli, da jim znajo drugi ljudje brati misli. če ne znajo so užaljeni. isto je tukaj programer mislil, da bodo drugi že vedeli, kaj pomenijo neke kratice. če ne vedo so butasti. slabe komunikacijske veščine v bistvu.
Citigroup ima dejansko 900 mio škode, ali Citigroup je namesto eden od posojilodajalcev v sindiciranem posojilu postal edini posojilodajalec Revlonu, saj je ostale po napaki predcasno in v celoti poplacal, dejansko škodo pa bo ugotavljal potem, ko (in če) Revlon posojila leta 2023 dejansko ne bo vrnil?
nekaj kreditodajalcev vkljucenih v sindicirano posojilo je denar Citigroupu vrnilo, tako da je Citigroup v resnici terjal 'zgolj' 501 mio USD.
Vsekakor zelo neumna napaka s strani Citigroupa, ampak razlika med naslovom novice in realnostjo je verjetno kar precejšnja.
A zdej smo pršli tako daleč, da kurčevi fdv ekonom dizajnerji serjejo po "nam", kako bi mi morali ubrati moderne ux/ui responsive mobile first smernice??
Vsi, ki ste po izobrazbi fdv/ekonomisti, spokite ven iz računalništva, ker tuki delate samo štalo in škodo.
Ohh, uzaljena dekla V bistvu kdorkoli v tem pogledu lahko serje po vas, ker UX/UI programerji dizajnirate za povprecnega janeza, ki mu mora bit logicen, ne pa za vas ego
Te stvari so ponavadi kopije papirnatih obrazcev. Takrat so ljudje, bančniki, računovodje itd. še vedeli kaj delajo. Za njih bi tam lahko pisala samo šifra, konto, karkoli, brez ene črke, pa bi vedeli kaj delajo. Danes pa samo klikajo po programih in program nekaj vrže ven. Ne vejo zakaj. Programerska hiša ne bi smela bit računovodsko svetovanje. Še zmeraj mora vsak računovodja odgovarjat sam zase kaj da od sebe.
A zdej smo pršli tako daleč, da kurčevi fdv ekonom dizajnerji serjejo po "nam", kako bi mi morali ubrati moderne ux/ui responsive mobile first smernice??
Vsi, ki ste po izobrazbi fdv/ekonomisti, spokite ven iz računalništva, ker tuki delate samo štalo in škodo.
Ohh, uzaljena dekla V bistvu kdorkoli v tem pogledu lahko serje po vas, ker UX/UI programerji dizajnirate za povprecnega janeza, ki mu mora bit logicen, ne pa za vas ego
Tole. Še je pravica na svetu, sam se že nekaj let vsakič, ko uporabljam “nov” uporabniški vmesnik za EB, jezim (ok, zdaj sem se ga že malo navadil). Enako lahko rečem za jebeni flat uporabniški vmesnik na Win10 in za spreminjanje le tega od stvari v Win7 po sistemu kako se dizajnerjem v tistem trenutku dvigne, da zato rabim jebeni tutorial v YouTubu za neko trivialno nastavitev, ki je bila prej očitna. Burn in hell!
Biseri...
PS: MENSA klub ST, obvoz. ŠIC! Ne zanimajo me vaše neštetokrat reciklirane
neumnosti.
Meni je bolj zanimivo, da je originalen naročnik sploh kadarkoli sprejel takšno (ne)uporabnost. Razvijalec navadno dela po specifikacijah, naročnik MORA zavrniti neustrezno rešitev. Osebno tule vidim krivdo naročnika, ker ga je izvajalec napi*dil. Če je zaslonski posnetek verodostojen, jasno.
A zdej smo pršli tako daleč, da kurčevi fdv ekonom dizajnerji serjejo po "nam", kako bi mi morali ubrati moderne ux/ui responsive mobile first smernice??
Vsi, ki ste po izobrazbi fdv/ekonomisti, spokite ven iz računalništva, ker tuki delate samo štalo in škodo.
Seveda. Ne programiraš zase. Programiraš za končne uporabnike. Ti pa nimajo enake "logike" kot ti. Če ti to ne paše, si vseeno lahko najdeš drugo kariero.
Meni je bolj zanimivo, da je originalen naročnik sploh kadarkoli sprejel takšno (ne)uporabnost. Razvijalec navadno dela po specifikacijah, naročnik MORA zavrniti neustrezno rešitev. Osebno tule vidim krivdo naročnika, ker ga je izvajalec napi*dil. Če je zaslonski posnetek verodostojen, jasno.
Jst sm dostikrat na obeh straneh. Po eni strani naročnik naredi nek svoj "dizajn" with zero research ali iteration. Po drugi strani imaš pa old school razvijalce, ki delajo po principu waterfall. In naredijo tako, kot piše v specifikacijah in se s tem, da mogoče nekaj ne bo delovalo na način kot je zapisano, sploh ne ukvarjajo.
Jst sm dostikrat na obeh straneh. Po eni strani naročnik naredi nek svoj "dizajn" with zero research ali iteration. Po drugi strani imaš pa old school razvijalce, ki delajo po principu waterfall. In naredijo tako, kot piše v specifikacijah in se s tem, da mogoče nekaj ne bo delovalo na način kot je zapisano.
Razumem, ampak to pomeni, da so procesi slabo definirani, IT industrija je zelo eksaktna, če specifikacije niso natančne, je to rešljivo z dialogom in dodatnimi razjasnitvami in dokumentiranimi spremembami. Glede na to, da gre tu za ene 900M$ škode, izgleda, da je to dobil nek junior za delat, kar pa je v osnovi spet problem naročnika, očitno se veliko denarja zapravlja po nepotrebnem, ker se ne dela s profesionalci, ki so (kot se vidi) na kratek rok dražji, na dolgi rok pa cenejši.
Jst sm dostikrat na obeh straneh. Po eni strani naročnik naredi nek svoj "dizajn" with zero research ali iteration. Po drugi strani imaš pa old school razvijalce, ki delajo po principu waterfall. In naredijo tako, kot piše v specifikacijah in se s tem, da mogoče nekaj ne bo delovalo na način kot je zapisano.
Razumem, ampak to pomeni, da so procesi slabo definirani, IT industrija je zelo eksaktna, če specifikacije niso natančne, je to rešljivo z dialogom in dodatnimi razjasnitvami in dokumentiranimi spremembami. Glede na to, da gre tu za ene 900M$ škode, izgleda, da je to dobil nek junior za delat, kar pa je v osnovi spet problem naročnika, očitno se veliko denarja zapravlja po nepotrebnem, ker se ne dela s profesionalci, ki so (kot se vidi) na kratek rok dražji, na dolgi rok pa cenejši.
Mja, ampak problem je, če ni dialogov. Kar se velikokrat dogaja. Zato pa navijam za to, da so zadeve že v prototipni fazi (na papirju - ne tehnično oz. deloma tehnično) dobro potestirane.
Je pa iz prebranega jasno, da pri razvoju niso identificirali vseh potencialnih scenarijev. Oz. namesto, da bi aplikacijo ustrezno nadgradili, ko so se ti scenariji prvič zgodili, so rajši uporabljali neke "hacke", kjer minimalna napaka lahko povzroči pizdarijo opisano v novici.
Dialogi morajo biti :-) Če drugače ne, jih mora zahtevati strokoven razvijalec (in se ustrezno pripraviti, da je suveren), če ne, je dolžnost naročnika, da izdelek zavrne. 900M$ je (vsaj za moje pojme iz ZS, ne vem, kako je s tem v JS) veliko denarja in meni izgleda, da dejansko ni mogla biti krivda sama izvedba produkta, ki bi moral biti zavrnjen. Lahko, da je bila kakšna 'pralna operacija' (se mi zdi bolj verjetno) ali nekompetenten operater, če je s tem delal prvič (produkt se, domnevno, uporablja že dolgo!); v vsakem primeru je krivda naročnika. Ne glede na to, kakšna opravičila se išče za izgubo za 900M$, dejanski problem je drugje, ne pri razvijalcih.
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail. Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Aha, očitno je kader z možgani ostal v Gorenju in izdeluje uporabniški vmesnik na pečicah in pralnih strojih, v IT-ju pa je očitno to pretežka naloga za zaposlene. Malo preveč vihate nosove nad ostalimi.
s temi stvarmi je tako: v podjetju je en človek, ki program naroči po svojih željah in ga zna pravilno uporabljat vsaj na začetku. potem gre ta človk na dopust / v penzijo in je kriza, ko noben ne zna uporablja programa. ali pa če mine več let, ko ga ni uporabljal tudi pozabi. na sploh je to velik problem, ko ne znaš uporabljat programa pravilno. pol ti še dostikrat rečejo, da pogruntaj iz kode, kaj program dela. to je pa nočna mora.
Dizajnerji naredijo stvar všečno na pogled. Morda ima neko znanje o procesih, ki se dogajajo v ozadju - mogoče pa ne.
Razvijalec uporabniškega vmesnika je tisti, ki lahko v sodelovanju z razvijalci zalednih sistemov predlaga izboljšave. Če se ga sploh vpraša. Za ta del je v končni fazi odgovoren načrtovalec. Novodobna navada pa je ta, da so za ta del krivi programerji/IT.
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail.
Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Sori, ampak, če so uporabniki teh kompleksnih operacij povprečne tetke na bankah, potem ja, je treba delati intuitiven UI. To ne pomeni, da mora ta UI imet tri gumbe. Dober UI zmanjša možnost človeške napake, ki pogosto to ni.
Dober primer je avion The Boeing B-17, ki je imel nadpovprečno število nesreč. Ravno zaradi slabega vmesnika.
The control that lowered the landing gear and the one that lowered the wing flaps looked identical. It was all too easy for a pilot, especially at night, to reach for the landing gear control and grab the wing flap one instead. If that happened, instead of putting down the plane's wheels for a safe landing, he would slow the plane and drive it into the ground.
To je tipičen primer, ko UX vmesnika razvija programer. Programer sledi programerski logiki. Za razvoj UX pa rabiš psihologa, družboslovca, designerja.
Samo tukaj je očitno prevladovalo mnenje, da en profil obvlada vsa področja.
Meni je bolj zanimivo, da je originalen naročnik sploh kadarkoli sprejel takšno (ne)uporabnost. Razvijalec navadno dela po specifikacijah, naročnik MORA zavrniti neustrezno rešitev. Osebno tule vidim krivdo naročnika, ker ga je izvajalec napi*dil. Če je zaslonski posnetek verodostojen, jasno.
Se strinjam. Ce ne drugo, je treba povprecnega janeza tudi naucit uporabljat nove stvari, predvsem v takih institucijah kot je banka.
To je tipičen primer, ko UX vmesnika razvija programer. Programer sledi programerski logiki. Za razvoj UX pa rabiš psihologa, družboslovca, designerja.
Samo tukaj je očitno prevladovalo mnenje, da en profil obvlada vsa področja.
Huje je lahko samo, ko se najde kak pravnik ... Pri nas imamo take z referencami! 🤣
Meni je bolj zanimivo, da je originalen naročnik sploh kadarkoli sprejel takšno (ne)uporabnost. Razvijalec navadno dela po specifikacijah, naročnik MORA zavrniti neustrezno rešitev. Osebno tule vidim krivdo naročnika, ker ga je izvajalec napi*dil. Če je zaslonski posnetek verodostojen, jasno.
Se strinjam. Ce ne drugo, je treba povprecnega janeza tudi naucit uporabljat nove stvari, predvsem v takih institucijah kot je banka.
Po potrebi je treba vključit določene varovalke. "Si ziher, da hočeš nakazat 900 milijonov nekam izven banke?" Mogoče potem še kak password al neki, karkoli, da ima sistem "zagotovitev", da lahko sprozi akcijo.
Meni je bolj zanimivo, da je originalen naročnik sploh kadarkoli sprejel takšno (ne)uporabnost. Razvijalec navadno dela po specifikacijah, naročnik MORA zavrniti neustrezno rešitev. Osebno tule vidim krivdo naročnika, ker ga je izvajalec napi*dil. Če je zaslonski posnetek verodostojen, jasno.
Se strinjam. Ce ne drugo, je treba povprecnega janeza tudi naucit uporabljat nove stvari, predvsem v takih institucijah kot je banka.
To je tipičen primer, ko UX vmesnika razvija programer. Programer sledi programerski logiki. Za razvoj UX pa rabiš psihologa, družboslovca, designerja.
Pa ja. Za naredit zgornji UI tako, da bo logičen rabiš poleg programerja še vsaj 3 družboslovce, ja. Me prav zanima, koliko programerjem je ta ekran logičen in bi naredili enako. Kako vemo, da tole ni zraslo na zeljniku kakšnega pametnega družboslovnega šefa ? A ni še nihče kdaj naredil nečesa, kar se mu je zdelo nelogično, ampak je stranka zahtevala da je narejeno TOČNO tako ?
To je tipičen primer, ko UX vmesnika razvija programer. Programer sledi programerski logiki. Za razvoj UX pa rabiš psihologa, družboslovca, designerja.
Pa ja. Za naredit zgornji UI tako, da bo logičen rabiš poleg programerja še vsaj 3 družboslovce, ja. Me prav zanima, koliko programerjem je ta ekran logičen in bi naredili enako. Kako vemo, da tole ni zraslo na zeljniku kakšnega pametnega družboslovnega šefa ? A ni še nihče kdaj naredil nečesa, kar se mu je zdelo nelogično, ampak je stranka zahtevala da je narejeno TOČNO tako ?
Ko načrtuješ uporabniški vmesnik - testiraš in nimaš predpostavk. Seveda, obstajajo smernice, ki jim slediš, ampak te smernice potem testiraš na segmentu uporabnikov in ustrezno prilagodiš.
Drugo je pa, če stranka ignorira kaj je smiselno in kaj ne. Ampak na tebi, kot načrtovalcu je, da stranki pojasniš. Če še vedno hoče po svoje. Narediš pač kot hoče. In potem dodatno računaš ko hočejo to popravit.
Nikogar ne zanima, kaj je programerju logično. Ker razvija proces za ljudi, ki niso programerji. In če njim ni logično. Potem nekaj ne štima.
Situacijo zahebejo tisti, ki vmesnik prilagajajo uporabnikom, namesto da bi pustili programerju da naredi tako, kot se gre, potem pa predložili navodila, katera bi uporabniki prebrali in delali po njih.
Rezultat so bumbarji, pritiskači gumbov, katerim je potrebno prilagajat vmesnik, ker so... pač bumbarji. S tem pade kvaliteta, raste pa produkcija smeti, katere delajo velecenjeni fdv/ekonom mojstri.
Idiot pač ne razume, da je računalnik stroj, in ne pobrendan modni dodatek.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail.
Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Tako je. Ta novica je na nivoju fake news. Nima to veze z uporabniškim vmesnikom. Softver se imenuje Flexcub, uporablja ga 10% vseh bank na svetu: https://www.oracle.com/industries/finan...
Imel sem priložnost videti kar nekaj visokoprofesionalnih softverov. Z visokoprofesionalen mislim, da se uporablja strogo v eni profesionalni domeni. Tudi jaz sedaj delam na enem takem softveru. Softver ima cca 4 strani (zavihke), na vsaki strani pa cca 27 izbir.
Ni tu nekih vprašanj 'A si ziher, da bi rad ocarinil 723 kontejnerjev, z 12463 pošiljkami?'
To ali znaš kaj se dogaja ali ne veš. Ni to za tiste z švohtnim srcem.
To me spominja na en softver, ki je kreiral cca 2 mio računov za telekom operaterja. To je delala ena gospa, z enim billing softverom. Si predstavljate vprašanje: 'A si ziher, da bi rad zaračunal 2352421 računov, ker če je kaj narobe, bo jeba živa.'
Gospa je vedela za vse detajle algoritmov, vedela je kako se obračunski intevali kreirajo, naredila je diagnostiko. Kliknila je in našopala rutinirano 2 mio računov.
Nima to z GUI veze. Ali obvladaš ali ne. In tile trije kekci pač niso obvladali.
Situacijo zahebejo tisti, ki vmesnik prilagajajo uporabnikom, namesto da bi pustili programerju da naredi tako, kot se gre, potem pa predložili navodila, katera bi uporabniki prebrali in delali po njih.
Rezultat so bumbarji, pritiskači gumbov, katerim je potrebno prilagajat vmesnik, ker so... pač bumbarji. S tem pade kvaliteta, raste pa produkcija smeti, katere delajo velecenjeni fdv/ekonom mojstri.
Idiot pač ne razume, da je računalnik stroj, in ne pobrendan modni dodatek.
Hahaha. Pol ti sigurno pišeš "kodo" v assemblerju. Ziher ne uporabljaš nekih fancy programskih jezikov pa IDE vmesnikov. Ker potem si tudi ti bumbar in so tudi tvoji programi smeti. Zakaj bi ti kdo zaupal načrtovanje uporabniškega vmesnika?
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail.
Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Tako je. Ta novica je na nivoju fake news. Nima to veze z uporabniškim vmesnikom. Softver se imenuje Flexcub, uporablja ga 10% vseh bank na svetu: https://www.oracle.com/industries/finan...
Imel sem priložnost videti kar nekaj visokoprofesionalnih softverov. Z visokoprofesionalen mislim, da se uporablja strogo v eni profesionalni domeni. Tudi jaz sedaj delam na enem takem softveru. Softver ima cca 4 strani (zavihke), na vsaki strani pa cca 27 izbir.
Ni tu nekih vprašanj 'A si ziher, da bi rad ocarinil 723 kontejnerjev, z 12463 pošiljkami?'
To ali znaš kaj se dogaja ali ne veš. Ni to za tiste z švohtnim srcem.
To me spominja na en softver, ki je kreiral cca 2 mio računov za telekom operaterja. To je delala ena gospa, z enim billing softverom. Si predstavljate vprašanje: 'A si ziher, da bi rad zaračunal 2352421 računov, ker če je kaj narobe, bo jeba živa.'
Gospa je vedela za vse detajle algoritmov, vedela je kako se obračunski intevali kreirajo, naredila je diagnostiko. Kliknila je in našopala rutinirano 2 mio računov.
Nima to z GUI veze. Ali obvladaš ali ne. In tile trije kekci pač niso obvladali.
Mhm. Najlažje je pa se sklicevat na uporabnika. Jst mislim, da je preventiva še vedno bolj smiselna, kot pa kurativa. Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo. Neglede na to, koliko se spozna na to.
Mhm. Najlažje je pa se sklicevat na uporabnika. Jst mislim, da je preventiva še vedno bolj smiselna, kot pa kurativa. Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo. Neglede na to, koliko se spozna na to.
Pa saj si razumel, da so bili *trije* pari oči, ali?
Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo.
In potem dobiš eno okno več, kjer upirabnik avtomstsko pritisne Enter. Sploh ne bere. Tako kot pri cookie obvestilih. Ne bereš, samo poiščeš gumb Sprejmi.
Verjetno so imeli usposabljanja in bi lahko kdo kaj zinil glede vmesnika? Drugače pa naj tožijo ta neintuitiven vmesnik. V Ameriki bodo sigurno dobili odškodnino. Mogoče primer pro bono prevzame Judge Judy.
Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo.
In potem dobiš eno okno več, kjer upirabnik avtomstsko pritisne Enter. Sploh ne bere. Tako kot pri cookie obvestilih. Ne bereš, samo poiščeš gumb Sprejmi.
Za take dodaš še okno, kjer napišeš 'Klikni ok za preklic'. Če ne bere, se bo naslednjič potrudil .
Uf! Uf! Je rekel Vinetou in se skril za skalo,
ki jo je prav v ta namen nosil s seboj.
Sam sicer nikdar ne delam na samem front-end layerju, ker so moje estetske spretnosti zastarele (če se blago izrazim), če so kdaj slučajno sploh bile na nivoju.
Mimogrede, psihologov, umetnikov, družboslovcev za razvoj UI ne more zahtevati inženir ampak naročnik (no, lahko, inženir, če prestavlja naročnika, če bi že kdo želel zabijati čas s tehnikalijami), ki napravi osnutek in ga inženirji materializirajo, vidim, da nekateri forumski družboslovni informatiki ne poznajo specifik IT industrije.
Se tudi ne strinjam z BB-jem, da so vse napake vzete zdravo za gotovo - sam bi uvedel, ker sem pač bolj previden z denarjem, ker moram biti, da uporabnik pred 'večjim nakazilom' vpiše zaokrožen povzetek kot potrditev (število prejemnikov, skupni znesek, morda celo povprečje - torej mentalno projekcijo) za celotno operacijo in če je znotraj določenih toleranc, proces nadaljuje, ne glede na to, če je 15 (!) oči prisotnih ali ne, domnevam, da vsi ne buljijo zraven, ker potrebuješ v resnici samo en par bistrih oči, ni potrebno, da gre za štirimestni IQ.
Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo.
In potem dobiš eno okno več, kjer upirabnik avtomstsko pritisne Enter. Sploh ne bere. Tako kot pri cookie obvestilih. Ne bereš, samo poiščeš gumb Sprejmi.
Za take dodaš še okno, kjer napišeš 'Klikni ok za preklic'. Če ne bere, se bo naslednjič potrudil .
Še vedno bolje kot "za izpis rezultata na ekran kliknite YES, za tiskanje kliknite NO, za oboje pa kliknite CANCEL"
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail. Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Aha, očitno je kader z možgani ostal v Gorenju in izdeluje uporabniški vmesnik na pečicah in pralnih strojih, v IT-ju pa je očitno to pretežka naloga za zaposlene. Malo preveč vihate nosove nad ostalimi.
Čisto prav ima. Če nisi pilot, noben GUI/UX v kokpitu ne bo pomagal. Če ne znaš letet, pač ne znaš leteti. Ali voziti avto, da dam primer, ki je večini bolj blizu. Če znaš voziti avto, boš znal vsakega. Pri enih boš mogoče pol minute iskal, kako se zadnji brisalec vklopi, ampak to je to. Če ne znaš voziti, pa ne boš znal voziti.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Dat not en if stavek z message alertom je mnogo ceneje kot pa, da nekdo ponesreči brez potrditve sproži eno operacijo, ki lahko povzroči milijonsko škodo.
In potem dobiš eno okno več, kjer upirabnik avtomstsko pritisne Enter. Sploh ne bere. Tako kot pri cookie obvestilih. Ne bereš, samo poiščeš gumb Sprejmi.
Za take dodaš še okno, kjer napišeš 'Klikni ok za preklic'. Če ne bere, se bo naslednjič potrudil .
Še vedno bolje kot "za izpis rezultata na ekran kliknite YES, za tiskanje kliknite NO, za oboje pa kliknite CANCEL"
Delati UI za kompleksne operacije za povprečnega Janeza je neumnost. Sliši se nobel ideja, ampak se izkaže, da je fail. Če Janez ne razume, kaj počne, ne bo pomagal noben UI.
Aha, očitno je kader z možgani ostal v Gorenju in izdeluje uporabniški vmesnik na pečicah in pralnih strojih, v IT-ju pa je očitno to pretežka naloga za zaposlene. Malo preveč vihate nosove nad ostalimi.
Čisto prav ima. Če nisi pilot, noben GUI/UX v kokpitu ne bo pomagal. Če ne znaš letet, pač ne znaš leteti. Ali voziti avto, da dam primer, ki je večini bolj blizu. Če znaš voziti avto, boš znal vsakega. Pri enih boš mogoče pol minute iskal, kako se zadnji brisalec vklopi, ampak to je to. Če ne znaš voziti, pa ne boš znal voziti.
Ampak ravno s tem razlogom so vsi avti narejeni na enak način. Da se lahko usedeš praktično v katerikoli avto in ga voziš. Kaj če bi vsak avto imel svoje ikone za napake ali pa zamenjano bremzo in gas? itd.
Nihče ne pravi, da mora biti uporabniški vmesnik super simple, z enim gumbom. Za uporabo naprednih aplikacij še vedno rabiš navodila in izobraževanja.
Trdit, da vmesnik nima nobene veze pri obvladovanju aplikacije oz. zmanjševanju (hudih) napak - in da bi morali oblikovanje prepustiti inženirju / programerju, je pa debelizem.
Sam sicer nikdar ne delam na samem front-end layerju, ker so moje estetske spretnosti zastarele (če se blago izrazim), če so kdaj slučajno sploh bile na nivoju.
Mimogrede, psihologov, umetnikov, družboslovcev za razvoj UI ne more zahtevati inženir ampak naročnik (no, lahko, inženir, če prestavlja naročnika, če bi že kdo želel zabijati čas s tehnikalijami), ki napravi osnutek in ga inženirji materializirajo, vidim, da nekateri forumski družboslovni informatiki ne poznajo specifik IT industrije.
Se tudi ne strinjam z BB-jem, da so vse napake vzete zdravo za gotovo - sam bi uvedel, ker sem pač bolj previden z denarjem, ker moram biti, da uporabnik pred 'večjim nakazilom' vpiše zaokrožen povzetek kot potrditev (število prejemnikov, skupni znesek, morda celo povprečje - torej mentalno projekcijo) za celotno operacijo in če je znotraj določenih toleranc, proces nadaljuje, ne glede na to, če je 15 (!) oči prisotnih ali ne, domnevam, da vsi ne buljijo zraven, ker potrebuješ v resnici samo en par bistrih oči, ni potrebno, da gre za štirimestni IQ.
No, večinoma inženir ni nujno predstavnik firme, ampak le eden iz ekipe.
Ampak ravno s tem razlogom so vsi avti narejeni na enak način. Da se lahko usedeš praktično v katerikoli avto in ga voziš. Kaj če bi vsak avto imel svoje ikone za napake ali pa zamenjano bremzo in gas? itd.
Nihče ne pravi, da mora biti uporabniški vmesnik super simple, z enim gumbom. Za uporabo naprednih aplikacij še vedno rabiš navodila in izobraževanja.
Tako. Za vožnjo avtomobila rabiš navodila in izobraževanje. Moraš vedeti, kaj pomeni rdeči znak za olje, ali akumulator. Moraš vedeti, kaj so prestave, v kakem vrstnem redu se uporabljajo in zakaj. Lahko bi poenostavili v en znak "NEKAJ JE NAROBE" in en gumb "VOZI". Pa ni tega. (s premikom proti avtomatski vožnji sicer nekako gremo v to smer, ampak tam potem človek sploh ne bo vozil/upravljal, tako da ni isto)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Ampak ravno s tem razlogom so vsi avti narejeni na enak način. Da se lahko usedeš praktično v katerikoli avto in ga voziš. Kaj če bi vsak avto imel svoje ikone za napake ali pa zamenjano bremzo in gas? itd.
Nihče ne pravi, da mora biti uporabniški vmesnik super simple, z enim gumbom. Za uporabo naprednih aplikacij še vedno rabiš navodila in izobraževanja.
Tako. Za vožnjo avtomobila rabiš navodila in izobraževanje. Moraš vedeti, kaj pomeni rdeči znak za olje, ali akumulator. Moraš vedeti, kaj so prestave, v kakem vrstnem redu se uporabljajo in zakaj. Lahko bi poenostavili v en znak "NEKAJ JE NAROBE" in "VOZI". Pa ni tega. (s premikom proti avtomatski vožnji sicer nekako gremo v to smer, ampak tam potem človek sploh ne bo vozil/upravljal, tako da ni isto)
Ampak, če bi vsak avto izgledal drugače, pa zadeve ne bi bile tako enostavne, ane? Avtomobili imajo poenoten uporabniški vmesnik. Včasih ni bilo tako. V samem začetku.
Poleg tega imajo pa avtomobili razne indikatorje, ki ti povedo stanje bencina, olja, kdaj je napaka na motorju ali na akumulatorju, kdaj imaš prižgane in ugasnjene luči. Da raznih oznak na ročkah sploh ne omenjam (brisalci, prestave, troblja).
Si predstavljaš avto, ki bi bil brez indikatorjev in oznak in ki bi imel določene funkcije drugje kot ostali avti. Kako bi na enostaven način vedel, da z avtom neki ne štima oz. vedel kje se nahajajo ročke za brisalce, tekočino itd. Ali pa predvsem - kako hitro greš. Brez, da bi moral za vsak model avta v roke vzeti navodila, če bi ga želel voziti?
Situacija iz tujine. Pri razvoju aplikacije so angažirali tudi psihologa.
Pri nas je to verjetno nezamisljivo. Kaj bo pa psiholog solil pamet inženirjem računalništva...
Tako kot pri uporabnikih tudi pri programerjih velja - the problem usually exists between the keyboard and the chair. Če imaš dovolj samokritike, se tega vedno zavedaš. In poizkušaš biti boljši.
Nekoč sem vodil projekt prenove procesov in vzpostavitve informacijskega sistema podporo tem, kjer je IT analitičarka mislila, da se bo odločala namesto mene in namesto ključnega uporabnika ter na hitro sprejemala odločitve in priganjala, da gremo na naslednje teme. Ne rečem, kar nekaj procesnih idej je imela dobrih, a mnogo njih bi povzročilo pravo procesno razdejanje v delovanju sistema, zato sem neprestano hodil v resne konflikte z njo sredi sestankov. Vsi ostali člani projektne ekipe so naju imeli počasi pol kufer, ključni uporabnik (vodja službe) pa ne. Vedno sem mu/ji namreč razložil vse vidike posameznih predlogov in posledice le-teh.
Na koncu je aplikacija (in z njo delovni procesi) delovala top šit. Ker sem znal sprejeti dobre ideje IT in kategorično zavrniti slabe ter jih tudi argumentirati. V bitke z njo nisem šel z namenom filati svoj ego, temveč izpolniti cilje projekta.
In, ja, UX/UI je bil pomemben del tega projekta in eden glavnih virov sporov.
Antifašizem je danes poslednje pribežališče ničvredneža, je ideologija ničesar
in neizprosen boj proti neobstoječemu sovražniku - v zameno za državni denar
in neprofitno najemno stanovanje v središču Ljubljane. -- Tomaž Štih, 2021
Seveda so. Je kdo trdil drugače? Oziroma: čemu oporekaš?
Oporekam mišljenju, da bi načrtovanje uporabniškega vmesnika za ne-programerje (navadne ljudi), moralo biti prepuščeno programerju in zgolj napisati navodila, kako ta vmesnik uporabljati. Namesto, da se vmesnik gradi z navadne ljudi v mislih.
. 