Blog Archives

Latest Posts

Monthly

Categories

All Posts in Interneto svetainių kūrimas

2011-10-11 - No Comments!

Mitas Nr. 5: pasiekiamumas yra brangus ir sunkiai įgyvendinamas

Myth #5: Accessibility is expensive and difficult straipsnio vertimas iš UX Myths (5 iš 5 išverstų)

Vertėjo komentaras – dažnai pasiekiamumas (angl. accessibility) yra suprantamas kaip ko nors pritaikymas neįgaliesiems, bet tai netiesa. Pasiekiamumas – tai ko nors pritaikymas kuo platesniam žmonių ratui. Norint padaryti svetainę pasiekiamą kuo platesniam žmonių ratui, nereikia papildomo funkcionalumo ar informacijos kartojimo. Lengviausias kelias – įtraukti skirtingų gebėjimų žmonių reikalavimus bei skirtingų įrenginių palaikymą projektuojant naują naudotojo sąsają ir kuriant informaciją.

Iš pagrindų sukurti svetainę, kuri būtų pasiekiama platesnei naudotojų auditorijai, kainuoja tiek pat, kiek ir sukurti įprastą.

Žinoma, jau egzistuojančios sistemos keitimas reikalauja papildomų išlaidų, tačiau ilgalaikėje perspektyvoje tai pelningas sprendimas – platesniam žmonių ratui pasiekiamos svetainės priežiūra yra pigesnė ir lengvesnė.

Priežastys, dėl kurių naudinga kurti svetaines pritaikytas didesnei naudotojų auditorijai

  1. Pasiekiama didesnė auditorija – Didžiojoje Britanijoje 14% žmonių kenčia nepatogumą dėl negalios.
  2. Plačiai pasiekiama svetainė turi geresnį tinkamumą (angl. usability)
  3. Plačiai pasiekiama svetainė taip pat geriau optimizuota paieškos sistemoms (angl. SEO)
  4. Kiti pasiekiamumo teikiami privalumai – mažesnis svetainės užsikrovimo laikas, skirtingų naršyklių palaikymas ir lengvas turinio valdymas.

Zoltán Kollin

2010-04-04 - No Comments!

Geresnis klaidos puslapis

Kompiuterininkai šiandien švenčia Lankomiausio puslapio diena. Jie juokauja, kad pats lankomiausias interneto puslapis – 404 klaidos puslapis. O kadangi šis puslapis yra pats populiariausias, pakalbėkime apie jo patogumą. Jau rašiau apie tai (Ups… padariau klaidą arba dar kartą apie 404), kad Lietuvos „geriausieji iš geriausiųjų“ nesinaudoja viena iš kūrybos erdvių. 404 klaidos puslapis nėra tik kūrybos erdvė. Jo pagalba galima pagerinti visos svetainės vartotojiškumo ir optimizavimo paieškos varikliams lygius. Kaip tai padaryti?

  1. Nenaudokite standartinio klaidos puslapio. Standartinis paieškos puslapis nėra naudingas ar patogus.
  2. Nenaudokite nukreipimo į kitą puslapį. Nukreipdami vartotoją į kitą puslapį (pvz. titulinį svetainės puslapį), Jūs nuvilsite vartotojo lūkesčius: jis norėjo vieno puslapio, o gavo kitą.
  3. Atsiprašykite vartotojo ir paaiškinkite jam kas įvyko. Vidutiniškas interneto vartotojas neturi žalio supratimo apie 404 klaidą, todėl nėra priežasties kodėl reikėtų puslapį užvadinti – 404 klaidos puslapis ar panašiai. Paprasčiausiai, paaiškinkite dėl kokių priežasčių jis mato kitokį puslapį ir ką reikėtų daryti, kad ateityje tai nepasikartotų.
  4. Nukreipkite vartotoją tinkamą linkmę. Vartotojas visada turi aiškiai matyti kur jis toliau gali judėti, todėl klaidos puslapyje rekomenduotina, kad be paaiškinimo dar būtų nuorodos į titulinį ir kitus populiariausius puslapius (arba tiesiog svetainės žemėlapis), paieškos laukas, pasiūlymas kur ieškoti užklaustą puslapį (pvz. Galbūt jūs norėjote apsilankyti ... ).
  5. Fiksuokite iš kur į klaidos puslapį atėjo vartotojas. Dažniausiai vartotojas į klaidos puslapį patenka neteisingas suvedęs adresą, iš paieškos puslapio, kuriame buvo neaktuali informacija, iš vidinio svetainės puslapio, kuriame buvo neteisinga nuoroda. Žinant priežastį, dėl kurios vartotojas pateko į svetainę, galima tobulinti pačią sistemą.
  6. Leiskite vartotojui išsakyti ką jis galvoja. Taip, taip, taip... Jei fiksuojate iš kur į klaidos puslapį atėjo vartotojas, jūs ir taip žinosite, kad pvz. kažkurį nuoroda veda į neegzistuojantį puslapį. Bet tegul vartotojas vistiek išsako, ką galvoja (nesvarbu ar tai bus pyktis ar pranešimas, kad neveikia nuoroda). Bent vienas iš 1000 tikrai parašys naudingą patarimą.
  7. Nepersistenkite su puslapio dizainu. Vartotojas atėjęs į klaidos puslapį ir taip atsiduria savotiškoje stresinėje situacijoje. Vartotojui turi būti aiškiai suprantama, kad jis atsidūrė norimoje svetainėje, tik dėl kažkokios priežasties norimo puslapio joje nėra. Nevadinkite vartotojo kvailiu ar kitaip nežeminkite joje.

