GE­NE­RISCH VS. Gu­te uSa­bi­li­ty

SCREENGUIDE - - KREATION - TEXT: Marcel Henk­haus

Ein Blick hin­ter die Ku­lis­sen der App „Con­tent Por­tal”

Gu­te Usa­bi­li­ty ist ei­ne der wich­tigs­ten Ei­gen­schaf­ten mo­der­ner We­b­ap­pli­ka­tio­nen. Wenn Sie wis­sen, wel­che Zie­le ver­folgt wer­den, ha­ben Sie kon­kre­te An­sät­ze, die Be­nut­zer­freund­lich­keit zu op­ti­mie­ren. Wie Sie vor­ge­hen kön­nen, wenn Ih­nen die­ses Wis­sen hin­ge­gen fehlt, zei­gen wir Ih­nen an­hand ei­nes Bli­ckes hin­ter die Ku­lis­sen der ge­ne­ri­schen We­b­ap­pli­ka­ti­on „Con­tent Por­tal”. Was ge­schieht mit ei­ner App, wenn ein an­ti­zi­pier­ter Worst Ca­se schlim­mer aus­fällt als ge­dacht? Wie stel­len wir ei­ne Ta­bel­le dar, wenn die­se mal ei­ne Spal­te, mal zwan­zig an­zeigt. Ha­ben wir Über­schrif­ten mit drei­ßig oder hun­dert Zei­chen? Bil­den wir ei­nen ein­zi­gen Ak­ti­ons­knopf ab oder fünf? Vor die­sen Fra­gen stan­den wir, als wir vor cir­ca ei­nem Jahr mit dem Pro­jekt ei­ner voll­kom­men ge­ne­ri­schen und re­s­pon­siven We­b­ap­pli­ka­ti­on star­te­ten.

EIN KUNDENINDIVIDUELLES PRODUKTPORTAL

Das Bochu­mer Un­ter­neh­men eggheads ist ein spe­zia­li­sier­tes Soft­ware­haus für Pro­dukt­in­for­ma­ti­on-Ma­nage­ment-Sys­te­me (kurz PIM). Un­ser Kun­den­port­fo­lio ist über di­ver­se Bran­chen breit ge­streut. Von gro­ßen Tou­ris­tik­un­ter­neh­men über Uni­ver­sal­ver­sen­der bis hin zu Kun­den aus der Me­di­zin­tech­nik sind fast al­le Bran­chen ver­tre­ten.

Da ei­ne Viel­zahl un­se­rer Kun­den den Wunsch äu­ßer­te, Da­ten nicht nur per na­ti­vem Cli­ent zu pfle­gen und be­reit­zu­stel­len, ent­stand un­ser web­ba­sier­tes Pro­dukt na­mens Con­tent Por­tal, das Mit­te die­ses Jah­res an ers­te Kun­den aus­ge­lie­fert wur­de. Das Con­tent Por­tal er­mög­licht Kun­den, ih­re Pro­dukt­da­ten si­cher on­line be­reit­zu­stel­len, ge­zielt zu durch­su­chen und zu pfle­gen. Das Por­tal lässt sich folg­lich bran­chen­über­grei­fend ein­set­zen, was be­deu­tet, dass Pro­dukt nicht gleich Pro­dukt ist. Für den Rei­se­ver­an­stal­ter ist ein Ho­tel oder ei­ne Pau­schal­rei­se ein Pro­dukt, für den Werk­zeug­her­stel­ler ei­ne Schrau­be und für den Ver­si­che­rer die Haft­pflicht. So­mit stellt je­des Pro­dukt un­se­rer Kun­den ei­ge­ne An­for­de­run­gen an das Por­tal, so­wohl was die Art und An­zahl an Pro­dukt­merk­ma­len be­trifft als auch die Struk­tu­ren, in de­nen die­se Da­ten dar­ge­stellt wer­den. Wir ent­wi­ckel­ten das Por­tal nicht ge­zielt für ei­nen spe­zi­fi­schen Kun­den, son­dern kon­zi­pier­ten ei­ne Ap­pli­ka­ti­on, die auf­grund der kon­kre­ten Nach­fra­gen für ei­ne Viel­zahl un­se­rer Kun­den ei­nen spür­ba­ren Mehr­wert bie­ten soll. An­statt die In­for­ma­tio­nen ei­nes je­den Kun­den in ein vor­ge­ge­be­nes Kor­sett zu zwän­gen, wähl­ten wir da­her ei­nen kom­plett ge­ne­ri­schen An­satz. Je­der ein­zel­ne Kun­de soll die Mög­lich­keit ha­ben, das Por­tal auf sei­ne ei­ge­nen Be­dürf­nis­se zu­recht­zu­schnei­dern. Wir ge­ben ihm da­für durch das Por­tal die rich­ti­gen Werk­zeu­ge an die Hand. Gleich­zei­tig soll die Ap­pli­ka­ti­on al­ler­dings auch mög­lichst be­nut­zer­freund­lich sein, da ei­ne brei­te Grup­pe an Nut­zern mit un­ter­schied­li­chen Vor­kennt­nis­sen da­mit ar­bei­ten soll. Ob Con­tent Crea­tor, der sich mit den Da­ten aus­kennt und nur mög­lichst schnell sei­ne Auf­ga­ben er­le­di­gen möch­te, oder ex­ter­ne Mit­ar­bei­ter oder Prak­ti­kan­ten, die auf die­se Da­ten zu­grei­fen müs­sen, je­doch vom Auf­bau der Pro­duk­te kei­ne Ah­nung ha­ben – al­le sol­len das Por­tal trotz Ge­ne­rik gleich gut be­die­nen kön­nen. Auch tem­po­rä­re Gast­zu­gän­ge sind ein mög­li­ches Sze­na­rio, das wir be­den­ken müs­sen. Dies hat­te eben­so zur Kon­se­quenz, dass wir uns auf die Nut­zung mit un­ter­schied­li­chen End­ge­rä­ten ein­stel­len muss­ten. So­mit kam ei­ne zu­sätz­li­che Ebe­ne an Kom­ple­xi­tät in Form ei­ner re­s­pon­siven Um­set­zung hin­zu. Wich­tig war uns hier­bei, dass wir vom Be­nut­zer nicht ver­lan­gen möch­ten, dass die­ser sich dar­um küm­mert, Struk­tu­ren auf­zu­bau­en, die so­wohl auf gro­ßen als auch auf klei­nen Bild­schir­men les­bar sind und pro­blem­los na­vi­giert wer­den kön­nen. Als Frame­work für un­se­re Ap­pli­ka­ti­on ent­schie­den wir uns für das Ja­vas­cript-Frame­work An­gu­lar 2. Aus vor­he­ri­gen Pro­jek­ten gab es be­reits Er­fah­run­gen mit An­gu­lar 1, wo­durch die Grund­prin­zi­pen, auf de­nen An­gu­lar auf­baut, be­reits be­kannt wa­ren. Ab der Ver­si­on 2.0 ist An­gu­lar voll­kom­men kom­po­nen­ten­ba­siert. Ein­zel­ne Funk­tio­nen der Soft­ware sind so­mit in sich ge­kap­selt, samt Re­prä­sen­ta­ti­on in Form ei­nes HTML-Tem­pla­tes. Die­ser An­satz kam uns im Lau­fe der Ent­wick­lung sehr ent­ge­gen. Zu­dem gibt es ei­nen enor­men Per­for­man­ce­ge­winn mit der neu­es­ten An­gu­lar-Ver­si­on, der sich vor al­lem bei kom­ple­xe­ren Sei­ten­struk­tu­ren, wie wir sie ha­ben, be­merk­bar macht.

