Responsive veeb

  • Kustutatud 12 a

    rain, wuzz, toon teema siia yle...

    rain, minuarust leht (mitte sait), millel on 6 yksteisest oluliselt erinevat vaadet on ilmselge overkill. ma ei v2ida, et mingi webappi puhul see ennast 6igustada ei v6iks, aga ma ei suuda yhtegi praegu ette kujutada. vbolla ma saan sust valesti aru, aga minu peas jagunevad oluliselt erinevad vaated telefoni, tableti ja desktopi vahel. ei tundu otstarbekas 1280 ja 1920 desktopi layouti oluliselt erinevana esitleda. loomulikult on seal meediumile vastavad kohandused head aga layout j22b reeglina alati samaks.

    wuzz, kus sa need common platvormid v2lja t6id -- selline seadmete targetimine on iga p2evaga j2rjest rohkem bad practice, olgugi, et su vastus oli v2ga yldine. ideaalis peab leht toimima telefonist times square'i billboardini, aga l2heb veel veidi aega kuni teiseltpoolt disainerid sellistele asjadele t6sist t2helepanu p88rama hakkavad ja vastavad oskused omandavad.

    arendaja seisukohast on jah tarvis t88d alustades mingid breakpontid valida, aga j2llegi ma arvan ykski kujundus sellist spektrit ei eelda ja tavaliselt on disainerilt raske 3-egi erinevat layouti millegi responsive'i kohta saada.

    ja sidenote: m6iste "small phone" androidi puhul veebi osas rolli ei m2ngi: 240x320 ekraaniga telefonid renderdavad k6ik 320 laiuse peal (kokkusurudes) v2lja. blackberry kohta ma kahjuks ei tea.

    05. november 2012 - 13:35:33 · Otselink

  • Kustutatud 12 a

    ma ei leia, et ka p6hjus mitte mobiilseid seadmeid omada oleks vabandus mittemobiilseid saite teha. ammuilma on igast online t88riistad oma layoutide testimiseks olemas.

    05. november 2012 - 13:39:20 · Otselink

  • wuzz 12 a

    Kõik sõltub sellest, mis on su kliendibaas ehk sihtgrupp. Kui on mingi suva restoraniveeb siis suht pohhui mingist vanakooli kliendist oma 800x600 IE või Nokia E seeria telefoniga. Kui aga tegemist on mõne panga või telco lehega siis on jutt teine.

    Ja minu välja toodud 6 sammu ei ole seadmepõhised vaid ekraanisuurustele vastavad sammud ja poolsammud. Touch ja non-touch ning modern ja non-modern probleemid tuleks resost sõltumata lahendada. Kõik need ei eelda omaette kujundust vaid sisu kohandamist. Täpsustan:

    1. wide desktop - kuna 100% stretch veeb 1900+ reso juures on sulaselge debiilsus siis on vaja mingist piirist üles minnes üldraam ära lukustada ja nt taustapilti näidata.

    2. default desktop/tablet landscape - kõige enam viimistlust vajav suurus, millele on kõige rohkem külastajaid. Reeglina peamine kujundusvaade.

    3. tablet portrait. - Siia alla lähevad nii tahvlid kui keskaegse arvutiga kliendid ruumikasutuse mõttes. Ja ka näiteks eri kohtadest popup akendega sisenevad kliendid. Neile pole mõtet näidata sidebare ja meeletusuurt taustapilti mida ei mahu näitama.

    4. phone landscape - eelkõige teemaks vormide kujundus kus näiteks 100% laiuses nuppude näitamine ei ole mõistlik. Samuti igasugu textareate kujundus androidile.

    5. phone portrait - mobiilikasutajate peamine vaade.

    6. small phone - antiiktelefonid, ehk siis sisuliselt pooled nokiad mis on vanemad kui 2 aastat. Neid on paraku nii soome kui näiteks läti-leedu täis. Handlimine kasvõi selles mõttes et tuleb viisakas error anda. Sama vaade tuleb näiteks ette visata ka JS vabadele brauseritele ja telefonidele.

    05. november 2012 - 14:22:50 · Otselink

    1

    Loe kõiki

  • Kustutatud 12 a

    v2ga selge, n6ustun.

    05. november 2012 - 14:36:08 · Otselink

  • wuzz 12 a

    A kui juba responsive arendus teemaks tuli. On kellelgi mingit alternatiivi Adobe Edge Inspect tööriistale mis nüüd tasuliseks tehti?

    05. november 2012 - 14:46:39 · Otselink

  • vaalaskala 12 a

    See ei ole tasuline, saab tasuta, kui creative cloud kasutaja teed endale? Nagu selgub siis on pask.

    Ise kasutan grunti ja sellel on vist https://npmjs.org/package/grunt-reload pak olemas mis muutuste salvestamisel teeb kõigile connectitud asjadele reloadi ideepoolest. Ma testinud mudugi mitmeid seadmeid korraga ei ole. Seal muidugi aint see jama , et igal seadmel pead lehe ise avama :(

    05. november 2012 - 14:53:19 · Otselink

    2

    • Tasuta on max 1 seade korraga küljes. See aga väga ei vea välja. Kuni tänaseni oli cloudi kasutajatel mingi trial periood.

    • haha seda ei teadnudki , uninstall instant

    Loe kõiki

  • Kustutatud 12 a

    wuzz, veel lisan: v2ga hea selgitus ja enamjaolt n6ustun.

    sisu kohandamist pidasin ka ise silmas ja tahtsin t2psustada, mida rain nende 6 sammu all m6tles.

    hd ekraanidele sisu stretchimine on j2lle subjektiivne ja kyll pigem erandlik, aga kindlasti mitte v2listatud, eriti mitte webappide puhul.

    tulles tagasi oma esimese (tanki) postituse juurde, siis mainin veel, et r22gin enimkasutatud platvormidest -- telefonid, tabletid ja desktopid ning nendega seonduvast. erilahendused erilahendusteks.

    wuzz, kas sa j2lgid iga projektiga neid 6 sammu v6i ainult panga/telco omadega? oskad sa 2kki peast antiiktelefonide kasutusosa kohta 8elda, see huvitaks mind lihtsalt...

    ja viimaseks klassikaline desktop/tablet landscape vaade ja fakt, et see reeglina kogu ylej22nud layoutide aluseks on... kui palju sa mobile first meetodit hindad? kui disain on tehtud desktop first, siis kas teeksid htmli ka vastavalt selles j2rjekorras? degrade on loomulikult lihtsam sellisel juhul, aga kas see saaks algmaterjalidest s6ltuvalt m22ravaks?

    t2nud, kogun lihtsalt erinevaid arvamusi...

    05. november 2012 - 15:01:53 · Otselink

    2

    • tglt mõtlesin muud, 6+ eri layouti lehel mitte dimensioone ja seda kui palju ekstra tööd nendega, ajaprognoosiga võib julmalt puusse panna

    • ajaprognoosimine on p2ris hull downer responsive layoutide puhul, tean omast k2est.

    Loe kõiki

  • vaalaskala 12 a

    ma ei vaataks markupi poolelt ja semantika poolelt projekte kui mobile, desktop või misiganes first vaid ikkagi teeks markupi valmis ilma stiilideta ja paneks ta loogiliselt ilma stiilideta jooksma. Ka selles responsive osas pead sa teadma mis kuhugi kõrvale või järgi kukkuma hakkab ja siin ei ole stiilid või pildid nii olulised esimeses järgus.

    Hiljem pole sul enam vahet milline seade sul stiilidega/mediaqueryga "first" on , sest ilma stiilideta on kõik sisu kättesaadav. Edasine sõltub siis juba sellest, kui raske "kellajavile" pakett sul sinna otsa tekkima peab . Mida edasi seda enam skilled sa ju oled ja oskad asju ette näha ja teed kohe hübriidi või teed juba kohe oma "kellajavile" lahenduse automaatselt ja samal ajal mõteldes , et kuidas see asi ilma stiilita või teise stiiliga jookseks.

    Minu arvates ei ole siin mingit meeletut tehnoloogia muutust millega disainer peaks arvestama pigem ikka tuleb minna vana hea tava juurde "content first, then markup" ja nüüd lisandub siia lihtsatl "content first, then markup, then device" . Lihtsalt arendajate teadmisse on jõudnud see sisu olulise arusaam ja selle põhjalt on hakatud tegema responsive osadega saite rohkem, see kõik oli ka vanasti võimalik (mitte nii lihtsalt muidugi, aga aeg on läinud ikka tulbisti edasi).

    Igasugust sitta juhtub :) kõige sagedam sitt mis ventikasse lendab ongi sul ju see, et sisu ei ole olemas ennem, kui lahendus või disain sisu esitamiseks ja siis juba see, et sisu juba tekib ja lahendust on vaja muuta (kuna ei nähtud asju ette jne jne) disaini muutuste või tekitatud sisu järgi.

    Kui on ulme kunstiteos vaja veebi jaoks teha, siis tehaksegi vajadusel erinevatele seadmetele erinev loogika.

    05. november 2012 - 15:18:30 · Otselink

  • wuzz 12 a

    Jälgin ikka valdavalt jah neid 6'te sammu sest sõltuvalt sisust ei pruugi kõiki samme vaja minna näiteks kui vorme pole.

    Ülesehituse poolelt ma väga ei poolda mobile-first lahendust sest see on natuke liiga ühes karbis mõtlemine ja seab liigselt piiranguid. Tuleb ikka vaadata kõike tervikuna.

    HTML osas tundub mõistlikum olevat desktopi jaoks ennem kirjutada sest näidatavat sisu on rohkem. Kui see paigas saab hakata mobiili jaoks kohendama. See et 5-6kb HTML koodi on mobiili jaoks kusagil kasutult peidus on oluliselt kiirem kui iga tükk eraldi kohale tuua eri reso juures või siis DOM'i elementide järjestuse muutmine JS'ga.

    JS osas tundub jälle et ei saa ühte suunda teisele eelistada ja tuleb kirjutada mõlemale korraga ning ehitada fixid vahele juhuks kui reso muutub.

    05. november 2012 - 15:25:56 · Otselink

  • vaalaskala 12 a

    adobe shadow asendamisest võid proovida http://yeoman.io/ mis peaks ka suutma livereloadi teha, kas ka üle mitme seadme peab testima (sisuliselt sarnane http://gruntjs.com/ grunt_reload) võid proovida ka http://livereload.com/

    05. november 2012 - 15:38:14 · Otselink

  • Kustutatud 12 a

    eriti tore arutelu, t2nan! jagaks veel m6ndasid t88riistu:

    yks olulisemaid pildimure lahendajaid
    https://github.com/scottjehl/picturefill

    pigem responsivenessi esitlemiseks kui testimiseks
    http://lab.maltewassermann.com/viewport-resizer/

    fluid video
    https://github.com/davatron5000/FitVids.js

    responsive image slider, toetab swipe'imist
    http://www.woothemes.com/flexslider/

    ja klassika
    http://apps.eky.hk/css-triangle-generator/

    ma oleks ka v2ga huvitatud teie responsive t8id n2gemast, vastutasuks enda paar viimast:
    http://jspro.com/
    http://secretagent.com.au/

    05. november 2012 - 15:58:50 · Otselink

    3

    • tööasju parem ei tea kas tohib näidata. aga noh selliseid http://kikinderkok.ee/ on omajagu

    • skriptidemonstrum kus sai tsipa olemasolevat asja silutud, css3 multicol, tablet ja telef peal sureb :( link

    Loe kõiki

  • Kustutatud 12 a

    t2nud rain et selle ajaprognoosi teema sisse t6id. mille alusel te sissetulevat t88d hindate? kui yldine maht k6rvale j2tta, siis just responsive osi projekti juures?

    05. november 2012 - 16:08:44 · Otselink

    1

    • eks see oleneb vist paljuski mis projektijuhtimismeetodeid sa kasutad . Agile puhul ilmselt hakkad usercase backlogi tegema ja hindama

    Loe kõiki

  • wuzz 12 a

    ajaprognoosid saavad tulla ainult kogemusega. vaevalt siin kellelgi paar aastat responsive kodeerimise kujundust on :)

    05. november 2012 - 16:29:46 · Otselink

  • rain 12 a

    ei kujuta mobile first workflowd korporatiivklientidele reaalsuses ettegi. eriti kui on veel nõudmised ntx mitmele kujunduskavandile.

    põhim idee ongi selles et on olemas proto ja siis selle põhjal kirjutad semantilise html ning siis hakkad seda browseris disainima.
    disainer on ise ka coder, üliharv juhus. või siis istuvad disainer ja frontend (siit ka omaette eeldus et sellel tüübil on silma disiainile ja soovi aktiivselt kaasa mõelda) kahekesi koos ekraanitaga ja üks räägib mis teha on vaja ja teine teostab. viimast oleme ise proovinud, aga seda kah kui projekt on pigem juba lõppfaasis mitte nullist.

    teine asi, jälgides browseris disainitud veebe mis maailmas tehtud siis nad kipuvad tihti väga sarnased olema

    07. november 2012 - 11:54:45 · Otselink

    1

    • Anna härrale ressurss ja ta kukub kohe raiskama.

    Loe kõiki