Moralas toks – jeigu įtrauki į savo kodą failus tiesiogiai iš kitų žmonių serverių, ypač jeigu jų nepažįsti ir nepaklausi jų sutikimo, viskas gali baigtis blogai. Štai pvz. mano blog’as naudoja html5.js – aš galėčiai ramiai pakeisti jį taip, kad jis vogtų jūsų svetainės lankytojų slaptažodžius ir siųstų man. Bet aš neesu blogietis ir to nedarysiu.

Jeigu kam nors reikia įsijungti HTML5 Internet Exploreryje – galima gi paimti ir parsisiųsti tą JS ir pasidėti savo svetainėje. Bet jeigu jau taip gaila srauto – Remy Sharp leidžia tiesiogiai naudoti jo sukurtą versiją iš Google Code SVN.

Man iš tikro negaila, bet pagunda bent pajuokauti yra… Tu žinai kas tu esi. Ar ne?

Pirmas argumentas, kurį gavau uždavęs šį klausimą, buvo tai, kad ranka rašyti, atseit, yra greičiau. Kodėl tuomet teismo stenografuotojai – žmonės, kurių darbas yra rašyti pačiu greičiausiu įmanomu būdu, naudoja (tegul ir specializuotą) aparatūrą? Turint omeny, kaip veikia žmogaus smegenys, kai jis atlieka darbą, kuris jam įaugęs į kraują, aparatūra teikia garantuotą privalumą.

Patogumo požiūriu, tam tikrose situacijose aš pats vis dar teikiu pirmenybę popieriui. Jeigu mokykloje būčiau mokytas kitaip – tokio įpročio neturėčiau. Ir nuo to visai nenukentėčiau – esu įsitikinęs, kad būčiau tik dar efektyvesnis. Turint omeny Twitter paplitimą ir kiek žmonių savo užrašus konferencijose atlieka tiesiai į kompiuterį ir į internetą, akivaizdu, kad patogumas tėra tik įprotis.

Nepaisant to, kad galbūt nukenčia rašymo greitis, aš naudoju spausdintines raides savo užrašuose. Ir nuo to taipogi nieko neprarandu – netgi laimiu, nes mano užrašus kiti žmonės gali įskaityti lengviau. Tiesą pasakius, turbūt rašytinėmis raidėm ir nebemokėčiau rašyt – reiškias lieka galvoj daugiau vietos dalykams, kurie yra naudingesni.

Be abejo, šiame reikale yra ir emocinis aspektas – ranka rašyti laiškai, atseit, yra kažkokiu būdu “žmogiškesni”. Aš nestudijavau psichologijos – nežinau ar tikrai pagrįstas yra šis argumentas, tačiau aš manau, kad mano būsimi vaikai pradės su manim bendrauti “mašininiu būdu” anksčiau, negu pradės eiti į mokyklą – SMS, Skype ir pan. Lygiai taip pat bus ir su jų bendraamžiais. Emocinis aspektas išliks tik siekiant parodyti, kad tai yra mano “rankų darbas” – lygiai kaip ir ranka pieštas, o ne pirktas, gimtadienio atvirukas. Tačiau juk piešti atvirukų žmonės privalomai mokykloje nemokomi. Na, bent jau ne visus metus ir ne kiekvieną dieną. Lygiai taip pat ir su bet kuriais kitais rankdarbiais.

Nesupraskit manęs neteisingai. Aš neteigiu, kad rašyti ranka yra apskritai nereikalingas įgūdis – sugebėti perduoti informaciją primityviais įrankiais yra labai svarbu. Maždaug taip, kaip svarbu mokėti sukurti laužą ir sužvejoti žuvį – elementarus išlikimas. Ir turint omeny, kad visiškai popieriaus atsikratyti artimu metu tikrai nepavyks, treniruotis greitai užpildyti formas derėtų, tačiau mes juk kalbame apie ateinančią kartą – tą, kuri turės gyventi gerokai po to, kai baigsis mūsų pačių galiojimo laikas.

Šiuo metu, nėra nei vieno žmogaus, kuris turi nusipirkęs iPad. Tačiau prieš šimtą metų nebuvo nei vieno žmogaus, kuris turėjo nusipirkęs radiją. Po šimto metų, būsim visi prijungti prie matricos, ir nei rašymas, nei spausdinimas, nei išvis diktavimas nebebus aktualūs. Tačiau šiuo pereinamuoju laikotarpiu, septynmetis, kuris sugeba kompiuteriu atlikti namų darbus yra ateities žmogus, kuris savo laiku galės konkuruoti su milijonais kitų dėl darbo ir mokės jūsų pensijas.

Diskleimeris

Man rūpi klimato kaita. Aš tikiu, kad žmonija yra kalta dėl to. Aš mėgstu gamtą ir noriu, kad mano vaikai ir vaikaičiai gyventų švariame pasaulyje. Todėl nuo rugpjūčio mėnesio šiek tiek savanoriauju Oxfam Ireland ir (tikiuosi) šiek tiek padėjau jiems internetinėje kampanijoje dėl klimato kaitos.

Mano požiūris šiuo klausimu nėra visiškai neutralus, tačiau faktus aš stengiuosi vertinti objektyviai. Mažų mažiausiai, aš stengiuosi patikrinti juos skirtinguose šaltiniuose ir išklausyti abi puses – kartais “vienos tiesos” paprasčiausiai nėra.