DIE HER­AUS­FOR­DE­RUN­GEN

Die­se Mix­tur aus An­for­de­run­gen stell­te ei­ne gro­ße Her­aus­for­de­rung bei der Gestal­tung und Um­set­zung der We­b­ap­pli­ka­ti­on dar. Ei­ne Ap­pli­ka­ti­on mit gu­ter Usa­bi­li­ty zeich­net sich oft­mals da­durch aus, dass sie ei­nen kla­ren Fo­kus setzt, wo­durch sie stets auf den ak­tu­el­len Kon­text re­agie­ren kann und so­mit dem Nut­zer im­mer ein op­ti­ma­les Tool­set be­reit­stellt. Googles pri­mä­rer Fo­kus ist die Su­che. Die ge­sam­te Start­sei­te ist dar­auf aus­ge­legt. Ein gro­ßes Such­feld in­klu­si­ve Au­to­fo­cus. Al­les an­de­re tritt in den Hin­ter­grund (Abb. 1). Erst wenn Sie ei­ne Su­che aus­ge­führt ha­ben, gibt Ih­nen Goog­le wei­te­re Mög­lich­kei­ten an die Hand, die Er­geb­nis­se zu fil­tern. Goog­le re­agiert hier auf den Kon­text, in dem Sie sich mo­men­tan be­fin­den. Bei un­se­rem ge­ne­ri­schen An­satz lässt sich der Kon­text oft nur schwer fas­sen, da die­ser un­ter Um­stän­den im di­rek­ten Zu­sam­men­hang mit den ein­ge­pfleg­ten Pro­duk­ten steht. Je­doch wis­sen wir eben nicht, was genau die­ses Pro­dukt sein wird. Wür­den wir Me­tho­den für ei­ne ver­bes­ser­te Usa­bi­li­ty nut­zen, die im di­rek­ten Zu­sam­men­hang mit dem Kon­text der Ap­pli­ka­ti­on ste­hen, könn­ten wir Ge­fahr lau­fen, dass un­ser Por­tal für Kun­de A op­ti­mal ge­stal­tet, für Kun­de B al­ler­dings ka­ta­stro­phal zu be­die­nen ist. Kom­po­nen­ten­ba­sier­tes CSS ist ge­ra­de ein ganz hei­ßes Ei­sen. Es be­deu­tet, dass CSS-Sti­le nicht glo­bal de­fi­niert wer­den, son­dern ex­pli­zit an ein­zel­ne Kom­po­nen­ten ge­bun­den sind, wo­durch sich ge­ge­be­nen­falls ge­gen­läu­fi­ge Sti­le für ver­schie­de­ne Kom­po­nen­ten nicht in die Que­re kom­men kön­nen. Die­sen An­satz auf Usa­bi­li­ty zu über­tra­gen, er­schien für uns der ge­eig­ne­te Weg zu sein, ein höchst­mög­li­ches Le­vel an Be­nut­zer­freund­lich­keit in un­ser ge­ne­ri­sches Por­tal ein­zu­brin­gen. An­gu­lars eben­falls auf Kom­po­nen­ten ba­sie­ren­der An­satz half uns hier bei der Um­set­zung. Wir un­ter­teil­ten un­se­re Usa­bi­li­ty-Kon­zep­te in zwei Be­rei­che: Por­tal-über­grei­fen­de Be­nut­zer­füh­rung und kon­text­sen­si­ti­ve Be­nut­zer­füh­rung.

DIE GRUNDAUSRICHTUNG MUSS STIM­MEN

