Parimad tavad veebidisainerite suhtes, mis on vastupanuvõimelised paigutused või kohalikud rakendused? [Op-Ed]

Ei ole eitamist, et mobiil on tulevik. Google kinnitab, et mobiilsides tehakse rohkem otsinguid kui töölaual, on täiesti selge, et kõik veebisaidid peaksid tõepoolest liikuma, kui nad pole veel.

Kuid brauseri sisus on huvitav dikotoomia reageeriva paigutuse ja rakendusesisese sisuga rakenduste kaudu.

Sooviksin uurida mõlemat piirkonda ja kaevata iga valiku juure. Millal peaks veebisait vastama oma kohalikule rakendusele? Kas sait võiks mõlemad toimida? Need on olulised küsimused, mida tuleb iga uue loomingulise projektiga täna esitada.

Native App väärtused

Enamik nutitelefoni kasutajaid toetub oma lemmikprogrammidele kohalikele rakendustele. Facebook, Twitter, Instagram ja teised kõik kasutavad oma kohalikke rakendusi.

Kuna kohalikud rakendused töötavad kohalikus operatsioonisüsteemis, on nad palju sujuvam ja lihtsam tegutseda animatsiooni, kasutajaliidese disaini ja sisuhalduse osas. Native rakendused järgivad kasutajaliidese suuniseid, hoides neid kõiki järjekindlalt ja loomulikult eeldusel. Sageli teavad kasutajad lihtsalt, kuidas kasutada libistavaid menüüsid ja vahekaarte.

Paljudel suurematel kirjastajatel on rakendused iOS-poodis ja Google Play poes, mis hõlmavad blogisid, veebisaite ja sotsiaalseid võrgustikke. Aga see on aus öelda suured saidid nagu Facebook ja Twitter saada rohkem väärtust kohalikest rakendustest kui väiksemad saidid.

Arutelul on eksperdiarvamused ja peamised väljaanded, mis pakuvad oma seisukohti. See on kuumalt arutatud teema nii disaineritele kui ka loomingulistele asutustele.

Siiski on tõsi, et lõppkasutajad on nii kasulikud kui ka kohalikud rakendused. Ainus muutuja on otsustada, kas teie veebisait võiks mobiilirakendustena paremini toimida, või kui kasutajad tahaksid isegi seda.

Täielikult reageerivad veebisaidid: plussid ja miinused

Üldises kontekstis on reageeriv veebidisain alati hea. Veebidisainerid ei kaota midagi, tehes nende paigutused täielikult reageerivaks ja mistahes ekraani jaoks kohandatavaks.

Kuid kohalike rakenduste kontekstis on mõned kaalutlused. Esiteks reageerivad veebilehed piirduvad brauseri renderdamismootoriga. Nutitelefonide puhul tähendab see piiratud animatsiooni, Flashi ja brauseri renderdamismootori sõltuvust.

Natiivsed rakendused võivad kasutada nutitelefoni või tahvelarvuti põhifunktsioone. Animatsiooniraamatukogud on palju võimsamad kui CSS või JS.

Sama kehtib ka vormide sisendelementide kohta andmete edastamise ja turvalisusega seotud probleemid. Paljud inimesed eelistavad kasutada Pinterest appi Pinteresti veebisaidil. Sama kehtib Flipboardi, Dropboxi, Feedly, Gmaili või mõne muu olulise veebiteenuse kohta.

Kuid kas need veebisaidid peaksid olema mitte pakkuma tundlikku paigutust? On kolm valikut:

1. Jõustage mobiilsed veebikasutajad kohaliku rakenduse allalaadimiseks
2. Pakkuda mobiilse veebipõhise paigutuse, millel on valikuline link kohalikule rakendusele
3. Lihtsalt käivitage mobiilse veebi paigutus oma rakendusest eraldi

Flipboard läheb 2. valikuga, asetades iga lehe ülaosas bänneri. Flipboardi kontole saate registreeruda otse Mobile Safari brauseris. Aga see on appi palju lihtsam, kiirem ja intuitiivsem.

Uudiste saidil ZDNet ei ole mobiilirakenduses mobiilirakenduse külastamisel isegi mainitud. See toimib nagu tüüpiline tundlik paigutus uudiste ja esiletõstetud postitustega.

Erinevus peitub kasutaja kogemuses. Määrake, mis on kasutajatele parim gabariit, kus saabub enamik liiklust.

Mäleta seda mobiilirakendused vajavad aega projekteerimise ja programmeerimise jaoks. Nad sageli nõuavad rohkem tööd kui veebilehe ülesehitamine. Kui soovite oma saidile rakenduse veenduda, et see täiendab teie tundlikku paigutust, et pakkuda tegelikku väärtust.

Töölaua-esimene või mobiil-esimene?

Veebi projekteerimisel peaksite alustama kõige laiemast või väikseimast laiusest? See on küsimus, mida vabakutselised ja suurel ajal loomingulised asutused sageli küsivad.

Väga populaarne arvamus on mobiil-esimene lähenemine, mida Luke Wroblewski raamat sai populaarsemaks. See meetod käsitleb järkjärguline täiustamine mis algab põhitõedest ja suurendab funktsionaalsust keskkondades, mis sellega hakkama saavad.