Būtent dėl to, per paskutinius kelis mėnesius perskaičiau begalę informacijos apie tai kokiais argumentais apie klimatą “kovoja” skirtingos šio reikalo pusės. Tiesą pasakius, man nelabai patinka kai kurių žaliųjų metodika, nes jie iš tikrųjų atrodo kaip viską pervertinantys verksniai. Kita vertus, jei nuoširdžiai, tai vadinamieji “klimato skeptikai” yra ne skeptikai, o nusišnekantys idiotai.

Mokslas ir faktai

• Kad CO₂ yra “šiltnamio efektą” sukeliančios dujos žinome jau daugiau nei šimtą metų
• Per tą šimtmetį žmonių išmetamų CO₂ ir kitų šiltnamio dujų kiekis išaugo daugybę kartų
• Per tą šimtmetį pačių žmonių kiekis išaugo beveik penkis kartus

Kiek suvokiu aš, paprasčiausiai nelogiška, kad žmonijos veikla pasauliui neturi įtakos. Nes, na, būkim atviri – tai, kas matosi šituose paveiksliukuose yra mūsų kaltė. Lygiai taip, kaip ir daugybė kitų dalykų. Ir skaičiavimai kiek CO₂ dalelių yra ore, bei kokį tai turi efektą klimatui, taipogi atrodo realesni, negu aklas pasakymas “viskas bus gerai”. Nebus gerai – ir geriausiai tai iliustruoja šis simuliatorius.

O dabar grįžtam prie žurnalistų pezalų…

Aš neįsivaizduoju, kaip žmogus parašęs tokį straipsnį gali save vadinti žurnalistu… Elementari paieška suranda kiekvieno pateikto pseudo-fakto paneigimą… Iš eilės:

… aštuntojo dešimtmečio pradžioje buvo skleidžiamas visiškai priešingas aiškinimas: JAV spauda mirgėjo straipsniais apie ledynmetį, kuris tuoj tuoj sustingdys visą pasaulį.

Melas. Faktas: buvo keletas mokslinių straipsnių, buvo spekuliacijų, bet nebuvo pasaulinio sutarimo, kad tai vyksta ir spauda tikrai nemirgėjo antraštėmis. Jeigu iš tiesų tai buvo kelis kartus daugiau straipsnių, kalbančių apie artėjantį atšilimą, negu apie atšalimą.

Kodėl tada taip išplito žmogaus sukelto pasaulinio atšilimo teorija? Yra nemažai manančiųjų – ir ne be pagrindo, – kad ši teorija kur kas labiau tinka spaudai, televizijai ir Holivudui.

Juokingesnio argumento nesu girdėjęs. Nors, turiu pripažinti, Kopenhagoje dabar vykstančio susitikimo įžanginis video tikrai atrodo baugiau negu Ice Age.

Kada gi žiniasklaidai nepatiko skleisti panikos?

Iš žurnalisto lūpų… Ypač, kai už poros pastraipų yra parašoma “O tai įdomu, nes kitas jų politinės evoliucijos etapas turėtų būti terorizmas.” Reductio ad Hitlerum yra geriausias argumentas bet kuriame ginče.

Daugiau kaip 30 tūkst. mokslininkų viešai pareiškė, kad A.Gore’o paskaita – nesąmonė, ir pagrasino jam teismu.

Melas. Faktas: Al’as Gore’as renginyje dalino autografus. Į renginį prisirinko protestuotojų. Vienas iš protestuotojų suriko: “30000 žmonių ketina paduoti jį į teismą”. Jokios naujienos apie tai Reuters. Jokios naujienos apie tai Associated Press.

Iš kur šitas mitas? Prieš dešimt metų kažkas, kas buvo suinteresuotas, sugalvojo peticiją, kad paneigtų, kad klimato kaita egzistuoja. Ją pasirašė 30 tūkst. žmonių. Dalis iš jų (mažiau nei penkiasdešimt…) buvo meteorologai ir klimatologai. Tačiau didžioji dalis – mokslininkai, kurie neužsiima tyrimais toje srityje. Dalis tų mokslininkų išvis neegzistuoja, dalis vardų ant peticijos buvo be pavardžių. Sluoksniai, kuriems tokia peticija buvo naudinga, išpūtė iš to burbulą, ir nepaisant to, kad ši informacija buvo paneigta šimtus kartų, jis vis grįžta ir grįžta…

Įdomus faktas: tabako industrija naudojo lygiai tokią pačią metodiką, bandydami paneigti, kad rūkymas nesukelia vėžio.

Kova su pasauliniu atšilimu, galima sakyti, virto pramone, kurioje pluša ne viena dešimtis tūkstančių žmonių. Juk nė vienas jų nenori prarasti darbo.

Geras argumentas, mat mosklininkai praras pinigų truputį. O kiek pinigų sukasi naftos pramonėje ir kiek yra suinteresuotų pusių, kad problema būtų ignoruojama trumpalaikiam pelnui užtikrinti?

Jeigu dėl klimato kaitos pakils vandens lygis, savo būstą praras apie 20 milijonų Bangladešo gyventojų, o Maldyvų salų išvis neliks.

Tačiau šie mokslininkai taip pat primena, jog mūsų planetos klimatas keitėsi per visą jos egzistavimo laiką, ir ne vieną kartą taip radikaliai, kad beveik lėmė gyvybės išnykimą.