Ar žinote, kad...
Šiandien, 2010 m. balandžio 4 d., visas krikščioniškas pasaulis švenčia Velykas. Bet mažai kas žino, jog šiandien šv. Izidoriaus iš Sivilijos – interneto šventojo globėjo (kitais duomenimis, oficialaus patvirtinimo dar nėra, – žr. vydija.lt) – diena. Galbūt oficialaus patvirtinimo ir nėra, bet, mano manymu, ši diena ir šis šventasis labai tinkami.

Naudingos nuorodos

2010-03-04 - No Comments!

Apsaugos nuo reklamos būdai (II dalis)

Kadangi mano subjektyvia nuomone, captcha kodų naudojimas mažina naudojimosi svetainę patogumą, tęsiu galimus būdus išvengti reklamos ar flood problemas.

Alternatyvus medaus puodynių (angl. honeypot) metodas. Robotai dažniausiai stengiasi užpildyti visus rastus formos laukus. Norint apsisaugoti, yra sukuriamas žmonėms nematomas laukas su populiariu pavadinimu (pvz. email). Jei vykdant submit veiksmą, šis laukas bus užpildytas, reiškia rašo robotas ir šį veiksmą praleisti negalima. Minusas - neapsaugo nuo specialiai svetainei pritaikytų robotų.

Minimalus formos užpildymo laikas. Robotai užpildo formas žymiai greičiau nei tai padaro žmogus, todėl priklausomai nuo formos sunkumo galima nustatyti minimalų formos užpildymui skirtą laiką. T.y. jei forma siūnčiama į serverį greičiau nei nustatytas laikas, reiškia didelė tikimybė, kad tai daro robotas. Minusai: neapsaugo nuo specialiai svetainei pritaikytų robotų, nepraleis vartotojus, kurie naudoja auto-complete įrankius.

Kodo obfuskacija arba šifravimas. Baisus žodis obfuskacija (angl. Obfuscated code) reiškia kodo apsunkinimas, norint pvz. sumažinti jo analizės galimybės. Apsaugos esmė -  kodo skanavimo apsunkinimas,  šifruojant arba taikant obfuskacijos metodą. T.y. jei robotas neras formos kodo, reiškia, jis negalės užpildyti formos ir nusiųsti jos į serverį su įrašytais duomenimis. Kita vertus, vartotojai net nepastebės, kad kodas yra šifruotas. Minusai: kodas veikia šiek tiek liečiau.

Blokavimas pagal user-agent atributą. Dažnai robotai naudoja specifinius user-agent atributus, todėl galima blokuoti visus lankytojus turinčius netinkamą arba nenurodytą user-agent parametrą. Minusas: robotai dažnai naudoja naršyklių parametrus.

Dinaminis formos kūrimas. Metodo esmė - dinaminis formos sukūrimas Javascript pagalba. Veiksmingas metodas prieš daugelį robotų, nes javascript palaikymas reikalauja didesnių resursų sąnaudų. Minusas: vis dar pasitaiko lankytojų, kurių naršyklės nepalaiko Javascript, tačiau tokių lankytojų labai ir labai mažai, todėl jiems galima panaudoti <noscript> HTML atributą.

Pagalbinių servisų naudojimas. Galima naudoti 3 šalių apsaugos nuo reklamos paslauga, pvz. Akismet.

