Bir filtreyi korumak, başarısız işlemi doğru anlatmak ve kullanıcının başladığı işe dönmesini sağlamak. Muhit’in tasarım yaklaşımı, bu küçük kararların uygulamada karşılık bulmasıyla belirginleşiyor.
İlk yazıda Muhit’i ortak bir davranış dili üzerinden ele almıştım. Bir arayüzün tutarlılığı; renkler ve yazı karakterleri kadar, kullanıcının yaptığı işin farklı ekranlar arasında nasıl devam ettiğine de bağlıydı.
Bu düşüncenin uygulamadaki karşılığını görmek için küçük bir akışı izleyebiliriz: Bir kaydı bulmak, açmak, üzerine not yazmak ve listeye geri dönmek.
Muhit’in güncel geliştirme örneklerinden biri bu akış üzerine kurulu. Örnekte araştırma çerçevesi, ortak kaynaklar ve karar notları gibi birkaç kayıt bulunuyor. Kullanıcı listeyi aramayla daraltıyor, bir kaydı açıp not yazıyor. Listeye dönüp aynı kaydı yeniden açtığında arama koşulu ve yazdığı not korunuyor.
Görünürde oldukça sıradan bir etkileşim. Ancak bunun gerçekleşmesi için arayüzün neyi hatırlayacağına, ne zaman unutacağına ve kullanıcıya ne söyleyeceğine karar vermek gerekiyor.
Bir kaydın etrafında verilen kararlar
Örnekte her kaydın taslağı kendi kimliğiyle tutuluyor. Böylece bir kayda yazılan not, başka bir kaydın alanında görünmüyor. Listeye dönmek taslağı temizlemiyor; arama alanı da kullanıcının bıraktığı koşulu koruyor.
Bu davranış, kişinin ekrana yeniden geldiğinde işini baştan kurmasını önlüyor. Aramayı tekrar yazmak, doğru kaydı yeniden bulmak veya az önceki cümleyi hatırlamaya çalışmak gerekmiyor.
Burada saklama süresi de tasarımın parçası. Örnekteki taslaklar yalnız açık sayfanın belleğinde tutuluyor. Sayfa yenilendiğinde veya sekme kapandığında kayboluyor. Bu sınır, düzenleme alanının yanında açıkça belirtiliyor.
“Emeği korumak” ilkesi böylece somut bir soruya dönüşüyor: Hangi bilgiyi, hangi kapsamda ve ne kadar süreyle koruyoruz?
Bir başka karar, ekranlar arasındaki odak geçişinde ortaya çıkıyor. Kayıt açıldığında klavye odağı ayrıntı başlığına taşınıyor. Listeye dönüldüğünde ise ilgili kaydın düğmesine geri geliyor.
Bu, görsel geçişin klavyeyle kullanan kişi için de bir karşılığı olmasını sağlıyor. Yeni görünümün nerede başladığı ve geri dönüldüğünde nerede kalındığı anlaşılır oluyor.
Aramada sonuç bulunamadığında da ayrı bir durum gösteriliyor. Kullanıcıya aramasına uyan kayıt olmadığı söyleniyor ve aramayı temizleme olanağı sunuluyor. Bu durum, verinin yüklenemediği bir hata gibi anlatılmıyor. Çünkü izlenecek yol farklı: Arama sonucunu değiştirmek için sorguyu düzenlemek gerekir; başarısız bir istekte ise yeniden denemek anlamlı olabilir.
Hata ve iptal, akışın içinde
Aynı örnekte işlemi bilerek başarısız kılan bir seçenek bulunuyor. Amaç, yalnız sorunsuz ilerleyen ekranı göstermekle yetinmeden toparlanma davranışını da inceleyebilmek.
Kullanıcı bir not yazıp işlemi başlattığında, arayüz bekleme durumuna geçiyor. Tekrar gönderim engelleniyor, işlem sürerken not alanı değiştirilemiyor ve iptal kontrolü görünür hâle geliyor.
Örnek işlem başarısız olduğunda yazılan not korunuyor. Mesaj, ne olduğunu anlatıyor ve yeniden denemenin yolunu gösteriyor. Düğmenin etiketi de bu yeni duruma uyum sağlıyor.
Böylece hata, kullanıcının bütün akışı baştan yaşamasını gerektiren bir kesintiye dönüşmüyor. Başarısız olan işlemin çevresinde, devam edilebilecek bir alan kalıyor.
İptal de aynı dikkatle ele alınıyor. Kullanıcı beklerken vazgeçtiğinde örnek işlem durduruluyor; taslak korunuyor ve onay verilmediği belirtiliyor. Önceki işlemin gecikmiş sonucu daha sonra gelip ekranı başarı durumuna çeviremiyor.
Gerçek bir sunucuyla çalışan uygulamada bu ayrım daha fazla dikkat istiyor. İsteğin istemci tarafında iptal edilmesi, sunucuda başlamış bir işlemin geri alındığını tek başına kanıtlamaz. Uygulamanın gerçek sonucu ayrıca değerlendirmesi gerekir.
Muhit’in React ve Vue referans entegrasyonlarında da bu sınır görünür. Form yeniden kurulurken devam eden işlem için iptal sinyali üretiliyor. Uygulamanın bu sinyali ağ isteğine iletmesi ve iptal edilmiş bir yanıtla kendi durumunu güncellememesi bekleniyor.
Kütüphane ile uygulamanın sorumlulukları burada birbirine bağlanıyor. Bileşen, etkileşimin yaşam döngüsünü yönetiyor; kaydın gerçekten gerçekleşip gerçekleşmediğini uygulama biliyor.
Çalışan küçük örnekteki düğmenin adı da bu nedenle “Yerel olarak onayla”. Başarılı sonuç, yalnız o sekmenin belleğindeki onayı ifade ediyor. Sunucuya veya kalıcı depoya kayıt yapıldığı izlenimi verilmiyor.
Geri bildirimin kapsamı, gerçekleşen işlemin kapsamıyla aynı olmalı.
Aynı yaklaşımı başka ekranlara taşımak
Bu kararları her projede yeniden uygulamak zamanla zorlaşıyor. Özellikle dil, tema veya görünüm değiştiğinde bileşenlerin yeniden kurulması gerekebiliyor.
Muhit’in React ve Vue referanslarında tablo yeniden kurulurken mevcut görünümün bir anlık görüntüsü alınıyor. Desteklenen akışlarda filtre, seçim ve sütun düzeni yeni bileşene taşınıyor. Uygulama açıkça yeni bir değer verirse bu değer öncelik kazanıyor.
Bu ayrıntı, durumun sahibini belirginleştiriyor. Uygulamanın sürekli kontrol etmesi gereken bilgiler, ilgili değişiklik olaylarıyla uygulamanın kendi durumuna aktarılmalı. Her yeniden çizimde korunması beklenen davranışın nerede yönetildiği bilinmeli.
Aynı ayrım Muhit’in JSON arayüz adaptörü için de geçerli. Adaptör geçersiz bir güncellemede mevcut görünümü koruyor; başarılı bir güncellemede ise görünümü yeniden kuruyor. Eski tablonun filtre ve seçim durumu bu yoldan kendiliğinden taşınmıyor. Daha sürekli bir etkileşim gerekiyorsa uygulamanın ilgili bileşen API’siyle bu sürekliliği kurması gerekiyor.
Tema tarafında da kararlar belirli roller üzerinden alınıyor. Bir yüzeyin zemini, okunacak metin, eylem vurgusu ve klavye odağı ayrı değişkenlerle tanımlanıyor. Örneğin --mh-surface ile --mh-text birlikte kullanılıyor; vurgulu bir düğmenin üzerindeki metin için --mh-on-accent seçiliyor.
Bu yapı, paleti değiştirirken bileşenin anlamını takip etmeyi kolaylaştırıyor. Yine de gerçek ekranın incelenmesi gerekiyor: Seçili öğe anlaşılıyor mu? Odak görünür mü? Daha yoğun yerleşimde kontroller rahat kullanılabiliyor mu?
Bir projeye Muhit’i uygularken bu yüzden önce en gösterişli ekranı seçmek yerine, baştan sona izlenebilecek küçük bir görev seçmeyi anlamlı buluyorum. Bir kaydı bulmak ve düzenlemek bunun için yeterli olabilir.
Ardından aynı görevi farklı koşullarda yürütmek gerekiyor: Sonuç bulunamadığında, işlem başarısız olduğunda, kullanıcı vazgeçtiğinde, dil değiştiğinde ve klavyeyle ilerlediğinde.
Bu örnekler çalışan davranışları gösteriyor. Gerçek cihaz ve manuel ekran okuyucu kabulü ise hâlâ tamamlanması gereken değerlendirmeler arasında.
Muhit’in uygulama tarafında aradığım karşılık böyle oluşuyor: Bir tasarım kararı, kullanıcı başladığı işe devam edebildiğinde görünür hâle geliyor. Notu yerinde durduğunda, hata anlaşılır olduğunda ve ekrandaki onay gerçekten ne olduğunu söylediğinde.
Bu yazı Muhit’in yerel 0.16.0 geliştirme kaynağındaki tasarım ilkeleri, çalışan kayıt akışı ve entegrasyon sözleşmelerine dayanır. Örnekler, bir üretim ortamında kullanıma veya tamamlanmış manuel erişilebilirlik kabulüne dair iddia değildir.
Kaynaklar: Muhit kaynak kodu · JSON arayüz sözleşmesi
Okumaya devam
Bu yazıyla ortak konuları olan yayınlar.
Bir arayüz önermek, işlem yapma yetkisi verir mi?
Muhit üzerinden yapay zekânın arayüz önerileri, işlem yetkisi ve insanın kontrolü arasındaki sınırlar.
Muhit: Bir arayüzü tutarlı yapan nedir?
Muhit üzerinden görsel dil, sayfa durumları, bağlamın korunması ve arayüzün verdiği söz üzerine.
Bağlantıları
Muhit: Bir arayüzü tutarlı yapan nedir?
İlk Muhit yazısındaki ortak davranış dilini; taslak, odak, hata, iptal ve tema kararlarının çalışan örnekleriyle uygulamaya taşır.
Bir arayüz önermek, işlem yapma yetkisi verir mi?
Çalışan arayüz kararlarından AI önerisi, işlem yetkisi ve insan kontrolü arasındaki uygulama sınırlarına ilerler.