Po šios pastraipos “žurnalistas” kalba apie tai, kad ginčas yra labiau apie tai, “kodėl” keičiasi klimatas. Per paskutinius kelis mėnesius perskaičiau kalną argumentų, kurie skamba maždaug taip:

• Viduramžiais buvo šilčiau – taip, bet tik Europoje ir kai kur Azijoje.
• Marse temperatūra irgi kyla – taip, bet tik Marse. Kituose Saulės sistemos kūnuose – ne.
• Grenlandija prieš 1000 metų buvo iš tikro žalia – absurdas – negana to, kad Grenlandija toli gražu nėra “pasaulis”, bet tokio ledo kiekio susiformavimui reikia tūkstantmečių.
• Tai natūralus ciklinis fenomenas – ir tie ciklai atsispindi temperatūros augime.
• CO₂ kiekis kyla dėl ugnikalnių – taip, bet ugnikalniai taip pat išmeta pelenus, kurie užstoja Saulę ir dėl to pasaulis šąla, o ne šyla. Tikėkimės, kad Vezuvijus vėl užsidegs, ir būsim išgelbėti nuo atšilimo!

Galų gale, o koks skirtumas kodėl? Prisitaikyti prie naujų sąlygų reikia šiandien. Taip – prieš tūkstančius metų buvo ledynmečiai. Prieš milijonus metų išnyko dinozaurai. Ar dėl to verta ignoruoti tai, ką patys prišikome (atleiskit už mano netobulą prancūzų kalbą)? Ar dėl to turime išnykti kaip eilinė gyvūnijos rūšis?

Ir dar truputis…

Mes išrausėme žemę. Išdeginome miškus. Priteršėme vandenynus. Gal jau laikas bent truputį susiimti ir apsikuopti? Aš neabejoju, kad mūsų išmetamosios dujos skatina šiltnamio efektą. Kas bus, jeigu iš tiesų prie to dar prisidės saulės aktyvumas? Natūralūs pokyčiai? Kiek žmonių turi pradėti auginti bananus maistui arba mirti iš bado, kad pagaliau atsibustume ir pažvelgtume į savo godumą? Ir kada žurnalistai pradės tikrinti faktus?

Šiame blogo įraše susidėjau tai, ką pasižymėjau pats sau beklausydamas kalbėtojų. Pačių kalbų tikrai neketinu aprašinėti – tai puikiai padarė Ajaxian (nuorodas pateikiu), o skaidrės taipogi prieinamos viešai.

Jeigu kažkuris punktas sudomino – palikit komentarą – išplėsiu!

Christian Heilmann – Frontloaded and zipped up – do loose types sink ships

Ajaxian santrauka; skaidrės; garso įrašas.

• Apie “AJAX” programuotojus kalbama žymiai pagarbiau negu apie “JavaScript” programuotojus. Abydna, vienok.
• JS nėra programavimo kalba skirta kiekvienam – ir ne kiekvienas save vadinantis “tinklo kūrėju” turėtu ja užsiimti.
• JS egzistavo gerokai prieš jQuery.
• Naudojant JS kalbą, reikėtų ją naudoti taip, kaip ji buvo suplanuota – gana kurti įvairias abstrakcijas pagal tradicinius OO modelius. JS turi savo stilių – privalu jį išnaudoti ir įsisavinti.
• Saugumo skylės (XSS, XSRF ir t.t.) yra server-side problema – JS dažniausiai yra nekaltas (nors ir išnaudojamas)
• Nepamiršti: http-only sausainiukai sesijoms
• Bet kuris API yra iš esmės saugumo skylė – Firefox greičiausiai yra pati nesaugiausia naršyklė būtent dėl savo plėtinių architektūros. Priminė kažkieno sakinį, kad mash-up’ai yra XSS atakos prieš save patį.
• Išbandyti: dažnos ir paprastos apklausėlės kaip mokymosi metodas komandoje
• Pasidomėti: adsafe.org saugumo rekomendacijos
• Pasidomėti: Google Caja (yra informacijos ir YDN)
  • Kas per saugumo skylė IE su radio mygtukais?
  • Kodėl clearfix nevartotinas pagal Caja?
  • Kodėl tiek daug CSS apribojimų?
• javascript:void(0) turi mirti (žiauria ir negarbina mirtimi)!
• John Resig yra, lyg ir, pažadėjęs, kad jeigu pakankamai žmonių to reikalaus – jQuery pritaikys Caja rekomendacijas
• Pasidomėti: ar įmanoma padaryti YQL injection?
• Pasidomėti: jau egzistuoja OAuth implementacija vien su JS

Robert Nyman – JavaScript: from birth to closure

Ajaxian santrauka; skaidrės.

• Kas čia per įprotis, tikrinti ar dižiąjame ekrane bėgantis Twitter srautas yra cenzūruojamas? Įdomus kultūrinis pokrypis, besivystant technologijoms…
• Nepamiršt: skaityti Dmitry Baranovskiy’o blogą
• Pasikartot: typeof kint == 'undefined' naudojimas
• Pasidomėt: Koks yra globalus this Rhino variklyje (t.y. window atitikmuo naršyklėse)?
• Pasidomėt: YAHOO Module Pattern

Peter-Paul Koch – W3C Widgets

Ajaxian santrauka; skaidrės.

