Výpisek z mé přednášky na ČVUT:FIT 16.12. 2015 v Dejvicích. Na chyby mě prosím upozorněte v komentářích.
Jak vnímá uživatel rychlost aplikace
Rychlost Aplikace
- Aplikace je bolestivě pomalá, uživatel jí opustí
- Aplikace je snesitelná, uživatel používá
- Aplikace je plynulá, uživatel má radost
“Jakmile má uživatel opravdu radost, už se nevyplatí investovat do zrychlení.”
|
A nebo z druhé strany:
“Investujte do zrychlení, dokud nemá uživatel opravdu radost.”
|
Prodleva
|
Reakce uživatele
|
0 - 100ms
|
Okamžitá reakce
|
100 - 300ms
|
Malá vnímatelná prodleva
|
300 - 1000ms
|
Stále v kontextu jednoho úkolu, vnímá prodlevu
|
1000+ ms
|
Mysl utíká k jinému problému (context switch)
|
10 000+ ms
|
Je to rozbité / přijdu později
|
60 FPS => 16ms (1/60)
|
RAIL Model
Model, který definuje časy pro svižnou aplikaci v různých typech interakce - k těmto hodnotám se pokoušíme přiblížit.
- Reaction Time < 100ms Uživatel pociťuje okamžitou odezvu. Např. po kliknutí na tlačítko. Cokoliv delší a akce-reakce je rozbitá.
- Animation Time = 16ms Změny jsou plynulé. Např. scrollování. Jakákoliv změna plynulosti otravuje.
- Idle Time “Na prázdno” = 50ms Uživatel nic aktivně nedělá, takže aplikace má čas udělat práci. Musíme jí ale omezit na 50ms, aby aplikace mohla zareagovat na uživatele.
- Load Time < 1s První zobrazení. Aby uživatel neztratil kontext, aby nezačal přemýšlet o něčem jiném.
Bojujeme proti fyzikálním zákonům a rychlost světla je protivně pomalá
Žádnou informaci nejsme schopni přenést po povrchu země z mého bytu do Dejvic rychleji, než za 31.2ms. A to je ideální případ ve vakuu, kdy na cestě nejsou žádné jiné “zpomalovače”, jako switche a routery. Realita bude mnohem horší (např. mobil nejprve musí navázat připojení k věži operátora).
Pokud 31.2ms porovnáme s čísly, které jsme si definovali pro RAIL, tak vidíme, že zde soupeříme s fyzikálními zákony a musíme k problému přistupovat chytře (trh a váš šéf většinou na fyzikální a matematické limity nedbá).
Poznatek: “Rychlost světla je protivně pomalá”
|