Hızlı Değişen Arayüzler Neden Yanlış Tıklamaya Yol Açar
Bir menüde aradığın satırı buldun, parmağın ekrana doğru iniyor ve tam o anda liste kendini yeniden sıraladı. Dokunduğun şey artık baktığın şey değil. Arayüzün hızı burada kullanıcıya yaramaz, çünkü sorun içeriğin ne kadar çabuk geldiği değil, kullanıcının hangi anda karar verdiği.
Hedef kayarsa tıklamayı geri alamazsın
Bir dokunma hareketi anlık değildir. Gözün hedefi seçmesiyle parmağın ekrana temas etmesi arasında yüz milisaniyeler mertebesinde bir boşluk vardır ve bu boşluğun son diliminde hareketi iptal etmek pratikte mümkün değil. Kullanıcı yanlış satıra bastığını temas ettikten sonra öğrenir.
Bu yüzden klasik senaryolar hep aynı yerden patlar: WiFi ağ listesi taramayı bitirdiği anda kendini yeniden sıralar, filtre uygulanan ürün listesi sonuçlar gelince yerinden oynar, bildirim kutusu okunmamışı yukarı taşır. Her birinde kullanıcı hâlâ eski düzene göre nişan almış durumda.
Peki ya değişimi yumuşatsak? Orijinal tavsiye genelde buraya çıkar: satırlar birden zıplamasın, geçiş animasyonuyla kaysın. Burada ters bir şey oluyor. 250 milisaniyelik bir yeniden sıralama animasyonu, hedefin çeyrek saniye boyunca hareket halinde olduğu anlamına gelir; ani değişimde en azından kayma tek karede biter. Animasyon kaymayı görünür kılar, kısaltmaz. Kullanıcıya bunu izleyecek zaman verirsen faydalı, parmağı yoldayken uygularsan hata penceresini genişletmiş olursun.
Doğru çözüm güncellemeyi geciktirmek
İşe yarayan desen ekranda zaten var: Gmail yeni gelen mesajları listeye enjekte etmez, üstte "N yeni mesaj" bandı gösterir. X ve benzeri akışlar aynı şeyi yapar. Yeni veri hazır, ama listeye ne zaman gireceğine kullanıcı karar veriyor.
Uygulama tarafında bu üçüncü parti bir kütüphane işi değil. Kullanıcının son etkileşim zamanını tut, liste görünürken ve son dokunuş üzerinden birkaç saniye geçmemişken gelen güncellemeyi bir kuyrukta beklet, kuyruk doluysa üstte sayaç göster. Otuz satırlık bir mantık, ve arayüzdeki yanlış tıklamaların büyük kısmını kapatıyor. Anlık güncellemeyi yalnızca kullanıcının kendi eylemi tetiklediyse yap, çünkü o durumda değişimi zaten bekliyor.
Fark edilmeyen değişiklik, olmamış değişikliktir
İkinci sorun ters yönde: değişiklik oluyor, kullanıcı görmüyor. Sepete ürün ekliyorsun, sağ üstteki rakam 2'den 3'e çıkıyor. Gözün o sırada sayfanın ortasında, ürün kartında. Ekranın öbür ucunda tek karakterlik bir değişim, dikkat oraya yönelmediği sürece olmamış sayılır.
Geri bildirimin nerede duracağı, ne kadar süreceğinden daha belirleyici. Kullanıcının eylemi gerçekleştirdiği noktaya yakın bir onay, uzak köşede üç saniye parlayan bir rozetten daha çok iş görür. Buton "Sepete eklendi" diye değişsin, ürünün kendisinden sepete doğru kısa bir hareket olsun, ya da bakılan alanın dibinde küçük bir bildirim çıksın. Uzak köşedeki sayaç bunun yerine değil, üstüne gelir.
Otomatik dönen içerikte kimin saati geçerli
Kayan bannerlar ve otomatik ilerleyen galeriler tasarımcının seçtiği bir süreyle döner: dört saniye, beş saniye. Ama o süre kimin okuma hızına göre ayarlandı? Metni ikinci dilinde okuyan biri, ekrandan uzaktaki bir kullanıcı, ya da telefonu tek eliyle tutarken bakan biri aynı cümleyi aynı sürede bitirmez. Otomatik geçiş, en yavaş okuyucuyu cezalandıran tek bir hızda çalışır.
Erişilebilirlik tarafında bu bir tercih meselesi bile değil. WCAG'in Pause, Stop, Hide ölçütü, beş saniyeden uzun süren ve otomatik başlayan hareketli içerikte kullanıcıya durdurma imkânı vermeyi şart koşar. Nielsen Norman Group'un otomatik ilerleyen bileşenler üzerine yazısı da aynı yere varıyor: kullanıcı içeriği okumaya başladığı anda kontrolün onda olması gerekiyor.
Pratikte üç şey yeterli. Fareyle üzerine gelindiğinde ve odaklanıldığında dönüşü durdur. Geri gitme yolu bırak, çünkü kaçırılan slayta dönmenin tek yolu tam turu beklemek olmasın. Ve slayt sayısını göster, kullanıcı kaç tane olduğunu bilmeden neyi kaçırdığını da bilemez.
Zamanlama kararını nereye bağlamalı
Bütün bu örneklerde ortak nokta şu: arayüzün saati ile kullanıcının saati birbirinden bağımsız çalıştığında hata çıkıyor. Sistem veriyi hazır olduğunda gösteriyor, kullanıcı ise kendi ritmiyle bakıyor, seçiyor, dokunuyor.
Bir güncellemeyi yayına almadan önce sorulacak soru "ne kadar hızlı gelsin" değil, "kullanıcı şu anda ne yapıyor". Kullanıcı bir şeye dokunmak üzereyse ertele. Kendi eylemine karşılık bekliyorsa hemen ve baktığı yerde göster. Pasif izliyorsa ona duraklatma düğmesi ver. Hız, ancak kullanıcının kontrol duygusunu bozmadığı sürece performans sayılır.