Als Al­ler­ers­tes muss das Grund­ge­rüst pas­sen. Es ist das Fun­da­ment un­se­rer Ap­pli­ka­ti­on. Soll­te un­se­re kom­po­nen­ten­ba­sier­te Usa­bi­li­ty auch noch so gut sein, wenn der Be­nut­zer erst gar nicht den In­halt fin­det, nach dem er sucht, bringt das gar nichts. So­mit hieß es für uns, dass wir uns im Lay­out und bei den grund­le­gen­den Struk­tu­ren un­se­res Por­tals so nah wie mög­lich an im Web be­kann­te Stan­dards hal­ten.

Nach dem Ein­log­gen wird der Nut­zer von ei­nem kla­ren Lay­out emp­fan­gen: Sei­ten­leis­te, He­a­der, In­halts­be­reich und Foo­ter. Die Por­tal-über­grei­fen­de Na­vi­ga­ti­on be­fin­det sich oben im He­a­der, der Ac­count­be­reich in der obe­ren rech­ten Ecke (Abb. 2). Dort, wo wir al­le es durch jah­re­lan­ge Kon­di­tio­nie­rung im Web er­war­ten. Da­durch ver­rin­gern wir die Zeit, die der Be­nut­zer be­nö­tigt, um sich zu ori­en­tie­ren. Ein wei­te­rer Vor­teil ist, dass wir hier schon da­mit be­gin­nen kön­nen, den Be­nut­zer mit un­se­rem Interface ver­traut zu ma­chen. Das Rah­men­pro­gramm ist im po­si­tivs­ten Sin­ne Stan­dard. Die­ser Stan­dard hilft uns spä­ter auch, im Re­s­pon­siven ein ge­wohn­tes Lay­out zu ar­ran­gie­ren, das wei­ter­hin in­tui­tiv be­dient wer­den kann. Auch die wei­te­ren Grund­la­gen müs­sen stim­men und ein­heit­lich sein. Da­zu ge­hö­ren aus­sa­ge­kräf­ti­ge Hin­wei­se und Feh­ler­tex­te, of­fen­sicht­li­che Schalt­flä­chen (Abb. 3) oder kla­res Feed­back, soll­te ei­ne Ak­ti­on mal et­was län­ger dau­ern. Die Por­tal-wei­te Usa­bi­li­ty dient da­zu, Ver­trau­en zu schaf­fen. Un­ser Interface muss ei­ne Be­stän­dig­keit auf­wei­sen, da­mit der Be­nut­zer un­ab­hän­gig vom Kon­text stets weiß, wel­che Mög­lich­kei­ten ihm zur Ver­fü­gung ste­hen.

DAS LEGOPRINZIP