• Pasidomėt: Ar Nokia N900 naršyklė yra fennec? (Atsakymas: taip)
• Mobilaus telefono naudojimas interneto naršymui yra puikus būdas pasimokyti – visos vartojiškumo pamokos gali būti pritaikytos eilinėms naršyklėms
• Ar @media kartu su iPhone’o <meta name="viewport" /> galėtų išspręsti problemą, kad user-agentai savaip interpretuoja pločius kai svetainė yra išzoominta? (Prie alaus PPK patvirtino, kad ketina tą patikrinti artimiausiu metu)
• Kai kuriuose aukšto DPI telefonuose kartais būna sunku paspausti tą vietą kurią nori – ar gali spaudimo jautrumo DPI ir ekrano DPI gali būti skirtingi?
• Nejaugi mobilūs telefonai neturi “ilgai trunkančio skripto” perspėjimų?
• Dėl greičio problemų, rekomenduojama nenaudoti iframe mobiliems telefonams skirtose svetainėse – kaip įgyventi AJAX-išką naršyklės istoriją (back/forward)?
• Dingstantis ryšys yra problema – ir online/offline įvykiai jos visiškai nepadeda spręsti
• Mobilių telefonų kešas yra ~200kb – būtina dar protingiau optimizuoti kodą
• W3C specifikacijos widgetai leidžia tik vieną HTML puslapį – potenciali problema?
• Dalintis widgetais per Bluetooth yra pavojinga
• Animacijos efektai mobiliuose telefonuose veikia lėtai. Iš patirties – ne viskas taip jau blogai, bet optimizuoti ir apskritai elgtis protingai privalu

Stuart Langridge – New things that HTML5 provides to JavaScript hackers

Ajaxian santrauka

• Pasidomėti: underscore.js
• Internetas jau nebėra “programų rašymo platforma”. Tavo svetainė gali būti ta platforma, jeigu atidarysi savo API. Ir net jeigu neatidarysi – yra GreaseMonkey. Reikia tam būti pasiruošus!
• Idėja: naršyklių gamintojai, galėtų turėti standartinį būdą palaikymo tikrinimui, t.y. jeigu tu rašai savo kodą laikydamasis progressive enhancement principo, kartais turi paprastus būdus patikrinti, ar kažkas veiks – o kartais ne (pvz. Operos <event-source/>). O galėtų būti kas nors paprasto, pvz. window.navigator.supports("event-source");

Todd Kloots – More accessible user interfaces with ARIA

Ajaxian santrauka, video įrašas ta pačia tema iš YUI konferencijos

• Idėja: YUI3 šiuo moment palaiko ARIA pridėdami roles ir atributus elementams, su kuriais dirba, pvz. sukuriant YUI meniu JS, susiiję elementai yra teisingai pažymimi. Ar neturėtų viskas būti atvirkščiai? T.y. rolės ir atributai nustatomi tiesiai HTML dar serveryje, o YUI (ar kita biblioteka) inicializuojasi jau naudodami tas roles.
• Toddas kalbėjo apie tai, kaip galima “uždėti ARIA sluoksnį savo sistemoje”. Bet argi nebūtų paprasčiau laikytis “ARIA palaikymo” kaip pagrindinio principo, t.y. tai yra kažkas tokio, ką tiesiog darai natūraliai, negu tai, ką darai pabaigoje, ant viršaus? Lygiai taip, kaip kažkada reikėjo pakeisti mastymą rašant HTML ir CSS, bei išmokti naudoti progressive enhancement, o ne graceful degradation.
• YUI2 palaiko “event delegation“? Čia nuo kada? (Atsakymas: pasirodo, nuo YUI 2.8 – pamiršęs buvau… “event delegation” valdo!)
• Žmonės su normaliu regėjimu, turbūt savo protiniuose modeliuose (kaip išversti mental model?) turbūt be problemų priima, kad meniu dažnai eina iš kairės į dešinę. Kaip tai suvokia aklieji? T.y. kaip jų modeliai susitvarko su tuo, kad meniu navigacija vykdoma “kairė/dešinė” mygtukais, o ne “viršus/apačia”, kai naudojamos ekrano skaityklės?
• Pasidomėti: ar ARIA turi kokį nors “fokusuotos grupės” apibrėžimą, o ne vien tik “fokusuoto elemento”?
• Pasidomėti: accessibility šiuo metu dažniausiai siejasi su pele ir klaviatūra, kaip įvesties įrenginiais – kokie modeliai naudojami kitiems įrenginiams?
• Pasidomėti: ką HTML5 specifikacija sako apie <section/> web application kontekste?
• Pasidomėti: klaviatūros greitųjų klavišų atrandamumas lankytojams su normalia rega

Jake Archibald – Optimising where it hurts

Ajaxian santrauka; tyrimas ir skaidrės

