Yeniden Kullanılabilir UX Bileşenleri: Eşik, Fiş ve Bakım Maliyeti
Bir tarih seçici ilk yazıldığında tek bir ekrana aittir. İkinci ekrana taşıdığınız anda o parça bileşene dönüşür: sürümü olur, dokümanı olur, sizden habersiz kullananları olur. Bu dönüşümün kârlı hale geldiği bir eşik var ve ekiplerin çoğu eşiği beklemeden kütüphane kuruyor.
Yeniden kullanılabilir eleman nedir
Yeniden kullanılabilir eleman, bir projede çözülüp başka projelerde olduğu gibi ya da küçük ayarlarla tekrar çalışan arayüz parçasıdır: buton, form alanı, kart, menü, uyarı kutusu. Kodda modül ne ise tasarımda da odur. Fark şurada: koddaki modülün sınırlarını derleyici zorlar, tasarım bileşeninin sınırlarını ise yalnızca yazdığınız doküman tutar. Doküman yoksa ortada bileşen değil, kopyalanmış bir ekran parçası vardır.
Ayrımı şöyle test edin. Parçayı yeni projeye taşırken içine girip görsel kararlarını baştan vermeniz gerekiyorsa, o hâlâ bileşen değildir; bir başlangıç şablonudur. Bu kötü bir şey değil, ama kütüphaneye koyup bakım yükünü üstlenmeye değmez.
Kütüphaneye alma eşiği
Bir parçayı genelleştirmek, onu tek yere yazmaktan pahalıdır. Neyin değişken olacağını ayırmak, isimlendirmek, kenar durumlarını düşünmek ve hepsini yazıya dökmek zaman ister. Yazılımdaki karşılığı üç kuralıdır: aynı çözümü ikinci kez yazmak kopyalamaktır, soyutlama üçüncüde başlar. Tasarım bileşenleri için de aynı eşik işe yarar. İki kullanımda genelleştirme masrafı ancak başa baş gelir, asıl kazanç üçüncüden sonra birikir.
Eşiği erken geçmenin bedeli görünmez olduğu için tehlikelidir: on beş bileşenlik bir kütüphanenin dördü tek projede kullanılıyorsa, o dört bileşen kimseye zaman kazandırmadan herkesin gözden geçirme listesinde durur.
Bileşen fişinde ne yazar
Dokümantasyon burada roman değil, fiş demek. Bir bileşeni ikinci bir ekibin doğru kurabilmesi için şu başlıklar yeter:
- İsim: kullanıcının ne yaptığını söyleyen kısa ad ("Tarih Seç").
- Kullanıcı ihtiyacı: hangi problemi çözüyor.
- İçerik: hangi alanlar, hangi metinler, hangi veri.
- Yerleşim: ekranda nereye oturur, hangi hiyerarşide durur.
- Etkileşim: kullanıcı sırayla ne yapar, sistem ne cevap verir.
- Teknik notlar: doğrulama kuralları, format, erişilebilirlik gerekleri.
Her bileşeni fişlemeye çalışmayın. Kütüphanenin en çok çağrılan on parçası düzgün belgelenmişse, gerisini belgelemek işi hızlandırmaz, sadece bakılacak sayfa sayısını artırır.
Örnek: saat girişi alanı
Somutlaştıralım. İsim, saat girişi alanı. Kullanıcı ihtiyacı, saatin hızlı ve hatasız girilmesi. İçerik, saat ve dakika için iki alan ve kısa bir yardım metni. Etkileşim, kullanıcı ilk alanı seçer, iki hane girer, odak kendiliğinden dakikaya geçer. Teknik notlarda 24 saat formatı, geçersiz değerde alan altında görünen hata metni ve klavyeyle gezinme sırası yazar.
Bu bileşenin klasik hatası, alan adını placeholder olarak yazmaktır. Kullanıcı yazmaya başladığı anda "Saat" ipucu kaybolur, formu yarıda bırakıp dönen kişi hangi kutunun ne olduğunu bilemez; ekran okuyucular da placeholder'ı etiket yerine güvenilir biçimde okumaz. Etiket alanın üstünde kalıcı olarak dursun, placeholder yalnızca format örneği göstersin.
Paylaşılan kütüphane bakımı kolaylaştırmaz, merkezileştirir
Bileşen kütüphanelerinin en sık tekrarlanan vaadi "tek yerden güncelle, her yerde düzelsin" cümlesidir. Doğru tarafı var, ama tersi de aynı ölçüde doğrudur: tek yerden bozarsanız her yerde bozulur. Paylaşılan bir bileşende yapılan değişikliğin maliyeti, o bileşeni kullanan proje sayısıyla doğru orantılı büyür.
Bir projede tarih seçiciyi ortak kütüphaneye aldık; aylar sonra format davranışında tek satırlık bir düzeltme, üç ayrı üründe yeniden test turu olarak geri döndü. O günden beri ortak kütüphaneye giren her bileşenin sürümlenmesini ve projelerin sürümü kendi takvimlerinde yükseltebilmesini şart koşuyorum.
Pratikte iki kural yetiyor: kütüphanenin bir sahibi olacak ve değişiklikler sürümlenecek. Sahibi olmayan kütüphane altı ayda birbirinin biraz farklı kopyası olan üç butona sahip olur, ki bu tam olarak kaçmak istediğiniz durumdur.
Kaynak