So un­ter­schied­lich Pro­dukt­da­ten auch sein mö­gen, sie al­le be­ste­hen aus In­for­ma­tio­nen in un­ter­schied­li­chen Au­s­prä­gun­gen, die in ei­nem For­mu­lar kon­su­miert oder ge­pflegt wer­den. Mit­hil­fe die­ser Tat­sa­che ent­schlos­sen wir uns, dem Be­nut­zer für die kom­ple­xen Pro­dukt­sze­na­ri­en ein kom­bi­nier­ba­res „Interface In­ven­to­ry” für For­mu­la­re an die Hand zu ge­ben. Die­ser Bau­kas­ten be­steht aus For­mu­la­r­ele­men­ten, wie In­puts oder Selects, und Lay­ou­t­e­le­men­ten, wie Rei­ter­na­vi­ga­tio­nen, Ac­cor­di­ons oder Con­tai­ne­r­ele­men­ten. Der Nut­zer kann so in bes­ter Le­go­ma­nier auf sei­ne Pro­duk­te in­di­vi­du­ell zu­ge­schnit­te­ne For­mu­la­re er­stel­len, mit de­nen er die Pro­dukt­da­ten er­fas­sen und le­sen kann. Es kön­nen für ein Pro­dukt vom Be­nut­zer auch meh­re­re For­mu­la­re an­ge­legt wer­den, er ist nicht auf ein For­mu­lar je Pro­dukt be­schränkt. Ein wich­ti­ger Punkt, denn so kann der Be­nut­zer For­mu­la­re für ver­schie­de­ne Use Ca­ses er­stel­len. Ein Bei­spiel: Ein Ho­te­lier soll die Da­ten sei­nes Ho­tels in das Por­tal ein­pfle­gen. Im For­mu­lar für sein Ho­tel wer­den al­le wich­ti­gen Da­ten ab­ge­fragt. Wie weit ist die Ent­fer­nung zum Strand? Wie vie­le Bet­ten bie­tet das Ho­tel? Was für Ver­pfle­gungs­ar­ten wer­den an­ge­bo­ten (Abb. 4). Nach­dem der Ho­te­lier die Da­ten ein­ge­ge­ben hat, soll ein Mit­ar­bei­ter des Tou­ris­tik­un­ter­neh­mens das Ho­tel sich­ten. Da­bei muss er ent­schei­den, in wel­chem Ka­ta­log das Ho­tel er­scheint, zu wel­cher Ka­te­go­rie es ge­hört (für Fa­mi­li­en, für Aben­teu­rer etc.) und wel­che in­ter­ne Bu­chungs­num­mer dem Ho­tel zu­ge­ord­net wer­den soll. Der Ho­te­lier sieht dem­nach ein For­mu­lar, das nur Da­ten ab­fragt, die er be­reit­stel­len kann. Wäh­rend das For­mu­lar für den Mit­ar­bei­ter die­sel­ben Da­ten an­zeigt, al­ler­dings um wei­te­re Fel­der für un­ter­neh­mens­spe­zi­fi­sche Ab­läu­fe an­ge­rei­chert. So ent­steht durch das je­wei­li­ge For­mu­lar wie­der ein Kon­text, in dem ge­ar­bei­tet wird. Je­des For­mu­lar kann so ein klar ab­ge­steck­tes Ziel ver­fol­gen, in dem Kom­ple­xi­tät an un­nö­ti­gen Stel­len her­aus­ge­nom­men wird und an wich­ti­gen Stel­len ge­ra­de be­nö­tig­te Ele­men­te er­gänzt wer­den. Die For­mu­la­r­ele­men­te kön­nen zu­dem mit ein­zel­nen Pro­dukt­da­ten ver­knüpft wer­den. Lie­gen in ei­nem ex­ter­nen Sys­tem die Ma­ße für ei­nen Tisch vor, so kann der Be­nut­zer zum Bei­spiel die Tisch­brei­te ei­nem For­mu­lar­feld zu­ord­nen. Än­de­run­gen an der Brei­te kön­nen dann von bei­den Sei­ten aus ge­pflegt wer­den. Der Be­nut­zer kann zu­sätz­lich not­wen­di­ge Va­li­die­rungs­re­geln in­di­vi­du­ell für je­des For­mu­lar­feld hin­ter­le­gen. Das Interface In­ven­to­ry ist al­so mehr als nur ei­ne Samm­lung an Fel­dern. Es dient zur Darstel­lung, Va­li­die­rung und Syn­chro­ni­sie­rung von Da­ten. Durch die Wie­der­ver­wend­bar­keit der Ele­men­te ga­ran­tie­ren wir ei­ne durch­weg kon­sis­ten­te Ober­flä­che. Dies ist des­we­gen wich­tig, da wir nicht möch­ten, dass der Nut­zer beim Wech­sel zwi­schen un­ter­schied­li­chen Pro­duk­ten sich im­mer wie­der neu ori­en­tie­ren muss. Ein pri­mä­rer But­ton bleibt im­mer ein pri­mä­rer But­ton, und ei­ne Rei­ter­na­vi­ga­ti­on sieht im­mer wie ei­ne Rei­ter­na­vi­ga­ti­on aus. Dank der Con­tai­ne­r­ele­men­te kön­nen die Da­ten der Pro­duk­te zu­dem lo­gisch grup­piert in un­ser ge­ne­ri­sches Sys­tem ein­ge­bracht wer­den (Abb. 5). Dies hilft im­mens, wenn Pro­duk­te auf der Su­che nach ei­nem be­stimm­ten Merk­mal über­flo­gen wer­den. Wir gin­gen noch ei­nen Schritt wei­ter. Ne­ben Pro­duk­ten bie­tet das Por­tal so­wohl ei­ne Ver­wal­tung von Por­tal-in­ter­nen Be­nut­zern als auch die Mög­lich­keit, Da­ten zum Bei­spiel in der Form ei­nes Uploads von Pro­dukt­bil­dern qua­li­fi­ziert zu er­fas­sen (Abb. 6 und 7). So­gar das Er­stel­len und Pfle­gen der For­mu­la­re ge­schieht di­rekt im Por­tal. Für all die­se vor­ge­ge­be­nen Auf­ga­ben­be­rei­che nut­zen wir die glei­chen Baustei­ne wie für kun­den­spe­zi­fi­sche In­hal­te.

Da­durch er­rei­chen wir, dass, wenn ein Kun­de mit den Ele­men­ten auf sei­ner Pro­dukt­sei­te ver­traut ist, er auch gleich­zei­tig weiß, wie die Ver­wal­tung ei­nes Be­nut­zers funk­tio­niert. Das ge­sam­te Sys­tem soll aus ei­nem Guss sein, um mit so we­nig Rei­bung wie mög­lich den Be­nut­zer durch al­le Funk­tio­nen füh­ren zu kön­nen. Ein für uns wich­ti­ger Aspekt für die For­mu­la­re ist, dass der User ei­ne über­sicht­li­che Darstel­lung al­ler Merk­ma­le er­hält, auf die er sich voll und ganz kon­zen­trie­ren kann. Die da­zu not­wen­di­gen Vor­gän­ge, um zu die­ser Darstel­lung zu ge­lan­gen, soll das Sys­tem im Hin­ter­grund für ihn über­neh­men. Al­le ver­füg­ba­ren Ele­men­te zur Gestal­tung der For­mu­la­re sind auf dem Ser­ver hin­ter­legt. Für die glei­chen Ele­men­te ist im Cli­ent ei­ne je­wei­li­ge Kom­po­nen­te ver­füg­bar. Dar­aus ent­steht auf dem Ser­ver ein For­mu­lar­mo­dell, das mit ei­nem Pro­dukt­typ ver­knüpft wird. Die­ses Mo­dell be­schreibt, wie das For­mu­lar in­klu­si­ve al­ler Da­ten, Va­li­die­run­gen und Baustei­ne aus­zu­se­hen hat. Ruft der Nut­zer nun die De­tail­sei­te ei­nes Pro­duk­tes auf, teilt der Ser­ver dem Cli­ent das kor­rek­te For­mu­lar mit, trans­for­miert wenn nö­tig die Da­ten aus ei­nem an­de­ren Sys­tem pas­send für das For­mu­lar und sen­det die­ses kom­plett als ein les­ba­res JSON-Ob­jekt zu­rück.

