Wireframe

Super članek Mitja, kratko in jedrnato, pa polno informacij. Trenutno se najbolj strinjam s predzadnjim odstavkom – preobsežno načrtovanje res ubije projekt. Pri načrtovanju mobilnih aplikacij ali mobilcem prirejenih spletnih strani pa sta minimalizem in iteriranje nujna, ker mora produkt čimprej na trg … v pol leta se namreč lahko že spremeni ekosistem za katerega si načrtoval.

@Rok Res .. na koncu je pogosto bolj pomembno je, da so stvari narejene, kot da so narejene prav. :)

V vašem primeru (tomcat idr), je analiza narejena v času testiranja. Na mobilnem trgu, kot je zdajle je najboljše naredit 10 aplikacij, pa se ena res prime, pa ugotoviš zakaj se je prijela, opazuješ fidbek In pičiš dalje. Pa itak praviš, da testiraš na nečakinjah … Članek je verjetno koristen za podjetja, ki nimajo prav nič uxa, recimo slovenske softwerske firme, ki jih pogosto uporabnik prav nič ne zanima.

Če dovoliš, se bom malo obregnil ob zadnji stavek, ki enači načrtovanje z wireframeanjem ali vsaj namiguje na to :) …

Načrtovanje je proces planiranja, ki je lahko tudi v celoti mentalen. Podrobno načrtovanje koristi zgolj izdelavi dokumentacij (in lažnemu občutku kontrole) med tem, ko je resničen cilj vedno čim prej materializirati idejo. Po tej logiki potrebuješ načrtovanja ravno toliko, da se samozavestno lotiš dela brez občutka zgubljenosti. Bolj, ko si iznajdljiv pri metodologiji tj. maksimalen rezultat z minimalno vloženega dela prej se lahko lotiš realnega dela. Sicer si se tega dotaknil tudi sam vendar mi preostali del članka daje občutek, da se tudi sam morda preveč rigorozno posvečaš načrtovanju po metodologiji izdelave mrežnih načrtov.

Osebno mrežne modele uporabljam zgolj za kompleksne projekte, ko ima problem preveč spremenljivk, da bi uravnoteženo rešitev lahko poiskal s hkratnim razmišljanjem o vseh aspektih in je zadeve dejansko potrebno razdeliti na manjše kose. Moje generalno vodilo je, da če z njimi načrtuješ zadeve, kot so npr. marketinška spletna mesta si zadevo ali zastavil prekompleksno ali pa izgubljaš čas z nepotrebnim delom.

Zgoraj opisan proces ponavadi razdelim na dve nalogi. Prva je informacijska arhitektura oz. bolje rečeno flow. Aplikacije so ponavadi strukturirane inžinirsko tako, da se delijo glede na zmožnosti (featurje) jaz pa se trudim razmišljati z glavo uporabnika, njegovih ciljev in pričakovanj. Tukaj samo skiciram različne konceptualne pristope bodisi na nivoju alinej ali zaporedij zelo primitivnih skic vmesnika. Iščem pač najbolj ustrezno rešitev, ki najbolje deluje pri najpomembnejših uporabniških scenarijih.

Druga naloga pa je iskanje najboljše rešitve uporabniškega vmesnika. Ideja je spraviti vse strani oz. screene aplikacije na najnižji skupni imenovalec. V veliki večini primerov je ta del možno razvijati vzporedno z vizualnim oblikovanjem, saj slednje ni nič drugega kot vizualna interpretacija funkcije oz. informacij. Osebno se na tem mestu ukvarjam predvsem z interakcijskimi modeli in razmišljam ali se da funkcije in zmožnosti aplikacije poenostaviti s kako drugo obliko interakcije ipd. Pa tudi roko na srce zelo redko imamo potrebo po odkrivanju inovativnega vmesnika – večinoma uporabljamo standardne vmesniške prakse (ti. “interface patterns”). Kadar res ne gre drugače, rišem žične modele. Ponavadi celo raje na papir kot digitalno.

Mimogrede še tole: agilen bi v slovenščini pomenilo okreten.

Natan. Se strinjam z večino stvarmi.

Wireframe je pogosto ključen produkt v fazi nastanka nekega produkta. Objavo sem začel pisat z osredotočenjem na to, da bom pojasnil besedo wireframe in ne načrtovanja v celoti. Seveda, ko skušaš pojasnit nekaj takega, kot je wireframe, zaideš v marsikaj kar spada zraven.

