Room 303

O ile robię wszystko, co w mojej mocy, żeby popu­la­ry­zo­wać wspar­cie dla stan­dar­dów i popra­wia­nie usa­bi­lity w sieci, nie każdy przy­pa­dek jest taki sam i nie zawsze można ślepo sto­so­wać te same reguły.

W więk­szo­ści przy­pad­ków fak­tycz­nie, powinno się ogra­ni­czyć tech­no­lo­gie wspie­ra­jące (czyli tak naprawdę wszystko poza HTML) do mini­mum, zapew­nia­jąc tym samym jak naj­lep­szą dostęp­ność do infor­ma­cji dla osób korzy­sta­ją­cych z róż­nych urzą­dzeń i opro­gra­mo­wa­nia. Nie chcemy prze­cież któ­re­goś dnia zalo­go­wać się do swo­jego sys­temu ban­ko­wego tylko po to, żeby dowie­dzieć się, że bra­kuje nam 16 wty­czek, z czego 8 nie jest dostęp­nych dla naszej plat­formy (co jest coraz powszech­niej­szym pro­ble­mem, nie doty­czy już tylko urzą­dzeń prze­no­śnych, ale także kom­pu­te­rów pra­cu­ją­cych na pro­ce­so­rach rodzin AMD64 i PPC). Wszystko jest jed­nak warun­ko­wane przez tar­get, dla któ­rego prze­zna­czony jest nasz produkt.

Głu­potą byłoby zre­zy­gno­wa­nie z tech­no­lo­gii takich jak Flash, czy zagnież­dżone wideo na stro­nach rekla­mu­ją­cych naj­now­szą grę kom­pu­te­rową — ser­wis tego typu jest prze­zna­czony dla wąskiej grupy odbior­ców, raczej nie grozi nam nawał użyt­kow­ni­ków uzbro­jo­nych w tele­fony komór­kowe, PDA czy kon­so­lowe prze­glą­darki pra­cu­jące pod kon­trolą sys­te­mów unik­so­wych. Zwłasz­cza, jeśli gra prze­zna­czona jest dla jed­nej kon­kret­nej plat­formy. Jej pod­sta­wową funk­cją jest poka­za­nie odwie­dza­ją­cym namiastki tego, co znajdą w rekla­mo­wa­nym pro­duk­cie, stąd zasto­so­wa­nie znajdą tam naj­now­sze tech­no­lo­gie multimedialne.

Podobna sytu­acja ma miej­sce w przy­padku apli­ka­cji webo­wych. Zamknięte sys­temy, wyma­ga­jące logo­wa­nia, takie jak intra­nety, eks­tra­nety czy panele kon­tro­lne CMS służą jedy­nie swoim użyt­kow­ni­kom. Nie musimy mar­twić się tym, że zostaną nie­pra­wi­dłowo zain­dek­so­wane przez wyszu­ki­warki, a układ hie­rar­chiczny z defi­ni­cji nie przy­po­mina typo­wej strony inter­ne­to­wej. Wszech­obecne for­mu­la­rze i układ apli­ka­cyjny z defi­ni­cji dyk­tują struk­turę doku­men­tów, która czę­sto nie może być tak czy­sta, jak w przy­padku zwy­kłych ser­wi­sów — musi spro­stać pro­jek­towi gra­ficz­nemu, który nie­jed­no­krot­nie bar­dziej przy­po­mina apli­ka­cję rodem z pakietu MS Office niż doku­ment stwo­rzony w HTML.

Tutaj znaj­dują zasto­so­wa­nie gorące nowinki ze świata, z mod­nym ostat­nio hasłem AJAX na czele. Jeśli apli­ka­cja ma wyglą­dać jak zwy­kły pro­gram, to funk­cjo­nal­ność typu drag-n-drop z zapi­sy­wa­niem danych w locie (bez prze­ła­do­wa­nia) jest dla użyt­kow­nika czymś natu­ral­nym. W prze­ci­wień­stwie do usa­bi­lity typo­wych stron, w kwe­stii apli­ka­cji stan­dardy wyzna­cza Ruby on Rails i świetny fra­me­work script.aculo.us.

Kwe­stia wspar­cia dla prze­glą­da­rek z wyłą­czo­nym JS nie jest pro­ble­mem, sprze­da­jemy pro­gram i ma on swoje wyma­ga­nia. Nikt nie ocze­kuje, że Win­dows XP zacznie dzia­łać na 286, nikt też nie narzeka, że naj­now­sze mor­do­bi­cie na kon­solę nie nadaje się do użytku po wyłą­cze­niu telewizora.

Ina­czej wygląda sprawa ze spe­cy­ficz­nymi klien­tami — w pew­nych warun­kach nie jest moż­liwe zasto­so­wa­nie czy­stego układu (struk­tu­ralny doku­ment + CSS). Nie jest to jed­nak powód do tego, żeby cał­ko­wi­cie zarzu­cić wspar­cie dla styli — zbu­do­wa­nie układu hybry­do­wego (tabela do pocię­cia układu + CSS do zgra­nia cało­ści) daje dużo wię­cej korzy­ści niż sama satys­fak­cja. Strona jest przede wszyst­kim dużo lżej­sza, a przez to ładuje się szyb­ciej (choć układy tabe­la­ryczne nie pozwa­lają na ren­de­ro­wa­nie pro­gre­sywne w takim zakre­sie, jak oparte na czy­stej struk­tu­rze) i jest znacz­nie łatwiej­sza w edy­cji (a wpro­wa­dza­jąc zmiany w arku­szu styli możemy w pro­sty spo­sób zmie­nić wygląd setek pod­stron). Zapew­niamy sobie też iden­tyczny wygląd we wszyst­kich prze­glą­dar­kach, także w tych przy­szłych (wyobraź sobie, jak wyglą­da­łoby teraz 95% inter­netu, gdyby prze­glą­darki nagle porzu­ciły wspar­cie dla prze­sta­rza­łych ele­men­tów, jak <font/>).

Z dru­giej strony są też eks­tre­mi­ści, któ­rzy nawet dane typowo tabe­la­ryczne (jak zesta­wie­nia sta­ty­styczne, czy cen­niki) zamie­niają na gro­te­skowe kon­struk­cje, które według nich są bar­dziej seman­tyczne. To jed­nak — na szczę­ście — kwa­li­fi­kuje się w więk­szo­ści przy­pad­ków jako nie­szko­dliwe geeko­stwo i zaję­cia typu proof of con­cept. Uży­cie takiego wyna­lazku w real­nym pro­jek­cie komer­cyj­nym może tylko wysta­wić autora na publiczne pośmie­wi­sko — jest dowo­dem zupeł­nego braku zro­zu­mie­nia seman­tyki języka.

Pod­su­mo­wu­jąc — twarde zapie­ra­nie się rękoma i nogami przed zasto­so­wa­niem boga­tych mul­ti­me­diów czy opar­ciem funk­cjo­nal­no­ści na języ­kach skryp­to­wych po stro­nie agenta przy argu­men­ta­cji, że to dla dobra usa­bi­lity, nie zawsze jest wła­ściwe. W nie­któ­rych, spe­cy­ficz­nych przy­pad­kach, odwie­dza­jący ocze­kuje takiej wła­śnie funk­cjo­nal­no­ści i wzbra­nia­nie się przed nią jest dzia­ła­niem na szkodę użytkownika.