Das JSON wird nun im Cli­ent dank des Interface In­ven­to­ries als nutz­ba­res For­mu­lar dar­ge­stellt. Un­se­re er­stell­te Form Di­rec­tive emp­fängt das JSON des Ser­vers und ite­riert über die­ses mit der ge­tDe­tailAt­tri­bu­te-Me­tho­de. Je nach ge­fun­de­nem Ty­pen ruft die Di­rec­tive die kor­rek­te Kom­po­nen­te auf und über­gibt ihr die er­hal­te­nen Da­ten. Die ein­zel­nen Kom­po­nen­ten küm­mern sich dar­auf­hin um die kor­rek­te Darstel­lung und Ver­wal­tung der Da­ten. So­mit hal­ten wir al­les, was mit der Darstel­lung zu tun hat, kom­plett auf der Sei­te des Cli­ents. Der Ser­ver hat da­mit nichts zu tun. Die­ser küm­mert sich nur um die Da­ten. Da­mit kön­nen wir in Zu­kunft auch we­sent­lich agi­ler re­agie­ren, soll­te es ein­mal da­zu kom­men, dass Än­de­run­gen an der HTML-Struk­tur be­nö­tigt wer­den. An­gu­lar 2 ist zu­dem sehr in­tel­li­gent beim Zu­sam­men­set­zen di­ver­ser Kom­po­nen­ten, wes­we­gen selbst tief ver­schach­tel­te Struk­tu­ren noch per­for­mant er­zeugt wer­den kön­nen. Der User soll da­von aber erst gar nichts mit­be­kom­men. In der Kon­zep­ti­ons­pha­se des Por­tals er­stell­ten wir al­le For­mu­la­r­ele­men­te. Da je­des Ele­ment aus zwei An­sich­ten be­steht, ei­ner le­sen­den und ei­ner schrei­ben­den, über­leg­ten wir uns, wel­che Ei­gen­schaf­ten je­des Ele­ment auf­wei­sen muss, da­mit es sei­nen Zweck er­fül­len kann. So be­steht ein ein­fa­ches In­put­feld aus ei­nem La­bel, ei­nem Sub­ty­pen (Text, Num­ber, E-Mail etc.), ei­nem Platz­hal­ter, ei­nem op­tio­na­len Stan­dard­wert, Va­li­de­rungs­ei­gen­schaf­ten wie mi­ni­ma­ler oder ma­xi­ma­ler Län­ge in­klu­si­ve pas­sen­der Feh­ler­mel­dung und ei­ner Zu­ord­nung zu ei­nem Feld in der Da­ten­bank. Es ent­stan­den am En­de cir­ca 20 Ele­men­te für un­se­re For­mu­la­re, je­des mit in­di­vi­du­ell spe­zi­fi­zier­ten Ei­gen­schaf­ten. Auf Ba­sis die­ser Ele­men­te ent­stand die kon­text­sen­si­ti­ve Be­nut­zer­füh­rung. Je­des Ele­ment für sich ge­nom­men hat ei­ne be­stimm­te Auf­ga­be, die es er­fül­len muss. Ei­ne Rei­ter­na­vi­ga­ti­on soll da­für sor­gen, zu­sam­men­hän­gen­de In­for­ma­tio­nen sau­ber zu grup­pie­ren und über­sicht­lich dar­zu­stel­len. Ein Text­feld soll die Mög­lich­keit bie­ten, Wer­te im Rah­men ei­ner ge­wähl­ten Va­li­die­rung frei ein­zu­tra­gen, die­se aber auch deut­lich les­bar dar­zu­stel­len.

