Veebilehekülje avalikustamine ja kasutusjuhendid

	Osta.ee	Selver.ee
Isikuandmete edastamine	Niisama ei edasta va Osta.ee valitud kollektiivile.	Ei edastata va kulleriteenustele.
Toote kättesaamine	Ei leidnud informatsiooni	2 varianti: Kohapealt kaupluses (10.00 – 22.00) ja kulleriteenusega lisatasu eest va kui hind on üle 39.99€.
Maksevõimalused	Sularaha, panga-ülekanne, Osta.ee rahakott	Ettemaksuna täies summas, muud informatsiooni pole.
Ostuvõimalused	Oksjon, Ostakohe hind	Klient loob e-poes endale ostukorvi, valib üleandmise viisi ja koha, tasub maksekeskkondades
Lepingust taganemine	Osta.ee kliendid on kohustatud ise leidma üksmeele.	14 päeva tagastada toode originaal pakendis
Pretensioonide esitamine	Pretensiooni esitamise aeg 21 päeva pärast oksjoni lõppu + tarneaeg.	Müüja vastub vigade tekkimise eest 2 aastat. Eeldatakse, et 6 kuu jooksul pole midagi juhtunud.

„ NB! Kasutajal tohib olla kuni 3 lahendamata või tema kahjuks lahendatud pretensiooni – seejärel on Osta.ee-l õigus tema konto sulgeda.“ Ehk siis on võimalik varikasutajate loomisega tekitada olukord kus kasutajakonto sulgetakse mis tundub tibakene ebaloogiline.

Selveri kasutajatingimustest leidsin sellise lause mis ei ole küll otseselt vastuoluline kuid kergesti erinevalt tõlgendatav: “kullerteenus Tallinna piires ning lähistel”. Leian, et kuna Tallinna piirid ei ole määratletud siis võib ka inimene Harjumaa piiri äärest tellida endale koju. Üldises pildis oli selveri tingimused kõik vägagi korralikud.

E-poodidel on kasutaja tingimused kindlasti kriitilise tähtsusega. Ilma nendeta on firmad täielikult ilma kaitseta kasutajate eest, ning samuti ka vastupidi. Kuid teades, et suuremosa inimesi nagu ka mina ei loe tihtipeale läbi ühtegi kasutajatingimust ja sellest tulenevalt on lihtsam panna linnuke kirja ja ignoreerida kohustulikku osa.

Ülessanne

Kasutatud kirjandus:

Osta (Kuupäev puudub). Osta. Loetud aadressil: https://osta-ee.postimees.ee/index.php?fuseaction=support.page&id=1048

Selver (Kuupäev puudub). Selver . Loetud aadressil: https://www.selver.ee/e-selveri-tingimused/

Heatmap for WordPress

Oma lehele paigutamiseks valisin siis Hotspots Analytics kuna ei olnud varasemalt heatmapidega kokku puutunud. Nagu kõikide pluginatega wordpressil tõmbasin selle alla ning laadisin läbi WinSCP serverisse ülesse.

Järgnevalt tuli aktiveerida plugin adminipaneelis. Ning sealt edasi oli kõik juba imelihtne. Antud plugin näitas ilusasti ära kõik kohad kuhu oli ekraanil vajutatud, kahjuks küll ei tekitanud see jooni hiire liikumistest kui õnneks oli jällegi ära näha väga detailselt kõik kasutaja poolt tehtud mõjutused.

Ainukene suurem probleem mida mina oma kasutamise jooksul leidsin oli see, et kui ma soovin vaadata heatmapi siis selleasemel et tabada ära, et kasutan localhost:5555 lehekülje kuvamiseks kasutas see lihtsalt localhosti ehk päris ühe klõpsuga minu jaoks ei saanud avada heatmapi pidin ümber kopeerima URLi ja siis lisama “:5555” juurde.

Ülessande link

Kasutatud kirjandus:

Dpowney, 2016, Hotspots Analytics, vaadatud veebilehel: https://wordpress.org/plugins/hotspots/

Otsingumootorid ja SEO