• Ar jis čia skaidres varto su savo WII kontroleriu? Geras!
• Niekada nenaudoti eval(), ypač closure viduje – tai iš esmės nužudo visas JS variklių (V8, TraceMonkey ir t.t.) optimizacijas, nes eval() gali nesunkiai pakeisti kintamųjų aprėptį (kaip išversti scope?)
• Nenaudoti closure per dideliam gyliui, jeigu galima to išvengti
• Niekada nenaudoti eilučių sujungimo, kai jos rašomos į innerHTML, t.y. ne el.innerHTML="<div>"+kint+"</div>", o var s="<div>"+kint+"</div>"; el.innerHTML=s;
• Vengti window.onunload naudojimo, nes nužudomas kešinimas (jQuery jau turi šią problemą – bet ketina išspręsti)
• Švarus ir paprastas HTML, neturintis bereikalingų tagų, pats savaime paspartina selektorių darbą (nes reikia perfiltruoti mažesnį kiekį elementų). Žodžiu, rašyti didelį kiekį nesemantinio HTML (ar tai būtų nereikalingi div, ar table) yra blogai!
• Kiekvienas turėtų pasimokyti pats rašyti vykdymo greičio testus (tik reikia nepamiršti apie “16ms problemą JS”)
• “Optimizuok ten kur skauda” iš tikro tereiškia “nebūk durnas” – visos diskusijos, apie tai kuris ciklas optimalesnis (for prieš while) yra bevertės (nes sutaupo 0.002 milisekundės). Iš tikro reikia izoliuoti tą dalį, kuri veikia lėčiausiai, ir tvarkyti būtent ją. Vargti stengiantis rašyti “teisingą kodą” iš anksto yra beprasmiška – žinot istoriją su “priešlaikine optimizacija”, ar ne?

Simon Willison – Beating server side engineers in their own game

Ajaxian santrauka; autoriaus santrauka

• Pasidomėti plačiau apie E4X
• Mac’ų vartotojai elgiasi… kitaip. Tiesiog kitaip ir tiek.
• Ar eitų NodeJS panaudoti kaip unit testų konsolę? Integruoti į continuous build’us?
• JS nėra “strongly typed” kalba – tai natūraliai yra sunkiau dirbant komandoje. Pasidomėti: kaip tai galima spręsti
• NodeJS ir CouchDB yra labai labai seksi! Kiekvienas turėtų pasidomėti kaip jie veikia, kaip optimizuoja procesus ir kokiais principais yra paremti!

Vieną dieną sužinojo, kad kai kurie butai būna neužrakinti. Gal dėl savininkų žioplumo, gal dėl to, kad pametė raktus – nesvarbu kodėl.

Nuėjo bomžas į laiptinę ir pradėjo tikrinti duris. Na ir rado atrakintas. Įėjo į vidų ir šiltai sau miega.

Juk tai nėra įsibrovimas į svetimą valdą, nes nu juk bomžui šalta. Ir tai nėra neteisėta, nes nu juk žalos tai jis nepadarė – išsimiegojo, neprišiko, išėjo. Butas vietoje, visi daiktai vietoje. Vagystės nėra. Žalos lyg irgi nėra.

Anglijoje, gi, žmonės, sakoma, daug uždirba. Todėl pas juos bomžai geriau gyvena. Prisirenka daugiau išmaldos, todėl gali miegoti nakvynės namuose. Todėl Lietuvoje bomžai tiesiog turi teisę eiti į svetimus namus ir ten miegoti.

Ir apskritai, bomžai turėtų įsteigti bomžų partiją, ir kovoti už teisę, kad visi žmonės paliktų duris atrakintas, kad jie galėtų ateiti ir miegoti kada nori. Nes na juk ne įsibrovimas į svetimą valdą ir visi turėtų turėt teisę miegoti svetimuose butuose.

Apie tai šiandien ir papasakosiu.

Pigumas

Kartais kuriant prototipą norisi perteikti kuo daugiau jo smulkmenų, o tai reikalauja investicijų. Automobilių gamintojai pastoviai išleidžia koncepcinius modelius, kurie iš tikro neveikia, nepaisant to, kad atrodo gražiai ir beveik išbaigtai. Tas poliravimas yra labai brangus, o rezultatą vistiek tenka išmesti. Eskizai, tuo tarpu, privalo tik perteikti idėją. Jeigu laikytis senos geros Pareto taisyklės, tai sukurti 80% produkto, užtenka 20% pastangų. Eskizai yra milžiniški žingsniai link produkto, už praktiškai nulį pastangų.

Ši savybė labai padeda vienam iš sėkmės principų – klysk dažnai ir klysk anksti. Išmetant pigiai kainavusias klaidas širdies per daug neskauda.

Neišbaigtumas

Nepaisant to, kad darant greitą “tep lep” darbą rezultatas niekada nebus patenkinamas, kuriant eskizus privalu išlaikyti tą stilių priverstinai. Netiesios linijos, nesulygiuotas tekstas ir mygtukai, jokių specialiųjų efektų – visa tai tiesiog šaukia “aš tik noriu sužadinti tavo vaizduotę“. Juk vieną kartą pamačius, geriau negu šimtą kartų išgirdus – tiek vidiniai, tiek išoriniai klientai idėjas priima lengviau, kai į jas gali pažiūrėti. Eskizai sumažina jų lūkesčius – kuriant prototipą dažnai per daug dėmesio skiriama detalėms. Pristatant eskizą, daug lengviau nuteikti žmogų, priimantį sprendimus, kad tai toli gražu nėra produktas, o tiesiog “dokumentuota idėja”.

Diskusija

Jeigu cituoti Billą Buxtoną, tai viena iš eskizo paskirčių yra užduoti klausimus, kai tuo tarpu prototipo – juos atsakyti. Iš šitos dalies, labai svarbu pasiimti tai, kad net drebančia ranka nupieštą eskizą galima panaudoti vartojiškumo testams – ar produktas juda tinkama linkme? Ar tenkina vartotojo poreikius ir padeda siekti tikslų? Ar aišku, kas įvyks paspaudus vieną ar kitą nuorodą? Greitas, paprastas bandymas taipogi padeda įvertinti ir galimas kliūtis ateityje.