Enkrat je Merholz (adaptive path) rekel, “We have no processes, just methods”. Wireframe je metoda, ki pomaga načrtovat. Včasih, za enostavne rešitve, ko ni treba nikomur razlagat in predstavljat, ne rabiš wirefrejma. Včasih ne rabiš analiz, ker problem dovolj dobro poznaš, ker je projekt brez budgeta. Ker ni časa. Pogosto pa jih rabiš .. Da se bolje odločaš in bolje zaupaš odločitvam … Če je vložek smiseln in dovolj časa na voljo, go for it. Sicer pač ne. V oglaševalskih okoljih je seveda mnogo bolj čislana kreativnost in hitrost launcha. Karkšnakoli analiza in testiranje se ponavadi ne prodaja in ne postavlja v ospredje. Genious led design je preferiran, ne user centered.

Informacijska arhitektura ni enako flow. Če boš povprašal koga, ki je proper informacijski arhitekt, kaj počne v službi, ti bo razlagal o taksonomijah, hierarhijah, analizi uporabnikov, ciljev, načrtovanju contenta, pa tudi o risanju vmesnikov in user testiranju. Ampak to je že črkarska pravda …v katero lahko vključimo še 100 različnih definicij, za vse ux job title, kot so Information designer, Interaction designer, user experience designer … :)

Seveda IA ni enako kot flow. Zato sem prvotni pojem “informacijska arhitektura” parafraziral v flow z namenom pojasnit, da gre dostikrat za bistveno širše razmišljanje. Najbrž precej nerodno formuliran stavek …

Sicer pa bolj kot izpostaviti nesmiselnost načrtovanja z WF za vsako nalogo sem želel opozoriti, da se po mojem mnenju v fazi WFanja nima smisla ukvarjat z gridom, razporeditvijo, realnimi teksti ipd. detajli, saj s tem že posegaš v oblikovanje informacij. Prvo dejstvo je, da tega ne moreš (dobro) početi brez znanja likovne teorije = grafično oblikovanje. V tvojem primeru, ko informacijsko in grafično oblikovanje prevzame grafični oblikovalec pa to pomeni, da se z istim problemom ukvarjata dve osebi kar pomeni, da je precej tvojega truda z detajli bilo namenjenega zgolj boljši komunikaciji z oblikovalcem ne pa reševanju in raziskovanju problema kar je bil prvoten namen. Skratka nepotrebno dvojno delo in izguba časa.

Seveda zgolj moje skromno mnenje z namenom kvalitetne debate, ne provociranja ;)

:) odvisno kdo wirefrejma, kdo oblikuje in kaksen je projekt. podvajanje ni okej, zato tud omenjam tesno kolaboracijo in ne dela po fazah.

Lepo povzeto.

Bi se dotaknil zadnjih dveh točk: testiranje in iteracija. Verjetno najpomembnejši in najboljši način približevanja k optimalni rešitvi. A ne na ravni wireframeanja, temveč na testiranju in spremembah produkcijske rešitve.

Žal se v tej bistveni točki sam pogosto srečam s ključnim faktorjem, ki onemogoča takšen potek: omejeni resursi. Podjetja niso pripravljena N-krat investirati v razvoj (oz. spremembe) iste rešitve. Optimalna rešitev se pričakuje takorekoč “iz prve”. Še posebej pri enkratnih, z rokom trajanja omejenih projektih (prodajne akcije itd.). Ali manjših naročnikih.

V takšnih primerih je potem ključ predvsem tisti prvi del: pripravljalna dela kot si temu sam rekel. Dobra analiza, spoznavanje uporabnika, njegovih potreb in pričakovanj ter poslovnih ciljev naročnika. Sam wireframe pripravim skoraj samo še na kosu papirja za hitro vizualizacijo ideje, potem pa ponavadi že kar sledi zelo konkreten mock-up za naročnika s specom funckionalnosti za razvijalce. Temu še usklajevanje in kakšna iteracija ideje ter potem počasi produkcija. Čeprav bi si včasih želel drugače.

Priznam, da sem se včasih bolj nagibal k obsežnejšemu wireframeanju, sedaj več k fokusirani predhodni analitki. A enotne formule ni. Odvisno od projekta, ekipe, €.

Aja, pa cenim omembo potencialne problematičnosti Lorem ipsum fillerja :) God, I hate that Latin BS.

hvala za komentar. resursov in iteracij je vedno premalo. za povecanje rabis re dobre argumente, da se splača. in ja lorem ipsum must die! :)