web.hc.lv - vortāls tīmekļa veidotājiem: Raksti http://web.hc.lv/lietojamiba/raksti/?rss=1/ Raksti par lietojamību (usability) lv 2007-2017, web.hc.lv web.hc.lv 60 http://www.hc.lv/inc/baners/hclv_baner_small.gif web.hc.lv - vortāls tīmekļa veidotājiem http://web.hc.lv/ web.hc.lv - vortāls tīmekļa veidotājiem Mon, 18 Dec 2017 01:25:07 +0200 2 3 4 5 6 Instrumenti mājaslapas ātruma optimizācijai Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/instrumenti-atruma-optimizacijai/ http://web.hc.lv/lietojamiba/raksti/instrumenti-atruma-optimizacijai/ Sat, 27 Feb 2010 20:56:57 +0200 web.hc.lv - vortāls tīmekļa veidotājiem Šajā rakstā ir atrodami diezgan advancētu mājaslapas optimizācijas rīku apraksti, kuru iespējas sniedzas tālāk par sākuma līmeņa "every byte counts" optimizāciju.

Kopš Google paziņoja, ka mājaslapas ātrums var ietekmēt mājaslapas pozīcijas meklētājsistēmu reitingos, tas kļuvis par diezgan aktuālu jautājumu mājaslapu izstrādātāju vidē, kā arī ir kļuvuši pieejamāki rīki un informācija par mājaslapu ielādes ātruma optimizāciju.

Kad sāku pētīt informāciju par mājaslapu ātdarbības uzlabošanu, atradu diezgan daudz iespējas būtiski paātrināt mājaslapu ielādes ātrumu, bez jau iepriekš zināmajām (gzip kompresija, attēlu, HTML, CSS un javascript failu izmēru samazināšana, PHP un SQL koda ātrdarbības uzlabošana), tāpēc ceru, ka šī informācija palīdzēs arī citiem veidot ātrākas un, līdz ar to, lietotājiem ērtāk lietojamas mājaslapas.

Google Page Speed

Viens no rīkiem, kas varētu palīdzēt uzlabot mājaslapas ielādes ātrumu, ir Google izstrādātais Page Speed, kas ir jāinstalē uz FireFox pārlūka ar FireBug paplašinājumu. Iesaku uzinstalēt uzreiz arī Closure Compiler for Page Speed. Google Page Speed izanalizēs mājaslapu un parādīs ieteikumus ātrdarbības uzlabošanai.

Page Speed

Yahoo! YSlow

Cits, līdzīgs rīks, kuru var izmantot paralēli ir Yahoo! izstrādātais YSlow, kurš tieši tāpat kā Page Speed instalējas uz FireFox pārlūka ar FireBug paplašinājumu.

YSlow

ShowSlow.com

Page Speed un YSlow ne tikai sniedz ieteikumus lapas ātrdarbības uzlabošanai, bet arī  izmēra lapas ātrdarbības optimizāciju skalā no 0-100 punktiem. Salīdzināt savas mājaslapas ātrdarbības optimizāciju ar citām lapām var lapā www.showslow.com (turpat ir aprakstīts, kā var publicēt savus rezultātus). ShowSlow.com lapā var redzēt arī sīkāku informāciju, par ātrdarbības problēmām lapās, kuru Page Speed un YSlow rezultāti ir publicēti.

Show Slow

WebPageTest.org

Cits rīks, kuru var izmantot neko neinstalējot, taču, iespējams, ka informācija tajā nav tik viegli impretējama kā iepriekšminētajos, ir www.webpagetest.org, kuru iesaka izmantot arī Google pārstāvji. Domāju, ka, ja ir radusies izpratne par Page Speed un YSlow ieteikumiem, tad arī šī rīka ieteikumi mājaslapas optimizācijai īpašas problēmas neradīs. Webpagetest.org ir ne tikai pieejama līdzīga informācija kā abos iepriekšminētajos rīkos, bet arī ir iespējams uzskatāmi vizuāli salīdzināt divu lapu ielādes ātrumu (piemēram, apollo.lv un delfi.lv vai google.com un bing.com...).

WebPageTest.org

FireFox paplašinājums FireBug

Tāpat, es ieteiktu izlasīt šo rakstu, kurā ar uzskatāmiem piemēriem ir aprakstīts, kas var aizkavēt lapas ātru ielādi un kā analizēt mājaslapas ielādi, izmantojot tikai FireFox paplašinājumu FireBug, un paanalizēt pašiem savas lapas ar FireBug rīku.

Papildus informācija mājaslapas ātrdarbības uzlabošanai

Ja esat pa īstam aizrāvušies ar savas mājaslapas ātrdarbības uzlabošanu, tad varat ielūkoties arī šajās saitēs:

Vai ziniet citus noderīgus resursus par mājaslapu ielādes ātruma optimizāciju? Padalieties komentāros!

]]>
Svarīgi lietojamības likumi un principi Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/lietojamibas-likumi/ http://web.hc.lv/lietojamiba/raksti/lietojamibas-likumi/ Wed, 03 Feb 2010 19:45:04 +0200 web.hc.lv - vortāls tīmekļa veidotājiem Atļāvos pārtulkot vienu nodaļu no "The Smashing Book" latviski.

7±2 princips

The Smashing BookTā kā cilvēka prāts ir ierobežots apjomā, lai apstrādātu informāciju, tas apstrādā sarežģītus objektus sadalot informāciju daļās un vienībās. Atsaucoties uz George A. Miller pētījumiem, cilvēki īstermiņā spēj saglabāt atmiņā tikai piecas līdz deviņas lietas vienlaicīgi. Tas bieži tiek izmantots, lai argumentētu nepieciešamību ierobežot vienību skaitu izvēlnē līdz septiņām. Taču debates par "Septiņi plus-mīnuss divi" mītu vēl aizvien turpinās. Tāpēc nav īsti skaidrs vai un kā 7±2 principu vajadzētu pielietot mājaslapās.

2 sekunžu likums

Šis ir izplūdis princips, ka lietotājam nevajadzētu gaidīt vairāk par divām sekundēm uz dažiem sistēmu atbildes reakciju veidiem, kā piemēram uz aplikācijas pārslēgšanos un aplikācijas palaišanu. Divu sekunžu izvēle ir apspriežama, taču tā ir diezgan pamatota. Reālāks princips ir, ka, jo mazāk lietotājiem būs jāgaida, jo labāka tiem būs pieredze.

3 klikšķu likums

Saskaņā ar šo likumu, lietotāji pārstāj lietot mājaslapu, ja tie nav spējuši atrast sev nepieciešamo informāciju vai piekļūt mājaslapas piedāvātajam pakalpojumam veicot trīs peles klikšķus. Likums uzsver skaidras navigācijas nepieciešamību, loģisku struktūru un viegli izsekojamu mājaslapas hierarhiju. Taču vairumā gadījumu klikšķu skaits nav tik būtisks; būtiskāk ir, ka apmeklētāji vienmēr saprot, kur tie atrodas, no kurienes viņi te ir nokļuvuši, un kur viņi var doties tālāk. Pat desmit klikšķi ir ok, ja lietotājiem saglabājas sajūta, ka viņi pilnībā saprot, kā darbojas sistēma.

80/20 likums (Pareto princips)

Pareto princips (arī zināms kā "dažu svarīgo likums" un "faktoru retuma princips") nosaka, ka 80% rezultātu veidojas no 20% iemeslu. Tas ir pamatlikums biznesā (80% ienākumus veido 20% no pārdošanām), taču tas var tikt pielietots arī dizaina un lietojamības jomās. Piemēram, būtiski uzlabojumi var tikt sasniegti, identificējot 20% lietotāju, klientu, aktivitāšu, produktu vai procesu, kas veic 80% ieņēmumus, un maksimāli pievēršot tiem savu uzmanību.

Astoņi saskarsmes dizaina zelta likumi

Savos saskarsmes dizaina pētījumos Ben Schneiderman pasludināja principu kopumu, kas tika analītiski izvilkti no pieredzes, un kuri attiecas uz visām interaktīvajām sistēmam. Šie principi attiecas uz lietotāju saskarsmi, un kā tādi tie ir pielietojami arī mājaslapu dizainā.

  1. Tiecieties uz konsistenci.
  2. Ļaujiet biežiem lietotājiem izmantot īsceļus.
  3. Piedāvājiet informatīvu atsauksmi.
  4. Veidojiet dialogus, kas tiecas uz nobeigumu.
  5. Piedāvājiet vienkāršu kļūdu apstrādi.
  6. Pieļaujiet vienkāršu darbību atcelšanu.
  7. Iekļaujiet kontroles sajūtu. Atbalstiet iekšējās kontroles atrašanos.
  8. Samaziniet īstermiņa atmiņas noslogotību.

Fita likums

Paul Fitts identificēts 1954.gadā, Fita likums ir cilvēka kustības modulis, kas iepriekš nosaka laiku, kas nepieciešams, lai ātri pārvietotos uz noteiktu mērķi, kā funkcija no attāluma līdz mērķim un mērķa izmēru. Likums nosaka, ka jārēķinās ar laika zaudējumiem, norādot mērķi, ja mērķis ir mazs un/vai atrodas tālu. Šo likumu parasti izmanto attiecinot uz peles kustību, kas apmeklētājiem jāveic, lai nonāktu no punkta A uz punktu B. Šis princips iesaka izvietot saturu vietās, kas palielina satura pieejamību un uzlabo klikšķu īpatsvaru.

Inversā piramīda

Inversā piramīda ir rakstīšanas stils, kas apraksta būtību raksta pašā sākumā. Patiesībā tas ir "ūdenskrituma efekts", labi zināms žurnālistikā, kur autori uzreiz sniedz saviem lasītājiem priekšstatu par to, par ko viņi rakstīs. Raksts sākas ar apkopojumu, turpinās ar būtiskākajiem punktiem un tad ar mazāk būtiskām detaļām.Tā kā lietotāji vēlas tūlītēju apmierinājumu (izpratni), tad inversās piramīdas stils būtiski uzlabos lietotāju pieredzi.

 

Vairāk informācijas par "The Smashing Book".

]]>
Yahoo! inženieri padalās ar lapas ātrdarbības noslēpumiem Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/yahoo-lapas-atrdarbiba/ http://web.hc.lv/lietojamiba/raksti/yahoo-lapas-atrdarbiba/ Sat, 03 Oct 2009 21:42:45 +0300 web.hc.lv - vortāls tīmekļa veidotājiem http://developer.yahoo.net/blog/archives/2009/09/search_performance.html]]> Atļāvos iztulkot latviski tekstu, kas oriģinālā ir atrodams te:
http://developer.yahoo.net/blog/archives/2009/09/search_performance.html

Ne tikai skaista seja: Ātrdarbība un jaunais Yahoo! Search

22.septembrī mēs atklājām jauno Yahoo! meklēšanas rezultātu lapu, kas ir pielādēta ar plašu jaunu iespēju klāstu. Jūs varat būt pārsteigts uzzinot, ka jaunais dizains patiesībā ir mazliet ātrāks par oriģinālo. Apdomīgi izmantojot mūsdienīgas ātrdarbības tehnikas, mēs ne tikai nepalielinājām lapas kopējo svaru un HTTP pieprasījumu skaitu, bet arī veicām daudzus uzlabojumus lapas ielādes ātrdarbībai. Tagad, kad esat aplūkojuši jauno meklēšanas rezultātu lapu, izskatīsim dažus ātrdarbības uzlabošanas iespējas, kuras mēs izmantojām veidojot jauno veidni.

Koda pārstrāde

Jebkura radikālas dizaina izmaiņa, kā šī, ir lieliska iespēja pārstrādāt kodu, un mēs to izmantojām, pārrakstot Yahoo! Search lapu HTML, CSS un JavaScript no nulles. Ja iedomājamies par veidni kā ietvaru, kas satur "10 zilās saites" lapas centrā, viss kods ap saturu centrā tika pārstrādāts. Tas mums deva iespēju atbrīvoties no veciem koda atlikumiem un izmantot dažas jaunas tehnikas un labāko praksi, samazinot lapas svaru un renderēšanas sarežģītību procesā.

Kā viens ātrs piemērs, par to, kas jauns, mūsu meklēšanas lapa tagad izmanto CSS attēlu pagriešanu. Tā vietā, lai izmantotu dažādus attēlus augšējai un apakšējai bultai mūsu spraitā, mēs izmantojam tikai apakšējo bultu. Lai ģenerētu augšejo bultu lielākajai daļai (izņemot Operu) A-klases pārlūkiem, mēs izmantojam šādu CSS triku:

-moz-trasform: rotate(180deg);
-webkit-transform: rotate(180deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=2);

Patiesībā tas ieekonomē tikai dažus baitus, taču katrs sīkums skaitās, un šo iestrādāt bija salīdzinoši vienkārši.

Mēs arī izmantojām šoi iespēju uzlabot lapas struktūru un pieejamību. Mēs uzskatam, ka filozofija, ka ir jāveido atsevišķa pieredze pieejamībai, ir maldīga; mēs ticam, ka ir iespējams rakstīt pieejamu kodu nesamazinot ātrdarbību. Būtiskākais uzlabojums jaunajā dizainā ir vienkārši labāka dokumenta struktūras izveidošana, izmantojot <h1>, <h2> un <h3> tagus, kas ļauj ekrānlasītājiem pārvietoties pa lapu daudz vieglāk. Mē arī pievienojām dažas labākas taustiņu kombinācijas, piemēram, ka pirmais spiediens uz tab taustiņa pārvieto pa tiešo uz meklēšanas ievades logu, tā vietā, lai pārvietotu uz navigācijas saitēm, un CTRL-SHIFT DOWN kombinācija ļauj pārlekt pāri galvenei un sānu joslai un fokusēties uz pirmo meklēšanas rezultātu.

Data URI attēli