Da wir die For­mu­la­r­ele­men­te iso­liert be­trach­te­ten, konn­ten wir uns dar­auf fo­kus­sie­ren, die­se op­ti­mal für den Be­nut­zer be­dien­bar zu ma­chen. Sind die Klick­flä­chen, um ein Ac­cor­di­on zu öff­nen, auch auf mo­bi­len Ge­rä­ten aus­rei­chend groß (Abb. 8)? Sind La­bel und In­put­feld ver­knüpft, da­mit ein Klick auf das La­bel den kor­rek­ten Fo­cus ins Feld setzt? Stel­len wir aus­rei­chend Weiß­raum zwi­schen Con­tai­nern dar, da­mit die­se vom Au­ge gut als zwei se­pa­ra­te Tei­le des For­mu­lars wahr­ge­nom­men wer­den? Wie schon bei der por­talüber­grei­fen­den Be­nut­zer­füh­rung soll­te bei je­dem Ele­ment genau ge­schaut wer­den, ob es ge­lern­te Stan­dards ein­hält oder, wenn es nö­tig ist, die­se zu bre­chen, ob es dem Be­nut­zer deut­lich auf­zeigt, wie er mit dem Ele­ment um­zu­ge­hen hat. Das Va­li­die­ren von For­mu­la­r­ele­men­ten wie In­put­fel­dern, Check­bo­xen oder Select­fel­dern über­las­sen wir wenn mög­lich di­rekt dem Browser. Der Be­nut­zer ist mit dem üb­li­chen Ver­hal­ten sei­nes Stan­dard­brow­sers ver­traut, und da­zu ge­hört auch die brow­ser­in­ter­ne Va­li­die­rung von For­mu­la­r­ele­men­ten. Da­her soll­te man sich im­mer fra­gen, ob es sinn­voll ist, ge­wohn­te Brow­ser­funk­tio­nen mit ei­ge­nen zu über­schrei­ben. Kön­nen wir da­durch wirk­lich ei­nen spür­ba­ren Mehr­wert lie­fern? Nur wenn die Ant­wort dar­auf ein kla­res Ja ist, lohnt sich die Im­ple­men­tie­rung. Ein Bau­kas­ten mit op­ti­mier­ten Ele­men­ten ist je­doch nur die hal­be Mie­te. So wür­den wir Ge­fahr lau­fen, dass For­mu­la­re er­stellt wer­den, de­ren kom­pli­zier­ter Auf­bau wie­der da­für sorgt, dass al­le bis­he­ri­gen Mü­hen um­sonst wa­ren. Es galt al­so nun, sinn­vol­le Be­schrän­kun­gen für das Kom­bi­nie­ren der Ele­men­te zu fin­den, die ei­nen Ba­lan­ce­akt voll­füh­ren muss­ten. Es soll trotz Ein­schrän­kun­gen wei­ter­hin die Chan­ce ge­ge­ben sein, ei­ne mög­lichst brei­te Pa­let­te an un­ter­schied­lichs­ten Da­ten­struk­tu­ren dar­zu­stel­len (Abb. 9). Auf der an­de­ren Sei­te sol­len die For­mu­la­re so ein­ge­schränkt sein, dass die breit ge­streu­te Nut­zer­schicht die­se in­tui­tiv be­die­nen kann. Auch auf ei­nem Smart­pho­ne. Doch wie fin­det man die rich­ti­ge Ba­lan­ce? Im ers­ten Schritt hilft es, sich auf all­ge­mei­ne Er­fah­run­gen und den ge­sun­den Men­schen­ver­stand zu ver­las­sen. Für den Be­nut­zer ist ei­ne We­b­ap­pli­ka­ti­on in ers­ter Li­nie nur ei­ne wei­te­re Web­sei­te, die er im Browser auf­ru­fen kann. So­mit gel­ten erst ein­mal die glei­chen Re­geln wie für an­de­re Web­sei­ten auch. Die­se kön­nen so­wohl tech­ni­scher Na­tur, wie Bild­schirm­grö­ßen oder Brow­ser­sup­port, als auch mensch­li­cher Na­tur sein. Da­durch lie­ßen sich Best Prac­tices ab­lei­ten, die in die oben er­wähn­te por­talüber­grei­fen­de Usa­bi­li­ty ein­flos­sen. Da­zu ge­hört zum Bei­spiel das er­wähn­te stan­dar­di­sier­te Lay­out, das auf ei­ne eta­blier­te Auf­tei­lung setzt und da­durch hilft, sich schnell zu­recht­zu­fin­den (Stu­die zu Plat­zie­run­gen von Ele­men­ten auf Web­sei­ten: goo.gl/TUez­pz). Aber auch Fil­ter- und Sor­tier­mög­lich­kei­ten, da­mit ein Nut­zer schnel­ler ei­ne Men­ge von Such­er­geb­nis­sen nach sei­nen Kri­te­ri­en ein­schrän­ken kann. La­de­zei­ten soll­ten wie bei je­der Web­sei­te so kurz wie mög­lich ge­hal­ten