Papildomas klausimas gimtąją kalbą. Kaip bebūtų, o lietuviškai kalbančių robotų yra pakankamai mažai (jei išvis yra), todėl apsaugai nuo botų galima panaudoti papildomą klausimą. Šis metodas ypač tinka mažoms bendruomenėms. Pvz. jau apie metus nesulaukiu reklamos forume, nes į paprastą klausimą „Du plius du?“ vis dar nesulaukiau roboto atsakymo ;) Minusas: labai lengva įveikti, jei į boto pagalbą ateina žmogus.

Hibrindinis metodas. Galima panaudoti vieną iš išvardintų viršuje metodų. Ir jei dėl kažkokių priežaščių vartotojui nepavyko jo praeiti, pasiūlyti kaip alternatyvą visų mėgstamą ir mylimą Captcha.

Pastebėjimai

  • Nei vienas iš išvardintų metodų nėra nepriekaištingas ir neapsaugos nuo nukreiptos reklamos ar flood atakos, tačiau nuo 90-99 proc., o Lietuvos atveju dar didesniu procentu, apsaugos nuo kvailų robotų-vorų.
  • Įraše paminėjau tik įdėjas. Skirtingus įgyvendimus galima aptarti komentaruose.
  • Galima naudoti iškart keletą iš išvardintų metodų.

Kokius metodus dar praleidau? Captcha nesiūlyti! :)

2010-03-03 - 3 comments

Apsaugos nuo reklamos būdai

Egzistuoja daug būdu kaip svetainės lankytojo neįtraukti į kovą tarp robotų ir sistemos programuotojų. Šiandien pabandysiu apžvelgti, mano manymu, geriausius. Prieš aprašant kiekvieną algoritmą ar apsaugos būdą atskirai, norėčiau dar kartą pažymėti, kad kiekvienas algoritmas turi savo minusų, tačiau visi žemiau išvardinti algoritmai turi vieną savybę - jie palengvina lankytojo dalią. Be to, vėlgi pasikartosiu, manau, kad nereikia bandyti atpažinti ar lankytojas yra robotas ar žmogus, o kovoti su tam tikrais nepageidautinais veiksmais (pvz. reklamos skleidimas). Svarbu ne kas daro, o ką daro.

Pvz. kam reikalingas Captcha kodas registracijos metu?  Tegul robotas užsiregistruoja, bet, jei jis neturės normalios galimybės parašyti komentarą, jis nepadarys didelės žalos, o po tam tikro laiko bus ištrintas dėl neaktyvumo.

Be abejo, kovoti galima keliais frontais - neleisti robotams rašyti, registruotis kol nebus įrodyta, kad rašo žmogus bei atlikti tam tikrų veiksmų prevenciją (pvz. reklamos skleidimas), bet turėtų visiems būti aiškus vienas faktas - lankytojo geriausia neįtraukti į šią kovą.

Pirmasis būdas yra Bajeso teoremos naudojimas. Bajeso filtrai gali savarankiškai, nedaug nusileisdami žmogaus sugebėjimams, atpažinti „blogą“ žinutę. Šį metodą kartais naudoja elektroninio pašto žinučių šlamšto (angl. spam) filtrams sukurti. Metodas yra pakankamai geras, tačiau reikalauja pakankamai didelio įdirbio. Vikipedijos skelbia, kad po mokymo ir didelio įdirbio pasiseka atrinkti iki 95 –97 proc. spamo.

Blokavimas pagal žodį ar jo kaukę - internetinės cenzūros mechanizmas kaip blokuojami tam tikri pranešimai turintys nepageidaujamų žodžių. Šis metodas dažnai nepasiteisina (žr. Scunthorpe problem) kai yra naudojamas vienas, tačiau jo panaudojimais kartu su kitais metodais gali atnešti pakankamai gerų rezultatų.

UPD: Atsiprašau, netyčia paskelbiau viešai šį įrašą, nors jis nebuvo iki galo pabaigtas. Šiek tiek vėliau pratęsiu apie galimus alternatyvius Captcha kodams apsaugos nuo reklamos ir fludo būdus. Laukite pratęsimo ;)

2010-02-28 - No Comments!

12 patarimų e. parduotuvės kūrėjams