Jaunais dizains izmanto dažas atkārtojušās krāsu pārejas, kuras izskatās lieliski, taču var būt absolūti ātrdarbības iznīcinātāji. Lai apietu šo problēmu, mēs izmantojām retu iespēju, ko atbalsta visi mūsdienu pārlūki, kas saucas Data URI attēli. Šī tehnika ļauj iekļaut kodētus datus individuāliem attēliem tieši iekš CSS. Šī tehnika ir zināma jau kādu laiku, taču tikai nesen tā ieguva pietiekošu atbalstu, lai to varētu plaši izmantot.

Data URI attēli ļāva mums izvairīties no papildus sprite attēlu smaguma, kas būtu saistīts ar krāsu pāreju attēliem, kas atkārtojas, tajā pašā laikā uzlabojot ātrdarbību, izvairoties no "ielekšanas" efekta, kuru dažreiz iespējams redzēt ar veidņu attēliem. Tradicionālās CSS failā, kas satur atsauces uz ārējiem attēliem, pārlūks ielādē CSS, apstrādā CSS un sāk attēlot lapu. Jebkuras atsauces CSS uz attēliem rada jaunu HTTP pieprasījumu. Atkarībā no pieslēguma ātruma, lapa var būt jau attēlota uz to brīdi, kad attēls ielādējas, kas rada "ielekšanas" efektu, ka pēkšņi lapā "ielec" attēls. Data URI attēli palīdzēja mums pilnībā izvairīties no "ielekšanas" efekta un nozīmīgi samazināt HTTP pieprasījumu skaitu.

Lai saglabātu atpakaļejošu savietojamību, mēs piedāvājam atsevišķu spraita attēlu ar gradācijām priekš IE6 un IE7. Tas nozīmē, ka šo pārlūku ātrdarbība būs mazliet mazāka par mūsdienīgāku pārlūku ātrdarbību, taču kopējais ieguvums vienalga ir tā vērts. Protams, sadalīta koda menedžēšana ir mazliet riskanta. Vairākas mājaslapas dod priekšroku to darīt ar nosacījuma komentāriem vai citām tehnikām. Mūsu gadījumā kopīgā atšķirība patiesībā ir ļoti maza - mūsu izstrādes rīki nosūta vajadzīgos statiskos resursus uz mūsu Satura Sadales Tīklu (CDN), un mūsu frontend nosaka pārlūku un ievieto vajadzīgo CSS failu.

Semantiska lapas padeve

Tā vietā, lai sagaidītu, kamēr serveris ģenerēs lapu pilnībā un tad nosūtītu to visu kopā, mēs nosūtam lapu klientam trīs semantiski nozīmīgās daļās, kas ļauj pārlūkam sākt attēlot lapu un pieprasīt statiskos resursus ātrāk.

  • Pirmā daļa sastāv no lapas galvenes un meklēšanas ievades loga, un tā tiek nosūtīta pirms mēs pat pieprasam meklēšanas rezultātus no backend. Tas ļauj pārlūkam sākt ielādēt statiskos resursus, kamēr mūsu serveris vēl apstrādā meklēšanas pieprasījumu.
  • Otrā daļa sastāv no visa redzamā lapas satura un reklāmām, bet ne JavaScript. Tas ļauj lietotājam acumirklī sākt meklēšanas rezultātu skanēšanu un darbības ar tiem, pirms pārlūks vēl ir ielādējis un sācis darbināt jebkuru Javacript kodu.
  • Pēdējā daļa satur JavaScript, kas pievieno būtisku, bet ne kritisku funkcionalitāti kā Search Assist un Search Pad.

Tīkla efekts ir tāds, ka lietotājs redz lapas ielādi un var ar to darboties daudz ātrāk. Nosūtot pēc iespējas ātrāk pārlūkam informāciju, kas nepieciešama, lai tas varētu ielādēt statiskos komponentus, mēs arī samazinam kopējo ielādes laiku.

Ņemiet vērā, ka vecais dizains arī izmantoja semantisku lapas padevi, bet ne tik agresīvi. Būtiskākā atšķirība ir tā, ka iepriekšējā dizainā pirmajā daļā tika iekļauts tikai kods līdz <head>. Pārstrādājot kā mūsu backend loģika darbojas, mēs varējām pirmajā daļā iekļaut arī daļu no <body> elementa un iekļaut būtiskus vizuālos elementus kā lapas galvene un meklēšanas ievades logu. panākot, ka vizuālais kods sāk nākt pa vadiem, tas rada iespaidu, ka lapa ielādējas, ka "kaut kas notiek".

Slinkā ielāde

JavaScript un CSS, kas tiek izmantots meklēšanas rezultātu attēlošanas lapās tagad ielādējas divās atsevišķās daļās. Pirmā daļa izmanto tikai pašu minimālāko CSS un JavaScript, kas nepieciešams 100% meklēšanas rezultātu lapu attēlošanai, tā ka pamatdarbībām nepieciešamais ielādējas tik ātri, cik vien iespējams. Otrā daļa ielādē papildus (bet smagāku) funkcionalitāti kā Search Assist un Search Pad. Mēs tāpat ielādējam papildus CSS un JavaScript daļas saīsinājumiem un citām dinamiskām iespējām tikai pie nepieciešamības, nodrošinot, ka mēs neizmantojam nelietderīgi laiku ielādējot kodu, kurš mums visdrīzāk nebūs nepieciešams.

Kā meklētājsistēmas mājaslapa mēs nevaram izvairīties no smagās slinkās-ielādes, jo meklēšanas pieredze ir ļoti būtiska lietotāju pieredze tīmeklī. Kad lietotājs pieprasa meklēšanas lapu, parasti viņi skanē un klikšķina ļoti ātri. Ja vien mēs varam nodrošināt šīs pamatdarības pēc iespējas ātrākas, mēs varam atlikt pārējās komponentes uz vēlāku laiku. Ja jūsu mājaslapai ir citādāka lietojamības paradigma, jums vajag būt uzmanīgākiem; jūs nevarat slinki ielādēt komponentus, ar kuriem lietotājs vēlas darboties uzreiz.

Dizaineri un inženieri piekrīt: Ātrdarbība ir būtiskākā!

Iespējams, aiz visiem šeit izklāstītājiem tehniskajiem spriedumiem, visnozīmīgākā ietekme bija mūsu filozofijai, ka ātrdarbība ir visu problēma, visos līmeņos. Mūsu frontend inženieru komanda sāka domāt un plānot ātrdarbību vēl pirms dizaini bija uzskicēti. Tas ļāva mums dot agras atsauksmes mūsu Lietotājpieredzes Dizaina departamentam un strādāt kopīgi ar viņiem, kamēr viņi atslīpēja savus dizainus.

Lapas ātrdarbības optimizēšanaMūsu dizaineri jau bija ņēmuši vērā daudzus ātrdarbības principus, kurus viņi iemācījās gadu gaitā, kā, piemēram, spraitu optimizācija. Tomēr, jaunajā dizainā tiek daudz vairāk izmantotas krāsu pārejas, kā iepriekšējā dizainā, kas var izmaksāt ļoti dārgi - īpaši, ja pārejas tiek izstieptas vertikāli vai horizontāli visas lapas garumā.

Par laimi, mūsu dizaineri laicīgi mums norādīja uz savām bažām, un mums bija iespēja veikt kopīgi prāta vētru, kā izmantot grafiskos komponentus efektīvāk. Pēc tam, kad dizaineri saprata dažas tehnikas, kuras mēs vēlējāmies izmantot un dažus ierobežojumus, tie bija spējīgi piedāvāt dažus absolūti brīnišķīgus dizainus, kas iekļāvās mūsu noteiktajās ātrdarbības robežās. Pēc šīm dažām sapulcēm, katrā dizaina pakāpē mūsu Lietotājpieredzes Dizaina departamenta komanda saskaņoja ar ātrdarbības inženieriem, lai pārliecinātos, ka mēs nepārkāpjam mūsu ātrdarbības mērķus. Šī ciešā sadarbība palīdzēja mums atturēties no uztraukumiem par ātrdarbību.

Citiem vārdiem, jauni triki un ātrdarbības tehnikas tikai noved jūs tik tālu. Pateicoties individuālu dizaineru un inženieru bezgalīgām smaga darba stundām jaunā Yahoo! Search lapa piedāvā lielāku funkcionalitāti un vairāk dizaina komponentes pat ātrākā iepakojumā. Un mēs vēl aizvien smagi strādājam kopā ar mūsu kolēģiem dizaineriem, lai veidotu meklēšanas pieredzi vēl ātrāku un labāku turpmākajās nedēļās un mēnešos. Ja jums ir kādi jautājumi par Yahoo! Search un frontend ātrdarbību, mēs gaidam jūsu atsauksmes!

Ryan Grove
Yahoo! frontend inženieris

Stoyan Stefanov
Yahoo! ātrdarbības inženieris

Venkateswaran Udayasankar
Yahoo! ātrdarbības inženieris

]]>
Ķidājam www.saeima.lv Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/kidajam-www.saeima.lv/ http://web.hc.lv/lietojamiba/raksti/kidajam-www.saeima.lv/ Thu, 12 Feb 2009 16:25:37 +0200 web.hc.lv - vortāls tīmekļa veidotājiem 2008.gada augustā kāda sabiedrisko attiecību aģentūra mani palūdza uzrakstīt īsu "eksperta viedokli" par mājas lapu www.saeima.lv, kurš būtu saprotams "parastajiem" cilvēkiem.

Vienojāmies, ka to drīkstēšu publicēt 2009.gadā. Tā kā www.saeima.lv nekas būtisks kopš tā laika mainījies nav, tad domāju, ka šis viedoklis ir aktuāls arī tagad.

Mājas lapas www.saeima.lv apskats

Kā jau visas mājas lapas, arī www.saeima.lv būtu jābūt veidotai, lai tā būtu ērta lietošanā un pieejama pēc iespējas plašākam cilvēku lokam.

Diemžēl pašlaik www.saeima.lv izskatās, ka tā ir veidota nevis lai to izmantotu cilvēki, bet gan, lai tiktu atzīmēts kāds ķeksītis kādā atskaitē.

Vienīgās pieņemtās normatīvās prasības valsts mērogā kārtībai, kādā iestādes ievieto informāciju internetā, lai nodrošinātu tās pieejamību ir MK noteikumi Nr. 171 "Kārtība, kādā iestādes ievieto informāciju internetā"1. Taču šie noteikumi attiecas tikai tiešās pārvaldes iestādēm un atvasinātām publiskām personām, izņemot pašvaldību iestādes. Tātad uz Saeimu šie noteikumi nav saistoši. Jāatzīst, ka neņemot vērā grozījumus, kuri ir spēkā ar 2008. gada 9. augustu, www.saeima.lv tomēr formāli ir ievērojusi gandrīz visus iepriekš minētajos noteikumos iestrādātos punktus. Taču, lai mājas lapa būtu ērta lietošanā un pieejama pēc iespējas plašākam cilvēku lokam, ar to vien nepietiek.

Mājas lapas raksturo šādas īpašības:

  • lietošanas ērtums jeb lietojamība (usability);
  • pieejamība (accessibility);
  • saturs;
  • lapas vizuālais noformējums.

Pētījumi liecina, ka mājas lapas apmeklētājiem par mājas lapu rodas pirmais priekšstats jau pirmajās sekundes desmitdaļās. Paskatoties uz mājas lapas www.saeima.lv sākumlapu, nekāds labais priekšstats neveidojas. Lapa nesniedz vizuālo baudījumu un nerada priekšstatu, ka tā pārstāv nopietnu valstisku institūciju. Paskatoties uz lapas vizuālo noformējumu, diemžēl nerodas nekāds priekšstats par to, kādas ir Saeimas vērtības. Neizprotama paliek arī mazās bildītes sākumlapā nozīme.

www.saeima.lv

Pirmā lieta, kas duras acīs – nekur nav redzama saite uz informāciju, kas ir Saeima, kurai intuitīvi vajadzētu būt ar nosaukumu "Par Saeimu". Apmeklētājiem būtu jādod iespēja noskaidrot, kas tā ir par iestādi un ar ko tā nodarbojas, kuras mājas lapu tie apmeklē, jo mājas lapai būtu jābūt kā iestādes vizītkartei internetā.

Aplūkojot rūpīgāk sākumlapu, ir redzams, cik neloģiski tiek attēlota informācija. Tā tiek sagrupēta četrās daļās – Deputāti, Likumdošana, Aktualitātes un Vispārējā informācija. Neloģiski šķiet tas, ka šo grupu virsraksti ir mazākiem burtiem, kā pati informācija zem šiem virsrakstiem.

www.saeima.lvPaskatoties citas mājas lapas www.saeima.lv lapas, ir redzams, ka nav ievērots viens no lietojamības pamatprincipiem – konsekvence2. Piemēram, saite "Rakstīt mājas lapas administratoram" atrodas te labajā, te kreisajā pusē, arī navigācijas elementi dažādās lapās izskatās savādāk, ir lapas, kurās navigācijas elementi vispār nav atrodami (piemēram, www.saeima.lv/saeima9/lasa?dd=LP0796_0).

Lapu vizuālais noformējums ir nevis ieturēts vienotā stilā, bet tā praktiski nav. Līdz ar to, lietotājs pārejot uz citu lapu, var pat nepamanīt, vai viņš vēl aizvien atrodas www.saeima.lv mājas lapā, vai arī atrodas kādā citā lapā.

Saites ir mājas lapu viens no pamatelementiem, tāpēc tām vajadzētu pievērst īpašu uzmanību. Pie lapas mīnusiem var pieskaitīt arī to, ka lapā ir ļoti daudz saišu uz ārējiem resursiem, taču šīs saites izskatās tieši tāpat, kā saites uz iekšējiem resursiem.

Turpinot par saitēm lapā, lietojamības eksperti iesaka, lai tās tiktu izceltas ar krāsu un arī ar pasvītrojumu3, lai palielinātu iespējas, ka lietotājs uz tām noklikšķinās. www.saeima.lv mājas lapā tas nav ievērots.