wer­den. Und kommt es mal zu ei­nem län­ge­ren La­de­vor­gang, muss der Be­nut­zer vi­su­el­les Feed­back er­hal­ten (zum Bei­spiel in Form ei­nes Loa­ding Spin­ners, Abb. 10). Feh­ler­mel­dun­gen soll­ten deut­lich her­vor­ge­ho­ben sein. Es reicht oft­mals nicht, nur ei­ne Mel­dung un­ter das Feld zu pa­cken. Auch das Feld an sich soll­te deut­lich mar­kiert sein (Abb. 11). Des Wei­te­ren hat­ten wir den Vor­teil, auf Er­fah­run­gen ei­ner an­de­ren Soft­ware von uns zu­rück­grei­fen zu kön­nen, die für den Browser auf Ba­sis ei­nes UI-Frame­works er­stellt wur­de, das Ja­va zu Ja­vaS­cript kom­pi­liert. In die­sem pri­mär als Lie­fe­ran­ten­por­tal ge­nutz­ten Pro­dukt gab es be­reits ei­ni­ge von Kun­den er­stell­te For­mu­la­re, die über Jah­re oh­ne Ein­schrän­kun­gen so sehr ge­wach­sen wa­ren, dass Browser die vom Frame­work er­zeug­te Ta­bel­len­struk­tur nicht mehr an­zei­gen konn­ten. Dies bot uns ei­nen gu­ten An­halts­punkt, zu prü­fen, wel­che Pro­ble­me bei sehr kom­plex ver­schach­tel­ten For­mu­la­ren ent­ste­hen kön­nen. Wir ana­ly­sier­ten den Auf­bau der grö­ße­ren For­mu­la­re und ver­such­ten die­se dann mit den von uns ge­wähl­ten Ein­schrän­kun­gen nach­zu­bau­en. Hier­bei stell­ten wir am En­de fest, dass wir zwar kei­ne Eins-zu-eins-Ko­pie er­stel­len, aber den­noch trotz un­se­rer Re­strik­tio­nen al­le Da­ten der For­mu­la­re un­ter­brin­gen konn­ten, so­gar in ei­ner we­sent­lich be­nut­zer­freund­li­che­ren, über­sicht­li­che­ren Art und Wei­se. So gibt es in der Soft­ware ein Do­ku­ment, das aus Rei­tern mit bis zu 15 Ein­trä­gen be­steht, in de­nen wie­der­um ein Rei­ter mit meh­re­ren Ein­trä­gen ist, wor­in sich ein wei­te­rer Rei­ter be­fin­det (Abb. 12). Be­nut­zer han­geln sich al­so durch zig Na­vi­ga­tio­nen, in der Hoff­nung, das ge­such­te Feld an der Stel­le zu fin­den, wo sie es ver­mu­ten. Den obers­ten Rei­ter mit sei­nen 15 Ein­trä­gen teil­ten wir in ein­zel­ne Pa­nels auf, die sich dank ei­ner An­ker-Na­vi­ga­ti­on im obe­ren Be­reich der Sei­te di­rekt an­sprin­gen las­sen. So­mit sind we­sent­lich mehr Fel­der di­rekt sicht­bar. In­ner­halb der Pa­nels konn­ten wir die For­mu­lar­fel­der mit ei­ner Kom­bi­na­ti­on aus Rei­ter­na­vi­ga­ti­on mit in­klu­dier­tem Ac­cor­di­on op­ti­mal dar­stel­len. Das For­mu­lar ließ sich am En­de schnel­ler scan­nen, und man kam mit we­ni­ger Klicks zum ge­wünsch­ten Ziel. Falls Ih­nen kei­ne ei­ge­ne Soft­ware zur Ver­fü­gung steht, hilft es, an­de­re Da­ten-las­ti­ge We­b­ap­pli­ka­tio­nen zu ana­ly­sie­ren und dort be­wusst zu schau­en, wel­che Lö­sungs­we­ge die Ent­wick­ler ein­ge­schla­gen ha­ben. In un­se­rem Fall ent­schie­den wir uns, dass kon­kre­te Merk­ma­le ei­nes Pro­duk­tes, wie zum Bei­spiel des­sen Far­be oder Ablauf­da­tum, nur in­ner­halb ei­nes spe­zi­el­len Con­tai­ne­r­ele­ments ge­la­gert wer­den kön­nen. Die­se Con­tai­ner wie­der­um fin­den Platz in er­wähn­ten Lay­ou­t­e­le­men­ten, wie ei­nem um­schlie­ßen­den Pa­nel, ei­nem Rei­ter oder Ac­cor­di­on. Es ent­ste­hen ganz kla­re Vor­ga­ben und so­mit Struk­tu­ren beim Auf­bau ei­nes For­mu­lars, die sich da­mit über al­le Pro­dukt­ty­pen hin­weg durch­zie­hen. Der Be­nut­zer fin­det ein Pa­nel vor, in des­sen In­halts­be­reich zum Bei­spiel ein Rei­ter ei­nen Con­tai­ner ent­hält, der die di­ver­sen Merk­ma­le des Pro­dukts dar­stellt. Nie wird der Nut­zer ei­nem Merk­mal be­geg­nen, das ver­lo­ren di­rekt in ei­nem Pa­nel oder ei­nem an­de­ren Lay­ou­t­e­le­ment her­um­liegt, egal ob Ho­tel oder Schrau­be. Wei­ter­hin ent­schlos­sen wir uns, ein ho­hes Maß an Kom­ple­xi­tät aus den For­mu­la­ren zu zie­hen, in­dem un­se­re Lay­ou­t­e­le­men­te nicht un­end­lich oft in­ein­an­der ver­schach­telt wer­den kön­nen, son­dern ma­xi­mal zwei Ebe­nen tief (mög­lich wä­re al­so ein Tab­set in ei­nem Ac­cor­di­on oder ein Tab­set in ei­nem Tab­set; ein Ac­cor­di­on in ei­nem Ac­cor­di­on in ei­nem Ac­cor­di­on gin­ge nicht mehr). Dies ver­hin­dert, dass Da­ten in den Tie­fen des For­mu­lars un­auf­find­bar ver­gra­ben wer­den, und ga­ran­tiert auch auf klei­ne­ren Ge­rä­ten wie Smart­pho­nes ei­ne op­ti­ma­le Be­die­nung. Auf die Darstel­lung der Merk­ma­le in­ner­halb ei­nes Con­tai­ners hat der Be­nut­zer eben­falls keinen Ein­fluss. Die­ses fein­gra­nu­la­re Lay­ou­ten über­nimmt un­ser CSS. Dank Flex­box ord­net un­ser Por­tal dy­na­misch die Merk­ma­le an­hand der Bild­schirm­brei­te und An­zahl an Merk­ma­len selbst an. Beim Auf­bau der For­mu­la­re gilt es, mit sol­chen Ein­schrän­kun­gen

zu le­ben, da­mit man sich nicht in Klei­nig­kei­ten ver­rennt, son­dern sich auf die wich­ti­gen Din­ge kon­zen­triert, wie ei­ne sau­be­re Struk­tu­rie­rung der Da­ten zu fin­den. Zu gu­ter Letzt tes­te­ten wir al­le Lö­sungs­vor­schlä­ge un­ter rea­len Be­din­gun­gen. Wir er­stell­ten re­du­zier­te Pro­to­ty­pen und Klick­dum­mys mit­hil­fe des Tools In­vi­si­on. Da un­se­re De­signs in Sketch ent­stan­den, lie­ßen sich die­se per Plu­gin di­rekt mit In­va­si­on ver­knüp­fen. Da­durch wur­den Än­de­run­gen an den De­signs di­rekt auch in die Klick­dum­mys über­nom­men. In re­gel­mä­ßi­gen Tref­fen mit in­ter­nen Mit­ar­bei­tern, die teil­wei­se we­ni­ger stark im Pro­jekt in­vol­viert wa­ren und kun­den­na­he Auf­ga­ben ver­tra­ten, kon­trol­lier­ten wir un­se­re Lö­sungs­an­sät­ze. De­ren ehr­li­ches Feed­back war ex­trem wich­tig für uns, da für uns die Ge­fahr be­stand, mit Scheu­klap­pen auf das Pro­jekt zu star­ren und den Blick über den Tel­ler­rand zu ver­lie­ren. Nach je­der Run­de be­wer­te­ten wir ge­nann­te Kri­tik, pass­ten De­signs an, spiel­ten er­neut den Klick­dum­my durch, bis wir an ei­nen Punkt ka­men, mit dem wir, die Ge­schäfts­lei­tung und al­le ein­ge­bun­de­nen Tes­ter zu­frie­den wa­ren.