Esimese ülessande osa täitmiseks kasutasin WordPressi pluginat Google XML sitemap (Brachhold, 2016) mis genereeris sitemapi asukohale: “http://localhost:5555/~joosjoe/II.Aasta/Sygis/wordpress/index.php?xml_sitemap=params=”.

Ülessande teise osa täitmiseks valisin Google otsinguga “digiagentuur” minu jaoks teise lehe alguses asunud MCdigital kodulehe. Esmapilgul ütleksin, et veebileht näeb vägagi hea välja ja üldiselt väga lihtsasti navigeeritav. Google PageRank annab talle 0/10. Lehe laadimine võttis aega 6.6 sekundit minul mis ausalt öeldes minu jaoks ei ole veel liialt pikk aeg. Leht on samuti ka responsive ja huvitava faktina avastasin, et antud firma pakub isegi SEO optimiseerimis lahendusi.

Veebileht ise oli ülesse ehitatud WordPressi peale mis võib ka olla seletus miks ei leidnud ma ühtegi H1 ega H2 tagi. Saidilt ei leidnud ma ka sitemap faili kuid võimalik, et neil on kasutusel sama plugin mida mina kasutan ja see ei genereerigi otseselt faili. Metatagides oli kasutatud Open Graph Protocoli ja need olid vägagi üleküllastunud näiteks: “<meta property=”og:description” content=”Uus mobiilisõbralik koduleht, portaal, e-pood või värskendme / täiendame olemasoleva veebilahenduse.
VAATA LÄHEMALT

Veebileht on, kuid see ei too piisavalt kliente? Abiks on internetiturundus ja kodulehe optimeerimine
VAATA LÄHEMALT

Kujundame visiitkaardid, voldikud, flaierid, plakatid, kataloogid, sildid, roll-up’id bännerid.
VAATA LÄHEMALT

Vajate veebilehe või e-poe”>”. Antud tag on ilmselt suure tõenäosusega ka põhjuks miks Google nii madalalt hindab veebilehte.

Ettepanekud: Esiteks võiks genereerida leheküljele sitemap faili kui seda juba ei ole tehtud. ning teiseks võiks ülevaadata metaandmed ja natukene lühemaks tõmmata neid. Üldises pildis on lehekülg küll väga ilus ja toimib hästi, struktuur on ka hea.

Ülessande link

Kasutatud kirjandus:

Arne Brachhold. (2016). Google XML Sitemaps. Allalaaditud aadressil https://wordpress.org/plugins/google-sitemap-generator/

MCDigital. (2016). Vaadatud leheküljel http://mcdigital.eu/et/teenused/

Kujundusmalli valik

Minu valitud kujundusmalliks sai siis “Appointment Green”, mis on “Appointment” kujundusmalli tütarkujundus. Antud mallil on nii tasuta kui ka tasustatud variant ehk nii nagu ikka tasuta variandiga tuleb vähem asju koheselt kaasa kuid see eest ise on siiski võimalik kõike teha.

Kergete muudatustena panin siis endale omapärased pildid keerlema muutsin pealkirjad ära ja lisasin jalutsisse autoriõiguste teabe samuti leidsin, et reaalsuses roheline mulle ei meeldinud ja muutsin lehe css faili muutes lillaks. Üks probleemne koht mis tekkis oli kui üritasin muuta läbi wordpressi installitud theme siis sain write errori ehk kui wordpress selle temaatika installis siis läks omanikuks Apache server ja minul ei olnud enam õigust neid muuta. Selle probleemi lahendamiseks ma eemaldasin selle teema ja kopeerisin failid manuaalselt serverisse ja sellega tekkisid ka omaniku õigused minule.

Minu esimene soovitus teistele oleks siis eCommerce Store. Antud teema on sobilik juhuks kui soov on luua epoodi ning esmasel ülevaatusel paistab olevat vägagi kvaliteetne. Lehekülje tutvustus väidab enda tugevate külgedena soovilisti olemasolu, täielikult reageeriv kujundus ja kategooriate baasil otsing.

Teiseks temaatikaks valisin teema nimega Vice mis on rohkem blogimiseks ja piltide jagamiseks, nagu demolehelt paistab, mõeldud lehekülg. Vägagi ilusa väljanägemisega. Kahjuks ei ole teema kohta lisaks mingisugust lisainformatsioon kirjas kuid välimuse järgi oleks see minu valik kui sooviksin blogi pidada.