Saitēm HTML kodā nav pievienoti arī title atribūti4, kuri ne tikai palīdz lietotājiem izprast, kurp vedīs saite, bet arī palīdz meklētājsistēmām (Google, Yahoo!, MSN, Live.com u.c.) precīzāk indeksēt mājas lapu, lai tās varētu lietotājiem piedāvāt visatbilstošākos rezultātus. Tieši tas pats attiecas uz alt atribūtiem5 HTML kodā pie bildēm mājas lapā.

www.saeima.lv lapā ir slikta prakse atvērt dažas saites jaunā interneta pārlūka logā. Lietotājam grūti aptvert informāciju jau esošajā logā, kur nu vēl divos logos. Lai gan, tas var arī neatvērties, jo lietotājiem pārlūkos bieži vien ir uzstādīti dažādi reklāmu bloķētāji, kuri vienkārši nobloķē jauna loga atvēršanu. Līdz ar to lietotājs iegūst negatīvu pieredzi par mājas lapu, jo viņam šķiet, ka saite nedarbojas.

Cita problēma ar saitēm www.saeima.lv mājas lapā ir tā, ka tās bieži vien norāda uz informāciju, kas nav internetā pieņemtajos formātos. Piemēram, MS Word formātā vai Adobe Acrobat formātā. Turklāt pie saitēm nav nekādas norādes, ka informācijas apskatei nepieciešamas papildus programmas. Lietojamības eksperti iesaka izmantot informāciju citos formātos pēc iespējas mazāk6.

Runājot par lapu saturu, arī te varētu vairāk piedomāt, kā to noformēt lasāmāku, jo pētījumi pierāda, ka internetā lietotāji tekstu biežāk nevis lasa, bet skenē7.

Palielinot burtu izmēru, teksts būtu salasāms daudz plašākai auditorijai. Ideāli būtu, ja burtu izmēru varētu mainīt (kā to paredz arī MK not. Nr. 171 "Kārtība, kādā iestādes ievieto informāciju internetā"1 19.1 punkts).

Būtu nepieciešams pārskatīt iespēju sadalīt garus tekstus pa vairākām lapām, jo pētījumi8 pierāda, ka "vidējā" interneta lapā lietotāji pavada tikai tik daudz, lai izlasītu maksimums 28% no teksta, visbiežāk gan tie izlasa tikai 20% no visa teksta. Tikai lapās, kurās ir 111 vārdi vai mazāk, lietotāji parasti izlasa vismaz pusi no teksta. Daži pētījumi9 norāda, ka labus rezultātus var panākt jaucot garākus tekstus ar īsākiem.

Garākos tekstos noteikti būtu jāievieto vairāk ilustratīvo materiāli – grafikus, bildes, jo tas ne tikai palīdz labāk un vieglāk uztvert informāciju, bet arī vienkārši ļauj lietotājiem atpūtināt acis. Tieši tā paša iemesla dēļ prasās tekstos arī lielākas atstarpes starp rindkopām, kā arī varbūt pārdomāt rūpīgāk burtu garnitūras izvēli. Pavisam noteikti tekstu vieglāk uztvert arī palīdzētu gaumīgi lapas grafiskie noformējuma elementi. Iespējams, ka lietotājiem būtu vieglāk arī uztvert lapu, ja tiktu vairāk izmantotas dažādas vispārpieņemtas piktogrammas, kuras uztvert ir ātrāk un vienkāršāk par tekstu.

Ņemot vērā, ka lietotāji biežāk skenē tekstu, nevis lasa vārdu pa vārdam7, tekstu vajadzētu ievietot viegli skenējamā formātā, tas ir, tam būtu jābūt sagrupētam, izmantojot virsrakstus un apakšvirsrakstus, sarakstus, jācenšas izmantot "piramīdas princips" (sākt ar secinājumiem vai kopsavilkumu un turpināt ar sīkāku iztirzājumu), kā arī būtiskākos atslēgvārdus tekstā vajadzētu izcelt.

www.saeima.lv

www.saeima.lv/Likumdosana/sede.html

Interneta adreses (URL) mājas lapā www.saeima.lv ir lietotājiem nedraudzīgas, tās ir grūti izprast, jo tās neatbilst lapas struktūras arhitektūrai, tās ir grūti nolasīt, lai citi cilvēki varētu tās saprast. Piemēram, www.saeima.lv/pages/aktualitates.jsp?page=info-medijiem. Daudz draudzīgāk lietotājiem (un arī meklētājsistēmām10) būtu, ja lapas interneta adrese (URL) būtu šāda:
www.saeima.lv/aktualitates/info-medijiem.

Mājas lapai www.saeima.lv iztrūkst arī interaktīvie elementi, par kuriem ir pieminēts arī MK not. Nr. 171 "Kārtība, kādā iestādes ievieto informāciju internetā"1 15.7 punktā (piemēram, "Jūsu jautājums", "Viesu grāmata", "Komentāri", "Forums", "Diskusija", "Aptauja"), kuri palīdzētu ne tikai iegūt atgriezenisko saiti no mājas lapas apmeklētājiem par Saeimas darbību, bet arī rosinātu diskusijas mājas lapas apmeklētāju starpā.

Žurnālistu, un citu cilvēku ērtībām, kuri vēlas sekot aktualitātēm mājas lapā, neapmeklējot to, būtu nepieciešama arī atsevišķu mājas lapas satura vienību piegāde, izmantojot vienkāršās sindicēšanas pakalpojuma (Really Simple Syndication jeb RSS) kanālus. Pašlaik šī iespēja www.saeima.lv mājaslapā nav pieejama.

www.saeima.lv ir arī dažādas tehniskas nepilnības, kuras traucē gan lapas lietojamībai, gan pieejamībai. Bez jau iepriekš minētajiem alt un title atribūtiem, lapa nav veidota pēc The World Wide Web Consortium (W3C) ieteikumiem. Dažās lapās nav nodefinēts Doctype11 (piemēram, www.saeima.lv/pages/aktualitates.jsp). Lapa tiek kodēta Windows-1257 kodējumā, nevis mūsdienās jau internetā vispārpieņemtajā UTF-8 kodējumā, kas ļauj bez problēmām attēlot vienā lapā dažādu valodu simbolus. Lapas izklājuma veidošanai nekorekti12 tiek izmantotas tabulas. Sākumlapā pilnīgi lieki tiek izmantoti tā saucamie freimi (frames), kuri samazina lapas pieejamību, lietojamību, kā arī rada problēmas korekti indeksēt lapu meklētājsistēmām13.

Ņemot vērā, ka mūsdienās mājas lapās parasti vismaz trešdaļa (dažās arī gandrīz 100%) no apmeklētājiem nonāk caur meklētājsistēmām (visvairāk tieši no Google14), tad nevajadzētu noniecināt meklētājsistēmu nozīmi, veidojot mājaslapas – vajadzētu rūpīgi pārdomāt saturā izmantotos atslēgvārdus, lapas struktūru, URL interneta adreses, lietotājiem un meklētājsistēmām draudzīgu lapas kodu.

 

Secinājumi: Mājas lapas www.saeima.lv vizuālais noformējums nespēj atbilstoši reprezentēt Saeimu, tā neatbilst mūsdienās pieņemtajiem mājaslapas veidošanas, lietojamības un pieejamības standartiem, līdz ar to liekot šķēršļus tās apmeklētājiem pilnvērtīgi iepazīties ar tajā publicēto informāciju, kā arī sniegt atgriezenisko saiti par Saeimas darbību izmantojot internetu.

Atsauces

1 MK noteikumi Nr. 171 "Kārtība, kādā iestādes ievieto informāciju internetā" ("LV", 41 (3617). 09.03.2007.spēkā ar 10.03.2007 ar grozījumiem:
MK noteikumi Nr. 648 ("LV", 122 (3906), 08.08.2008.) spēkā ar 09.08.2008.
www.likumi.lv/doc.php?id=154198

2 "Consistency is one of the most powerful usability principles: when things always behave the same, users don't have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good." – Jakob Nielsen.
www.useit.com/alertbox/9605.html

3 "To maximize the perceived affordance of clickability, color and underline the link text. Users shouldn't have to guess or scrub the page to find out where they can click." – Jakob Nielsen
www.useit.com/alertbox/20040510.html

4 www.w3.org/TR/REC-html40/struct/global.html#h-7.4.3

5 www.w3.org/QA/Tips/altAttribute

6 "When using PC-native file formats such as PDF or spreadsheets, users feel like they're interacting with a PC application. Because users are no longer browsing a website, they shouldn't be given a browser UI." – Jakob Nielsen
www.useit.com/alertbox/open_new_windows.html
www.useit.com/alertbox/20030714.html

7 "People rarely read Web pages word by word; instead, they scan the page, picking out individual words and sentences. In research on how people read websites we found that 79 percent of our test users always scanned any new page they came across; only 16 percent read word-by-word." – Jakob Nielsen
www.useit.com/alertbox/9710a.html

8 "On the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely. (...) On an average visit, users read half the information only on those pages with 111 words or less." – Jacob Nielsen
www.useit.com/alertbox/percent-text-read.html

9 www.useit.com/alertbox/content-strategy.html

10 www.google.com/support/webmasters/bin/answer.py?hl=en&answer=76329

11 www.w3schools.com/tags/tag_DOCTYPE.asp

12 "HTML is a structural language, which means it is - or should be - used to add structure into a text through tags. The table tag should then only be used to format data into a table to relate columns with rows."
www.w3.org/2002/03/csslayout-howto

"The Web Standards Project’s (WaSP) Browser Upgrade Initiative (BUI), has spurred many a designer to move towards more standards compliant web design, using CSS rather than tables for layout to save user bandwidth while enhancing underlying semantics, accessibility, and reach."
www.alistapart.com/articles/practicalcss/

13 "Google supports frames and iframes to the extent that it can. Frames can cause problems for search engines because they don't correspond to the conceptual model of the web. In this model, one page displays only one URL. Pages that use frames or iframes display several URLs (one for each frame) within a single page. Google tries to associate framed content with the page containing the frames, but we don't guarantee that we will.

If you're concerned with how your site appears in the Google search results, please read Search Engines and Frames This document describes the use of the "NoFrames" tag to provide alternate content. If you use wording such as "This site requires the use of frames," or "Upgrade your browser," instead of providing alternate content on your site, then you'll exclude both search engines and individuals who've disabled frames on their browsers. For example, audio web browsers, such as those used in automobiles and by the visually impaired, typically do not support frames."
www.google.com/support/webmasters/bin/answer.py?answer=34445

14 "Uz šo brīdi Googles daļa pasaulē interneta meklēšanas jomā sastāda 70,77%, seko Yahoo! ar 18.65%, Microsoft ar 5.36% un ask.com ar 3.53%."
www.notepad.lv/slideinfo.php?t=2160

]]>
Kā nesāpīgi padot RSS plūsmu caur FeedBurner.com Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/rss-plusma-caur-feedburner.com/ http://web.hc.lv/lietojamiba/raksti/rss-plusma-caur-feedburner.com/ Wed, 06 Feb 2008 12:31:52 +0200 web.hc.lv - vortāls tīmekļa veidotājiem Ja vēlies izmantot Feedburner.com iespējas savas mājaslapas RSS barotnei, šajā rakstā ir aprakstīts, kā to izdarīt, lai nesagādātu neērtības saviem patreizējiem RSS plūsmas lietotājiem.
Iemesli RSS plūsmas pārvietošanai uz FeedBurner.com var būt dažādi, taču kopumā tie parasti balstās uz iespēju aplūkot statistiku,  mājaslapas RSSbarotnes izmantošanu. Līdz ar to parādās arī iespēja uzlabot savas mājaslapas reitingu tādās reitingu sistēmās kā, piemēram,  blogtop.lv un tamlīdzīgās.

FeedBurner.com pingJau esošajiem RSS plūsmas lietotājiem pāreja uz FeedBurner.com uzlabojumus nekādus nenes, drīzāk gan otrādi, ziņas līdz viņiem nonāk lēnāk, jo tiek izmantots starpnieks. Automātiski, ja netiek izmantots ping serviss, FeedBurner.com atjauno savā galā RSS plūsmu reizi 30 minūtēs.

Diez vai RSS plūsmas lietotājam ir tik būtiski zināt, vai līdz ar viņu šo pašu informāciju lasa vēl 123 cilvēki vai 542 cilvēki. Bet no otras puses skatoties - mājaslapas veidotājam vienmēr ir interesanti novērot, kā attīstās viņa mājaslapa, un statistika par RSS barotnes izmantošanu var palīdzēt noskaidrot, kas lietotājus interesē vairāk, tādā veidā arī mājaslapas kopējā kvalitāte var uzlaboties.

Tātad arī šajā mājaslapā tika izlemts galveno RSS plūsmu turpmāk padot caur FeedBurner.com, tāpēc es pastāstīšu, kā tas tika izdarīts RSS lietotājiem nemanot, lai tiem nebūtu jāraksta šāda satura paziņojumi:

FYI: Switch to Feedburner

FYI: Sāku izmantot Feedburner.

Tiem, kas lasa caur RSS agregatoriem - lūdzu pārvariet slinkumu un pierakstiet jaunu “fīdu”:
http://feeds.feedburner.com/insight-blog

* Vecais “fīds” vēl jo projām ir vietā. Ir iespējams lasīt arī caur to.


Tātad sākotnējā situācija bija tāda - RSS barotnes adrese bija http://web.hc.lv/rss/rss.xml, kuru pa tiešo izmantoja daudzi lietotāji (arī RSS agregātori, kā, piemēram, nekur.lv u.c..). Shematiski tas izskatījās šādi:

RSS plūsma

