Komentáře k článku

Případová studie: Prezentační web na mobilních zařízeních

Malý prezentační web, to je webařská rutina. Technologických nástrojů pro tenhle typ webů máme víc než dost, a tak je tady dnes už široký prostor pro vytvoření zajímavého vizuálního sdělení. Anebo technické experimentování. Během práce na Snowkidz.cz jsme zkoušeli, jak co nejsnadněji zjednodušit používání desktopového prezentačního webu mobilnímu uživateli.

Zpět na článek

20 komentářů k článku Případová studie: Prezentační web na mobilních zařízeních:

    1. Martin MichálekAutor příspěvku

      Re: Nejstarší křáp

      Drželi jsme se smartphonů — iOS a Androidu. Soustředili jsme se na vyzkoušení uživatelského rozhraní a front-end technologie. Hrátky se starými telefony by tady byly vyhozená energie. ;)

  1. Chamurappi

    Je výsledek osmihodinové práce někde k vidění?

    V článku vidím jen fotku zmobilněné verze, v ní kus adresy… rád bych testoval, testoval a taky testoval. Ale nemám co :-)

    Některým bodům z kroku d) moc nevěřím. Může se o nich pochybovat, nebo už patří do všeobecně uznávané mytologie?

      1. Chamurappi

        Re: Je výsledek osmihodinové práce někde k vidění?

        Ještě doplním pohodlnější cestičku pro nás, kdo si běžně při čtení Zdrojáku ničíme desktopovou sadu obratlů:

        █▀▀▀▀▀█  ▄    █ █ ▄▀█ █▀▀▀▀▀█
        █ ███ █ ▄▄ █▄▀▄▄██ ▀▀ █ ███ █
        █ ▀▀▀ █ ▄█▀ ▀█▀ ▄▄█ ▄ █ ▀▀▀ █
        ▀▀▀▀▀▀▀ █▄▀ █ ▀ ▀▄▀ █ ▀▀▀▀▀▀▀
        ▄▀█▄▄ ▀▄ █▄ █  █▄█ ▀█ ▀█▄▀▄▄▄
        ▄▄   ▀▀▄▀▄▄▄▀▄▄    ▄█▄▄█▄▄▀ ▀
        ▀▄ ▀▀▄▀ ███ ▀██ ▀  ▄█▀█▀ ▄ █▄
        ▀██  █▀▄▄ ▀ ▄█  ▀▀█▀██▀▀▄█▀▀█
          ▀ ▀▄▀ ▄██ ▄▀▄ █▀█▀ █▀▀▀ ▄▀▄
        ▀▀ ▄▀█▀▀ ▀█▀ █▀▄█ █▀ ▄▄▀▀ ▀▄▀
        ▀▀▀  ▀▀▀▄  ▀▄██▄▄▄▄▀█▀▀▀█▄ ▄█
        █▀▀▀▀▀█   ▄█▀ ██▄▄ ▄█ ▀ ██▀▄▀
        █ ███ █   ▄▄ ▀▀  █ ▀██▀██▄ ▄▀
        █ ▀▀▀ █ ███  ██▀  ▀▀ █▄▀▀ ▀▀▀
        ▀▀▀▀▀▀▀  ▀▀▀  ▀▀▀ ▀  ▀ ▀▀▀  ▀

        (Díky zdejšímu line-height je to docela výzva pro QR čtečky.)

  2. Chamurappi

    Nejasnosti v kroku d)

    1) „Vykreslování elementů rozhraní pomocí CSS3 (stíny, kulaté rohy, gradienty) je skoro vždy rychlejší než obrázky.
    Nevěřím. Zkoušel jsi to? Bitmapy by měly být prakticky vždy rychlejší.

    2) „Javascriptové animace jsou na mobilních zařízeních pomalé, používejte CSS3 transitions a animations.
    Skutečně je rozdíl v celkové zátěži? Je-li skript dobře napsaný, trvá ve výsledku pevnou dobu nezávisle na výkonu mašiny. Vážně je znatelný rozdíl v tom, kterým druhem animace se mobil zabývá?

    3) „V případě, že například schováte text v elementu pomocí text-indent: –9999px, zařízení musí renderovat několikanásobně větší plochu, než je viewport samotný.
    To mi též zní nepravděpodobně. Bude skutečně odsazení -999px méně náročné než odsazení -99999px?

    1. Koca

      Re: Nejasnosti v kroku d)

      Souhlasim s Vami, taky napisu k jednotlivym bodum sve postrehy

      1)Gradienty a stiny musi byt opravdu male. Pokud je na strance napr. tlacitko 200 x 200 pixelu s gradientem a stinem, je vykresleni narocne. Pokud pridate jinou barvu gradientu a stinu jako hover efekt, ucitite znatelne zpozdeni hover efektu po najeti mysi. Myslim si, ze obrazek je v tomto pripade rychlejsi.

      2) Tady asi zalezi na optimalizaci prohlizece. Kazdopadne i CSS3 transformace jsou na mobilech pomale. Navic CSS3 ma v tomto nevyhodu, ze nema callbacky ani ji nemuzete v pulce zastavit. Javascript je v tomto variabilnejsi. A potom jsou tu zarizeni jako iPad, ktere maji vykon na javascriptove animace a neni to tam zadny problem.

      3) Tady neznam technicke specifikace jednotlivych vykreslovacich enginu (zde bych cekal na mobilech spise vysokou miru optimalizace v podobe NEvykreslovani toho, co je mimo zobrazovanou plochu – rozumej document). Kazdopadne k tomuto bodu mam perlicku: na ukazkovem webu (http://www.snowkidz.cz/osobnost/samkova) je u nadpisu pouzit prave text-indent: -5000px :) Way to go!

      1. Martin MichálekAutor příspěvku

        Re: Nejasnosti v kroku d)

        ad 1) Zkoušel jsem varianty vykreslování UI elementů s a bez CSS3 na mobilním Scuku na lowend Android zařízení (Vodafone 945). V obou případech byla rychlost reakce (např. na scrollování) prakticky totožná. Vzhledem k dalším výhodám CSS3 (urychluje načítánání, lépe se spravuje) toho na m.scuk.cz máme co možná nejvíce v CSS3. Jenže — CSS3 tam nepoužíváme na velké plochy.

        Tvrzení v článku opírám o výsledky kolegů, např. tady: http://estelle.github.com/mobile/#slide24 Je to opravdu situaci od situace a je potřeba testovat na reálných zařízeních. Gradient nebo box-shadow na ploše 200×200 pixelů už jsou pro mě z kategorie „obvyklí podezřelí zpomalovači“. Tvrzením proti tvrzení se výsledku nedopátráme. Otestujte, napište.

        ad 2) Nejsem zrovna javascriptový supermág, ale animace se v jeho případě vytváří „uměle“, ne? Tzn. manipulací s CSS vlastnostmi objektu v čase. CSS3 transitions a CSS3 animations jsou „nativní“ animace, které obstarává prohlížeč sám.

        Prohlížeč má motivaci a prostor pracovat na tom, aby takové animace byly dostatečně výkonné. A tak selský rozum říká, že CSS3 bude obecně rychlejší. Jen občas k tomu ovšem potřebujete umět zapnout HW akceleraci. :) A zase platí — pokud jsem někdy animoval cokoliv jen trochu složitějšího, vždycky testoval, testoval a zase testoval.

        ad 3) To je asi nejlepší vyzkoušet si na lowcost telefonu. (Zeldman píše na iPadu1.) http://lab.pgdn.us/hidden-text-performance/

        1. Chamurappi

          Re: Nejasnosti v kroku d)

          Ad 1) Píšeš, že pokud je efekt na velké ploše, tak je zátěž zřetelná, a pokud je na menší, zdá se „prakticky totožná“. Čím tedy podpíráš tvrzení z článku, že jsou CSS efekty rychleji vykreslované než obrázky? V odkázaných slajdech zdroj nenacházím.

          Ad 2) Uměle… co si pod tím představit? Jen sugestivní přívlastek. I ty nativní CSS přechody mění vlastnosti v čase a oba dva postupy se snaží o co nejplynulejší činnost. CSS pracuje rovnou s vypočtenou hodnotou, takže by mělo mít trochu navrch. Ovšem máš-li dvě půlsekundové animace, které usilují o maximální možné fps, jedna jede 45 fps a druhá 50 fps, obě dvě zaměstnají počítadélka naplno na půl sekundy. V čem bude spočívat ta slibovaná úspora?

          k tomu ovšem potřebujete umět zapnout HW akceleraci
          Pokud vím, tak hardwarová akcelerace urychluje obecně 3D transformování, nikoliv CSS přechody a animace.

          Ad 3) Nemám při ruce iPad 1, jen nějakou loukoťovou Samšunku s Androidem, kde se příležitostně zaškobrtávají obě části odkázané ukázky synchronně. Zkusil jsem vyrobit násobičku roztočených koček, která by měla vyšponovat náročnost do lépe pozorovatelných výšin, a stejně se mi nedaří najít žádný přístroj, v němž by byl pozorovatelný rozdíl. Z toho usuzuji, že Zeldman opět káže bludy.

          1. keff

            Re: Nejasnosti v kroku d)

            Ahoj, rád bych objasnil to 2): javascriptová animace vypadá (většinou) takhle:

            Vykresli nějaký stav, počkej 50 ms, opakuj. A tak browser dělá, co mu javascript řekne, a přerendrovává stránku.

            U CSS animací jen browseru řekneme, co bychom chtěli – animuj tenhle prvek odsud sem v čase t. Pokud se je zrovna na obrazovce, browser ho rendruje (ideálně tak, že jen šoupe HW akcelerovaným polygonem). Může si při tom vybrat framerate (a dělá to) tak, aby dosáhnul kompromisu mezi vzhledem a spotřebou baterky.

            Ještě důležitější ale je, že CSS animace není závislá na předchozích stavech – je daná čistě časem. Pokud je na hodinkách t, pak má být div na pozici f(t). Takže pokud div není na obrazovce, browser se může na renderování a aktualizace úplně vykašlat, a místo 20ti updatů za vteřinu klidně spí, ukazuje statický obrázek stránky a šetří baterku. A pokud uživatel přeskroluje na div, není problém okamžitě spočítat jeho pozici.

            Tohle je obecná výhoda deklarativního přístupu k programování a taky důvod, proč se tvůrci browserů koukají, co lidé na stránkách programují, a vymýšlejí způsoby jak to popsat deklarativně (tzn. dnes v CSS).

            Toliko teorie jak by to mělo vypadat, teď jsem vyzkoušel náš web http://csshat.com s css3 animacemi na Androidu 4 s debug módem (kdy obrazovka problikne při každém screen update), a bohužel, po nahrání stránky bliká pořád, i když odskroluju všechny animované prvky mimo viewport (ICS browser, Chrome for Android). Nicméně, možnosti pro optimalizace tu jsou.

            Neumíte někdo změřit překreslování obrazovky s animacemi mimo viewport na iOS zařízeních?

            1. keff

              Re: Nejasnosti v kroku d)

              Ještě přidám odkaz na techniku, jak dosáhnout výhod deklarativních animací i z JS – requestAnimati­onFrame: http://paulirish.com/2011/requestanimationframe-for-smart-animating/

              Browser tak může interval aktualizace stránky volit sám např. podle typu napájení (adaptér/baterka), a hlavně sdružovat všechny animace najednou (takže pokud je na stránce víc animací, překreslí se všechny ve stejný čas a zbytek času může procesor spát). Podle ticketu http://bugs.jquery.com/ticket/8101 to už umí i jQuery.animate…

              1. keff

                Re: Nejasnosti v kroku d)

                A ještě jedna podstatná výhoda deklarativních animací na desktopu: prohlížeč je umí zastavit (a zastavuje, už dnes!), když je uživatel v jiném tabu. Takže můžu mít puštěný Chrome s 50ti taby, aniž bych měl CPU 100% zatížený překreslováním animovaného loga na 20ti stránkách které stejně nevidím.

                1. Chamurappi

                  Re: Nejasnosti v kroku d)

                  Zrovna tak umí prohlížeč zvednout spodní limit časovačům v neaktivních tabech na jednu sekundu (a zvedá, už rok!), takže ani javascriptové animace nezatěžují procesor zbytečně.

                  1. keff

                    Re: Nejasnosti v kroku d)

                    Díky, to jsem nevěděl. Ale z hlediska memory manageru je dost zabijácké mít na pozadí třeba 50 chrome procesů, které jen kvůli ticku (zbytečného) javascriptu nelze odswapovat – a to ani když se na daný tab týden nepodívám.

                    A ano, jasně že to jde ošetřit dalšími pár řádky javascriptu, ale kdo z tvůrců webu vůbec ví o tomhle problému (a proč by měli?). Tohle mají imo řešit browsery nebo frameworky (a tlačit uživatele do deklarativního zápisu).

                    1. Chamurappi

                      Re: Nejasnosti v kroku d)

                      Odswapovat jde všechno, co není akutně potřeba, nezávisle na procesech. Jeden animující tik moc paměti nepotřebuje.

                      a tlačit uživatele do deklarativního zápisu
                      Předkládáš samé hypotetické scénáře a domněnky, není důvod někoho někam tlačit. Naproti tomu požadavek, aby animace fungovala pokud možno všem návštěvníkům nezávisle na prohlížeči, je velmi skutečný.

            2. Chamurappi

              Re: Nejasnosti v kroku d)

              Díky za objasňování, ale spíš bych řekl, že javascriptová animace vypadá většinou takhle:
              Zjisti, kolik času t uběhlo od nastartování animace, spočítej f(t) pro jednotlivé vlastnosti, nastav hodnoty… a co nejdříve zopakuj další krok. Je to tedy přesně ten samý princip. Používá ho jQuery, já a pravděpodobně i méně agresivní frameworky a lidé.

              Toliko teorie jak by to mělo vypadat
              Nepřipadá mi domyšlená. To, zda prohlížeč musí překreslovat animovaný element, je zcela jiné téma. Někdy musí přepočítat pozice a rozměry bloků, někdy ne — vše záleží výhradně na tom, které vlastnosti se mění, a je celkem jedno, jestli se mění skriptem, či stylem. Animace řízená nativním přepočtem v prohlížeči by měla být trošku rychlejší, protože výpočet f běží na nižší úrovni a protože se přeskakuje přepočet hodnot, ale očekával bych, že celkově půjde o nepatrný zlomek. Žádný prostor pro zázračné optimalizace, které by se nemohly dít i u skriptů, tu nevidím.

              Uvážím-li, že stylopisové animace mají podstatně slabší podporu než skriptované a jsou navíc zavšivené proprietárními prefixy, nespatřuji v nich momentálně žádný přínos.

              1. keff

                Re: Nejasnosti v kroku d)

                I dare to concur – jestli chceš dělat animace přátelské pro uživatelův procesor a baterku, měl bys v nich zjistit druh napájení a preference OS (pro optimální framerate), měl bys hlídat jestli je tab zobrazený (a pokud ne, animaci zastavit a při zobrazení tabu zase spusit, pokud mezitím nedoběhla), a hlavně, hlídat nová API která pomáhají spořit výkon, zapracovávat je do svého kódu, a aktualizovat web.

                Anebo použiješ CSS animaci, řekneš s ní ČEHO chceš dosáhnout, a JAK necháš na autorech browseru. Your choice.

                1. Chamurappi

                  Re: Nejasnosti v kroku d)

                  I dare to concur
                  Odpovídej mi česky, prosím. Teď jsem na pochybách, jestli si se mnou opravdu troufáš souhlasit, nebo jestli ses pokoušel vyjádřit opak.

                  měl bys v nich zjistit druh napájení a preference OS
                  Dělá tohle některý z prohlížečů u CSS animací?
                  I mé javascriptové intervaly jsou plně v moci prohlížeče, počítám s tím, že si je zreguluje podle chutě.

                  zapracovávat je do svého kódu, a aktualizovat web
                  Prefixovaná vlastnost ti připadá více nadčasová a stabilní? Až se W3C rozhodne, že v animation změní způsob zápisu zpoždění (nebo něčeho jiného), budeš muset upravovat svůj kód ty.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3662