Mano galvoje kaip visada chaosas. Todėl šiame įraše pabandysiu į vieną surinkti visus techninius pamąstymus apie e. parduotuvės kūrimą. Manau, tai bus naudinga ir man ir jums.

  1. Išsaugokite į cache (atsiprašau kalbininkų, tačiau man sąžinė neleidžia naudoti žodį podėlis) viską ką tik galite: prekių aprašymų puslapius, paieškos rezultatus, prekių krepšelius ir t. t. ir panašiai. Tai padės sumažinti duomenų bazės apkrovimą bei pagreitins sistemos veikimą.
  2. Sumažinkite užklausų į duomenų bazę skaičių.
  3. Naudokite saugomas procedūras (angl. stored procedures). Duomenų bazė tampa izoliuota nuo besikeičiančių verslo taisyklių. Be to, šių procedūrų naudojimas stimuliuoja pakartotinį procedūros naudojimą bei modulumą (angl. modularity). O taip, leidžia padidinti duomenų bazės saugumą. Plačiau: MySQL 5.0 New Features: Stored Procedures.
  4. Išskirkite e. parduotuvę į du skirtingus serverius: viename sistema, kitame - duomenų bazė.
  5. Darykite atsargines kopijas. Banalu, bet patirtis rodo, kad apie atsarginių kopijų darymą kūrėjai pamiršta.
  6. Tikrinkite formas:
    • vartotojui privaloma pasakyti, kad jis kažką padarė blogai;
    • visi užpildyti  laukai po patikrinimo privalo likti užpildyti;
    • peržiūrėkite ar nėra SQL injekcijų.
  7. Apgalvokite veiksmus nulužus serveriui ar užpuolus programišiams (taip pat žinomi kaip hakeriai).
  8. Naudokite SSL sertifikatą tik atsiskaitymų ir kitiems puslapiams, kur reikalingas padidintas saugumo lygis. Kodėl? Tyrimai rodo, kad SSL naudojimas visoje sistemoje padidina kreipimųsi į serverį skaičių, bet nesuteikia papildomos naudos. Be to, gali kilti problemų su Google Analytics.
  9. Pasistenkite nenaudoti ar sumažinti sesijos unikalaus parametro (SSID) naudojimą formuojant svetainės adresą. Šis parametras teršia svetainės adresą, bet nesuteikia kažkokios aiškios naudos. Iškyrus atvejus, kai reikia išsaugoti prekių krepšelio turinį.
  10. Paruoškite e. parduotuvę analizei. Neužtenka į kodą įdėti Google Analytics kodo gabaliuką, pati svetainė turi būti paruošta šio įrankio naudojimui. Plačiau: How to Use Ecommerce Tracking in Google Analytics.
  11. Sudarykite prielaidas standartizuotam turiniui. Plačiau: Canonicalization Defined.
  12. Rašykite dokumentaciją:
    • kitiems programuotojams - žinau, kad programuotojai nekenčia rašyti dokumentacijos, tačiau tai būtina. Prisiminkite, kiek kartų teko keikti programerius, kad jie nepaliko normalios dokumentacijos.
    • e. parduotuvės administratoriams - neužtenka apsaugoti pačią sistemą nuo kvailų vartotojų bei sukurti suprantamą pagalbos sistemą, būtina po savęs palikti vartotojo naudojimosi instrukciją.

Turbūt šiam kartui tiek. Jei į galvą šaus daugiau minčių, pratęsiu.

2009-11-24 - No Comments!

Pinigai už turinį

Dažnai informacinių ar pramoginių portalų kūrėjams kyla klausimas: Kaip pritraukti žmones, kad jie kurtų naują turinį ir dėtų į svetainę?
Vienareikšmiško atsakymo į šį klausimą nėra. Kiekvienai svetainei yra savas atsakymas, kuris priklauso nuo lankytojų auditorijos, nuo svetainės tikslų, nuo lankytojų motyvacijos skatinimo ir t. t.