Lai neliktu esošajiem RSS lietotājiem mums ir jāsaglabā RSS barotnes adresi, kuru izmanto lietotāji (konkrētajā piemērā: http://web.hc.lv/rss/rss.xml), tajā pašā laikā RSS plūsmu izlaižot pirms tam caur Feedburner.com. Shematiski tas izskatās šādi:
rss_2
Tātad soli pa solim, kas jāizdara:
  1. Jānomaina reālās RSS barotnes URL adrese uz jebkuru citu (konkrētajā gadījumā no http://web.hc.lv/rss/rss.xml uz http://web.hc.lv/rss/rss_new.xml);
  2. Iekš FeedBurner.com jānorāda kā RSS avots jaunā RSS barotnes URL adrese (http://web.hc.lv/rss/rss_new.xml);
  3. Mājaslapā visi pieprasījumi uz veco RSS barotni (http://web.hc.lv/rss/rss.xml) jāpāradresē uz FeedBurner.com izveidoto RSS adresi (http://feeds.feedburner.com/webhclv).
Pāradresāciju visvienkāršāk ir izveidot ierakstot .htaccess failā (ja tiek izmantots populārais Apache serveris), kurš atrodas mājaslapas saknes direktorijā (ja šāda faila nav, tad to var izveidot), sekojošu rindiņu:
Redirect 301 /rss/rss.xml http://feeds.feedburner.com/webhclv
Protams, /rss/rss.xml jānomaina pret savas RSS barotnes relatīvo ceļu no mājaslapas saknes direktorijas, un http://feeds.feedburner.com/webhclv jānomaina pret savu FeedBurner.com izveidoto RSS barotnes adresi.

Pēc visu darbību veikšanas esošajiem RSS plūsmas lietotājiem nevajadzētu pat pamanīt, ka mājaslapas RSS plūsma iet caur FeedBurner.com. Vienīgi, jāņem vērā, ka FeedBurner.com būtu vēlams nopingot, katru reizi pēc mājaslapas RSS barotnes izmaiņām (piemēram, pēc ziņas pievienošanas), gadījumā, ja šī iespēja nav iestrādāta mājaslapas satura vadības sistēmā (CMS), lai izmaiņas lietotājiem atspoguļotos pēc iespējas ātrāk.
]]>
Skatiena izsekošanas pētījums Google rezultātu lapai Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/skatiena-izsekosanas-petijums-google-serp/ http://web.hc.lv/lietojamiba/raksti/skatiena-izsekosanas-petijums-google-serp/ Sat, 13 Oct 2007 01:12:16 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Kompānija Enquiro ir veikusi skatiena izsekošanas pētījumu Google rezultātu lapām, kas parāda, cik daudz, kurā brīdī un kur cilvēki skatās lapā, atkarībā no attēla atrašanās lapā.
Pētījuma pamatā tika dažādi pārveidota Google universālās meklēšanas rezultātu lapa (SERP – search engine results page), un tika skatīts, vai var izmainīt tipisko lietotāju uzvedību. Pieņēmums bija, ka attēli lapā (kādi tie ir Google universālajā meklēšanā) varētu mainīt lietotāju tipisko uzvedību, kas arī tika pierādīts.


Lapas sadalīšana

Kopīgā lietotāju tendence parastā rezultātu lapā, bija sākumā vērst skatienu lapas kreisajā augšējā stūrī (bildē pa labi atzīmēts ar A), un sākt skanēt lapu no šejienes – sākumā vertikālā virzienā (bulta uz leju), bet pēc tam arī horizontālā virzienā, kad virsraksts piesaista uzmanību (bulta pa labi). Attēlā vietas, kur skatiens ir uzkavējies visintensīvāk ir atzīmētas kā karstuma plankumi.

Skanēšanas karstuma karte

Izmainītajā lapā, kurā ir pievienota bilde, var pamanīt (bildē pa kreisi), ka, lai gan notiek neliela skanēšana kreisajā augšējā stūrī (B), izskatās, ka skanēšana nesākas tur. Tā vietā, skanēšana sākas pie attēla rezultātos (C). Skanēšana turpinās uz sāniem un uz leju (D). Vai tas varētu nozīmēt, ka aktīvais trijstūris tiks novirzīts uz leju?

Patiesībā grafiskā elementa atrašanās augstu rezultātos, kā piemēram iPhone attēls rezultātos, kas redzami zemāk, izskatās, ka mentāli sadala lapu pa daļām. Izskatās, ka iedomātie attēla robežu pagarinājumi sadala lapu turpmākajai skanēšanai. Te ir skanēšanas secība, ja pastāv šeit minētie apstākļi.

iPhone attēls rezultātos

Lai gan mēs vēl aizvien cenšamies pacelt skatienu uz kreiso augšējo stūri, mēs praktiski vienlaicīgi (zem sekundes) pārvietojam saktu uz attēlu (A), lai pārliecinātos, vai tas ir atbilstošs. Grafiskais attēls izskatās iespaidīgs skatiena piesaistītājs. Tendence tālāk ir pārliecināties, vai ieraksts blakus attēlam (B) ir atbilstošs un unikāls savā ziņā. Mūsu smadzenes mums saka, ka, ja ierakstam ir unikāls izkārtojums, tad tam vajadzētu būt unikālam savā ziņā. Visdrīzāk, tas ir tāpēc, ka šāds izkārtojums iekš SERP ir diezgan neierasts. Iespējams, ar laiku, mēs kļūsim mazāk jūtīgi pret šādiem ierakstiem. Lai nu kā, šajā mirklī mēs redzējām tendenci skanēt šo ierakstu pirmo. Pēc tam, jo mums tomēr prasās noskanēt 3-4 ierakstus, pirms izdarīt izvēli, mēs izvēlamies no daļām virs attēla (C) un zem attēla (D).

E formas skanēšana

No augšas uz leju un no kreisās uz labo F formā skanēšanas, mainītajā rezultātu lapā ir redzama vairāk E formas skanēšana, ar vertikālo un pirmo (laika ziņā) horizontālo svītru tajā vietā, kur atrodas attēls. Iepriekšējā F formas tendence no augšas uz leju un no kreisās uz labo malu izskatās, ka ir dramatiski zaudējusi savu aktualitāti ar attēla esamību.


Skanēšanas norobežošana

Cita kopīga uzvedība, kas tika novērota, bija skanēšanas „norobežošana” ar attēlu vai grafisko elementu klātesamību ar taisnām malām.

Skanēšanas ierobežošana

Izskatās, ka mums patīk pagarināt šīs taisnās līnijas, lai noformētu mentālas robežas, kuras izmantojam sadalot lapu skanēšanai. Papildus lapai sadalīšanai skanēšanai, kas tika aprakstīta agrāk, tas var arī iegūt skanēšanas aizlieguma efektu zem šīm robežām. Piemēram, palūkojieties abos attēlos augstāk. Abos gadījumos izskatās, ka attēla klātesamība ir izveidojusi robežu, kas aizliedz skanēt zemāk, un kas noved pie intensīvākas skanēšanas augstāk.

Tas, protams, ir atkarīgs no ātras aplūkošanas, lai pārliecinātos, vai noderīgākais atrodas virs vai zem robežas. Iekš SERP, ja te ir pietiekoši ierakstu virs robežas (pieņemot, ka mums ir vismaz dažas piedāvātās iespējas), ir dabīgi pieņemt, ka mēs atradīsim meklēto drīzāk augstāk, nekā zemāk. Taču fakts ir, ka taisnstūraina attēla klātesamība noved pie attēla sānu pagarinājuma, lai radītu robežas, un, kad lapa ir sadalīta, mēs mēdzam pieņemt šīs sekcijas kā vienotu veselumu, tā vietā, lai skanētu katru ierakstu individuāli. Šis ir tas pats ieradums, kas liek mums ignorēt vairākas reklāmas labajā lapas pusē pēc kārtas, pēc ātra skatu uzmetiena uz pirmo, tā vietā, lai skanētu tās individuāli. Sadalīšana un šo robežu esamība maina mūsu lineāro skanēšanas ieradumu, liekot mums sadalīt lapu vēl vairāk.

Aplūkojot dažādus Google SERP variantus, izskatās, ka te ir diezgan daudz ko attīstīt, kas varētu ietekmēt to, kā mēs uztveram meklēšanas rezultātus. Grafiska elementa klātesamība uz lapas ietekmē mūs savādākā manierē, kā vienkārši parādot mums teksta attēlus. Pirmkārt, kā Jakob Nielsen to ir norādījis, mēs uztveram attēlus daudz ātrāk. Ātrs acu skatiens ir pietiekošs, lai mēs noteiktu attēla nozīmi. Bet otrkārt, un iespējams tas ir vēl būtiskāk, attēls iekairina citas smadzeņu daļas. Teksta lasīšana ir abstrakts, loģisks process, bet attēli mūs ietekmē emocionālā līmenī. Pēdējie pētījumi pierādījuši, ka gadījumā, ja mūsu smadzenes apstrādā dažāda tipa informāciju paralēli, tad emocionālākā informācija tiek apstrādāta daudz ātrāk par racionālo. Kaut kas, kas skar mūsu emocijas, kļūst par ietekmīgu skatiena piesaistītāju.

Tomēr, arī vienkārši ar attēla esamību nav pietiekami. Attēlam jāpiedāvā arī informācijas „smarža”. Attēlam jābūt atbilstošam mūsu iedomai. Un, jo tas ir attēls, mēs varam noteikt atbilstību ļoti ātri. Mēs varam noteikt gan attēla atbilstību, gan cik tas ir saistošs un sekundes daļā noteikt, vai tas ir mūsu uzmanības vērts. Ja attēls izpilda šo uzdevumu, tad mēs to varam apbalvot ar uzmanīgāku skanēšanu. Piemēram, aplūkojiet šos piemērus.

Neatbilstoša bilde

Attēli pierāda skanēšanas ietekmēšanu agrākajās interakcijas stadijās, piesaistot skatienu un darot to, izveidojot savādāku skanēšanas rakstu. Nevienā gadījumā nav redzams „karstums” uz attēla, jo mums nav jāvelta daudz laika, lai to saprastu, taču mēs redzam attēlu stipro ietekmi uz aci.

Mēs varam noteikt atbilstību diezgan ātri, un ja attēls tiek atzīts par neatbilstošu, mēs ātri virzāmies tālāk. Piemēram, karstuma kartē augstāk, pieprasījums pēc „spice girls” parādīja parodiju klipu no YouTube, kas izrādījās mazāk atbilstošs par ierakstiem virs un zem tā. Lai gan attēls pievērsa uzmanību, tas to nenoturēja. Pievērsiet uzmanību, ka te bija arī vēlāka nosaukuma vai apraksta fragmenta (snippet) skanēšana. Te nebija informācijas „smaržas”.

Atbilstoša bilde

Salīdziniet to ar rezultātiem priekš Apple iPhone. Šajā gadījumā attēls izrādās atbilstošs un piesaista uzmanību. Tas noved pie skanēšanas, un, kas ir svarīgāk, rezultāta, kas pieder attēlam agrākas skanēšanas. Šis ir klasisks piemērs, kad attēls veido informācijas „smaržu”, kas pievērš pastiprinātu blakus esošās informācijas skanēšanu.


Personalizācijas ietekme

Tika iztestēts arī kā personalizācija varētu ietekmēt lietotāju pieredzi. Šajā scenārijā interakcija tika sadalīta divās daļās. No sākuma, pētījuma dalībniekiem tika dota iespēja pameklēt vairāk informācijas par Apple iPhone. Netika ierobežotas viņu online aktivitātes, taču tika piefiksētas mājaslapas, kuras viņi apmeklēja un kādus meklējumus viņi veica. Tad, šī informācija tika izmantota, lai izveidotu meklēšanas rezultātu lapas maketu, otrajai sesijai, kur pētījuma dalībniekiem tika palūgts atsākt, kur viņi beidza un turpināt meklēt vairāk par iPhone. Tika parādīti personalizēti rezultāti pozīcijās 3, 4 un 5, pielāgoti vietām, kur dalībnieki varētu meklēt informāciju. Pārējie rezultāti bija reāli Google rezultāti.

Personalizēts pret nepersonalizētu

Bija interesanti salīdzināt interakcijas ar 3., 4. un 5. pozīcijām, testa pozīcijas personalizētajos rezultātos personalizētajos maketos un nepersonalizētajās versijās.

Šie personalizētie rezultāti, lai gan tie neatradās pirmajās divās top pozīcijās pierādīja sevi ļoti labi. Grafiks zemāk norāda aplūkošanas laika procentus, fiksācijas procentus un reālos klikus nepersonalizētajos rezultātos attiecībā pret personalizētajiem. Karstuma kartēs augstāk, var redzēt šīs vietas salīdzinātas, pirmajā kartē nepersonalizēti rezultāti un otrā kartē – personalizētie rezultāti.

Grafiks

Acīmredzami, testa pozīcijām, personalizācija piešķīra stipru informācijas „smaržas” komponentu, ar šo ierakstu efektivitātes dubultošanos, salīdzinot ar nepersonalizētajiem rezultātiem. Šie trīs personalizētie rezultāti arī savāca divas reizes vairāk klikšķus, kā augšējie divi dabīgie rezultāti, dramatiska atšķirība no nepersonalizētiem rezultātiem, kur 3., 4. un 5. ieraksti savāca tikai trešdaļu no tiem klikšķiem, ko savāca 1. un 2. ieraksti. Personalizētie rezultāti piesaistīja gandrīz 4 reizes vairāk klikšķus, kā nepersonalizētie rezultāti.

Tagad aplūkosim, kas notiek, ja tiek kombinēti universālās meklēšanas rezultāti ar personalizētās rezultātiem. Šī kombinācija, vismaz, kā tā tika attēlota, parāda ļoti interesantu skanēšanas rakstu, kas varētu dot būtiskas norādes informācijas optimālākai izvietošanai lapā.

Kombinēti universālās meklēšanas rezultāti ar personalizētās rezultātiem

Vienkāršākais veids to parādīt būtu parādīt no sākuma kā izskatītos tipisks skanēšanas raksts, ja nebūtu iesaistīti universālie un personalizētie meklēšanas rezultāti:

Rezultātos lielākā daļa vērstu skatienu augšējā kreisajā stūrī, tieši virs (E). Tad tie sāktu skanēt lapu uz leju lineārā veidā, sākumā palūkojoties sponsorētajās reklāmās, kas atrodas „E” sadaļā, tad turpinātu uz dabīgiem rezultātiem „C” sadaļā. Izvēles brīvībai nepieciešamie ieraksti ir izvēlēti, visdrīzāk tie sastāvēs no diviem augšējiem sponsorētajiem rezultātiem un diviem augšējiem dabīgajiem rezultātiem, un ieraksts, kas piedāvās labāko atbilstību un „garšu”, tiks izvēlēts.

Taču aplūkosim kā attēla un personalizēto rezultātu ieviešana izmaina skanēšanas rakstu. Tagad skatiens tiek sākumā fiksēts uz attēlu un uz ieraksta nosaukumu, kas atrodas blakus (A), pēc tam ieraksts sadaļā „B” visdrīzāk tiktu noskanēts pirmais. Pēc tā, lietotājam būtu jāizvēlas starp ierakstiem virs un zem. Ja nebūtu personalizācijas, mēs pieņemtu, ka virsējiem rezultātiem būtu lielāka „smarža”, taču tā nenotiktu, ja personalizētie rezultāti iegūst no personalizācijas. Uzmanība tiktu piesaistīta uz leju (kas ir dabīga skatiena tendence), lielākas „smaržas” dēļ, ko nosaka personalizācija. No karstuma kartes ir redzams, ka personalizētie rezultāti novērsa diezgan lielu skanēšanas uzmanību prom no lapas augšas.

Vizuāli bagātākas un iespējami atbilstošāku meklēšanas rezultātu lapas ienākšana dramatiski ietekmēs, kā mēs skanējam šādu lapu. Pirms šī pētījuma bija ievērota diezgan viendabīgs skanēšanas raksts Google meklēšanas lapās, lai gan tas diezgan stipri atšķīrās no skanēšanas raksta starp Google, Yahoo! un Microsoft meklēšanas rezultātu lapām. Tas bija par spīti tam, ka visas trīs meklētājsistēmas izmantoja diezgan vienādu lapas izkārtojumu, un tam par iemeslu pārsvarā bija mazas formatēšanas atšķirības un tas, cik agresīvi meklētājsistēma rādīja top sponsorētās reklāmas. Taču, kad lapa kļūst par dinamiskāku vidi, mēs pielāgojamies, novēršoties no „no augšas uz apakšu, no labās uz kreiso” F veida skanēšanu, kas veidoja Zelta Trīsstūri, uz vairāk ogu lasīšanai līdzīgo interakciju, kas mainās atkarībā no elementu izvietojuma uz lapas. Pagātnē SERP reālā vērtības skala bija diezgan statiska: augšā un pa kreisi. Izskatās, ka nākotnē to būs daudz grūtāk nodefinēt.

Raksta autors ir Gord Hotchkiss, kompānijas Enquiro izpilddirektors.
Raksts pārtulkots no searchengineland.com.
]]>
Par TextAds.lv Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/textads.lv/ http://web.hc.lv/lietojamiba/raksti/textads.lv/ Thu, 20 Sep 2007 15:15:41 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Sakarā ar visām tām piņķerīgajām lietām, kas saistās ar Latvijas Republikas likumdošanu, laika un varēšanas trūkumu, diemžēl es no šī projekta lietošanas atteicos, toties man par prieku pieteicās BlogAds.lv lielais brālis — reklāmas servisa projekts TextAds.lv. Tā kā sāku to aktīvi lietot, vēlējos padalīties savos iespaidos par projektu kā arī minēt lietas, kas tad man viņu servisā šķita ievērības cienīgas vai kaitinošas.
(Raksts pārpublicēts no sv.lv/poligrafija/2007/08/15/par-textadslv/ ar autora atļauju.)

