Prosta krzywa uczenia się

Ucz się ucz…

Pod­czas pro­jek­to­wa­nia sys­te­mów i apli­ka­cji nale­ży pamię­tać o czyn­ni­kach, któ­re wpły­wa­ją na pro­ces ich nauki – szyb­kość i efek­tyw­ność nauki sys­te­mu przez użyt­kow­ni­ków koń­co­wych jest klu­czo­wa z punk­tu widze­nia biz­ne­so­we­go. Celem jest przy­spie­sze­nie tego pro­ce­su i doj­ście do eta­pu, w któ­rym sys­tem lub apli­ka­cja są obsłu­gi­wa­ne nie­mal auto­ma­tycz­nie. Taka auto­ma­ty­za­cja w kon­tek­ście pro­ce­sów myślo­wych ozna­cza mię­dzy inny­mi zmi­ni­ma­li­zo­wa­nie ilo­ści pamię­ci krót­ko­trwa­łej wyko­rzy­sty­wa­nej pod­czas korzy­sta­nia z sys­te­mu oraz umoż­li­wie­nie tzw.  mul­ti­ta­skin­gu (ozna­cza­ją­ce­go, że rów­no­le­gle do obsłu­gi sys­te­mu mogą być wyko­ny­wa­ne przez użyt­kow­ni­ka inne czyn­no­ści). Wie­lo­za­da­nio­wość jest szcze­gól­nie istot­na wła­śnie w apli­ka­cjach biz­ne­so­wych, gdzie użyt­kow­ni­cy muszą wyko­ny­wać w tym samym cza­sie sze­reg nie­za­leż­nych zadań np. pra­cow­ni­cy call cen­ter poszu­ku­ją infor­ma­cji w swo­im sys­te­mie jed­no­cze­śnie roz­ma­wia­jąc z klien­tem przez tele­fon. Zada­niem pro­jek­tan­ta jest stwo­rze­nie takie­go sys­te­mu, któ­re­go nauka obsłu­gi zosta­ła­by skró­co­na do nie­zbęd­ne­go mini­mum, co prze­kła­da się wymier­nie na kosz­ty (pomył­ki, czas tre­nin­gu, itp.).

Jakie zatem czyn­ni­ki przy­spie­sza­ją naukę? Jeff John­son w swo­jej książ­ce Desi­gning with the mind in mind wska­zu­je na trzy waż­ne ele­men­ty:

• Ope­ra­cje – zorien­to­wa­ne na kon­kret­ne zada­nia, pro­ste i spój­ne;
• Słow­nic­two – zorien­to­wa­ne na kon­kret­ne zada­nia, pro­ste i spój­ne;
• Niskie ryzy­ko.

Ope­ra­cje

Pro­jek­tant powi­nien zli­kwi­do­wać coś, co Donald Nor­man nazwał gulf of exe­cu­tion tj. róż­ni­cę mię­dzy tym co użyt­kow­nik chce zro­bić a tym co ofe­ru­je mu dane narzę­dzie. Nie­zbęd­ne do tego sta­je się więc zro­zu­mie­nie celów użyt­kow­ni­ka oraz typo­wych zadań, któ­re będzie wyko­ny­wał użyt­kow­nik. Aby spre­cy­zo­wać te wyma­ga­nia war­to zacząć od  ana­li­zy zadań, na jej pod­sta­wie zbu­do­wać kon­cep­tu­al­ny model apli­ka­cji a następ­nie zapro­jek­to­wać na tej pod­sta­wie inter­fejs.

Ana­li­za zadań ma na celu zna­le­zie­nie odpo­wie­dzi na nastę­pu­ją­ce pyta­nia:  któ­re zada­nia wyko­ny­wa­ne są czę­sto a któ­re rzad­ko, jakie są kolej­ne kro­ki poszcze­gól­ne­go zada­nia, jaki jest wynik każ­de­go zada­nia itp.

Kie­dy znaj­dzie­my już odpo­wie­dzi na te i podob­ne pyta­nia, moż­na będzie przy­go­to­wać model kon­cep­tu­al­ny apli­ka­cji, któ­ry okre­śla funk­cje apli­ka­cji i któ­ry powi­nien uwzględ­niać zada­nia wyko­ny­wa­ne przez użyt­kow­ni­ka.

Pod­czas two­rze­nia mode­lu kon­cep­tu­al­ne­go war­to prze­pro­wa­dzić ana­li­zę obiek­tów i dzia­łań – okre­śla ona, jakie ele­men­ty będą widocz­ne w sys­te­mie dla użyt­kow­ni­ka oraz jakie dzia­ła­nia będzie mógł on na nich wyko­ny­wać. W przy­pad­ku sys­te­mu ban­ko­wo­ści elek­tro­nicz­nej pod­sta­wo­wy­mi ele­men­ta­mi – obiek­ta­mi będą np. kon­to, rachu­nek czy trans­ak­cja a moż­li­wy­mi dzia­ła­nia­mi np. spraw­dze­nie sta­nu kon­ta lub prze­lew na rachu­nek. Obiek­ty i dzia­ła­nia widocz­ne dla użyt­kow­ni­ka nie mogą być pro­stym odwzo­ro­wa­niem obiek­tów i dzia­łań widocz­nych na pozio­mie imple­men­ta­cji – użyt­kow­ni­ka nie inte­re­su­ją takie obiek­ty jak bufor, tabe­la i „string” lub ope­ra­cje takie jak zacią­ga­nie danych  bazy czy opróż­nia­nie bufo­ra.