Kolmandaks ja viimaseks valisin The Skin teema. See on selline kõige tegemiseks mõeldud temaatika mis oma iseloomustuse järgi hiilgab turvalisuse, mitte ressursi nõudlikuse ja painduvusega. Jällegi ei ole liialt informatsiooni kirjas selle kohta kahjuks kuid see oli üks mu kahest algsest valikust oma lehele.

Ülessande link

Lingid kujundusmallidele:

Webriti. (kuupäev puudub). Appointment Green. Loetud aadressil http://webriti.com/appointment-green-child-version-details-page-1/

Themes4WP. (01.10.16). eCommerce Store. Loetud aadressil https://wordpress.org/themes/ecommerce-store/

Saumya010. (08.10.16). Vice. Loetud aadressil https://wordpress.org/themes/vice/

Ahmed Kaludi. (05.10.16). The Skin. Loetud aadressil https://wordpress.org/themes/skin/

WordPress püstipanek ja turvamine

Minu saatuslikuks valikuks sai siis WordPress CMS mille installimine Greeny serverisse oli üllatavalt vaevatu. Tõmbasin alla WordPress.org veebilehelt nende viimase väljalaske kopeerisin failid .zip failist ümber serverisse ühte kausta ning tuletasin veel meelde mis olid sqli kasutaja ja parool. Järgnevalt sai kuulsa wordpressi 5 minuti installi protsessi osaks olla.

Mõni minut hiljem oligi server püsti ja minule isikustatud admin kasutaja loodud. Järgnevaks etapiks oli panna püsti kaitse admin kataloogile, selleks kasutasin htpasswd varianti mille seadistasin kasutades thesitewizard(Heng, 2016) lehel olevat õpetust. Pärast mõningat jamamist ja lõpuks parooli omava faili asukoha korduvalt muutmist leidsin lõpuks koha kus see toimis ning sai ka selle probleemi lahendatud.

Server püsti ja esmane kaitse sellele peale pandud hakkasin otsima kujundamise võimalusi kuid täpsemalt sllest järgmises blogis.

Ülessande link

Kasutatud kirjandus:

Christopher Heng. (August 27, 2016). How to Password Protect a Directory on Your Website. Loetud aadressil: How to Password Protect a Directory on Your Website

WordPress vs Drupal

Olles läbi töödelnud kolm lehekülge, milles arutleti WordPressi võimaluste üle ja võrreldi neid Drupali võimalustega, olen jõudnud järeldusele, et nendega saab teha põhimõtteliselt samu asju kuid samas täiesti erinevalt.

Kõige suurem eristaja minu jaoks oli nende mõlema õppimiskõver. WordPressi oma on suhteliselt lineaarne kuid Drupali oma meenutab graafi kujul pigem suure kallakuga mäge mis ülevalt ära tasandub ehk Drupaliga on algus raske kuid samas lõpp on seda väärt.

Teine kõige tähtsam asi mida mina märkasin oli turvalisuse erinevused. WordPress on rohkem tuginev välistele pluginatele millel võib olla palju turvaauke. Kuna igalühel on võimalik antud pluginaid teha siis on see alati kergelt probleemne. Drupal see eest toendub rohkem iseendale samuti Drupalil on ka lehekülje tasemeline ja korporatsiooni tasemeline turvalisus tagatud(Bigtuna interactive) ehk on võimalik saada informatsiooni täpselt selle kohta kes mida tegi ja kuna kõik Drupali arendajad töötavad pigem rohkem samade asjade kallal pigem mitte nagu WordPressil igaüks oma pluginaga.

Peaaegu lõpetamiseks veel mõned erinevused nimelt nii WordPressil kui ka Drupalil on oma meetodid kuidas optimiseerida lehti nii, et need oleksid otsingumootorites kõrgel kohal WordPress kasutab pluginaid jällegi samas drupal on iseenesest natukene paremini ehitatud selleks nimelt sellel on sisse ehitatud erinevad cachemise meetodid mis täiustavad lehe laadimist ja samuti suudavad Drupali baasil ehitatud lehed kuvada rohkem informatsiooni sama ajaga ehk Google otsingumootor näiteks eelistab pigem natukene rohkem Drupali lehekülgi. (Barron, 2015)