Pirmie iespaidi


TextAds.lvTextAds.lv dizaina veidotājs ir līdz galam sapratis galveno ideju — pasniegt visu pēc iespējas vienkāršāk, pārskatāmāk, bez liekas grafikas vai plašo fonu lietošanas. Tas priecē, jo līdz ar to arī nav nekādu problēmu izprast lapas navigāciju.

Zemāk var apskatīt pirmo lapu, ko ierauga apmeklētājs. Vienīgais, kas šeit būtu vēl labojams, ir šausmīgais kernings virsrakstos. To varētu daļēji atrisināt, nedaudz izretinot burtus. Krāsu gamma gan pirmajā lapā, gan arī iekšlapās ir labi pārdomāta un tā arī lietota — neparādās lieki, nevajadzīgi ievazājumi.

TextAds.lv front page

Šeit gan atkal jāatzīmē pieslēgšanās forma, kurā kārtējo reizi (tipiska kļūda Latvijas interneta projektos) tiek nez kāpēc ekonomēta vieta. Vai tiešām to uzrakstu «Aizmirsāt paroli?» nevarēja pārnest jaunā rindā, bet pirms pogas ielikt kaut nedaudz gaisa, lai tā nelīstu virsū paroles ievades laukam?

TextAds.lv front page pieslēgšanās forma

Pieslēdzamies un sākam lietot

Priecē tas, ka pirmais, ko es ieraugu, pieslēdzoties, ir tieši tas, kas mani interesē — aktuālā statistika.

Viena atkāpe — par navigāciju: to bultiņu, kas atrodas navigācijā zem teksta «Statistika» būtu jāvāc āra, jo es neredzu nekādu jēgu un pamatojumu, kāpēc tai tur būtu jāatrodas. Savukārt piktogrammai un tekstam «Iziet» būtu jāatrodas tajā pašā līmenī, kur visa pārējā navigācija, pa labi no «BUJ», varbūt vienīgi tai pelēkajā tonī un nedaudz mazākai, nekā pārējie navigācijas elementi. Tas, pirmkārt, sakārtotu augšējo joslu, otrkārt, vairs nevajadzētu teju 30px lielu gaisu un pelēku līniju zem navigācijas zilās strīpas.

TextAds.lv Statistika page

Šeit gan mulsina dažas lietas:
  • laika perioda izvēles pogas nav tādā pašā dizainā, kāda ir pieslēgšanās formas poga un līdz ar to nevar saprast, vai tas tiešām ir trīs punktu ievades lauks. Es ieteiktu te izvietot piktogrammas, kā tas ir augšējā labajā stūrī, kur ir iespēja atslēgties no sistēmas.

  • Tiek jaukti termini «meklēšana», «atlase» un «šķirošana». Rinda, kas iesākas ar vārdu «Meklēšana», patiesībā ir atlases rīks, tāpēc daudz prātīgāk būtu to sakārtot sekojoši:

    TextAds.lv Statistika page - atlases variants

  • Vai tas ir kāds joks — poga «Rādīt visus» ar tekstu «Rodyti visus»?

  • Man skrien šermuļi pār ādu katru reizi, kad redzu visādus trakos saīsinājumus bez paskaidrojumiem. Es būtu bijis ļoti pateicīgs, ja visus tos «eCPM», «Saņemti kr.», utt. paskaidrotu zem tabulas, nevis tikai "BUJ" (Šķiet, ka arī ar šo saīsinājumu man ir tas pats, kas cilvēkiem ar manis lietoto SA — sabiedriskās attiecības. Vai tad jūs nezinājat, ka "FAQ" angļu valodā ienāca un palika tikai un vienīgi tā pareizā skanējuma dēļ.)? Nemaz tik daudz vietas tas neaizņemtu un katrā ziņā būtu pat ļoti noderīgi.

Es būtu ļoti pateicīgs, ja pie saīsnēm uz visbiežāk lietotajiem laika periodiem tiktu pievienota arī saīsne «Visu servisa lietošanas laiku», jo tad man nebūtu jāklikšķina kalendārā 1900. gads vai jāiespringst, lai atcerētos, kad es esmu sācis lietot šo pakalpojumu.

No papildus fiškām, kuras es šeit gribētu redzēt, ir iespēja salīdzināt vienā lapā divus dažādus laika periodus, piemēram, iepriekšējo un tekošo mēnesi.

Kas tās «manas mājas lapas»?

Oki, skatamies tālāk — sadaļa «Manas mājaslapas». Neatgriezīšos vairs pie atlases formas, vien minēšu, ka arī pati ideja par «manas mājaslapas» man ne īpaši patīk. Es daudz labprātāk tur redzētu uzrakstu «Manas kampaņas» vai vienkārši «Reklāmas laukumi», kas precīzāk atspoguļotu to, ko es šeit daru, jo man tak vienā mājaslapā var būt vairāki reklāmas laukumi?!

Nemaz nerunājot par to, ka nav tādas «mājas lapas», ir «mājaslapas».

TextAds.lv Manas mājaslapas page

Pirmais, kas cērtas acij, ir piktogrammas — būtu tomēr jāizdomā, ko tad ar tām piktogrammām dara — vai nu krāso zilā krāsā, vai pelēkā, kā tas ir augšā pie saites «Iziet». Mans ieteikums būtu visur tad uztaisīt viņas zilas.

Vēl tas teksts «ievadīt jaunu mājas lapu», nu bāc, veči, vai teksts: «Pievienot jaunu» un izvietošana virs atlases formas, tieši zem sadaļas virsraksta nebūtu bijis daudz prātīgāka? Pirmkārt, tas elements atrastos vietā, kur to ir viegli uztvert un tas kontekstuāli tur iederas, otrkārt, trīs reizes neatkārtotos «mājas lapas».

Atšķirībā no "Statistikas" lapas, šeit pilnīgi noteikti zem tabulas ir nepieciešams paskaidrojums visiem formas elementiem, jo papildus tam, ka nevar saprast formas kolonnu nosaukumus, nevar arī atšķetināt bez «метода тыка», ko katrs no tiem pasākumiem nozīmē.

Es daudz nerunāšu par apakšsadaļām šajā lapā, t.i. — jaunas reklāmas kampaņas izveidi un esošās labošanu, vien piebildīšu, ka sarakstam ar reklāmas kampaņām un atsevišķu reklāmas kampaņu bloķēšanu es vēlētos redzēt pirmajā lapā, nevis ļoti neveiklā vietā pie esošās reklāmas kampaņas labošanas. To var mierīgi izvietot gan tabulā, gan arī blakus «Jaunas mājas lapas» pievienošanas iespējai.

Savukārt pati forma «Ievadīt mājas lapu» ir ļoti neveikli maketēta. Pie šāda izkārtojuma piezīmes zvaigznīti daudz pareizāk būtu izvietot labajā pusē ievades vai izvēles laukiem, paskaidrojumus, tādus, kā «Ievades forma: www.link.lv» būtu jāizvieto zem ievades laukiem, savukārt tekstu «Ekspozīcijas mēnesī:» jāizlīdzina no kreisās puses un būtu vēlams, lai šo formas daļu atdalītu no pārējās formas ar fonu (kā pie pieslēgšanās formas) vai arī līnijām no augšas un apakšas, ja jau tas viss attiecās uz vairākiem laukiem.

TextAds.lv jaunas kampanas pievienošanas page

Tieši tādas pašas un/vai līdzīgas problēmas skar arī lapas sadaļas «Informācija par maksājumiem» un «Mani dati».

Biežāk uzdoto jautājumu mučkulis

Šī ir tā daļa no lapas, kurā ir visvairāk tekstuālās informācijas un tai pat laikā tā ir lapa, ka ir visbriesmīgāk sakārtota. Pirmkārt, nez kāpēc saitēm uz biežāk uzdotajiem jautājumiem ir pazudis stils (visās lapās teksti ar saitēm ir melnā krāsā ar melnu līniju), bez tam, izvietojums vienā slejā, kad vienā rindā var būt pat 200 (!) simbolu ir vienkārši šausmīgs. Tāda biežāk uzdoto jautājumu sadaļa liek šaubīties, vai tiešām servisa īpašnieki vēlās, lai viņu atbildes kāds kādreiz arī izlasa. Es noteikti iesaku pārkārtot šo garo teksta penteri divās, varbūt pat trijās slejās, tādējādi gan atvieglojot lasīšanu, gan arī gūstot iespēju sadalīt jautājumus un atbildes loģiskos blokos.

Vēl viena nianse — lūgums kontaktus un tekstu par to, ka var vēl kaut ko uzjautāt uzmest lapas augšā. Es saprotu, ka, iespējams, lapas īpašniekiem nav bijusi vēlme atbildēt uz jau atbildētiem jautājumiem vēlreiz tiem cilvēkiem, kas neuzmanīgi pārskrien pāri jautājumu sarakstam, tomēr iekopēt jau gatavo atbildi un nosūtīt uz e-pastu klientam ir vienkāršāk, nekā skaidrot, ka patiesībā jau kaut kur apakšā BUJ lapā tik tiešām ļoti nepamanāmi ir iemesti kontakti, kur jāgriežas jautājumu gadījumā.

Secinājumi

Lapu ir nepieciešams sakārtot, piemērojot vienādu stilu visiem elementiem (pogām, virsrakstiem, saitēm, formām, utt.).

Ir pareizi jāizvieto atsevišķi funkcionālie elementi, nevis jāiesviež tie iepriekš neparedzamās vietās (jaunas reklāmas kampaņas pievienošana, reklāmas kampaņu bloķēšana, iziešana no sistēmas, utt.) .

Kopsummā jāsaka, ka lietuvieši "M2 technologijas", kuri ir šīs sistēmas izstrādātāji, ir godam pastrādājuši — sistēma ir ātra, un ja vēl salabotu šos dažus sīkumus, tā būtu arī sasodīti ērta lietošanā.
]]>
Par BlogAds.lv Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/blogads.lv/ http://web.hc.lv/lietojamiba/raksti/blogads.lv/ Wed, 19 Sep 2007 12:20:20 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Pēc dažādu resursu ļurināšanas par jauno servisu BlogAds.lv, nolēmu šamajā piereģistrēties un paskatīties, kas tad nu tas tāds ir, jo no lapas kā tādas neko saprast nevarēja.
Tad nu arī tālāk bija interesanti, jo izrādījās, ka izstrādātājs ir labi zināms cilvēks, kas palūdza, lai nedaudz pakomentēju projektu.

