Fitts Kanunu: Arayüzde Hedef Boyutu ve Mesafe
Fitts Kanunu bir tasarım kuralı değil, 1954'te Paul Fitts'in hareket süresini ölçerek çıkardığı bir model: T = a + b × log2(2D/W). Hedefin uzaklığı D ve genişliği W verildiğinde, işaretçiyi oraya götürme süresini tahmin eder. Arayüz tarafında işe yarayan kısım formülün kendisi değil, nerede tıkandığı.
Formülün söylediği
İçerideki log2 yüzünden kazanç doğrusal değil. Mesafeyi yarıya indirmek ile hedefi iki katına çıkarmak tam olarak aynı şeyi kazandırır, ikisi de indeksten bir bit düşürür. 24 pikselden 48'e çıkmak ne kazandırıyorsa 48'den 96'ya çıkmak da onu kazandırır.
Asıl fark a sabitinde. Tepki verme, hareketi başlatma, tıklama eylemi; bunlar hedefi ne kadar büyütürseniz büyütün yerinde duruyor. Kısa mesafelerde toplam sürenin çoğu zaten a. Bir butonu 44 pikselden 72'ye çıkarıp kullanıcının işini hızlandırdığınızı düşünüyorsanız, kazandığınız şey ölçülemeyecek kadar küçüktür.
Görünen hedef ile tıklanabilir hedef
Formüldeki W ekranda görünen genişlik değil, dokunmayı kabul eden alanın genişliği. Material 48dp, Apple'ın arayüz kılavuzu 44pt diyor; ikisi de parmak temas alanının fiziksel boyutundan geliyor, ekran çözünürlüğünden değil.
İkon ve etiketi tek hedef yapmak buradaki en ucuz kazanç. Yan yana duran 20 piksellik bir ikon ve "Kaydet" yazısı ayrı ayrı tıklanabiliyorsa, kullanıcı ikisinin arasındaki iki pikselde kayboluyor.
Hedefi büyütmek için ikonun kendi padding değerini şişirmem. Padding düzeni kaydırır, grid'i bozar, sonra bunu negatif margin'le geri almaya çalışırsınız ve iş çığırından çıkar. Görünmez bir katman (pseudo-element ya da mutlak konumlu bir kardeş eleman) hedefi düzene dokunmadan büyütür.
Görünmez alan, boşluğun yerine geçiyor
Yaygın tavsiye ikiye ayrılıyor ve iki yarısı birbirini yiyor: "hedefleri görünmez padding ile büyüt" ve "hedefler arasında yeterli boşluk bırak."
Rakamla bakın. 24 piksellik iki ikon, aralarında 12 piksel boşluk. Her ikisine 12 piksel görünmez alan eklediğinizde sınırlar boşluğun tam ortasında buluşuyor. Artık o boşluğa yapılan hiçbir dokunuş boşa gitmiyor, her biri bir tarafa düşüyor. Kullanıcı ıskaladığını fark etmiyor, çünkü ıskalamadı, komşu aksiyonu çalıştırdı.
Yanlış tıklamanın maliyeti yüksekse (silme, gönderme, ödeme) görünmez alanı büyütmek değil, hedefleri gerçekten ayırmak gerekir. Geri alınabilir aksiyonlarda tersi geçerli.
Kenar hedefleri her kurulumda sonsuz değil
macOS'un üst menü çubuğu ve Windows'un görev çubuğu, ekran kenarının imleci durdurmasına dayanır. İmleç duvara çarptığı için W pratikte sonsuzdur, hedefe nişan almanız gerekmez.
Bu avantajın iki koşulu var ve ikisi de kolayca kayboluyor. İki monitör yan yana takıldığında ortak kenar duvar olmaktan çıkar, imleç oradan diğer ekrana geçer; köşeye fırlatma numarası çalışmaz. Dokunmatikte ise hiç duvar yoktur, üstelik ekranın alt kenarı sistem jestlerine ayrılmıştır.
Kenar yerleşimi fare ve tek ekran için bir optimizasyon. Aynı arayüzü dokunmatikte de kullanacaksanız kenara koyduğunuz şey avantaj değil, risk.
Menü biçiminin sınırı
Dikey listede her öğe eşit genişlikte ama farklı uzaklıkta; alttaki öğeler sistematik olarak yavaş. Pasta menüde bütün seçenekler eşit uzaklıkta, bu yüzden ilk bakışta daha hızlı görünüyor.
Yakalamadığı nokta şu: pasta menüde hedef genişliği öğe sayısıyla doğrusal olarak küçülürken, formül bunu yalnızca logaritmik olarak cezalandırıyor. 100 piksel yarıçapta 8 öğenin her birine yaklaşık 78 piksellik bir yay düşer, 16 öğede bu 39'a, 24 öğede 26'ya iner. Model hâlâ "daha hızlı" der, kullanıcı ise komşu dilime kayar. Hata oranı, modelin ölçtüğü süreden hızlı büyüyor.
Pasta menüyü sekiz seçeneğe kadar kullanın. Üstüne çıkıyorsanız liste daha dürüst bir tercihtir, en azından yanlış öğeye kaymanın sebebini görürsünüz.