Kaip programuotojas, turiu didelį aplanką mažų failų, kuriuose tėra po 10 eilučių kodo tam, kad tiesiog patikrinti ar įmanoma, kad paprastos idėjos tiesiog veiktų (su visomis naršyklėmis) – tiek hasFocus/activeElement, tiek horizontalaus centravimo sprendimai gimė būtent iš to.

Aukštesniame Метод научного тыка galioja bet kokiam darbui – įskaitant ir user interaction dizainą!

Dokumentacija

O dabar gali pasirodyti, kad prieštarauju pats sau. Nepaisant to, kad eskizai yra pigūs, jų nevalia išmesti. Vykdant projektą, svarbu turėti juos kaip istorinius duomenis – jeigu kartojimas yra mokslų motina, tai būtent žiūrint į savo klaidas ir pasikartojant kokios jos buvo, galima iš jų mokytis. Užrašai, anotacijos, atsiliepimai ir vertinimai – visą šią informaciją privalu išsaugoti ateičiai (dabar gali dar kartą pasirodyti, kad prieštarauju pats sau), nes ilgesniu laikotarpiu, viena iš eskizų paskirčių yra būtent nutraukti diskusijas, t.y. kiekvienas eskizo užduotas klausimas, ir kiekviena pateikta idėja turi būti atsakyta prieš pradedant tikrąjį darbą, kad išvengti bereikalingo laiko švaistymo grįžtant prie jau patikrintų problemų.

Kas iš viso to? Ech… Prieš porą savaičių pats pačiulbėjau, kad abstraktūs dalykai patys savaime neturi prasmės. Reiškias ateina įrašas, su daugiau prasmės. Продолжение следует…

PS žodis “vartojiškumas” yra tik eskizas. Vienas iš kelių variantų. Gal reiktų “š” pakeisti į “ž”, kad atrodytų neišbaigčiau? Imu jį į praktiką, žiūrėsim kas gausis – kiek galima apie tai vien galvoti ar kalbėti.

function isNumberKey(evt)
{
     var charCode = (evt.which) ? evt.which : event.keyCode
     if (charCode > 31 && (charCode < 48 || charCode > 57))
        return false;

     return true;
}

Ši funkcija naudojama kaip onkeypress event handler. Ką ji daro iš tikro? Kai įvesties lauke paspaudžiamas klavišas, kuris nėra skaičius, ir nėra vienas iš kontrolinių klavišų (Enter, Backspace ir tt), klavišo paspaudimas yra sustabdomas ir ignoruojamas. Konkrečiu atveju, man reikėjo įvesti svetainėje savo 8 skaitmenų prisijungimo kodą, na ir lyg būtų logiška, kad man nereikia spausti kitų klavišų, tik skaičius, ir po to Tab, kad įvesti slaptažodį. Netiesa!

Visiškai galima kombinacija, kurią galiu įvesti yra Ctrl+V. Nes paprasčiausiai naudojuosi konkrečia svetaine kartą per metus, todėl prisijungimo vardą, kuris yra generuojamas automatiškai, galiu surasti tik el. pašto archyve. Ar tai veiks? Be abejo ne (išskyrus Chrome – nesigilinau kodėl), nes tokio paspaudimo atveju charCode bus lygus 118, t.y. “v” raidės ASCII kodas, ir mano Paste veiksmas bus sustabdytas.

Patarimas: leisk vartotojui elgtis kaip jis įpratęs

Galima, be abejo sakyti, kad prisijungimo formoje tokia validacija išvis nereikalinga, nes įvedus neteisingą vartotojo vardą (pvz. ' OR ''='), prisijungti tiesiog nepavyks, su pranešimu “Neteisingas vartotojo vardas ir/arba slaptažodis”. Tačiau lygiai taip pat galima teigti, kad siekiama vartotoją apsaugoti nuo to klaidos pranešimo, arba, kad toks validacijos veikimas kai kuriais atvejais gali būti pageidautinas. Netiesa!

Patarimas: nepasikliauk naršyklės API

Javascript palaikymas interneto naršyklėse yra labai ribotas. Jis negali suteikti standartinių OS galimybių, kaip pvz. garsinis signalas paspaudus netinkamą klavišą. Negana to, konkrečioje formoje nėra suteikiama jokių užuominų, kad “leidžiama įvesti tik skaičius” (tuo atveju galima būtų tiesiog keikti programuotoją, už neteisingą vykdymą). Tačiau net jeigu viso to implementacija būtų teisinga, o puslapis pateiktų visas užuominas apie tai, ką galima daryti ir ko negalima, vistiek aš pasisakyčiau prieš tokį dalyką, ir ne vien tik todėl, kad Nokia telefonai neteisingai perduoda keyCode.

Dar vienas pavyzdys būtų validacijos vykdymas, kai nuspaudžiamas Enter klavišas – ši problema mane nervuoja pragare, kuris vadinamas o2.ie kasdien. Kodėl? Ogi tiek Firefox, tiek Chrome (su Opera svetainė neveikia išvis) autocomplete pasirinkus reikšmę, ir paspaudus Enter, įvykis perduodamas į Javascript, todėl pasirinkęs iš sąrašo savo telefoną, gaunu malonų pranešimą, kad neįvedžiau slaptažodžio, nors dar net nespėjau prieiti iki to žingsnio!