Järgnevana räägiks lühidalt veel mobiilsusest ja on the go lahendustest. Antud alas minu jaoks võidab wordpress kuna neil on androidi äpp mida on väga lihtne kasutada ja millega saab teha kõike mida tavalises admini paneelis saab kuid drupalil see kahjuks puudub mainitud oli ühes artiklis küll, et drupali veebi administraatori paneel jookseb ka sama hästi mobiilil kui desktopil kuid ise ei ole seda saanud kasutada veel. Drupal on võtnud mobiilsete veebilehtede loomiseks ka seisukoha, et see peaks olema oma ala domeenis ehk see on tibakene halvem variant võrreldes worpressi kõik ühes süsteemiga mis muutub vastaval sellele millist veebilehitsejat kasutatakse.  (Barron, 2015)

Üldises pildis leian, et neid mõlemaid võib kasutada nii lihtsamate lehte tegemiseks kui ka raskemate ja see valik oleneb sellest millist sisuhaldus süsteemi on klient varasemalt kasutanud ja kas nad on nõus muutma oma harjumusi, kui klient ei ole varasemalt ühtegi kasutanud siis tuleks lähtuda veebilehe haldus süsteemi valikul sellest mida antud leht peaks suutma teha. Näiteks kui leht saab olema suhteliselt staatiline ja vaja on lihtsalt, et klient saaks vahepeal lisada endale mõne lõigu teksti või paar pilti siis soovitaksin valida wordpressi platformi kui aga plaanitakse teha suurt lehte millel peab olema palju võimalusi on mõtekam kasutada Drupali platformi.

Ülesande link

Kasutatud kirjandus:

Bigtuna interactive. (kuupäev puudub). WordPress vs Drupal. Loetud aadressil https://www.bigtunainteractive.com/wordpress-vs-drupal

Brenda Barron. (April 7, 2015). WordPress vs. Drupal: Choosing Between Two Platforms. Loetud aadressil https://www.elegantthemes.com/blog/resources/wordpress-vs-drupal

II teema: veebisaidi nõuded, dokumenteerimine

Valisin oma ülessandeks siis nii öelda kliendiga esimese kohtumise, kus uuritakse välja mida on tarvis, kuidas on tarvis ja milline see kõik olema peaks. Samuti saab tavaliselt sellel hetkel kokku lepitud kuidas saab olema töö eest tasustamine, kas staatilise hinnaga või tunnitasu eest, ning millist riistvara on veel kliendil tarvis, kes seda kõike haldama hakkab. Nagu näha siis see on osati toetuv meie tunnis tehtud ülessandele kuid nüüd üritan läheneda veidikene teise nurga alt.

Leidsin lisamaterjalide alt artikli milles ei olnud otseselt räägitud veebilehe loomisest kui pigem üleüldse projekti loomisest kuid suutsin sealt välja noppida paar põhi aspekti.

Esimeseks etapiks oleks siis välja uurida mis on projekti põhi ülesanded mida antud lehega edasi soovitakse anda ja mis on tema üldine funktsionaalsus. Sellega tagatakse, et veebiprogrameerija ja klient ei räägi üksteisest möödas ning hiljem kui leht on valmis ei tekiks hetke kus see ei vastaks kliendi tahtmistele.

Kui funktsionaalsus on juba läbimõeldud on alles kasulik liikuda edasi disaini juurde. Disaini poolest ei tohiks hakata üleliia hulluks minema kuna kohakuti, eriti esimeste lehtede juures võib klient eeldada palju rohkem kui te reaalselt valmis suudate teha. Pigem püsida rahulikuma ja võibolla mitte nii silma paistva kuid samas palju rohkem rafineeritud välimuse juurde. Alati tuleb ka kasuks kui kliendil on endal kerged kunsti oskused ja ta suudab koos disaineriga panna näiteks paberile plaani sellest milline leht olema peaks.

