See on saidi täiendav lihtsustatud versioon, mis asub tavaliselt alamdomeenil eesliitega "m" (näiteks m.site).
Nagu tahvelarvutitel olevalt pildilt näha, siis telefonidele mõeldud versioon ka avab ja venitab laiusesse, sest tahvel on peaaegu väga-väga lai nutitelefon 🙂
Väliselt ja stiililiselt saab seda muidugi teha põhisaidiks (et ei jääks tunnet, et oled sattunud mõnele teisele lehele): samad värvid, fondid, elemendid. Kuid struktuur võib olla radikaalselt erinev ja enamasti on see nii. Vaevalt, et keegi telefoni teel endale korterit valib või autot otsib või pangast laenu taotleb. Lõppude lõpuks on see ebamugav, ekraan on väike (võrreldes sülearvuti või arvutiga). Kuid lähimate sularahaautomaatide või pizzeria aadressi leidmine on vastupidine. Seetõttu on mobiiliversioonid tehtud väga lihtsustatult, ilma keeruliste kalkulaatoriteta, kahe või enama sarnase toote tohutute võrdlustabeliteta. Eemaldage kõik kõige keerulisemad ja lihtsustage juurdepääsu kontaktidele, töörežiimile ja nii edasi.
Mobiilikasutajate osakaal kasvab ühtlases tempos: 2014. aasta lõpus ületas nende arv veebis esimest korda lauaarvutite kasutajate arvu. Rohkem kui 10 miljonit inimest pääseb Internetti AINULT mobiilseadmete kaudu. Ja see kõik toimub praegu Venemaal.
Kas teil on endiselt kahtlusi, kas vajate mobiilisaiti? Asume siis asja kallale.
Selle artikli eesmärk on tutvustada teile responsiivsete veebisaitide ja mobiilirakenduste arendamise põhiterminoloogiat ning aidata teil välja selgitada, millised meetodid teile sobivad.
Niisiis, loetleme peamised viisid, kuidas muuta oma teenused mobiilsetele vaatajaskondadele kättesaadavamaks.
Mõistete “adaptiivne” ja “reagatiivne” erinevuste teemal on palju Interneti-koopiaid purunenud ja selle kohta saate kirjutada rohkem kui ühe artikli, kuid terve esseekogu. Üldiselt on olemus järgmine: mõlemad mõisted viitavad saidi võimele kohaneda erinevate seadmete ekraanidega ja kuvatakse ühtviisi hästi nii laiatel monitoridel kui ka tahvelarvutites või mobiiltelefonides. Kuid "tundliku disaini" mõiste on mõnevõrra laiem ja sisaldab "tundlikku disaini". Seetõttu viitame edaspidi sellistele saitidele nagu kohanemisvõimeline.
Kohanemisvõime saavutatakse järgmiste tööriistade abil:
Kohanemisvõime näite leiate meie veebisaidi veebisaidilt. Alustage brauseriakna kitsendamist ja näete, kuidas ülemine menüü esmalt kahaneb, kohandudes akna suurusega, ja seejärel peidab end täielikult nn hamburgeri ikooni sisse. Näete sarnast kuva, kui avate meie veebisaiti mobiilseadmest.
Seega, kasutades adaptiivset disaini, saame veebilehe, mida on sama mugav kasutada igast seadmest. See on muidugi ideaalne, sest kui saidil on keeruline funktsionaalsus, on seda keeruline väikese mobiiliekraani raamidesse mahutada.
Vaatamata asjaolule, et mobiilseadme kasutajale võidakse näidata põhisaidi kärbitud versiooni, laadib brauser lehe täismahus: kõik tekstid, pildid ja skriptid, seega võib laadimisaeg olla üsna pikk, mis on puuduseks. kohanduvatest saitidest.
Selle asemel, et muuta oma sait kummitundlikuks, saate luua mobiilseadmete jaoks mõeldud eraldi versiooni. Olete selle meetodi näiteid näinud kümneid kordi. See näeb välja selline - põhisaidil on link "Mine saidi mobiiliversioonile".
See link avab eraldi saidi, millel on erinev URL, näiteks m.vk.com Vkontakte jaoks. Samuti on tavaline, et põhisait on konfigureeritud nii, et kõik mobiilikasutajad suunatakse automaatselt ümber mobiilisaidile.
Sellise saidi eripära on see, et see on mobiilseadmetes töötamise mugavuse jaoks maksimaalselt kohandatud: lehtede kaal on tihendatud, kõik mittevajalikud elemendid eemaldatakse. Mobiilikasutajatele on palju mugavam saada teie kohta vajalikku teavet ja esitada tellimus.
Pange tähele, et mobiiliveebisaidi loomiseks ei pea te programmeerimist mitu kuud õppima. Nüüd on palju teenuseid, mis võimaldavad teil poole tunniga saidi mobiiliversiooni luua. Kui soovid näiteks oma visiitkaardiga veebisaiti mobiilisõbralikuks muuta, siis suure tõenäosusega on selline mobiiliveebi koostaja kõik, mida vajad. Samuti pakuvad saidikonstruktori mobiiliversiooni teenust paljud hosterid, üksikasjaliku teabe saamiseks võtke ühendust oma hostimise toega.
Mobiilisaidi miinuseks võib olla see, et tegelikult tuleb ülal pidada kahte saiti ja teha kõik olulised muudatused kaks korda. Siiski võite veenduda, et mõlemad saidid on ühendatud samast andmebaasist ja kõik peamise teisendused viiakse läbi mobiilses, nii et mobiiliversiooni väljatöötamisel või konstruktori ostmisel on parem seda punkti selgitada.
Mobiilirakendus ei ole veebisait, vaid programm, mis installitakse kasutaja mobiilseadmesse. See selgitab selle lähenemisviisi peamisi plusse ja miinuseid.
Programm installitakse otse teie kasutaja telefoni / tahvelarvutisse, mis tähendab, et ta saab rakendusse siseneda ka ilma Interneti-juurdepääsuta, samuti saab kasutada tuttavat liidest ja kõiki oma seadme funktsioone.
Samal ajal on see miinus, kuna mitte iga kasutaja ei soovi mõne minuti toimingu tegemiseks rakendust installida. Või saab klient kohe pärast vajaliku teabe saamist selle kustutada.
Mobiilirakenduse arendamine on väga aeganõudev ja rahaliselt kulukas protsess. Veebisaidid on platvormidevahelised ja mobiilirakendused tuleb luua iga platvormi jaoks eraldi (iOS, Android, Windows Phone).
Muidugi on olemas spetsiaalsed tööriistad, mis lihtsustavad rakenduste loomist ja võimaldavad portida selle korraga kõikidele suurematele platvormidele, näiteks Phonegap, Ionic, jQuery Mobile. Kuid igal juhul peate rakenduse arendamiseks ja värskendamiseks ühendust võtma spetsialistidega.
Millal vajate mobiilirakendust? Tõenäoliselt siis, kui saate pakkuda kasutajale midagi, mis on talle kasulik ja huvitab teda pikka aega. Näiteks kui olete psühholoog, võite luua rakenduse nimega "Teie taskupsühholoog", mis sisaldab artikleid, teste, vastuseid küsimustele ja milles kasutaja veedab produktiivset aega.
Küsimus on selles, millist tulemust soovite rakendusest saada. Psühholoogi puhul on see pigem klientide lojaalsuse kasv ja potentsiaalsete ostjate lihtsam ümbersuunamine reaalseteks; kui rakendus neile meeldib, usaldavad nad tõenäoliselt psühholoogi rohkem ja tulevad tema juurde konsultatsioonile.
Kui projekt hõlmab kasutajate otsesuhtlust, siis oleks hea valik nii mobiiliversioon kui ka mobiilirakendus, kuid see on raske ja rahaliselt kulukas projekt.
Kui projekt on informatiivne, näiteks ajaveeb või uudisteportaal, siis sobib selle jaoks pigem tavaline adaptiivne paigutus.
Teadliku otsuse tegemiseks selle kohta, kas teie sait vajab mobiilsust ja millist valikut valida, peaksite vähemalt uurima veebianalüütika andmeid ja välja selgitama, kui suur protsent teie kasutajatest tavaliselt mobiilseadmeid kasutades teie saidile siseneb.
95% juhtudest piisab kohanemisvõimest või saidi mobiiliversioonist. Uue saidi loomisel tasub valida kohanemisvõime, olemasoleva mobiliseerimisel on sageli kiirem ja lihtsam välja töötada alternatiivne mobiilivõimalus.
Nii tõsist teemat ei saa ühes artiklis käsitleda, kuid proovisime põhiteavet rääkida. Küsige julgelt küsimusi kommentaarides, vastame neile üksikasjalikult.
Kui olete juba otsustanud, et teie sait tuleb "mobiliseerida", kirjutage meie tugiteenusele ja me ütleme teile, milline variant sobib teile kõige paremini ja kui palju see maksab.
P.S. Keda huvitab mobiilikasutajatega töötamise teema, kutsume teid 16. juulil meistriklassi "
Otsingureklaami hind ja selle tulemus sõltuvad sellest, kuidas me saiti mobiilseadmete jaoks kohandame.
Järjehoidjate juurde
Ashmanov & Partnersi optimeerija Dmitri Mrachkovsky rääkis, kuidas valida adaptiivse ja mobiilse saidi vahel ning milliste mitteilmsete probleemidega te kokku puutute.
Raske on üheselt vastata küsimusele, milline nutitelefonide ja tahvelarvutite kohandamistehnoloogia on SEO seisukohalt tõhusam. Isegi suurte tegijate seas ei märganud ma eelist mõne otsuse kasuks. M.Video, DNS, Wildberries, Aviasales kasutavad adaptiivset paigutust ning Lamoda, 220 Volt, Ulmart, Yandex.Market kasutavad mobiilisaite. Kuid vaatame, millist kasu saavad esimene ja teine.
Saidi "M.Video" ja saidi mobiiliversiooni "220 volti" kohandatav paigutus
Tundlik paigutus aitab teha ilma eraldi mobiiliversiooni arendamata. Sellel on eelised:
Mobiiliversioon on kulukam ja paindlikum lahendus. Seda saab muuta põhisaiti mõjutamata. See annab teile järgmised eelised:
Tahan mainida veel üht tehnoloogiat – RESS. See näitab kasutajale olenevalt seadmest laua- või mobiilimalli, kuid lehe URL ei muutu. RESS ühendab endas ülalkirjeldatud adaptiivse ja mobiilse versiooni eelised. Kuid sellel on ka kaks puudust: keeruline ja kallis rakendamine ning vead haruldaste ja ebapopulaarsete telefonimudelite tuvastamisel.
Responsive on ökonoomne ja mugav lahendus, kuid otsingu edendamise osas on sellel mitmeid lõkse.
Mõned rakendavad adaptiivset paigutust valesti ja kuvavad koodis ühel lehel korraga kahte malli – lauaarvuti ja mobiili. Olenevalt kasutaja seadmest jääb soovitud osa koodist nähtavaks, ülejäänud aga peidetakse ekraani abil: none . See tõstatab kolm probleemi:
Selline teostus on vale lähenemine RESS-tehnoloogiale.
Adaptiivse versiooni liidese mugavamaks muutmiseks vabaneb mõni osast funktsionaalsusest: segavad plokid, suured tekstid kataloogikategooriates jne. Kõik üleliigne peidetakse kuva abil: none . Kuid probleem on selles, et lehe laadimiseks kasutatakse kogu koodi ja sait on aeglane. Lisaks, nagu eespool mainitud, suhtuvad otsingumootorid sellisesse sisusse vastuoluliselt – on oht sattuda sanktsioonide alla.
Mõned kasutavad JS-i, et vältida tarbetute plokkide kuvamist mobiilseadmetes. Kuid see meetod pole parem kui kuvamine: puudub . On oht, et otsingumootorid ei indekseeri neile mõeldud sisu isegi lauaarvuti versioonis. Otsingumootorid ei taju üldiselt AJAX-i sisu alati õigesti, eriti kui õige indekseerimise tingimused ei ole täidetud.
Adaptiivse valikul on tavaliselt kaks peamist eelist: saidi ainult ühe versiooni arendamine ja probleemide puudumine mitme URL-iga.
See on ka mugav lahendus mitmesse piirkonda reklaamimiseks. Keskendume kõik oma jõupingutused ühele domeenile ja saame tulemusi lauaarvuti- ja mobiiliotsingutes. Selleks peate linkima huvipakkuvad piirkonnad saidiga Yandex.Directory.
Ja Google'i jaoks looge leht filiaalide aadressidega, et otsingumootor mõistaks, millistes piirkondades te töötate. Ühe domeeniga adaptiivset paigutust kasutab M.Video väga edukalt. Kauplus on toote-, kategooria- ja teabepäringute mobiili- ja töölauatulemustes kõrgel kohal.
Võite minna ka teist teed pidi – kasutage lehtede teksti asjakohasuse suurendamiseks geo-alamdomeene. Sel juhul määratakse alamdomeenidele nagu spb.site.ru, samara.site.ru, kazan.site.ru piirkonnad Yandex.Webmasteri kaudu ning seejärel määratakse pealkirjad ja metasildid koos toponüümiga. Teine pluss on see, et geo-alamdomeenide jaoks on lihtne seadistada eraldi analüütikat, et jälgida tulemusi piirkondade kaupa. Seda reklaamimeetodit kasutab MediaMarkt.
Suhteliselt kõrge arenduskulu pole mobiilisaitide ainus puudus. Siin on loetelu vähem ilmsetest probleemidest, millega võite selle tehnoloogia valimisel kokku puutuda.
Mobiilisaiti optimeeritakse ja reklaamitakse põhisaidist eraldi ning see nõuab rohkem ressursse kui adaptiivse puhul. Peate alustama optimeerimist, et mobiiliversioon oleks õigesti indekseeritud ja ei konkureeriks lauaarvuti versiooniga. Selleks linkige need Yandex.Webmasteris ja Search Console'is, määrake õiged rel="alternate" atribuudid, seadistage indekseerimine ja XML-kaardi genereerimine.
Laua- ja mobiilimallid laadivad sisu samast andmebaasist 99% juhtudest. Kui see kasutab absoluutseid linke töölaua saidi siselehele, märkides protokolli ja domeeni, siis kuvatakse need ka mobiililehel. Kui klõpsate lingil, ilmneb üks kahest stsenaariumist:
Sel juhul võidakse rikkuda saidi siselingi kaalu. Selle probleemi vältimiseks kasutage oma sisus suhtelisi linke. See tähendab, et atribuudi href jaoks määrake https://site.ru/page/ asemel /page/.
Laua- ja mobiilisaitide sisu ja struktuur võivad erineda. Seetõttu on loogiline vigade vältimiseks otsingus mõlema sisu indekseerida. Google soovitab mobiiliversioonil näidata, et töölauasaidi sisu on kanooniline. Teisalt ütleb otsingumootor, et mittekanooniliste lehtede sisu ei võeta arvesse.
Yandexiga on selles osas kõik selge - see indekseerib eraldi mobiili- ja töölaualehtede sisu. Selleks määra lihtsalt põhiversiooni atribuut rel="alternate" mobiiliversioonile ning lisaks saate seadistada 301 ümbersuunamist töölauaversioonilt mobiiliversioonile, võttes arvesse seadme kasutajaagenti.
Mobiilipõhisele registrile üleminekuks valmistumiseks on loogiline valida kanooniliseks leheks saidi mobiiliversioon. Tõsi, soovitustes, mis puudutavad esmalt mobiili, on mõned ebaselgused. Näiteks Google'i juhised ütlevad, et mobiili- ja lauaarvutiversioonide sisu peaks olema sarnane, kuid ei avalda "sarnasuse" määra.
Aga mis siis, kui lauaarvutiotsingus järjestamiseks on vaja teatud sisuplokki, mis on mobiiliversioonis üleliigne, kuid eelisjärjekorras on mobiiliversioon?
Väljavõte Google'i mobiilisaitide indekseerimise juhendist
Väljavõte Google'i aruandest mobiilipõhise indeksi rakendamise kohta
Mõned uuendavad otsingumootoreid valimatult, lootes, et see mõjutab paremusjärjestust. Näiteks Yandexi turbo lehed, mis ei asenda otsingus täisväärtuslikke mobiililehti, sisaldavad väikest osa kasutaja funktsioonidest ja toovad vähem konversioone. Kui teil on kommertssait ja olete mobiiliversiooni kvaliteedis kindel, ärge kiirustage "turbo" rakendamist - isegi artiklite ja arvustustega lehtede puhul.
Lingid on edetabelis endiselt olulised, eriti Google'i otsingus. Kui meil on mobiili alamdomeen, hakkavad mõned kasutajad sellele sotsiaalvõrgustikes ja foorumites viitama. Ja teine osa kasutab linke saidi põhiaadressile. Selle tulemusena toimivad lingid mobiili- ja lauaarvutiotsingutes vähem kui siis, kui meil oleks üks domeen.
Eespool rääkisime kahest võimalusest kohanemisvõimet piirkondlikult edendada – kasutades ühte domeeni ja geo-alamdomeene. Kaaluge neid mobiiliversioonide valikuid.
Esimesel juhul reklaamime põhidomeeni ja mobiili alamdomeeni m.site.ru. Igaüks neist peab määrama piirkonnad Yandex.Directory kaudu. Probleem on selles, et mõnikord ei saa saidi mobiiliversiooni iseseisvalt filiaaliga linkida. Peate võtma ühendust tehnilise toega, kuid see ei garanteeri tulemust. Saidi mobiiliversiooni jaoks ei saa luua eraldi organisatsiooni. Seega, kui oksi on palju, võib sidumine võtta kaua aega.
Üldiselt välistame alamdomeenide (nt m.spb.site.ru või spb.m.site.ru) kasutamise. Kuigi näiteks Kholodilnik.ru kasutab seda. Kuid sel juhul peate seadistama adresseerimise kõigi mobiili- ja lauaarvutiversioonide piirkondade vahel, hoidma neid ajakohasena, jälgima muudatusi ja jälgima veebihaldurite teenuseid. See on tohutu töö, mis ei tasu end tõenäoliselt ära.
Kui te ei saada Yandex.Webmasterile mobiilisõbralikkuse testimiseks oma saidi optimeeritud versiooni, ei pruugita seda mobiiliotsingu tulemustes ilmuda. Probleem puudutab ka kohanemist. Seda ei juhtu alati, kuid soovitan teil jälgida Webmasteri sõnumeid.
Fragment suhtlusest Yandexi tehnilise toega saidi mobiiliversioonile piirkonna määramise kohta
Mobiiliversioonide peamised eelised on loomulikult võimalus luua eraldi mall ja suur allalaadimiskiirus. Lisaks on vanadel saitidel lihtsam luua eraldi mobiiliversioon kui rakendada adaptiivset.
Samuti märkisid paljud SEO spetsialistid otsinguliikluse kasvu pärast mobiilisaidi kasutuselevõttu adaptiivse saidi asemel. Kuigi ma ei välista, et kasvu põhjuseks oli nende adaptiivses paigutuses esinenud vead, mis pingerida negatiivselt mõjutasid.
Kui arendate veebisaiti nullist või teil on väike projekt, vaadake adaptiivset paigutust lähemalt. See on säästlikum ja kiirem lahendus. Kuid parem on funktsionaalsust kohe planeerida, et te ei peaks osa saidist tulevikus mobiilseadmetes kuvamise eest varjama.
KirjutageMobiilseadmete buumi tulekuga seisid arendajad valiku ees: kas nad peaksid säilitama oma saitide mobiiliversioonid koos "täisväärtuslike" versioonidega või peaksid saidid muutuma tundlikuks ja kohandama end erinevate ekraanisuurustega?
Praegu on saitide mobiiliversioonide loomisel nende loomiseks kolm peamist viisi:
@meediaekraan ja (maksimaalne laius: 1600 pikslit) ( div.näiteks (laius: 1500 pikslit;) ) @meediumiekraan ja (max-laius: 1280 pikslit) ( div.näiteks (laius: 1100 pikslit;) ) @meedia ekraan ja (maksimaalne laius: 1024 pikslit) ( div.näiteks (laius: 980 pikslit;) )
Üldiselt õigustab saitide mobiiliversioonide loomine end üsna hästi, eriti suurte projektide puhul. Näiteks kasutab Amazon saidi spetsiaalset mobiiliversiooni.
$DS = DIRECTORY_SEPARATOR; nõuda_once(dirname(__FILE__) . $DS . "teegid" . $DS . "brauser.php"); $seade = BBrowser::detectDevice(); if($device == DEVICE_TYPE_MPHONE)( $tmpl = "mall.m.php"; ) else if($device == DEVICE_TYPE_TABLET)( $tmpl = "mall.t.php";) else( $tmpl = "mall .php"; ) include(dirname(__FILE__) . $DS . "mallid" . $DS . $tmpl);
Üldiselt on RESS kolmest pakutud variandist parim, kuid see nõuab arenduse käigus palju rohkem pingutusi.
Tänapäeval liigub enamik inimesi internetis läbi mobiilividinate – tahvelarvutite, telefonide, sellega seoses on ka saidi optimeerimine jõudmas uuele tasemele. Kui kasutaja siseneb ja näeb, et sait pole mobiilseadmete jaoks optimeeritud: pilti ei saa vaadata, nupud on välja nihkunud, fondid on väikesed ja loetamatud, kujundus on viltu - 99 100% -st, et ta lahkub ja hakake otsima teist mugavamat. A märgib kasti, et ressurss on ebaoluline, st see ei vasta otsingupäringule. Seetõttu tuleb lehe kujundust kohandada erinevatele mobiilsetele seadmetele. Mis on saidi mobiiliversioon, kuidas seda teha ja kuidas seda kõige paremini rakendada? Lisateavet leiate sellest artiklist.
Seega on saidi mobiiliversiooni jaoks kohandamiseks neli peamist viisi.
Reageerivad mallid muudavad saidi pilti sõltuvalt ekraani suurusest. Reeglina on need seatud standardsetele 1600, 1500, 1280, 1100, 1024 ja 980 pikslitele. Rakendamiseks kasutatakse päringuid. See ei muutu iseenesest.
Selle meetodi eelised hõlmavad järgmist:
Muidugi on adaptiivsetel mallidel oma puudused, mis muide on rohkem kui eelised. Sellegipoolest järgivad seda kontseptsiooni paljud arendajad, näiteks Google Corporation, kelle saidi mobiiliversioon on adaptiivse kujundusega. Niisiis, miinused:
Sellegipoolest võimaldab selline saidi mobiiliversioon kiiresti, ilma eriliste oskuste ja kuludeta kohandada ressurssi mis tahes vidinatega. Kuid loetletud puudusi silmas pidades sobib see väikestele, lihtsatele ressurssidele minimaalse teabe ja multimeediaga, ilma keeruka navigeerimise ja animatsioonita. Keerulise saidi jaoks sobivad veel 2 meetodit.
See meetod on väga levinud ja on sageli edukas saidi mobiilseadmes loetavamaks muutmisel. Selle olemus on luua rakenduse jaoks eraldi lehe versioon, mis asub eraldi URL-il või alamdomeenil, näiteks m.vk.com. Samal ajal säilib põhifunktsionaalsus, saidi kujundus näeb lihtsalt erinev välja. Selle meetodi eelised on ilmsed:
Kuid isegi siin polnud puudusteta:
Üldiselt õigustab eraldi mobiilisait end ja on kõige levinum viis ressurssi mobiilseadmete jaoks kohandada. See on populaarne suurte veebipoodide, nagu Amazon, seas.
Google'i otsingumootor toetab seda mobiilidisaini suunda aktiivselt. See on kõige keerulisem, kulukam, kuid tõhusam meetod saidi kohandamiseks telefoni või tahvelarvutiga. Seda nimetatakse RESSiks. See on ressursi sihtimine mobiilirakendusse, mille saab alla laadida iga seadme jaoks eraldi. Androidi jaoks - GooglePlayga ja Apple'i jaoks - iTunesiga.
Sellised rakendused on kiired, tasuta, mugavad, võimelised mahutama erinevat tüüpi teavet, samas kui telefoni mälu ja Interneti-liiklus ei söö ära nagu brauseri kaudu saiti külastades. Neid on lihtne külastada, kuna link on alati ekraanil käepärast ja pole vaja brauseri aadressiribale keerulist nime sisestada.
Muidugi on siin ka miinuseid, nagu keerukus arenduses, suure hulga programmeerijate kõrged tööjõukulud ja vajadus teha mitu paigutusvalikut. Mõnikord ei tunne rakendus mobiilseadet ära. Vajalik on regulaarne tehniline tugi, puuduste parandamine. Sellegipoolest peetakse seda kolmest pakutud võimalusest parimaks selle produktiivse ja katkematu töö tõttu.
Kõik ülaltoodud meetodid hõlmavad, kuigi mitte alati pikka ja keerukat, kuid siiski tasustatud veebihalduri tööd. Kui te ei näe sellise arenduse järele tungivat vajadust, sobib teile saidi lihtne ja tasuta mobiiliversioon. Kuidas on seda kõige lihtsam valmistada?
Reageeriva disaini jaoks laadige alla spetsiaalsed mallid (pluginad). Näiteks WP Mobile Detector, WordPress Mobile Pack, WPSmart Mobile ja teised. Need aitavad saiti telefonis korrektsemalt kuvada, samas saate paar näpunäidet selle kohta, mida on vaja parandada, et leht paremini mobiiliversiooniga kohandada.
Muidugi ei sobi see meetod tõsiste ressursside jaoks. Pigem on see tasuta funktsioon mõeldud väikestele ja lihtsatele saitidele, ajaveebidele, uudistevoogudele. Ärge unustage, et Google'i otsingumootor ja ka Yandex esitavad tänapäeval mobiiliversioonidele tõsiseid nõudmisi, seega on selle meetodi abil suur võimalus oma positsioone alandada.
Selle meetodi abil lõigatakse suure tõenäosusega reklaamid ja hüpikbännerid ära, kuid leht laaditakse kiiresti ja ilma viivitusteta.
Pole vahet, kas saidi mobiiliversioon loodi tasuta või veebihaldurite abiga, see tehti RESS-süsteemis või adaptiivse malli abil. Kõige tähtsam on see, et selle tõhusaks toimimiseks on vaja järgida mitut äärmiselt olulist põhimõtet. Niisiis, milline peaks olema saidi mobiiliversioon? Kuidas muuta see tootlikuks, tõhusaks ja tootlikuks?
Minimalism on see, mille poole saidi mobiiliversiooni arendaja peaks püüdlema. Kujutage ette, kui raske on tajuda teavet, mis on täis värve, nuppe, bännereid ja mida peate õige materjali otsimiseks lõputult sirvima. Mobiilne disain peaks olema lihtne ja puhas. Valige ruumi jagamiseks 2-3 värvi (näiteks kaubamärgiga). Parem, kui üks neist on valge. Jagage väikese ekraani ruum arusaadavateks ja loetavateks tsoonideks. Virtuaalsed võtmed peaksid olema nähtavad, et kasutaja teaks selgelt, kuhu vajutada ja näeks - siin on toode, siin on andmete täitmise vorm, siin on info kohaletoimetamise ja maksmise kohta.
Kõik lisavõimalused, mis töölauaversioonis kasulikud oleksid ja kasutaja elu lihtsamaks teevad, toovad siin vaid raskusi. Jätke ainult kõige olulisemad elemendid. Animatsioon, reklaambännerid, multimeediumid tõenäoliselt ainult aeglustavad saidi või rakenduse tööd ja tõmbavad tähelepanu peamiselt kõrvale.
Joondamise küsimus pole vähem terav, sest kui seda valesti teha, saab kasutaja ainult oluliste sõnade lõpud. Vasakpoolne ja vertikaalne joondus on üldiselt aktsepteeritud. Kujutage ette, et kerite oma telefoni uudistevoogu. Teete seda ülalt alla, kuid mitte vasakule ega paremale.
Kui pikka üleminekute ahelat pole võimalik teha, proovige ühendada mitu sammu üheks. Näiteks nõuab sait andmete sisestamist mitmes etapis – nimi, seejärel aadress, kus iga üksik lahter sisaldab eraldi maja, tänavat, korterit jne. Et mitte sundida kasutajat proovima tabada paljusid väikeseid lahtreid, küsige ta täidab ainult 2 - nimi ja aadress.
Mõnikord, vastupidi, on vaja eraldada liiga palju teavet. Näiteks on rippmenüüs loend enam kui 80 linnast, kus kohaletoimetamine toimub. Rühmitage need piirkondade kaupa, et kasutaja ei peaks seda tohutut loendit läbi kerima. Kui ta hõljutab kursorit piirkonna keskuse või piirkonna kohal, langeb välja veel üks linnade loend.
Muide, nimekirjade kohta. Neid on kaks – fikseeritud tähestikulises või muus järjekorras ja asendusega. Nende valik sõltub sellest, mida loetletakse.
Fikseeritud on kasulik, kui kasutaja teab täpselt, mida ta otsib. Näiteks linn, number või kuupäev. Teine võimalus sobib pikkade keeruliste nimede jaoks või juhtudel, kui sama nimega on palju variatsioone ja igaüks toob kasutaja eesmärgile sammu lähemale. Automaatse asendamise võimalust kasutatakse sagedamini siis, kui külastaja vajab abi. Näiteks pakub kudumiskoht osta kudumisvardaid. Kasutaja sisestab otsingupäringu “Metallist kudumisvardad” ja vihjes näeb “Kudumisvardad 5 mm”, “Kudumisvardad 4,5 mm” jne.
See punkt kehtib eriti saitide kohta, kus midagi Internetis müüakse ja kus peate täitma standardsed makse-, tarne- jne vormid. Kui inimene sooritab ostu telefonist, siis tõenäoliselt pole tal aega arvuti, mis tähendab, et protsessiostud tuleks sooritada võimalikult kiiresti ja mugavalt.
Selleks võivad vormid sisaldada juba täidetud andmeid, võite kasutada kõige populaarsemaid vastuseid. Näiteks sisestage tänane kuupäev, sularahamakseviis, linn, kui töötate samas piirkonnas. Neid saab muuta, kuid kui tabad sihtmärki, säästetakse kasutaja aega.
Saidi mobiiliversiooni kujundust luues pidage meeles, et igaühe telefonid on erinevad ja ka nägemine on erinev. Võib-olla vaadatakse teie saiti väikeselt ekraanilt, nii et fondid peaksid olema lihtsad ja loetavad, nupud peaksid olema piisavalt suured, et neid saaks klõpsata ilma teisele lehele viimata, ja pildid peaksid avanema eraldi, suurelt, eriti kui see tuleb internetti.-pood.
Rääkides saidi kohandamisest mobiilseadmetega, ei saa muud kui kasutada statistikat, et mõista, kui oluline see protsess veebireklaami jaoks on.
Numbrid on järgmised. Tänapäeval kasutab vidinaid ilmselt 87% elanikkonnast, välja arvatud kõige väiksemad lapsed ja mõned vanurid. Majandusteadlased ennustavad, et mobiilne kaubandus kasvab järgmise 5 aasta jooksul 100 korda. Samal ajal on mobiilseadmetega töötamiseks kohandatud vaid 21% saitidest. See tähendab, et Interneti-liiklusest ja e-kaubanduse turul on vaid väike 5. osa.
Mõelge nendele numbritele. Kas on mõtet oma ressurssi kohandada? Muidugi jah. Pealegi, kuigi sellel turul on nii palju vaba ruumi, saate sellel oma segmendi välja töötada.
Mobiiliversiooni kasutamine on mõttekas mis tahes platvormi jaoks, mille eesmärk on saada kõrge positsioon. Lõppude lõpuks mõjutab see kasutajat otse, luues talle mugavad tingimused teie saidil viibimiseks.
Ilma mobiiliversioonita ei saa eksisteerida:
Tänapäeval on mobiiltehnoloogiad aktiivse kasvu ja arengu faasis, mistõttu turuliidri poole püüdlemisel peab iga ettevõte tagama, et tema Interneti-ressurss vastab nõuetele. Kasutaja kasvavate nõudmiste tõttu tuleb saite pidevalt täiendada ja kohandada erinevatele seadmetele. On selge, et kui inimesel on ebamugav teatud ressursil viibida, ta ei saa sealt teavet toote või hinna kohta, ei saa tellimust esitada, tarne kohta teada, siis leiab ta saidi, kus see kõik võimalikuks saab. . Seetõttu on konkursi võitmiseks oluline paindlik, mugav, funktsionaalne ja huvitav ressurss.
Seda aitab teha saidi Android või Ios mobiiliversioon. Selleks tuleb valida üks ülaltoodud ümberkujundamise meetoditest – adaptiivne mall, luua alamdomeenile uus sait ja minna sellele ümbersuunamise teel, kasutada tasuta malle või luua mobiilirakendus, millega kasutaja pääseb ligi ja saab olla lehel mugavamalt.