Patarimas: nedėk apribojimų ten, kur jie visiškai nereikalingi

Problema slypi tame, kad ribojama mano veiksmų laisvė. Neverta to daryti. Štai pvz. textarea elementas neturi maxlength atributo – galima to palaikymą sukurti su JS, bet daug geresnis variantas yra tiesiog parodyti kiek yra likę galimų įvesti simbolių, o klaidos pranešimą rodyti tik tada, kai klaida yra tikrai padaryta. Įsivaizduokite, jei Twitter neleistų įvesti daugiau negu 140 simbolių ir nesuteiktų galimybės redaguoti tekstą tol, kol jis telpa į juos.

Lygiai taip ir šiuo validacijos atveju, derėtų leisti vartotojui spausti tuos klavišus, kuriuos jis nori spausti, o įvestus duomenis tikrinti tik tada, kai vartotojas pasako “taip, aš žinau, kad noriu tokius duomenis išsiųsti”, t.y. onsubmit įvykio metu, arba tiesiog server-side.

Antraščių problema HTML 4.01

HTML4 specifikacija apie h? antraštes kalba gana abstrakčiai. Jų esmė – pristatyti toliau einačios dokumento dalies turinį. Paminėta, kad h1 yra svarbiau negu h6, taipogi, kad iš to galima sukurti dokumento “apžvalgą” ar “turinio rodyklę”. Dar rašoma, kad “kai kurie žmonės” laiko, kad “peršokti” lygius (t.y. h1 h3 h5) yra neteisinga, tačiau neteikia jokių rekomendacijų šiuo klausimu.

Be jau paminėto komentaro pačioje specifikacijoje, toks aprašymas palieka begalybę kitų klausimų, kad ir pvz. kiek puslapyje gali būti h1 žymų? Kaip atskirti skirtingą jų kontekstą? Viena iš SEO strategijų (kol robotai nebuvo to išmokę pažinti), buvo sukišti vos ne visą puslapio turinį į h1, taip raktažodžiams suteikiant papildomą vertę. Kita problema buvo, kad ir tai, kad pvz. dokumento skiltis skirta navigacijai (blog’o sidebar) taipogi buvo suskirstyta į dalis – tokiu atveju norėtųsi atskirti, kad sidebar poskyriai (pažymėti h3) nėra vienos iš įrašo pastraipų (pažymėtų h2) dalis.

Interpretacija: h1 yra svarbiausias ir vienintelis

Negana to, mano asmeniniu požiūriu, puslapyje derėtų derėjo naudoti tik vieną h1 tipo elementą (WCAG rekomendacija) – tą, kuris daugiau mažiau sutaptų su puslapio pavadinimu, nurodytu title. Taigi titulinis eilinio blog’o puslapis atrodytų maždaug taip:

• h1: blog’o pavadinimas
  • h2: navigacija
    • h3: sidebar skiltis
    • h3: sidebar skiltis
  • h2: įrašas
    • h3: įrašo pastraipa
    • h3: įrašo pastraipa
  • h2: įrašas
    • h3: įrašo pastraipa
    • h3: įrašo pastraipa

Ką daryti kai antraštės “šokinėja”?

Aukštesnis suskirstymas tinka tik pirmąjam puslapiui. Jeigu kalbame apie individualaus įrašo puslapio sužymėjimą, tai situacija lyg ir keistųsi – blog’o pavadinimas jau nebėra h1 svarbos, nes svarbiausia antraštė tokiu atveju yra įrašo pavadinimas! Įrašo pastraipos taipogi turėtų kylti lygiu aukščiau – iki h2. Kas tokiu atveju atsitinka su sidebar skiltimis? Nežinau.

Taip iki galo ir neišsprendžiau tos problemos, nors ir labai norėjosi. Viena iš minčių buvo išvis atsisakyti pašalinės navigacijos. Lankytojų tai per daug nenuskriaustų – pagal mano duomenis didžioji dalis lankytojų iš Google patekę tiesiai į konkretų įrašą arba tiesiog išeidavo (aš gal rašyt nemoku?), arba po to keliaudavo į titulinį puslapį (o gal vistik moku?), o ne tiesiogiai į kitus įrašus.

HTML5 dokumento skilčių apibrėžimai į pagalbą!

Nepaisant to, kad iš aukščiau apibrėžtos problemos grafomanas išspaustų tris įrašus, o internetas pilnas nesibaigiančių diskusijų, man tai nebėra aktualu! HTML5 apibrėžia dokumento skiltis – joms sužymėti galima naudoti section, nav ir article elementus (aside taipogi laikoma atskiru, susijusiu poskyriu). Visi šie elementai gali turėti savo antraštes ir paraštes (header ir footer). Tokiu atveju, kiekviena antraštė įgauna savo individualų kontekstą (body viduje esanti antraštė aprašo puslapį, gi tuo tarpu article viduje – tik tą įrašą) ir savo individualią hierarchiją.

Nepaisant to, kad specifikacijoje gana daug teksto yra skiriama rodyklės (outline) formavimo algoritmui, paprastam blog’ui, o turbūt ir daugeliui kitų svetainių, tai yra neaktualu, nes antraščių hierarchija visada gaunasi elementari – praktiškai bet kurios dokumento dalies antraštės apsirašo tiesiog <header><h1> pavadinimas </h1></header>, t.y. h1 šiuo atveju nebereiškia tiesiog “svarbiausia antraštė”, o interpretuotina kaip “svarbiausia antraštė šioje dokumento dalyje”. Naudojant tokią logiką, individualus įrašo puslapis jau nebeturi kitokio globalaus antraščių lygmenų išsidėstymo, nei sąrašuose – dabar aš drąsiai galiu savo įrašų poskilčius žymėti tiesiog h2.