FA­ZIT

Ei­ne be­nut­zer­freund­li­che We­b­ap­pli­ka­ti­on zu bau­en, be­nö­tigt Zeit und Schweiß. Je grö­ßer der Funk­ti­ons­um­fang, um­so kom­pli­zier­ter wird es, die Usa­bi­li­ty auf ei­nem ho­hen Le­vel zu hal­ten. Neue Funk­tio­nen brin­gen ein Mehr an Kom­ple­xi­tät mit sich, wo­durch ein UI schnell un­über­sicht­lich wird. Ver­fol­gen Sie dann noch ei­nen ge­ne­ri­schen An­satz, so­dass Sie nicht ab­schät­zen kön­nen, wie kom­plex die Struk­tu­ren in­ner­halb der Ap­pli­ka­ti­on wer­den, rückt ei­ne gu­te Be­nut­zer­füh­rung wei­ter in die Fer­ne. Ein ge­sun­des Maß an Ein­schrän­kun­gen, die nicht da­von ab­hal­ten, Zie­le zu er­fül­len, hilft da­bei, die Be­nut­zer­füh­rung in gu­te Bah­nen zu len­ken. Ver­wen­den Sie Teil­stü­cke, die für sich ge­nom­men ei­ne spe­zi­fi­sche Auf­ga­be ha­ben. Die­se Teil­stü­cke bil­den ein Tool­set, mit dem lo­gi­sche Struk­tu­ren und grup­pier­te Funk­tio­na­li­tä­ten er­stellt wer­den kön­nen. Sie kön­nen im Rah­men der ge­wähl­ten Re­strik­tio­nen kom­bi­niert wer­den, um mög­lichst na­he an die Er­war­tungs­hal­tung des Nut­zers her­an­zu­kom­men. So ent­steht ei­ne mo­du­lar er­stell­te Be­nut­zer­ober­flä­che, ein­ge­bet­tet in das be­reits op­ti­mier­te Ge­samt­lay­out der Ap­pli­ka­ti­on. Kom­pli­zier­te Ver­fah­ren, die das Sys­tem durch­läuft, um die Ober­flä­che dar­zu­stel­len, soll­ten Sie im Hin­ter­grund ab­lau­fen las­sen. Am En­de zählt nur, ob Ih­re Nut­zer schnell und oh­ne Frust ih­re Zie­le er­rei­chen kön­nen. Kom­men­tie­ren: screen­gui.de/36/usa­bi­li­ty

Abb. 1: Googles Start­sei­te ist voll­kom­men aufs Su­chen op­ti­miert.

Abb. 3: Die But­tons ei­nes Mo­dals zei­gen klar auf, wel­ches die pri­mä­re und wel­ches die se­kun­dä­re Ak­ti­on ist.

Abb. 2: Das Dash­board zeigt die üb­li­che Auf­tei­lung des Lay­outs.

Abb. 6: Me­di­en kön­nen per Upload in das Sys­tem ge­bracht wer­den. Da­bei kann je­der Upload voll­kom­men in­di­vi­du­ell ge­stal­tet sein.

Abb. 7: Die Be­nut­zer­de­tail­sei­te ba­siert auf den glei­chen Ele­men­ten wie die De­tail­sei­te ei­nes Bil­des.

Abb. 4: Bei­spiel ei­nes kom­ple­xen, ge­ne­ri­schen Ob­jekts an­hand ei­nes Ho­tels im Con­tent Por­tal.

Abb. 5: Ein Pa­nel kann aus meh­re­ren Ein­zel­tei­len zu­sam­men­ge­steckt wer­den.

Abb. 8: Ele­men­te in der Desk­top- und Re­s­pon­sive-An­sicht. Rei­ter wer­den mo­bil au­to­ma­tisch zu Ac­cor­di­ons trans­for­miert.

Abb. 10: Das Loa­der-Icon (links) zeigt di­rekt am Ele­ment, dass ein La­de­vor- gang ge­star­tet ist. Ein zu­sätz­li­cher Fort­schritts­bal­ken in­for­miert über die Dau­er des Vor­gangs.

Abb. 9: Die Auf­lis­tung al­ler ver­füg­ba­ren Interface-Ele­men­te zeigt die Viel­falt des Interface In­ven­to­ries.

Abb. 13: Wei­te­res Bei­spiel ei­nes Pro­dukts im Con­tent Por­tal. Hier wird ein Mö­bel­stück ab­ge­bil­det.

Abb. 11: Deut­lich mar­kier­te Fel­der hel­fen dem Be­nut­zer schnel­ler, die­se Feh­ler zu fin­den und zu be­he­ben.

Abb. 12: Bei­spiel ei­ner kom­ple­xen Ver­schach­te­lung im Lie­fe­ran­ten­por­tal

Marcel Henk­haus ist Web­in­ter­face De­si­gner bei eggheads in Bochum, ei­nem spe­zia­li­sier­ten Soft­ware­un­ter­neh­men für Pro­dukt­in­for­ma­ti­onMa­nage­ment-Sys­te­me [eggheads.de]. Er ist dort für die Kon­zep­ti­on, Gestal­tung und Um­set­zung von be­nut­zer­freund­li­chen Ober­flä­chen im Web zu­stän­dig.

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.