Konu Başlıkları
Yükleniyor...

Responsive Enabling: Arayüz Öğesini Ne Zaman Kapatmalı

Devre dışı alanlar gerçekten hatayı önlüyor mu?

Responsive enabling, çok adımlı bir formda o an gereksiz olan alanları soluklaştırıp kapatma alışkanlığının adı. Sadeleştirdiği doğru. Ama kapalı bir alan, kullanıcıya neden kapalı olduğunu söylemez ve çoğu uygulamada bunu telafi eden hiçbir şey yoktur. Deseni savunmadan önce ne zaman ters teptiğine bakmak gerekiyor.

Desen tam olarak ne yapıyor

Fikir basit: göreve ait bütün öğeleri tek panelde tut, kullanıcının seçimine göre sadece o adımda anlamlı olanları etkin bırak. Kargo yöntemi seçilmeden adres alanları açılmaz, fatura tipi kurumsal seçilmeden vergi numarası istenmez. Adımları ayrı ekranlara bölen sihirbaz akışına göre avantajı, deneyimli kullanıcının bütün resmi görmesi ve aralarda ileri geri gezinebilmesi.

Buraya kadar itirazım yok. İtiraz, kapatmanın bedava sayılmasına.

Kapalı öğe kullanıcıya hiçbir şey anlatmaz

Soluk gri bir buton iki farklı şeyi aynı görüntüyle ifade eder: "burayı henüz doldurmadın" ve "bu seçenek senin hesabında yok". Kullanıcı ikisini ayırt edemez, ayırt edemediği için de ne yapacağını bilemez. Klasik arayüz literatüründe bu durumun bir adı bile var, gizemli soluk menü öğeleri diye geçiyor. Kaynak metinlerin çoğu bunu deseni anlattıktan sonra dipnot gibi ekliyor, oysa desenin doğrudan ürettiği sorun bu.

Teknik tarafı daha da rahatsız edici. disabled öznitelikli bir öğe pek çok tarayıcıda klavye odağı almaz. Odak almayınca ekran okuyucu kullanıcısı sekme tuşuyla gezerken o alanın varlığından haberdar olmaz. Formda bir alan eksik kaldığında görme engelli kullanıcı "şu alanı doldur" uyarısı almaz, alan onun için hiç yoktur. Erişilebilirliği sonradan eklenecek bir katman sanmak tam olarak böyle yerlerde patlıyor.

Kapalı buton bir doğrulama yöntemi değil

Bu desenin en sık duyulan gerekçesi hata önlemek. Sorun şu ki kapatma işlemi istemci tarafında yaşıyor. Tarayıcı konsolundan özniteliği silmek, isteği doğrudan uç noktaya göndermek ya da eski bir sürümle formu göndermek mümkün. Sunucu tarafında aynı kuralı zaten yazmak zorundasınız. Yani kapalı buton bir doğrulama değil, doğrulamanın görsel özeti.

Bunu kabul edince soru değişir. Artık "bu alan kapalı olmalı mı" diye sormuyorsunuz, "kullanıcı yanlış bir şey yaptığında ona ne söyleyeceğim" diye soruyorsunuz. İkinci sorunun cevabı her durumda gerekli, birincisininki değil.

Kapatmak yerine

Çoğu formda daha iyi çalışan yol, düğmeyi açık bırakıp gönderim anında eksikleri isim isim göstermek. Kullanıcı neyi eksik bıraktığını okur, doğrudan o alana gider, tamamlar. Bir rezervasyon formunda devam düğmesini koşullu kapattığımız sürümde destek kayıtlarının yarısı "buton çalışmıyor" diye geliyordu, düğmeyi açıp altına eksik alan listesi koyunca o kayıtlar tamamen kesildi.

Alan gerçekten o senaryoda anlamsızsa kapatmak yerine tamamen gizlemek de bir seçenek. Kurumsal fatura seçilmemişken vergi numarası kutusunun soluk halde durmasının kimseye faydası yok. Gizlemenin şartı, alanın geri gelme koşulunun kullanıcı için tahmin edilebilir olması: seçim değişince alan görünüyorsa sorun yok, rastgele beliriyorsa arayüz kaygan hale gelir.

Kapatmanın hâlâ doğru olduğu yerler

Deseni bütünüyle çöpe atmıyorum. Kapatmak, işlemin geri dönüşü olmadığı ya da tıklamanın gerçekten bozuk bir duruma yol açacağı yerlerde yerinde durur. Henüz kaydedilmemiş bir belgede "yayınla", boş bir sepette "ödemeye geç", seçim yapılmamış bir listede "seçilenleri sil" gibi. Ortak nokta, kapalı olma nedeninin ekranda zaten görünüyor olması. Sepet boşsa kullanıcı bunu görüyordur, ayrıca açıklamaya gerek kalmaz.

Nedeni ekranda görünmüyorsa bir yere yazmak gerekir. En ucuz çözüm düğmenin hemen altındaki tek satırlık açıklama. İpucu balonu, dokunmatik cihazlarda üzerine gelme diye bir şey olmadığı için tek başına yetmez.

Pratik ölçüt

Bir öğeyi kapatmadan önce şu cevabı hazır edin: kullanıcı bunun neden kapalı olduğunu ekrana bakarak, tek seferde anlayabiliyor mu? Cevap evetse kapatın. Hayırsa ya nedeni yazın ya da öğeyi açık bırakıp hatayı tıklamadan sonra gösterin. Sadeleşmiş görünen ama kullanıcıyı çıkmazda bırakan arayüz, kalabalık arayüzden daha pahalıya mal oluyor.