Desertas

• HTML5 neberiboja antraščių gilumo (anksčiau buvo maks. 6) – nors ir nelabai žinau kam to gali prireikti
• hgroup elementas leidžia grupuoti antraštes su paantraštėm, kaip pvz. aš esu padaręs su blog’o pavadinimu – View source naudoti mokat?
• ARIA banner rolė leidžia atskirti “svetainės” ir “dokumento” pavadinimus – apie ARIA apskritai dar reiktų daugiau man pasiskaityti…

Papildomas skaitymas

• Introducing the <hgroup> element
• Headings in HTML 5 and accessibility
• More than one H1 on a page: good or bad?

PS neturiu laiko ieškoti, bet gal kas turit pasiūlymą, kaip WordPress priversti nedėti aside į p?

Struktūriniai elementai veikia puikiai

Naujieji elementai (header, footer, time, etc) veikia (beveik) puikiai. Nėra nei vienos rimtos priežasties, kodėl reiktų delsti su jų naudojimu. Vienintelė išimtis (kurios aš net nesistengiau išspręsti) – Firefox 2. IE šeimos naršyklės taipogi nenori pripažinti naujų žymų ir pritaikyti joms stilių, tačiau tai nesunkiai išsprendžiama Javascript pagalba. Jeigu vien Javascript sprendimas netenkina (unobtrussive, progressive enhancement, etc) – visada galima naudoti tarpinį sprendimą – naudoti naujas HTML5 žymas semantikai, o stiliams prikaišioti div‘ų.

Be viso šito, perrašydamas savo blog’o HTML, nesusidūriau su jokiom problemom, išskyrus header ir h1 semantinėm reikšmėm, bet tai yra verta atskiro įrašo. Dar turėjau šiek tiek dvejonių dėl section naudojimo, tačiau priėjau išvados, kad geriau šiandien eksperimentuoti, o rytoj padaryti teisingai – be klaidų progreso nebus.

Formos elementų tipus naudoti galima

Aš pats nenaudojau naujų formų elementų tipų (type=email, type=url), tačiau kai tik turėsiu daugiau laiko paeksperimentuoti – naudosiu ir juos. Kol kas juos palaiko tik Opera naršyklė, tačiau kitos netruks prisivyti, o tos kurios jų nepalaiko – atvaizduos laukus tiesiog kaip type=text – demo. Vėlgi – truputėlis JS šen bei ten, truputėlis CSS ir ateitis bus šiandien.

canvas, video ir audio palaikymas

Na, šitie trys žvėrys man šį savaitgalį, ir juo labiau eiliniam blog’ui, buvo visai neaktualūs, tačiau jie jau veikia bent dalyje naršyklių.

Turint omeny, kad iš dalies HTML5 yra kuriamas kaip standartas, dokumentuojantis jau egzistuojančią tinklo ir naršyklių būklę, tai canvas yra tas dalykas, kuris turi mažiausiai palaikymo problemų (neskaitant vienos, ghkhmz, naršyklės). Ajaxian vos ne kas antrą dieną paskelbią kokį nors naują demo su canvas. Super Mario žaidimas – sukurtas prieš daugiau nei metus! Aš ir pats dar užpernai naudojau vieną iš jQuery pluginų grafikų paišymui.

Su video problemos yra kur kas didesnės. Kas nors dar atsimenat, kaip prieš daug daug metų tekdavo vargti ieškant codec packų? Internete tai būtų visos “video be pluginų (skaityti: Flash)” idėjos žudikas. Safari palaiko Quick Time, Opera 10 ir Firefox – OGG Vorbis ir Theora, Chrome – OGG ir H.264, ir nei vieni, nei kiti neketina pasiduoti.

Kodekų problema yra iš esmės tai, kad dauguma jų yra uždari, apsaugoti patentų ir brangiai kainuoja. Tie, kurie yra atviri – netenkina kokybės reikalavimų (Google, kaip didžiausias video turinio teikėjas, nenori naudoti OGG, nes na interneto srautas yra brangus dalykas).

Ateitis

Kadangi XHTML2 mirė, tai HTML5 lieka vienintelis ateities standardas. Ir jis nors ir nėra tobulas, tačiau panašu, kad neketina sugriauti egzistuojančio interneto. Naršyklės pradeda jį po truputį palaikyti, tinklo kūrėjai taipogi jau turi galimybę juo naudotis. Kartais atrodo, kad jis gal ir nėra reikalingas – juk internetas veikia ir dabar, tačiau tikrasis postūmis bus tada, kai paieškos robotukai pradės labiau gerbti semantinį tinklą. Tai nutiks tik tuo atveju, jeigu HTML5 bus naudojamas jau dabar – nereikia laukti galutinės W3C rekomendacijos (juk ji bus tik tada, kai bus 2 pilnai įgyventintos realizacijos).

Šaltiniai ir tolesnis skaitymas

• HTML5 doctor
• HTML5 enabling script
• Yes, You Can Use HTML 5 Today!
• HTML5 darbo grupės blog’as