Teised disainerid toetuvad töölaua esimesele lähenemisele, mis ostsilliseerub “mobiil kõigepealt” kuni “ka mobiilsed”.

See strateegia töötab, planeerides kõigepealt kõiki funktsioone, mida soovite täissuuruses töölaua monitoril. Sellest ideest lähtudes järk-järgult vähendate funktsioone, määratlete katkestuspunktid ja lõpuks saate nutitelefonide väikseima paigutuse.

Kas siin on õige vastus? Kui reageerivad paigutused algavad väikseimast ekraanist või on mobiil-esimene aegunud mõiste?

Ainsaks puuduseks on ühe teise valimine teise vastu puuduvad funktsioonid. Alustades mobiilist võite jätke need funktsioonid välja või unustage neid suurematel resolutsioonidel lisada. Alustades töölauast võite kujundada paigutusi tunne, et mobiilil on liiga ülerahvastatud.

Kuid ükski neist ei ole õige ega vale. Valige sobiv tööprotsess. Lihtsalt ärge kartke teha suuri muudatusi, kui nad võiksid disaini parandada.

Mõlema maailma parim

Täielikult reageeriva veebisaidi loomine, mis töötab mis tahes ekraanil, on tõenäoliselt enamikule lugejatele rahuldav. Nii et kui sul on juba tundlik paigutus, peaksite mobiilirakendusega isegi vaeva nägema?

Modo Labsi selles suurepärases töös leidub vastus kasutaja kogemus. Absoluutset lõplikku vastust ei ole. See on umbes milline meetod pakub parima tarbimismoodi teie konkreetne projekt mobiilseadmes. Kas teie kasutajad soovivad mobiilirakendust? Või on veebileht rohkem kui piisavalt?

Tech uudiste blogi TechCrunch on tundlik paigutus ja tasuta mobiilne app, nii hea põhjus. Nende veebileht hõlmas hiljuti lugu, mis kinnitas, et USA inimesed kulutavad rohkem aega rakendustes kui teleri vaatamine.

Aga mis siis, kui keegi suhtleb Twitteris TechCrunchiga? Kui keegi klõpsab sellel lingil oma iPhone'is, avab see mobiilse Safari, kuna see on HTTP link. See on koht, kus tundlik paigutus on mugav, sest mitte igaüks tahab teie rakendust.

Mõned kasutajad soovivad ikka veel teie veebilehte külastada ja eelistavad külastada ilma rakenduse tasuta alla laadimata.

Töö projekti alusel

Parim vastus reageeriva ja natiivse rakenduskeskkonna arutelule on iga projekti hindamiseks ja otsustada, mis on parim iga juhtumi puhul eraldi.

Minu kogemustest tuleneksin seda sotsiaalsed võrgustikud ja interaktiivsed veebisaidid saavad kõige rohkem kasu kohalikest rakendustest. Nii Androidil kui ka iOS-il on suured raamistikud rakenduste loomiseks, mis võivad liituda API-dega, saata andmebaasi päringuid ja toimida puhtamaks kui veebileht.

Ja kohalikud rakenduste kasutajaliidesed on nagu tarkvara, nii et te ei pea muretsema CSS-i omaduste või brauseri piirangute pärast. See on suured platvormid, mis vajavad kasutajaid sisse logima ja tegema üksikasjalikke interaktsioone.

Kuid üldised äri veebisaidid, nagu näiteks restoranid, töötavad tavaliselt kõige paremini ainult reageerivate paigutustega - eriti arvestades kohaliku rakenduse ehitamiseks vajalikku tööd.

Blogid ja digitaalsed ajakirjad on mõnevõrra hallid piirkonnad. Native rakendused töötavad mõnede jaoks hästi, kuid teised ei vaja neid. Tavaliselt sõltub see sinust turu suurus ja publik (st tehnilised inimesed).

Uue Interneti-väljaande käivitamisel on palju kaaluda. Kui te just alustate, soovitan kõigepealt ehitada ainult veebisaiti. Sealt on lihtsam järeldada, kas kohalik rakendus oleks vaeva väärt.

Pakkimine üles

See peaks ütlema ütlemata iga kord kaasaegne veebisait on kasulik reageerimisel. Kas soovite luua native-rakenduse või mitte, peaks teie saidi paigutus olema reageeriv ja mistahes ekraani suurusele kohandatav. Puudub negatiivne külg ja see pakub stabiilset sihtlehte mobiilikasutajatele, kes on tõusuteel.

Mõned veebisaidid võivad pakkuda mobiilikasutajatele rakenduse allalaadimise linki. Need võivad olla produktiivsed ja kasulikud teie veebisaidi mobiilplatvormi turustamiseks. Aga mõnikord tasub seda pakkuda pigem alternatiivina kui mandaadina.

Võimaluse korral koguda kasutajate tagasiside ja hinnata mobiilirakenduse arvamusi. Püüdke õppida, mida teie külastajad tegelikult kohalikust mobiilirakendusest mõtlevad, ning otsustage oma otsuseid edasiseks uurimiseks.