Šiame įraše vieną iš motyvavimo būdų – motyvavimas per pinigus. Kiekvienas daugiau mažiau didesnis portalas bando gyventi iš reklamos. Kodėl gi vardan didesnės vartotojų motyvacijos, potencialaus pelno bei geresnio turinio nepasidalinti su autoriais pinigais? Pvz. straipsnio autorius gauna kažkokį užmokestį už tai, kad lankytojas straipsnio puslapyje paspaudžia reklaminį skydelį arba nuorodą. Be abejo, iškart neišvengiamai atsirastų autorinių honorarų administravimo kaštai, todėl norint to išvengti, siūlyčiau pasinaudoti AdSense ar kitų panašių servisų pagalba. Adsense atveju, kiekvienas Adsense lankytojas gauna leidėjo ID (pvz. mano numeriukas – pub-3077003901413181). Šis numeris nusako kam turėtų būti skiriami pinigai už paspaudimus. Straipsnio autoriui tereikėtų kažkur svetainėje (pvz. prie nustatymų) įrašyti savo ID, o portalo kūrėjams - parašyti mažą kodo gabalą, kuris priklausomai nuo straipsnio autoriaus sugeneruoti reklamos atvaizdavimo skriptą su autoriaus ID. Gaunama abipusė nauda: svetainės kūrėjas gauna geresnį tūrinį, didesnį lankomumą, potencialą pardavinėti reklamą, o straipsnio autorius – pinigus už paspaudimus.

Manau, šis būdas turėtų suveikti tokiuose portaluose kaip ikrauk.15min.lt, kur lankytojai yra skatinami rašyti.

2009-11-11 - 6 comments

CAPTCHA kitaip

captchaCAPTCHA kodai skirti apsaugoti nuo automatinės robotų registracijos ar kitos formos užpildymo, bet neretai pasitaiko, kad CAPTCHA „apsaugo“ ir nuo pačių žmonių, kurie tiesiog nesugeba praeiti apsaugos. Labiausiai trukdo būtinybė į tekstinį lauką įrašyti kodo tekstą. Šis žingsnis, mano manymu, nėra patogus. Būtų galima vartotojui tiesiog pasirinkti vieną iš užrašymo variantų. Saugumo šis pakeitimas labai nesumažintų, o žmonėms būtų patogiau.

2009-10-02 - No Comments!

2009 m. valstybės institucijų interneto svetainių atitikimo bendriesiems reikalavimams tyrimas

Kiekvienais metais IVPK organizuoja tyrimą, atskleidžiantį kaip valstybinės bei savivaldybių institucijos ir įstaigos atitinka Bendrųjų reikalavimų valstybės ir savivaldybių institucijų ir įstaigų interneto svetainėms aprašą. Tyrimo išvadas analizuoja ir priima atitinkamus tolimesnių veiksmų sprendimus LR Vyriausybės Informacinės ir žinių visuomenės plėtros komisija. Tačiau ar yra teigiami pokyčiai? Read more

2009-08-25 - 3 comments

Interneto svetainės pritaikytos neįgaliesiems (II dublis)

Kaip jau minėjau anksčiau, man liūdna ir pikta, kad Lietuvoje beveik nėra svetainių pritaikytų neįgaliesiems. Šiandien nutariau vystyti šią temą ir susisiekiau su IVPK. Pasirodo, IVPK planavo šiemet atnaujinti Neįgaliesiems pritaikytų interneto tinklapių kūrimo, testavimo ir įvertinimo metodines rekomendacijas, tačiau dėl susidariusios ekonominės situacijos šalyje tenka šiuos darbus nukelti vėlesniems metams. Ir čia krizė.
O šiaip, nudžiugino, kad Lietuvoje yra kažkas daroma. Vykdydamas LRV „Dėl Bendrųjų reikalavimų valstybės institucijų interneto svetainėms patvirtinimo“ nutarimo Nr. 480 (Žin., 2003, Nr. 38-1739; 2006, Nr. 115-4376) 2 punktą, IVPK kartą per metus atlieka valstybės ir savivaldybių institucijų ir įstaigų interneto svetainių būklės analizę. 2008 metų analizės ataskaita pateikiama IVPK svetainėje Statistikos archyve. Šiuo metu rengiama ir rugsėjo mėnesį bus paskelbta 2009 metų analizės ataskaita. Su nekantrumu lauksiu šių metų rezultatų. Read more

2009-08-03 - 3 comments

Apie slaptažodžius

Kiekvieną kartą kai paspaudžiu slaptažodžio priminimo mygtuką ir iškart sulaukiu savo slaptažodžio e. pašte, aš pradedu abejoti duomenų saugumu.
Jei man į e. paštą atsiuntė mano nustatytą slaptažodį, reiškia slaptažodžiai duomenų bazėje saugomi be šifravimo, o tai yra nesaugu bei nepagarba vartotojams: slaptažodis ir yra tam, kad jis būtų žinomas tik žmogui, kuris jis įvedė. Todėl paprastas patarimas svetainių kūrėjams, gerbikite savo vartotojus, leiskite tik pakeisti slaptažodį, bet nesiųskite jo e. paštu.