(Raksts pārpublicēts no
sv.lv/poligrafija/2007/07/16/par-blogadslv/ ar autora atļauju.)

Nu viss šis vēl tiek kodēts. Ceru šonedēļ visu noslīpēt un uzrakstīt arī kaut kādu help. Jo īstenībā viss ir vienkāršs - tiem kam pāris vārdos esmu apstāstījis tiem viss skaidrs.


Lūk, tieši tāpēc, ka viss ir pāris vārdos jāskaidro, izdomāju, ka varētu izpalīdzēt, lai nav nekas pāris vārdos jāskaidro un viss tāpat būtu skaidrs.

BlogAds.lv kopskats

Man šķiet, ka vienīgais, kas šajā projektā pašlaik ir nesakarīgi atbaidošs, ir vizuālā koncepcija, kuras šobrīd vienkārši nav. Līdz ar to ir ārkārtīgi neiespējami kaut ko saprast, kur kas ir jāmeklē.

Ģenerālās kļūdas

  1. Sadaļas "Par BlogAds.lv" un "Kontakti". Es īsti nesaprotu, kāds pamatojums būtu taisīt šīs divas sadaļas atsevišķi, ja jau informācija ir viegli un saprotami apkopojama vienā sadaļā "Par BlogAds.lv", kur var iemest gan kontaktus, gan arī citu juridiski/kā citādi nozīmīgu informāciju.

  2. Sadalītā navigācija. Es nespēju saprast jēgu, kāpēc būtu jāsadala navigācija kreisajā slejā un augšā esošajā. Tur dikti liels bardaks dēļ tā vien valda.

  3. Problēmas ar paskatu. Nu ir daudz dažādas lietas, kas krīt acīs, bet no svarīgākajām ir būtiski saprast, kas lapā ir nozīmīgs. Piemēram, priekš kam ir nepieciešams tik daudz līniju?

    BlogAds.lv sānu līnijas

    Šis ir gabaliņš no labās lapas puses.

    Vēl man ļoti nepatīk, ka kaut kas nav līdz galam sataisīts un kaut kur kaut kā karājās.

    BlogAds.lv valodas pārslēgšanas pogas

    Bet visu pārspēj viena poga, kas ievietota, lai varētu iziet ārā no sistēmas.
    BlogAds.lv poga "Iziet"

    Trīs reizes ir parādīts, ka šeit kaut kādā veidā var iziet (durvis ar bultiņu, podziņa ar krustiņu, teksts «Iziet»), bet tikai vienu reizi ir parādīts, ka kaut kur jānospiež (podziņa). Tas man atgādināja Ļebedjeva idiotēkā nokļuvušo attēlu.

  4. Formas. Katrā lapā ir kaut kāds bezjēdzīgs grafiskais klucis, kas tiek izvietots virs saturiskās daļas (meklē ekrānšāviņā zaļo kluci). Tas objekts novērš uzmanību un nenes nekādu funkcionālo jēgu.

    BlogAds.lv reģistrācijas formaIr ļoti haotiski sakārtotas atsevišķas lapas daļas, piemēram, pieslēdzoties aizpildāmā forma ir trakoti sarežģīta. OK poga, paldies dievam, vismaz sarkanā krāsā iekrāsota. Kas traucēja to visu sakārtot vairākās rindiņās, kaut vai, lai visu var atrast un viegli ieraudzīt? Piedevām, man pavisam nav skaidrs, kāpēc ir jāizvēlas starp Reklāmdevēju un Publicētāju (kuru vispār, skaidrības labad, labāk nosaukt par Blogeri)? Vai tā ir tālejoša doma, ka blogeris var pie sevis izvietot reklāmas, bet tai pat laikā var arī pārdot reklāmas laukumus citiem? Tad es drīzāk piedāvātu to parādīt pēc tam, pie pieslēgšanās, nevis sākumā. Daudz vienkāršāk būtu pieslēgties, vienkārši norādot e-pastu un ievadot paroli.

    Paroles aizmiršanas gadījumā, saiti uz lapu, kas atjauno paroli ir jāievieto pēc pirmās nesekmīgās pieslēgšanās mēģinājuma, nevis uzreiz pie tās formas. 90% cilvēku neaizmirst savas paroles katru dienu, bet ja aizmirst, tik un tā vismaz vienu reizi pamēģina kaut kādu ievadīt, lai pārliecinātos, ka tiešām kaut ko ir aizmirsuši.

  5. Saites. Visām saitēm ir jābūt ar kaut kādu loģiku, kas ļautu saprast, ka tās ir saites. Visvienkāršākais variants, un arī vispareizākais, ir saites pasvītrot.

  6. Tabulas un cita informācija. Iekšlapās visur ir nepieciešams uzturēt vienādu loģiku vizuālajiem elementiem. Zemāk redzams ekrānšāviņš no divām dažādām lapām, kurās abās ir tabulas/formas, kas nez kāpēc ir krāsotas, kā papagaiļa sekste

    BlogAds.lv tabulas

Tie ir tikai daži sīkumi, kas man šķiet, ir šobrīd nozīmīgākie labojumi, kas būtu lapā jāveic, lai servisa lietotājiem būtu daudz vienkāršāka dzīve. Jāatzīmē, ka es būtu nenormāli priecīgs, ja parādītos vēl sekojošas iespējas:

  • Ekrānšāviņi, kas parādītu, kā sistēma darbojas. Ideālā variantā - demo versija, kas ļautu paspēlēties ar sistēmu.
  • Loģisks un skaidrs paskaidrojums, kā kas notiekās un kā blogeris tiek pie naudiņas (un, no otras puses - kā reklāmdevēja naudiņa tiek iztērēta). Kaut vai elementāra zīmējuma veidā, kas parādītu, kā no punkta A līdz punktam B nonāk naudiņa.
  • Izmest visur ārā briesmīgo grafiku, pogas, krāsas, utt. Atstājam divas/trīs krāsas, kuras tad arī izmantojam visā lapā maskimāli visu parādot tekstuālā veidā un tadējādi samazinot trafiku.

Kamēr to visu pētīju, fiksi uzmetu maziņu paraudziņu tam, uz ko es ar to visu domāju (bet tam ir tikai un vienīgi skices funkcija un vizuāli man ir vieglāk paskaidrot to, ko es gribu).

Tātad, lai ir nedaudz vairāk skaidrs: Pie loguča piemetam klāt to LV un RU, lai jau tiek visiem un skaidrs ir, ka var dažādas valodas paņemt, bet iesaku pēc tam to iemest pie sadaļas "Mani dati", kur var valodu izvēlēties un tad pie loguča arī tās valodas vairs nerādīt.

Pieslēgšanās/atslēgšanās formu sakārtot tā, lai viņa ir saprotama. Izmest ārā izvēlni par to, kas es esmu - reklāmdevējs vai ņēmējs, bet parādīt to pēc tam, kad esi pieslēdzies, attiecīgi rādot vai nu navigāciju blogerim, vai navigāciju reklāmdevējam, bet gadījumā, ja tu esi gan viens gan otrs, tad rādīt abas navigācijas.

Visu pārējo bullshit samest pašā apakšā, ja nu kādam tiešām ļoti aktuāli ir zināt BlogAds.lv telefona numuru, tad lai viņš to atrod tur.

BlogAds.lv skice dizainam
]]>
Jaffa.lv lietojamība Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/jaffa.lv-lietojamiba/ http://web.hc.lv/lietojamiba/raksti/jaffa.lv-lietojamiba/ Sun, 26 Aug 2007 17:45:02 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Mazliet par Artūra Medņa projekta Jaffa.lv lietojamību.
Iespaidojoties no kāda raksta par citu Artūra Medņa projektu mobs.lv, nolēmu paturpināt tēmu un uzrakstīt savas pārdomas par jaffa.lv projekta lietojamību.

Sākšu ar labo. Patīkams, gaišs un „tīrs” dizains, ar salasāmiem burtiem un viegli saskatāmām saitēm populārajā Web 2.0 stilā.

jaffa.lv

popuri.us modulisSkaidri redzams, ka kopējo lapas augstumu varētu samazināt vismaz uz trešdaļu, samazinot nepieciešamību izmantot vertikālo scrollbar. Ja lapa ir veidota Web 2.0 stilā, kur viens no galvenajiem principiem ir "nost ar visu lieko un nebūtisko, atstāt tikai pašu nepieciešamo!", tad neizprotami šķiet, kādā sakarā šajā lapā ir palicis popuri.us modulis, kurš rāda nekorektu informāciju - vismaz man Google Toolbar neuzrāda, ka jaffa.lv lapai būtu vispār Google Pagerank. Novācot šo moduli tiktu ieekonomēts diezgan daudz "vertikālās" vietas. Tieši tas pats attiecas uz reklāmu augšā pašā redzamākajā vietā - pati reklāma ir apmēram 10 reizes (!) mazāka, nekā tai atvēlētais lauks. Pat augstumā reklāma ir 3x mazāka, nekā reklāmai atvēlētais lauks. Arī te būtu lieliskas iespējas samazināt lapas "vertikālo" garumu.


Nonākam līdz navigācijai.

jaffa.lv navigācija

Te nu atkal saskatāmas problēmas:
  • Navigācijas elementi (tabi) nav pietiekoši kontrastaini, lietotājiem ar vājāku redzi tas varētu sagādāt problēmas.
  • Vai man vienīgajam liekas, ka „Sākumam” vajadzētu atrasties sākumā, nevis beigās?
  • Navigācijas elementi nepilda vienu no svarīgākajiem saviem uzdevumiem – neatspoguļo, kurā sadaļā es pašreiz atrodos.
  • Ir pieņemts (un pierasts), ka noklikšķinot uz mājaslapas logo no jebkuras  lapas var nokļūt sākumlapā. Diemžēl, tikai ne jaffa.lv.

jaffa.lv ielogošanās logs

Ielogošanas lodziņā pēkšņi, nez kāpēc, paspīd teksts svešvalodā. Nedomāju, ka "Lost password?" tik slikti izklausās pārtulkots latviski, lai to nebūtu vērts tulkot.


Diemžēl, tikai vietām lapas saitēs pie <a> taga tiek izmantots arī title atribūts. It kā sīkums, bet šādiem sīkumiem piemīt tendence uzkrāties.


Noklikšķinam uz kādu saiti, lai apskatītu sīkāku informāciju par kādu pasākumu. Izskatās, ka attēliem vieta nav paredzēta. URL aderese arī nešķiet pārāk lietotājam draudzīga: http://www.jaffa.lv/pasakumi/job.php?job=255. Palūkojamies uz virsrakstu. Atkal kontrasta problēma. Tik liela, ka var pat nepamanīt vēl vienu kļūdu - ir redzams teksts "apskatīts reizes", bet nav rakstīts, cik tad reizes ir apskatīts.

jaffa.lv virsraksts
Intereses pēc palūkojos lapas kodā, kā tad tur izskatās šis virsraksts. Izrādās, ka tas ir tikai 3. līmeņa virsraksts ar tagu <h3>! Zem iekš <h2> taga atrodas daudz nebūtiskāks šajā lapā teksts "Un kurp tu dosies šonedēļ?" un <h1> tags... tādu nevar atrast. Tātad par semantiski pārdomātu kodu te nav pārdomāts, ar visām no tā izrietošajām sekām.


Starp citu, neizprotams šķiet arī <meta name="description"> un <meta name="keywords"> tagu pielietojums nelietderīgi pārblīvējot tos ar atslēgvārdiem, tikai lieki palielinot lapas koda apjomu.

Ok, pamēģināšu pameklēt, kādi pasākumi notiek klubā "Depo", kurš atrodas man tuvumā. Ierakstu meklēšanā "depo", skatos rezultātus:

jaffa.lv meklēšanas rezultāti

Tā arī neizpratu, vai meklēšana nestrādā, vai arī tiešām nekas netika atrasts, jo nekur nav norādīts, ka nekas netiek atrasts (patiesībā tieši šis fakts mani pamudināja uzrakstīt šo rakstu, tā vietā, lai pievērstos savu projektu labošanai un uzlabošanai).


Varbūt vēlos pievienot kādu pasākumu, kuru es organizēju? Spiežu pievienot pasākumu un te man liek reģistrēties! Tātad man ir jāreģistrējas, lai piepildītu lapu ar saturu? Nē, labāk, lai to dara tie cilvēki, kam Artūrs par to maksā (acīmredzot tā ir, jo savādāk es nevaru izskaidrot pievienoto pasākumu daudzumu, ņemot vērā faktu, ka ir jāreģistrējas, lai tos pievienotu. Varbūt tam ir kāds cits izskaidrojums (iespēja labot informāciju par sevis pievienotajiem pasākumiem?). Ja tā ir tad, tad to vajadzētu norādīt, lai tomēr radītu kaut nelielu motivāciju reģistrēties.

Patiesībā mani māc šaubas par šī projekta attīstību, ja tas paliks ar tādu koncepciju, kāda tā ir pašlaik. Visus pasākumus var atrast daudz atpazīstamākajā projektā notikumi.lv. Es no savas puses varbūt ieteiktu atrast savu nišu, savu mērķauditoriju un ievietot jaffa.lv tikai tos pasākumus, kas šai auditorijai interesētu (līdzīgi, kā tas tiek darīts www.hc.lv/afisa/), nevis gāzt iekšā visus pēc kārtas, kā tas izskatās pašreiz.

Nobeigumā piebildīšu, ka jā, es zinu teicienu par baļķi, aci un skabargu. Un es arī zinu, ka konstruktīva kritika ir daudz lietderīgāka, par klusēšanu - ja es vēlētu jaffa.lv projektam ļaunu, šī raksta nebūtu.
]]>
iPhone un mājaslapas Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/iphone-majaslapas/ http://web.hc.lv/lietojamiba/raksti/iphone-majaslapas/ Sat, 28 Jul 2007 16:23:38 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Neskatoties uz to, ka iPhone Latvijā diez vai iegūs plašu izplatību, līdzīgi kā iPod, tomēr ir interesanti uzzināt, kā padarīt mājaslapas lietojamākas aplūkošanai uz iPhone.
iPhoneUz iPhone darbojas MobileSafari, kas atbalsta sekojošus standartus:
  • HTML 4.01
  • xHTML 1.0
  • CSS 2.1 un daļēju CSS3
  • ECMAScript 3 (JavaScript)
  • W3C DOM Level 2
  • AJAX tehnoloģijas, ieskaitot XMLHTTPRequest