Przy two­rze­niu mode­lu kon­cep­tu­al­ne­go war­to zadbać aby był tak pro­sty, jak to moż­li­we – zbyt roz­bu­do­wa­ny model, posia­da­ją­cy wie­le obiek­tów i moż­li­wych  ope­ra­cji powo­du­je, że sys­tem jest bar­dziej skom­pli­ko­wa­ny a co za tym idzie – trud­niej­szy w nauce.

Inną klu­czo­wą kwe­stią jest zacho­wa­nie spój­no­ści zarów­no na pozio­mie mode­lu kon­cep­tu­al­ne­go – aby na podob­nych obiek­tach moż­li­we były do wyko­na­nia takie same ope­ra­cje. Waż­na jest rów­nież spój­ność na pozio­mie „fizycz­ne­go” inter­fej­su – co ozna­cza, że te same akcje są wywo­ły­wa­ne i kon­tro­lo­wa­ne w ten sam spo­sób (cho­dzi o ustan­da­ry­zo­wa­nie spo­so­bu wyko­ny­wa­nia czyn­no­ści tego same­go typu na pozio­mie inter­fej­su – np. jeże­li w apli­ka­cji desk­to­po­wej po klik­nię­ciu pra­wy przy­cisk myszy na jed­nym pli­ku otwie­ra się menu, a na innym już nie – moż­na mówić o bra­ku spój­no­ści na tym pozio­mie).

Słow­nic­two

Dru­gim czyn­ni­kiem wpły­wa­ją­cym na czas potrzeb­ny do nauki sys­te­mu jest uży­te słow­nic­two – tutaj rów­nież war­to pamię­tać o tym aby ter­mi­no­lo­gia była zorien­to­wa­na na zada­nia, zna­na użyt­kow­ni­kom oraz spój­na.

Poję­cia uży­wa­ne w sys­te­mie powin­ny być infor­ma­tyw­ne i zorien­to­wa­ne na zada­nia – tzn.  nieść za sobą zro­zu­mia­łą dla użyt­kow­ni­ka treść zwią­za­ną z zada­niem któ­re chce wyko­nać. Zakres uży­wa­ne­go słow­nic­twa moż­na usta­lić za pomo­cą np. wywia­dów z użyt­kow­ni­ka­mi. Poza tym waż­ne jest sto­so­wa­nie słow­nic­twa, któ­re jest zna­ne dla użyt­kow­ni­ków koń­co­wych – nie zmu­szaj­my ich do nauki  nowych, skom­pli­ko­wa­nych, tech­nicz­nych pojęć. Ich zna­jo­mość nie powin­na być koniecz­na do wyko­na­nia zada­nia (o ile oczy­wi­ście nie pro­jek­tu­je­my np. inter­fej­su sys­te­mu do zarzą­dza­nia baza­mi danych).

Słow­nic­two uży­wa­ne w sys­te­mie powin­no być spój­ne –  te same ele­men­ty powin­ny być tak samo nazwa­ne oraz tak samo nazwa­ne ele­men­ty powin­ny ozna­czać te same rze­czy. Jeże­li wpro­wa­dzi­my do sys­te­mu róż­ne nazwy dla ozna­cze­nia tych samych ele­men­tów lub jeśli jed­no poję­cie będzie sto­so­wa­ne do ozna­cze­nia róż­nych rze­czy to  wpły­nie to nega­tyw­nie na pro­ces nauki oraz moż­li­we pomył­ki.

Ryzy­ko

Kolej­ną kwe­stią uła­twia­ją­cą naukę jest zapro­jek­to­wa­nie sys­te­mu, któ­ry zapo­bie­ga błę­dom, wyba­cza błę­dy już popeł­nio­ne oraz daje moż­li­wość wyco­fa­nia się z pomył­ki. Taki sys­tem redu­ku­je stres i zachę­ca do jego eks­plo­ra­cji – pozna­wa­nia nowych funk­cji i tym samym bar­dziej efek­tyw­ne­go korzy­sta­nia z sys­te­mu. I odwrot­nie –  użyt­kow­ni­cy nie będą chcie­li uczyć się sys­te­mu ze świa­do­mo­ścią, że jeże­li popeł­nią pomył­kę to może ona być trud­na do sko­ry­go­wa­nia.

Wymie­nio­ne przez John­so­na czyn­ni­ki nie wyczer­pu­ją oczy­wi­ście listy – oprócz nich ist­nie­je sze­reg innych ele­men­tów (czę­sto zewnętrz­nych i nie­za­leż­nych od pro­jek­tan­ta) któ­re wpły­wa­ją na to jak szyb­ko użyt­kow­ni­cy uczą się obsłu­gi sys­te­mu czy apli­ka­cji. Nie­mniej te wyżej wymie­nio­ne pozo­sta­ją w zasię­gu wpły­wu pro­jek­tan­ta i tyl­ko od nie­go zale­ży czy za ich pomo­cą upro­ści­my czy utrud­ni­my naukę sys­te­mu.