Kui lehe funktsionaalsus ja disain on välja mõeldud on võimalik edasi liikuda serveri vajaduste peale ning suuresti funktsionaalsuse baasil otsustada millist riistvara sinna tarvis oleks ning teavitada klienti sellest. Samuti saab nüüd hakata ka tekitama kerget arusaama sellest milline saab olema terve hinnapiir ning kas kliendile ja / või endale oleks kasulikum tunnipalga baasil teha tööd või leppida kokku kindlas hinnas.

Kui alustada funktsionaalsusest ning hoida kainet mõistust ei tohiks olla esimesel kohtumisel terve lehe probleemide lahendusi välja mõelda liiga raske.

Lõppu ka väikene pilt sellest milline üldine arendus järjestus välja peaks nägema.

Link ülessandele

Kasutatud kirjandus:

Chris Bank. Hold A Kickoff Meeting Before Diving Into The Design. Loetud aadressil https://www.smashingmagazine.com/2015/01/hold-a-kickoff-meeting-before-diving-into-the-design/

1.Kodutöö

Ülesande link

Kuidas ping lehe laadimist mõjutab ja miks on erinevate veebimajutuste puhul erinev?

Ping ehk latency on aeg kaua läheb informatsioonil, et jõuda veebilehitseja arvutist läbi erinevate ruuterite veebiserverini ja tagasi (HTG Explains). Seda mõõdetakse millisekundites ning eesti serverites olevate veebilehtedega nagu Delfi.ee ja Postimees.ee on DSL ühenduse korral minul ping <8 ms. Mida see tähendab on siis see, et kui ma vajutan lingile ühel neist veebilehtedest hakkab minu arvuti saama uue veebilehe informatsiooni juba 8 ms pärast. Sotsiaalmeedia saidiga Facebook on aga ping ~120 ehk umbes kümnendiku sekundi pärast saan ma informatsiooni uue lehe kohta. Võiks ju arvata, et kümnendik sekundist ei ole väga pikk aeg kui tahta liikuda veebilehtede vahel kuid kui näiteks server on koormatud ja asub teisel pool maakera võib tekkida juba kuni sekundiline viiteaeg ja lisaks veel lehe informatsiooni saamise aeg ning kokku ootabki 15 – 20 sekundit enne kui veebileht laetud saab.

Facebook on lehekülg millel ei ole serverit Eestis vaid lähim server peaks olema Rootsis (liialt täpset informatsiooni ei leidnud) ning selleks, et sealt informatsiooni saada peavad pakettid “hüppama” läbi mitme vahepealse teenusepakkuja. Sellest tulenevalt ka põhjus miks erinevad teenusepakkujad on erineva mõjutusajaga.

Kui oluline on riistvara veebimajutuse pakkujal?

Veebimajutuse pakkuja riistvara olulisus on suhteline. Olenevalt sellest kui palju inimesi külastab lehekülge igapäevaselt ning kui suur on lehe maht. Riistvarast oleneb see kui paljudele kasutajatele veebilehte on korraga võimalik näidata. Kõige tavalisem hetk kus on märgata veebimajutuse riistvara nõrgaks jäämist on kui veebileht muutub päevapealt kuulsaks ning saab kordades rohkem vaatamisi kui tavaliselt.

Tavalisel päeval suudab nõrk riistvara ära toita need mõningad inimesed kes seal päeva jooksul käivad kuid kui veebileht peaks populaarseks muutuma on tarvis riistvara uuendada või minna üle paremale süsteemile.

Millal on ping ja riistvara lehe veebimajutuse puhul väga oluline?

Ping ja riistvara võivad olla eriti olulised kui on tegu mingi veebimänguga nagu näiteks agar.io kus kõik kasutajad peavad olema oma vahel sünkroniseeritud. Kui mõnel kasutajal on väga kõrge ping siis server ei saa informatsiooni piisavalt kiiresti kätte ega saata teistele mängijatele ja tekib sisse tõkkamine.

Kasutatud kirjandus:

Autor teadmata. HTG Explains: How Latency Can Make Even Fast Internet Connections Feel Slow. Loetud aadressil http://www.howtogeek.com/138771/htg-explains-how-latency-can-make-even-fast-internet-connections-feel-slow/

First blog post

This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.