Netiek atbalstīts:
  • window.showModalDialog()
  • mouse-over events
  • Hover styles
  • Tool tips
  • Java applets
  • Flash
  • Plug-in installation
  • Custom x.509 certificates
Jāņem vērā, ka neviena faila izmērs, kurš tiek ielādēts, nedrīkst pārsniegt 10 Mb robežu.

Kā redzams, uz iPhone var darboties lielākā daļa mājaslapu un WEB 2.0 servisi. Protams, ka tiek ieteikts izmantot atzītas mājaslapu veidošanas metodes: atdalīt saturu no prezentācijas un darbības.

Protams, ka iPhone lapu ielāde notiek stipri lēnāk, ja tiek izmantota EDGE tehnoloģija. Tāpēc ir ļoti svarīgi, lai lapas izmērs būtu pēc iespējas mazāks, un būtiski ir arī lai lapas galvenais saturs lapas HTML kodā atrastos pašā sākumā, tādējādi ielādējoties ātrāk (viens no veidiem, kā to izdarīt ir aprakstīts te).

Izlasīt vairāk par to, kas jāņem vērā veidojot lapas, lai tās varētu ērti aplūkot uz iPhone, var apple.com lapā (angļu valodā). Tā kā iPhone atbalsta lielāko daļu no populārākajiem standartiem (varbūt izņemot Flash tehnoloģiju), tad pēc standartiem veidoto mājaslapu īpašniekiem īpaši nevajadzētu satraukties, taču varbūt būs interesanti uzzināt, kā ar vienas rindiņas palīdzību kodā var uzlabot mājaslapas lietojamību uz iPhone, ņemot vērā, ka būtiskākā iPhone atšķirība ir stipri mazāks ekrāns nekā datoram.



]]>
Kā paātrināt lapas ielādes ātrumu Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/ka-paatrinat-lapas-ielades-atrumu/ http://web.hc.lv/lietojamiba/raksti/ka-paatrinat-lapas-ielades-atrumu/ Tue, 12 Jun 2007 01:40:14 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Pēc lietojamības eksperta Džeikoba Nīlsena domām, ir labi, ja lapa ielādējas pārlūkprogrammā 1 sekundes laikā. Kā to panākt?
Paskatīsimies pēc kārtas visus procesus, kuri notiek pēc tam kad serveris ir saņēmis pieprasījumu pēc kādas lapas, un kā šos procesus iespējams ietekmēt.


Kods

Pirmām kārtām, ja lapa nav statiska (nav gatava lapa uz servera HTML kodā), bet gan HTML tiek veidots dinamiski, izmantojot PHP, Perl vai jebkuru citu valodu, tad jācenšas pēc iespējas optimizēt programmas kods, lai tas izpildītos pēc iespējas ātrāk. Protams, ka izpildes ātrums ir atkarīgs arī no servera parametriem – tā ātrdarbības, atmiņas daudzuma un citiem parametriem, taču diemžēl bieži vien mājaslapu veidotājiem nav iespējas ietekmēt šos resursus.


Informācijas kešošana uz servera

Cita lieta, kuru var izmantot, lai paātrinātu mājaslapas darbību, ir kešošana. Piemēram, ja mums mājaslapā ir jāattēlo nākamās dienas koncertu saraksts, kurš tiek veidots no ierakstiem datubāzē, tad katru reizi dienas laikā, kad kāds apmeklēs šo lapu, tiks pieprasīta un apstrādāta viena un tā pati informācija no datubāzes. Parasti šādu ierakstu atlase un apstrādāšana aizņem salīdzinoši lielu laiku.

Tātad optimizējam to tādā veidā, ka informācija tiek pieprasīta no datubāzes un apstrādāta tikai pirmo reizi pa dienu apmeklētājam atverot lapu un tādos gadījumos, ja tiek mainīta informācija par nākamās dienas koncertiem datubāzē. Pie tam šo apstrādāto informāciju saglabājam datubāzē vai failā un nākamreiz, kad tiek atvērta šī lapa un pieprasīta šī pati informācija, mēs vienkārši attēlojam iepriekš saglabāto informāciju, kura jau ir vienreiz apstrādāta, ieekonomējot gan servera jaudas resursus, gan laiku.

Līdzīgi protams var darīt ar komentāriem zem rakstiem un citu informāciju, kura ir jāatlasa un jāapstrādā konkrētai lapai.


Gzip kompresija

Tad, kad ir izveidota HTML lapa, tad bieži vien tiek izmantota iespēja to sakompresēt izmantojot gzip kompresiju, lai tā aizņemtu mazāk. Ja tiek izmantots PHP un Apache webserveris, tad to parasti var panākt Apache webservera konfigurācijas failā .htaccess ievietojot šādas rindiņas:

php_flag zlib.output_compression On
php_value zlib.output_compression_level 5


Ciparu var norādīt no 0 līdz 9, kas norāda uz kompresijas līmeni. Parasti tiek ieteikts neizmantot lielāku līmeni par 6, jo ieguvumu/patērētās jaudas attiecība sākt palikt nelietderīga. Reāli kompresijas rezultātā ir iespējams samazināt HTML lapas izmēru par 10%-50%, kas ir diezgan liels ieguvums. Pie tam ir iespējams sakompresēt arī CSS un Javascript failus.

Kompresējot ar gzip lapas ieguvums ir lapas izmēra samazināšanās, līdz ar to pie lēnāka interneta pieslēguma šāda lapa nonāks ātrāk no servera līdz lietotājam, kas protams ir liels pluss.


FBIB

Taču gzip kompresijai ir arī savi trūkumi. Viens no tiem, ir tas, ka kompresija var notikt tikai tad, kad PHP kods ir beidzis savu darbību. Tātad jāsagaida, kamēr izpildīsies pilnībā PHP kods, tad lapa tiek kompresēta uz servera un tikai tad tā kompresētā veidā tiek nodota tālāk apmeklētāja pārlūkprogrammai, kura šo lapu atkompresē un tikai tad var attēlot lapas apmeklētāja pārlūkprogrammā.

Neizmantojot gzip kompresiju, lapa var tikt sākta attēlota uz apmeklētāja ekrāna vēl pirms PHP kods ir beidzis savu darbību uz webservera, kas lietotājam šķitīs ātrāk, kaut arī lapas kopējais ielādes laiks var būt daudz ilgāks, nekā tad, ja tiek izmantota gzip kompresija.

Reāli tas notiek tā, ka tiko PHP kods izpildās un sākt dot ārā HTML kodu, tā šis kods jau tiek sūtīts uz lietotājam uz pārlūkprogrammu, kur tas jau tiek attēlots iespēju robežās (lietotājs jau redz lapas sākumu), kamēr PHP kods vēl turpina izpildīties uz servera.

Tāpēc ir cilvēki, kuri uzskata, ka FBIB (First Byte in Browser – pirmais baits pārlūkprogrammā) ir daudz būtiskāks parametrs, nekā visas lapas ielādes ātrums.

Kurš no variantiem ir pareizāks, izmantot gzip kompresiju vai neizmantot – tas laikam ir atkarīgs no konkrētās situācijas.


HTML Headers

Tātad lapa ir izveidota un vajadzības gadījumā arī sakompresēta un tiek nosūtīta uz lapas apmeklētāja pārlūkprogrammu. Izrādās, ka arī pa ceļam mēs varam mazliet piestrādāt pie lapas ielādes ātruma, izmantojot arī šeit kešošanu.

Izmantojot dažādus HTML Headers (PHP kodā, javascript kodā un citās valodās), mēs varam norādīt vai šīs lapas kopiju var saglabāt (un ja var, tad cik ilgi) uz proxy serveriem, kas atrodas starp mājaslapas serveri un lietotāja datoru. Līdz ar to, ja kāds vēlēsies aplūkot šo pašu lapu vēlreiz, iespējams, ka viņam tuvākais proxy serveris atsūtīs saglabāto (kešoto) lapas kopiju – tātad tas aizņems daudz mazāk laika, nevis ja lapa tiktu sūtīta no servera, uz kura lapa tiek veidota.

Te ir jāuzmanās ar to, kuru lapu kopijas drīkst kešot šādā veidā un kuras nē. Citādi var gadīties, ka, ja esmu ielogojies lapā http://www.serveris.lv/lapa/ un tajā rakstīts „Sveiks, Deniss!”, un kāds Pēteris gribēs pēc tam atvērt šo pašu lapu, tad viņam gaidītā „Sveiks, Pēteri!” vietā attēlosies „Sveiks, Deniss!”.


HTML kods

Tātad lapa nonāk veiksmīgi līdz lietotāja pārlūkprogrammai un, ja tai ir pielietota gzip kompresija, tad tā tiek atkompresēta. Ja tā nav kompresēta, tad to mūsdienu pārlūkprogrammas jau sāk mēģināt attēlot jau pēc pirmā baita saņemšanas.

Es uzrakstīju „mēģināt” apzināti, jo bieži vien šie mēģinājumi ir vairāki, kamēr lapa ielādējas pilnībā. Te nu ir ļoti svarīgs korekts kods, lai šādi mēģinājumi būtu pēc iespējas mazāk. Piemēram, ja nav norādīti bildes izmēri HTML kodā,  pie <img> taga izmantojot atribūtus width=" " un height=" ", tad pārlūkprogramma vēl nezin, cik daudz vietas uz ekrāna jāieplāno bildei, kamēr tā vēl nav ielādēta, tāpēc pārlūkprogrammai nāksies visu pārzīmēt vēlreiz, kad būs zināms, cik tad īsti bilde aizņem vietas uz ekrāna.

Tiek uzskatīts, ka ir slikts stils izmantot tabulas lapas izkārtojuma attēlošanai. Viens no iemesliem tiek minēts tas, ka tabulas tiek attēlotas tikai tad, kad tās un to saturs ir ielādēts pilnībā. Nemāku spriest, kā to dara pārlūkprogrammas mūsdienās, taču zinu pavisam noteikti pēc savas pieredzes, ka xHTML kodā veidota tabula uz FireFox 2.0 pārlūkprogrammas tiek sākta attēlota vēl pirms tabula ir ielādējusies pārlūkā pilnībā.


Pieprasījumu skaits

Nākamais, ko dara pārlūkprogramma, kad saņem HTML kodu pilnībā vai daļēji, tas ir tā veido pieprasījumus pēc bildēm, CSS failiem, javascript failiem un citiem, kuri ir norādīti saņemtajā HTML kodā. Te nu atkal, ņemot vērā tīmekļa darbības principus, jāsaprot, ka jo mazāk būs šādu pieprasījumu skaits, jo ātrāk tie tiks izpildīti un saņemta nepieciešamā informācija – tātad arī lapa ielādēsies ātrāk.


Kešošana, kuru veic pārlūkprogramma

Nepieminēju par vēl vienu kešošanas veidu – arī pārlūkprogramma veic HTML apmeklēto lapu un tajo iekļauto elementu kešošanu, ja vien lietotājs to ir atļāvis un ja pieprasītā lapa to pieļauj – šos parametrus var norādīt arī HTML kodā <meta> tagos.

Līdz ar to, ja tas ir iespējams, tad nākamreiz apmeklējot to pašu lapu, tā tiks nevis pieprasīta no servera, bet izmantota tās kešotā kopija, kura glabājas turpat uz lietotāja datora.


Neapmeklēto lapu kešošana

Ir vēl viens ļoti interesants veids, kuru izmanto arī Google, kā paātrināt lapas ielādes ātrumu – proti piespiest pārlūku ielādēt lapu kešā, pirms tā tiek pieprasīta. Piemēram, ja mēs ielādējam pārlūkprogrammā lapu ar kāda raksta pirmo daļu, tad, kamēr mēs to lasām, pārlūkprogramma mums nemanot var ielādēt kešā lapu, kurā ir raksta otrā daļa, pieņemot, ka tā būs nākamā lapa, kuru mēs vēlēsimies aplūkot. Šādu procesu sauc par „prefetching”. Tad kad mēs noklikšķināsim, lai pieprasītu lapu ar raksta otro daļu, tā jau būs ielādēta kešā un mums nebūs jāgaida, kamēr tā tiks nosūtīta no servera.

„Prefetching” efektu var panākt ar javascript palīdzību, taču ir arī cita iespēja.

Uz Mozilla bāzētie pārlūki un Google Web Accelerator (kuru var izmantot kopā ar Internet Explorer), atbalsta HTML tagus, kuri norāda, kuru lapu prefetčot. Šie tagi ir šādi:
<link rel="prefetch" href="http://url.to.prefetch/" />
un
<link rel="next" href="http://url.to.prefetch/" />
Nevar izmantot GET metodes pieprasījumus, kā arī https protokolu norādot saiti, kuru vajag prefetčot.


Javascript un AJAX

AJAX tehnoloģiju, kas balstās uz javascript parasti izmanto, lai nosūtītu datus (pieprasījumu) uz serveri, saņemtu atbildi no tā un ņemot vērā saņemto informāciju nepārlādējot visu lapu pārlūkprogrammā, izmainīt tikai daļu no lapas. Lielisks piemērs AJAX tehnoloģijas izmantošanai ir redzams draugiem.lv.

