Freed is de ein fan de wurkdei. Min nijs komt altyd oan 'e ein fan' e wurkdei op freed.
Jo steane op it punt om it kantoar te ferlitten, in nije brief oer in oare reorganisaasje is krekt yn 'e post kaam.
Tankewol xxxx, yyy fan hjoed ôf sille jo zzzz melde
...
En Hugh's team sil soargje dat ús produkten tagonklik binne foar minsken mei in beheining.
Och nee! Wêrom haw ik dit fertsjinne? Wolle se dat ik fuortgean? Stel josels op foar tankber hurd wurk en besykje de flaters fan oaren te korrigearjen. Dit is perfoarst in mislearring ...
Dit wie de beskikberens in pear jier lyn. Guon earme sielen krigen de taak om de UI "op te romjen" om te besykjen it tagonklik te meitsjen foar minsken mei in beheining.
Wat dit eins betsjutte wie frij ûndúdlik - nei alle gedachten as jo in fokusyndikator en ljepper troch fjilden koene sjen, wat alt-tekst en in pear fjildbeskriuwings hawwe, soe it wurde beskôge dat jo applikaasje tagonklik is ...
Mar ynienen begûnen de "bugs" te fermannichfâldigjen mei de snelheid fan in lawine.
Ferskate skermlêzers (Ingelsk Skermlêzers) en browsers gedragen har folslein oars.
Brûkers hawwe klage dat de app net te brûken is.
Sadree't op it iene plak in flater korrizjearre waard, ferskynde op in oar in oare.
En gewoan feroarjen en korrizjearje brûkersynterface flaters fereaske Herculean ynspannings.
Ik wie dêr. Ik oerlibbe, mar wy hawwe net "slaggen" - technysk wy skjinmakke in protte, tafoege in soad fjild beskriuwings, rollen, en berikte wat nivo fan neilibjen, mar gjinien wie bliid. Brûkers klage noch dat se de applikaasje net koenen navigearje. De behearder klage noch oer de konstante stream fan flaters. Yngenieurs klage dat it probleem ferkeard steld wie, sûnder dúdlik definieare "korrekte" oplossing dy't yn alle gefallen soe wurkje.
D'r wiene wat beslist each-iepenjende mominten lâns myn reis nei it begripen fan tagonklikens.
Miskien wie de earste it besef dat it tafoegjen fan tagonklikensfunksjonaliteit boppe op in klear produkt lestich wie. En it is noch dreger om managers te oertsjûgjen dat it ongelooflijk lestich is! Nee, it is net allinich "in pear tags tafoegje" en de UI sil goed wurkje. Nee, dit kin net yn trije wiken foltôge wurde;
Myn folgjende momint fan wierheid kaam doe't ik út de earste hân seach hoe bline brûkers ús app eins brûkten. Dit is SO oars as nei flaterberjochten sjen.
Ik kom hjir hieltyd wer op werom, mar hast al ús "oannames" oer hoe't minsken ús app brûkten wiene ferkeard.
Navigearje fan in komplekse brûkersynterface mei toetsoanslagen Tab/Shift+Tab - dit sjit! Wy moatte wat betters. Toetseboerd fluchtoetsen, kopteksten.
Fokus ferlieze by it feroarjen fan de UI is gjin grut probleem, is it? Litte wy nochris tinke - dit is ongelooflijk betiizjend.
Ik gie troch, wurke in skoft oan ferskate projekten, en doe begûnen wy in nij projekt, mei in komplekse brûkersynterface en in dúdlike ynstallaasje, om dizze kear einlings de tagonklikheid goed te krijen.
Dat, wy namen in stap werom en seagen hoe't wy dit oars kinne ymplementearje en slagje, en it proses minder saai meitsje!
Hiel fluch kamen wy ta wat konklúzjes:
- Wy woenen net dat minsken dy't de brûkersynterface ûntwikkelen, rommele mei aria-labels / rollen en, fansels, de HTML-struktuer fan 'e komponinten. Wy moasten har de juste komponinten leverje dy't tagonklikens direkt út 'e doaze bouden.
- Tagonklikheid == Gebrûksgemak - d.w.s. Dit is net allinich in technyske útdaging. Wy moasten it heule ûntwerpproses feroarje en soargje dat tagonklikens yn rekken brocht waard en besprutsen foardat it UI-ûntwerp begon. Jo moatte betiid tinke oer hoe't brûkers elke funksjonaliteit sille ûntdekke, hoe't se sille navigearje, en hoe't rjochts-klikken fan it toetseboerd sil wurkje. Tagonklikheid moat in yntegraal diel wêze fan it ûntwerpproses - foar guon brûkers is it folle mear dan allinich it uterlik fan 'e applikaasje.
- Fan it begjin ôf woenen wy feedback krije fan bline en oare útskeakele brûkers oer it gemak fan gebrûk fan 'e applikaasje.
- Wy hiene echt goede manieren nedich om berikberensregressions te fangen.
No, út in technysk eachpunt klonk it earste diel frij leuk - it ûntwikkeljen fan in arsjitektuer en it útfieren fan in bibleteek fan komponinten. En yndied wie it sa.
In stap werom dwaan, sjen en troch dit te tinken as in ûntwerpprobleem yn stee fan in "passend" probleem, hawwe wy wat abstraksjes yntrodusearre. In komponint hat in 'Struktuer' (bestiet út HTML-eleminten) en in 'Gedrach' (hoe't it ynteraksje mei de brûker). Bygelyks, yn 'e snippets hjirûnder hawwe wy in ienfâldige net-oardere list. Troch it tafoegjen fan "gedrach" wurde de oerienkommende rollen tafoege oan de list om it as in list te dwaan. Wy dogge itselde foar it menu.
Yn feite wurde hjir net allinich rollen tafoege, mar ek evenemintehannelers foar toetseboerdnavigaasje.
Dit sjocht der netter út. As wy der in skjinne skieding tusken krije koene, dan soe it net skele hoe't de struktuer ûntstien is, wy kinne der Gedragen op tapasse en de berikberens goed krije.
Jo kinne sjen dit yn aksje by - UX-bibleteek , dat is ûntwurpen en útfierd mei berikberens yn gedachten fan it begjin ôf.
It twadde diel - it feroarjen fan de oanpak en prosessen om ûntwerpen makke my ynearsten bang: leechte yngenieurs dy't besykje organisatoaryske feroaring troch te drukken einiget net altyd goed, mar it die bliken ien fan 'e meast nijsgjirrige gebieten te wêzen wêr't wy wichtige bydragen levere oan it proses . Yn in notedop wie ús proses as folget: nije funksjonaliteit soe wurde ûntwikkele troch ien team, dan soe ús liederskip it foarstel beoardielje / werhelje, en dan, ienris goedkard, soe it ûntwerp typysk wurde oerdroegen oan it yngenieurteam. Yn dit gefal is it yngenieurteam effektyf "eigendom" fan 'e tagonklikensfunksjonaliteit, om't it har ferantwurdlikens wie om alle problemen dy't dêrmei ferbûn binne te reparearjen.
Yn it begjin wie it nochal in drege klus om út te lizzen dat tagonklikens en brûkberens ûnskiedber meiinoar ferbûn binne en dat dat dien wurde moast yn it ûntwerpstadium, oars soe it liede ta grutte feroarings en weryndielings fan guon rollen. Lykwols, mei de stipe fan behear en wichtige spielers, namen wy it idee en sette it yn beweging sadat ûntwerpen waarden hifke op tagonklikens en brûkberens foardat se waarden presintearre oan it management.
En dizze feedback wie ekstreem weardefol foar elkenien - it wie fantastysk as in oefening yn kennis dielen / kommunikaasje oer hoe't brûkers ynteraksje mei webapplikaasjes, wy identifisearre tal fan UI probleem gebieten foardat se waarden boud, de ûntwikkeling teams yn no hawwe folle bettere spesifikaasjes fan net allinnich fisuele, mar ek gedrachsaspekten fan design. Echte diskusjes binne leuke, enerzjike, hertstochtlike diskusjes oer technyske aspekten en ynteraksjes.
Wy koene dit noch better dwaan as wy bline en handikapten brûkers hiene op dizze (of folgjende) gearkomsten - dit wie lestich te organisearjen, mar wy wurkje no mei sawol lokale bline-organisaasjes as bedriuwen, dy't eksterne testen leverje om de útfieringsstream betiid te ferifiearjen ûntwikkeling - sawol op it komponint- as útfieringsstreamnivo's.
Yngenieurs hawwe no frij detaillearre spesifikaasjes, beskikbere komponinten dy't se kinne brûke om te ymplementearjen, en in manier om de útfieringsstream te falidearjen. In diel fan wat ûnderfining ús hat leard is wat wy de hiele tiid hawwe mist - hoe't wy de regression kinne stopje. Likemin kinne minsken yntegraasje as ein-oan-ein-tests brûke om funksjonaliteit te testen, wat wy nedich binne om feroaringen yn ynteraksjes en útfieringsstreamen te detektearjen - sawol fisueel as gedrach.
It bepalen fan fisuele regression is in frij definieare taak, d'r is heul lyts dat kin wurde tafoege oan it proses oars as miskien kontrolearje oft fokus sichtber is by it navigearjen mei it toetseboerd. Mear nijsgjirrich binne twa relatyf nije technologyen foar wurkjen mei tagonklikens.
- is in set ark dat kin wurde útfierd sawol yn 'e browser en as ûnderdiel fan' e build / test syklus te identifisearjen problemen.
- Ferifiearje dat skermlêzers goed wurkje hat in bysûnder útdaagjende taak west. Mei de ynfiering fan tagong ta Tagonklikheid DOM, kinne wy einliks snapshots fan tagonklikens fan 'e app nimme, lykas wy dogge foar fisuele tests, en se testen op regression.
Dat, yn it twadde diel fan it ferhaal, ferhuze wy fan it bewurkjen fan HTML-koade nei wurkjen op in heger nivo fan abstraksje, feroare it ûntwerpûntwikkelingsproses en yntrodusearre yngeande testen. Nije prosessen, nije technologyen en nije nivo's fan abstraksje hawwe it lânskip fan tagonklikens folslein feroare en wat it betsjut om yn dizze romte te wurkjen.
Mar dit is mar it begjin.
De folgjende "begryp" is dat bline brûkers driuwe cutting-edge technology - se binne dejingen dy't profitearje it measte net allinnich út de feroarings dy't wy beskreaun earder, mar ek dat nije oanpakken en ideeën wurde mooglik makke troch ML / AI. Bygelyks, Immersive Reader technology lit brûkers tekst makliker en dúdliker presintearje. It kin lûdop lêzen wurde, sinstruktuer wurdt grammatikaal ôfbrutsen, en sels wurdbetsjuttings wurde grafysk werjûn. Dit past hielendal net yn 'e âlde "meitsje it tagonklik" mentaliteit - it is in brûkberensfunksje dy't elkenien sil helpe.
ML / AI makket folslein nije manieren fan ynteraksje en wurkje mooglik, en wy binne optein diel út te meitsjen fan 'e folgjende stadia fan dizze nijsgjirrige reis. Ynnovaasje wurdt dreaun troch in feroaring yn tinken - it minskdom bestiet al milennia, masines foar hûnderten jierren, websiden foar ferskate desennia, en smartphones noch minder, technology moat oanpasse oan minsken, en net oarsom.
PS It artikel is oerset mei lytse ôfwikingen fan it orizjineel. As mei-auteur fan dit artikel bin ik it iens oer dizze digressions mei Hugh.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Jou jo oandacht oan de tagonklikens fan jo applikaasjes?
-
dat
-
gjin
-
Dit is de earste kear dat ik hearde oer app tagonklikens.
17 brûkers stimden. 5 brûkers ûntholden har.
Boarne: www.habr.com