Muhit: Bir arayüzü tutarlı yapan nedir?

Renklerden ve bileşenlerden başlayıp davranışlara, bağlama ve güvene uzanan bir tasarım sistemi üzerine.

Bir çalışma tablosu düşünelim. Kayıtları daraltıyor, birkaç satır seçiyor, ardından bir ayrıntıyı incelemek için başka bir görünüme geçiyoruz. Geri döndüğümüzde aramamızın, seçimimizin ve kaldığımız yerin korunmasını bekliyoruz.

Bu beklentiyi çoğu zaman tasarımın bir parçası olarak adlandırmıyoruz. Oysa arayüzle kurduğumuz ilişkinin önemli bir bölümü burada oluşuyor: Yaptığımız şeyin karşılığı ne olacak? Sistem neyi hatırlayacak? Bir işlem tamamlanmadığında bunu nasıl anlayacağız?

Muhit üzerinde çalışırken ilgilendiğim soru bu oldu: Bir arayüzün farklı parçaları, kullanıcıya nasıl ortak bir davranış sunabilir?

Tutarlılık nerede başlar?

Bir tasarım sisteminin görünür tarafını tarif etmek kolay. Yazı aileleri, renkler, boşluklar, düğmeler, kartlar ve tablolar bir araya gelir. Sayfalar arasında tanıdık bir ritim oluşur.

Ancak aynı görünen iki düğme farklı beklentiler yaratabilir. Biri işlemi hemen tamamlar, diğeri bir onay penceresi açar. Bir form hatayı ilgili alanın yanında gösterirken başka bir form yalnız kısa süreli bir bildirim verir. Bir tablo filtreyi korur, diğeri her güncellemede başlangıca döner.

Böyle bir arayüzde kullanıcı, görünüşü tanısa bile davranışı yeniden öğrenir.

Muhit’in çıkışında, Nevmos arayüz çalışmalarında oluşan parçaları bağımsız bir kütüphaneye dönüştürme düşüncesi vardı. Bu ayrıştırma, hangi kararların belirli bir ürüne ait olduğunu, hangilerinin başka çalışmalara taşınabileceğini sorgulamayı gerektirdi.

Bir ürünün logosu ve içerikleri kendi bağlamına ait. Buna karşılık görünür klavye odağı, anlaşılır durum etiketleri, bir hatadan sonra yeniden deneme olanağı ve yapılan işlemin sonucunu bildirmek daha geniş bir kullanım alanına sahip.

Muhit bu ortak kararları bir arada tutmaya çalışıyor. Adındaki çevre ve komşuluk çağrışımını da burada anlamlı buluyorum: Her parçanın kendi görevi var; birlikte oluşturdukları ortamın anlaşılır kalması gerekiyor.

Aynı dil, farklı koşullar

Bu ortamın her projede aynı görünmesi gerekmiyor.

Bir araştırma aracı uzun metinlere ve kaynaklara yer açabilir. Yoğun kullanılan bir yönetim ekranı daha sıkı bir yerleşim isteyebilir. Başka bir çalışma, daha sakin yüzeyler ve daha geniş boşluklarla kurulabilir.

Muhit’te tema yaklaşımını bu farklılıklar üzerinden ele alıyorum. Renk, tipografi, yoğunluk, sınırlar ve hareket tercihleri birlikte değişebiliyor. Bu değişikliklerin altında ise metin, zemin, vurgu, durum ve odak gibi tanımlı roller bulunuyor.

Böylece bir tema değiştiğinde şu soruları da sormak gerekiyor: Yazı hâlâ okunuyor mu? Seçili durum anlaşılıyor mu? Klavyeyle ilerleyen kişi nerede olduğunu görebiliyor mu? Yoğun görünümde dokunma alanı yeterli mi?

Benzer bir sınama, sayfanın farklı durumlarında ortaya çıkıyor.

İçerikle dolu bir ekran, tasarımın yalnız bir anını gösteriyor. Aynı ekranın veri beklerken, henüz kayıt yokken, bir istek başarısız olduğunda veya erişim gerektiğinde de bir karşılığı olmalı.

“Henüz kayıt yok” ile “kayıtlar yüklenemedi” farklı durumlar. Kullanıcının atacağı sonraki adım da farklı olabilir. İlkinde yeni bir kayıt oluşturmak anlamlıdır; ikincisinde yeniden denemek gerekebilir.

Muhit’in sayfa tariflerinde bu durumları ayrıca çalışmak, ekranın olağan akış dışındaki davranışını da tasarımın içine alıyor.

Aynı dikkat, bileşenler uygulamaya bağlandığında sürüyor. Referans entegrasyonlarda dil değişirken form taslağının korunması, bir tablo yeniden kurulurken filtre ve seçim durumunun taşınması gibi ayrıntılar önem kazanıyor. Kullanıcının az önce yaptığı işlem, sonraki adımın bağlamını oluşturuyor.

Bir arayüzün sözünü tutması

Bu yaklaşım, ajanların arayüz önerdiği durumlarda da karşılık buluyor.

Bir model, gösterilecek bilgileri ve sunulabilecek eylemleri yapılandırılmış bir tanım olarak önerebilir. Böyle bir tanımın hangi bileşenlere dönüşeceğini ve hangi sınırlar içinde kalacağını önceden belirlemek mümkün.

Muhit’in ajan adaptörü bu noktada çalışıyor: Tanımı doğruluyor ve izin verilen bileşenlerle görünümü kuruyor. Kullanıcı bir eylemi seçtiğinde bunu uygulamaya iletiyor. Verinin kaydedilmesi, bir isteğin gönderilmesi ve gerekli yetkinin denetlenmesi uygulamanın sorumluluğunda kalıyor.

Bu ayrımın kullanıcı açısından da açık olması gerekiyor. Bir “Kaydet” düğmesinin ekranda bulunması, kaydın başarıyla tamamlandığını göstermiyor. Arayüzün verdiği geri bildirim, arkasındaki işlemin gerçek durumuna dayanmalı.

Muhit’in tasarımında benim için belirleyici olan düşünce burada toplanıyor: Arayüzün verdiği söz ile sistemin yaptığı iş birbirine karşılık gelmeli.

Bu hâlâ sınanması gereken bir çalışma alanı. Muhit’in 0.15.0 sürümünde bileşenler, sayfa durumları, tema seçenekleri ve entegrasyon örnekleri üzerinde otomatik kontroller bulunuyor. Gerçek cihaz kullanımı ve ekran okuyucuyla yapılacak değerlendirmeler de çalışmanın devam eden tarafları arasında.

Bir tasarım sistemi geliştikçe yeni bileşenler kazanıyor. Ben bunun yanında, kullanıcıdan ne kadar yeni öğrenme istediğine de bakmak istiyorum.

Bir kez öğrendiğimiz davranış başka bir sayfada da anlamını koruyorsa, yaptığımız seçim sonraki adımda yerini buluyorsa ve sistem beklemediğimiz bir durumda bize anlaşılır bir yol sunuyorsa, ortak bir dil oluşmaya başlıyor.

Muhit’i, bu dilin içinde farklı çalışmaların kendi karakterleriyle yer bulabileceği bir ortam olarak geliştiriyorum.

---

Farklı biçimler, ortak bir ritim. Kapak görseli bu yazı için yapay zekâ ile üretilmiştir.

Kaynaklar: Muhit kaynak kodu · Muhit 0.15.0 belgeleri

İlgili yazı: Sınırlı bir görsel dil neyi mümkün kılar?

Atlas kavramları: Tasarım · Yazılım · Bağlam · Sistemler