Pozitīvais AJAX izmantošanā parasti ir tas, ka netiek zaudēts laiks, kamēr pārlādējās visa lapa un arī serveris ir mazāk noslogots, jo tam ir jāsūta informācija nevis par visu lapu, bet tikai par vienu tās daļu - tātad stipri mazāk.

Negatīvais AJAX izmantošanā ir dažas lietojamības problēmas (javascript nestrādā uz mobilajām ierīcēm, mainot lapas saturu izmantojot AJAX iespējas, nevar tikt pie iepriekšējā lapas izskata nospiežot pārlūkprogrammas "Back" pogu un vēl dažas citas). Taču ja AJAX izmanto tikai kā papildus alternatīvu iespēju esošai iespējai, nevis esošās iespējas vietā (lai iespēja nezustu ja javascript ir atslēgts), tad daudzas lietojamības problēmas tiek atrisinātas un lietojamība tikai palielinās, jo AJAX risinājumi strādā ātrāk par tradicionālajiem, klasiskajiem risinājumiem.


Nobeigumā

Protams, ka ir arī citas metodes, kā tiek paātrināts mājaslapas ielādes ātrums, šeit tika apskatītas tikai dažas vienkāršākas. Beigās padalīšos ar noderīgu saiti uz kādu pakalpojumu, kurš gan, manuprāt, nepretendē uz pašu korektāko informāciju, bet tomēr dod kādu priekšstatu dažiem aspektiem, kā varētu censties uzlabot norādītās lapas ielādes ātrumu - Web Page Analyzer.
]]>
Kontakti mājaslapās Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/kontakti-majaslapas/ http://web.hc.lv/lietojamiba/raksti/kontakti-majaslapas/ Mon, 11 Jun 2007 17:08:10 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Cenšoties izsūtīt dažiem cilvēkiem informāciju par web.hc.lv, uzdūros kādai, manuprāt, diezgan lielai lietojamības problēmai, proti, daudzās mājaslapās vienkārši nevar atrast kontaktu e-pasta adresi.
Scenārijs sekojošs:

Vēlos nosūtīt MS Word dokumentu un attēlu lapas īpašniekam/administrācijai. Ieeju lapā un meklēju ierasto saiti lapas apakšā („footerī”) ar uzrakstiņu „Kontakti” vai „Par mums” vai ko tamlīdzīgu. Ja neatrodu apakšā, pameklēju citur lapā. Bieži vien neatrodu visā lapā. Tā, kā vajadzība nosūtīt e-pastu tomēr ir, tad pameklējos arī citās lapās tajā pašā vietnē. Ja arī tur neko neatrodu, tad ņemu talkā Google, lai gan tur būtu vismazāk cerības ko atrast, ņemot vērā iestājušos mēstuļu laikmetu. Un ja ir pavisam nepieciešamība un galīgs izmisums, tad var meklēties pa draugiem.lv

KontaktformaGadās, ka atrodas lapa, kur var, aizpildot formu, nodot informāciju lapas veidotājiem/īpašniekam/administrācijai. Diezgan ērti, jo nav jāver vaļā savs e-pasta klients, taču – formā nav iespējas pievienot failus, tātad manā konkrētajā gadījumā tas īpaši nepalīdz. Varētu jau protams formā palūgt kādu e-pasta adresi, taču, tas kontaktēšanās procesu lieki sarežģī.

Ir cilvēki, kuri uzskata, ka e-pasta adrese ir privāta lieta, kuru nevajadzētu publiskot, labi, lai tā ir. Bet kas tev liedz izveidot vēl vienu publisko e-pasta adresi?

Un īpaši, ja tu esi „publiska personībaa”, kura, iespējams, ir labi zināma, publicējies tīmeklī, tavu e-pasta adresi var noskaidrot dienas laikā no desmin/simts/tūkstotis citiem cilvēkiem vai pajautājot kāda nesenāka raksta komentāros (kas gan primāri ir domāti citiem mērķiem), tad es nespēju iedomāties, kāpēc gan šo procesu nepadarītu vieglāku, publicējot e-pasta adresi savā mājaslapā/blogā. Ja ir bailes no mēstulēm, tad ir izdomāti jau simts un viens veids, kā publicēt e-pasta adreses tā, lai tās nevarētu iegūt automātiski.

Protams, ka es nesāku pildīt formas un nesāku meklēt e-pasta adreses caur citiem „galiem”. Neesmu pārāk slinks pēc dabas, bet tomēr aizsūtīju vēstuli tikai tiem, kam atradu e-pasta adreses vai kuriem zināju. Un nākamo reizi darīšu tieši tāpat.

0nkuļa "Par mani" lapaMan personīgi patika 0nkuļa lapa „Par mani” (kaut arī to vajadzētu pārsaukt par „Kontakts”, jo neko vairāk kā savu e-pasta adresi pa 18. augusta piekdienām 0nkulis tur neatklāj) – e-pasts norādīts skaidri un lieliem salasāmiem burtiem, labākajās Web 2.0 tradīcijās.

Tā, ka padomājiet, ka, iespējams, jūs reizēm palaižat garām kādu izdevīgu iespēju vai klientu tikai tāpēc, ka jūsu lapā nav iespējams atrast jūsu e-pasta adresi.


Starp citu, ja kādam ieinteresēja šī tēma, tad iesaku palasīt rakstu angļu valodā, kurš ir publicēts www.alistapart.com "Your About Page Is A Robot".
Important stuff, and not too tricky, but while most organizations now recognize this page as an important opportunity to communicate, many still don’t.
]]>
Mājaslapas navigācija no lietojamības viedokļa Lietojamība Raksti http://web.hc.lv/lietojamiba/raksti/majaslapas-navigacija/ http://web.hc.lv/lietojamiba/raksti/majaslapas-navigacija/ Sun, 03 Jun 2007 01:57:26 +0300 web.hc.lv - vortāls tīmekļa veidotājiem Navigācija ir katras mājaslapas būtiska sastāvdaļa. Navigācija ir viena no lietām, kurām jāpievērš vislielākā uzmanība no lietojamības viedokļa. Tā nav tikai izvēlne, kā to daudzi iedomājas.
Pirms veidot navigāciju, ir jātiek skaidrībā ar mājaslapas struktūru – kādā veidā informācija mājaslapā tiks sagrupēta. Tieši no struktūras ir atkarīga navigācija. Tā kā šis raksts nav par struktūras veidošanu, tad tikai pateikšu īsumā, ka lapas struktūrai ir jābūt loģiskai un intuitīvai, lai lietotājam būtu skaidrs, kurā lapas sadaļā, kura informācija ir atrodama.

Mājaslapas navigācijai ir jāveic trīs galvenās funkcijas:
  1. Jānorāda, izvēles iespējas, kur jūs varat doties tālāk
  2. Jānorāda, kur jūs atrodaties pašreiz lapas struktūrā
  3. Jābūt skaidri saprotamam, kā nokļūt atpakaļ (sākumlapā)
Tradicionāli izvēlni izvieto aktīvākajā mājaslapas zonā – kreisajā augšējā stūrī, tāpat, kā lapas logo (parasti kalpo kā navigācijas elements). Iemesls šādam izvietojumam ir tas, ka mainot lapas izmērus (samazinot pārlūka logu), vai vienkārši aplūkojot mājaslapu uz ierīcēm ar maziem ekrāna izmēriem (plaukstdatoriem, mobilajiem tālruņiem), izvēlnei ir jābūt ērti pieejamai. Un otrs, vēl svarīgāks, iemesls ir tas, ka tā ir vienkārši jau ierasts, ka navigācija automātiski tiek meklēta pierastajā vietā.

Aktīvā zonaIr pierasts, ka uzklikšķinot uz mājaslapas logo, lietotājs nonāks sākumlapā – tāpēc arī mājaslapas logo var uzskatīt par navigācijas elementu. Šādam elementam ir liela nozīme gadījumā, ja lietotājs apjūk lapas struktūrā - viņam ir drošības sajūta, ka viņš jebkurā brīdī varēs nospiest uz logo un nokļūt sākumlapā. Cits iemesls, kāpēc logo parasti liek kreisajā augšējā stūrī, ir tas, ka logo ir lapas zīmols, un lai saglabātu lapas „branding”, tam jāatrodas nemainīgā vietā, turklāt, vēlams, lai to varētu redzēt jebkuros apstākļos.

Veidojot mājaslapas bieži domājot par navigāciju, atceras tikai pirmo navigācijas funkciju - norādīt, kur jūs varat doties tālāk, aizmirstot par pārējām divām. Bet arī ar šo svarīgāko funkciju ļoti bieži gadās lietojamības problēmas.

Ļoti bieži navigācija tiek izveidota ar javascript vai Flash palīdzību, aizmirstot par tiem pārlūkiem, kuri neatbalsta vai tikai daļēji atbalsta šīs tehnoloģijas, līdz ar to mājaslapa praktiski ir nebaudāma, jo navigācijas vienkārši nav. (Konkrēts piemērs: stats.tunt.lv statistika – pēc ielogošanās izvēlne darbojas tikai ar ieslēgtu javascript.)

Cita problēma ir tāda, ka izvēlne darbojas, taču tā nemaz neizskatās pēc izvēlnes. Saites izvēlnē ne ar ko neatšķiras no parasta teksta lapā, un vistrakāk ir tad, ja pat ar peli uzbraucot uz šādas izvēlnes, kursors nenomainās no bultiņas uz pierasto rociņu, kas ierasti norāda uz saiti.

Izvēlnē nevajadzētu piedāvāt vienā līmenī vairāk par 10 izvēlēm, lai nesamulsinātu lietotāju. Ja ir vairāk izvēles par 10, tad pavisam noteikti jāsāk domāt par par grupēšanu. Lietotāji nebūs tik pacietīgi, lai izlasītu 10 nosaukumus mēģinot atrast viņiem nepieciešamo informāciju.

Vairāklīmeņu izvēlnē jābūt skaidri saredzamam, kurā līmenī lietotājs atrodas, pretējā gadījumā izvēlne un lapas struktūra šķitīs kā vairākstāvu labirints.

Manuprāt liela kļūda ir veidot daļu no izvēlnes pa augšējo malu un daļu pa kreiso malu (kā tas ir tajos pašos draugiem.lv), vismaz es līdz šim nespēju izprast, kura draugiem.lv ir pirmā līmeņa izvēlne, kura ir otrā līmeņa izvēlne, un kura ir trešā līmeņa izvēlne, tāpēc man navigācija pa draugiem.lv atgādina tādu bakstīšanos uz labu laimi un intuīciju. Reizēm ar sesto prātu izdodas atrast meklējamo …

draugiem.lv izvēlnes

Ja jāizvēlas starp kreisās puses izvēlni un augšējo izvēlni (kuru parasti izveido tabu veidā, jāņem vērā sekojoši plusi un mīnusi.

Horizontālās un vertikālās izvēlnes salīdzinājums
Kreisās puses izvēlne (vertikālā) Augšējā izvēlne (horizontālā)
Tradicionāla un klasiska Mūsdienīgāka par kreisās puses izvēlni
Nav sadaļu skaita ierobežojuma Sadaļu skaits vienā līmenī ir ierobežots ar ekrāna platumu (kurš pie tam var būt mainīgs)
Lietotājam ne vienmēr ir skaidrs, kura sadaļa pašreiz ir atvērta Lietotājam uzskatāmi ir redzams, kura sadaļa pašreiz ir atvērta

Līdz ar to, veidojot kreisās puses izvēlni, būtu ļoti vēlams lapā ievietot arī tādu navigācijas elementu kuru angliski sauc par „breadcrumbs”, (pēc pasakas par Ansīti un Grietiņu, kur bērni atstāja aiz sevis maizes drupačiņas), kuras norādītu atpakaļceļu, kas skaidri norāda, kurā navigācijas līmenī un kurā lapā lietotājs pašreiz atrodas.

Breadcrumb

Veidojot navigāciju, sadaļām jādod skaidri saprotami nosaukumi, kuri skaidri un īsi norāda uz to, kas tajā lapā ir atrodams – bez jebkādām mīklām. Ja strikti nesekosiet lietojamības norādēm, jūsu veidotā mājaslapa jau tā lielākai daļai liksies kā milzīga mīkla, tāpēc veidot vēl papildus mākslīgi šādas mīklas nav jūsu interesēs.

Tas ir līdzīgi kā veikalā, kurā ieejot, jums ir skaidri jāzina, kur atrodas izeja, kurā nodaļā atrodaties jūs paši un ka pārtikas nodaļai jāsaucas „Pārtikas nodaļa”, nevis „Baudījums līdz pašai naktij”.

Izvēlnē pie sadaļas nosaukuma var pievienot klāt arī kādu ikoniņu, kas reprezentētu sadaļas saturu un nosaukumu, bet arī te ir ļoti jāuzmanās, jo vienu un to pašu ikoniņu dažādi lietotāji var (ne)uztvert pilnīgi dažādi.

Vēl viens būtisks navigācijas elements ir iespēja nokļūt atpakaļ – kā, un cik ērti lietotājs var nokļūt iepriekš atvērtajā lapā? Jāatceras, ka daudzi lietotāji meklē kādu saiti pašā lapā, un ir tikpat daudzi lietotāji, kuri lieto pārlūkprogrammas „Back” pogu, kura bieži vien pie AJAX risinājumiem mājaslapās bieži vien nedarbojas korekti (Piemēram, aplūkojot tajos pašos draugiem.lv bilžu albumā bildes, iepriekš apskatīto bildi nu nekādīgi nevar aplūkot vēlreiz, normāli nospiežot uz pārlūka „Back” pogu, kas personīgi mani ļoti tracina.)

Ceru, ka šis nelielais rakstiņš sniegs kaut nelielu ieskatu, kādām problēmām vajadzētu pievērst uzmanību, plānojot mājaslapas navigāciju. Ja kādam ir vēl kādas konstruktīvas domas par lietojamības problēmām lapas navigācijā – gaidīšu jūsu komentārus!
]]>