Bileşen Tabanlı Tasarım Sistemleri Ne Zaman İşe Yarar
Bir düğmeyi tek yerden değiştirip sitenin tamamında değiştiğini görmek, tasarım sisteminin en çok anlatılan vaadi. Bu vaat yalnızca düğme gerçekten tek bir kaynaktan geliyorsa çalışır; on iki yere kopyalanmış düğme varsa ortada sistem değil, ortak bir isimlendirme alışkanlığı vardır. Aradaki farkı anlamanın yolu bileşen sayısını saymaktan değil, bir değişikliğin kaç dosyaya dokunduğuna bakmaktan geçiyor.
Kopya mı, kaynak mı
Bileşen tabanlı tasarım, arayüzü düğme, form, kart ve menü gibi parçalara ayırmak demek. Ayırmak kolay kısmı. Zor kısmı, aynı görünen iki düğmenin aynı tanımdan gelip gelmediği. Tasarım dosyasında bileşen olarak işaretlenmiş ama kodda üç ayrı yerde elle yazılmış bir düğme sisteme ait değildir, sadece öyle görünür.
Basit bir sınama var: bileşenin iç boşluğunu 12 pikselden 16'ya çıkarın, sonra kaç dosyada değişiklik yapmak zorunda kaldığınızı sayın. Cevap birden büyükse sistem henüz tek kaynak değil.
Varyantlar çarpımsal büyür
Varyantlar anlatılırken hep toplama gibi sunulur: birincil, ikincil, üçüncül düğme, toplam üç varyant. Oysa eksenler birbirine çarpılır. Üç görsel tür, üç boyut ve dört durum (normal, üzerine gelme, odak, pasif) tanımladığınızda ortaya 36 kombinasyon çıkar. Buna "ikonlu / ikonsuz" gibi ikili bir eksen eklemek sayıyı 72'ye taşır.
Sayı kendi başına sorun değil, çünkü kodda bu kombinasyonların çoğu tek bir tanımdan türetiliyor. Sorun tasarım tarafında başlıyor: 72 kombinasyonun her birini elle çizip güncel tutmaya çalışan bir ekip, tutarlılık için kurduğu sistemin bakımına, tutarsızlığın kendisinden fazla zaman harcar. Varyant sayısını kısmak yerine eksen sayısını üçte tutmak daha işe yarar bir sınır.
Aynı kelime, farklı anlam
Tasarımcı ile geliştiricinin aynı terimi kullanması işbirliğini kolaylaştırıyor, orası doğru. Peki "ürün kartı" iki tarafta da aynı şeyi mi anlatıyor? Tasarım dosyasında kart bir çerçeve, bir görsel ve iki metin alanıdır. Kodda ise aynı kart, veri gelmediğinde ne göstereceğini, başlık üç satıra taştığında nereden kırpacağını ve görsel yüklenmezse yerine ne koyacağını da bilmek zorunda. Tasarımda hiç çizilmeyen bu durumlar, uygulamada kartın kodunun yarısını oluşturuyor.
Bu yüzden bileşen teslimini görsel yerine davranış listesiyle yapmak daha iyi sonuç veriyor. Boş durum ve taşma durumu yazılmamışsa bileşen tanımlanmış sayılmaz.
Ne zaman kurmaya değmez
Tasarım sisteminin bir kurulum maliyeti var ve bu maliyet proje küçüldükçe geri dönmüyor. Beş sayfalık bir tanıtım sitesinde bileşen kütüphanesi, dokümantasyon sayfası ve varyant matrisi kurmak sitenin kendisinden uzun sürer. Küçük projelerde bunu genelde tek bir değişken dosyasıyla çözerim: renk, boşluk ölçeği ve tipografi ölçeği bir yerde dursun, kalanı sayfanın içinde kalsın. Görünürdeki tutarlılığın büyük kısmını zaten bu ölçekler taşıyor.
Sistemin karşılığını verdiği yer başka: aynı arayüzün birden fazla ekip tarafından, birden fazla üründe kullanıldığı durumlar. Orada bileşenin bakım maliyeti kullanıcı sayısına bölünür. Tek projede ise tek ekibin sırtında kalır.
Sistemi ölçmenin tek yolu
Bir tasarım sisteminin işe yarayıp yaramadığını bileşen sayısı, dokümantasyonun uzunluğu ya da kütüphanenin ne kadar düzenli göründüğü söylemiyor. Söyleyen tek ölçü değişim maliyeti: marka rengi değiştiğinde, düğme yüksekliği arttığında veya yeni bir hata durumu eklendiğinde kaç yerde çalışmak gerekiyor. Bu sayı zamanla düşüyorsa sistem yaşıyor. Sabit kalıyorsa elinizde iyi düzenlenmiş bir arşiv var, sistem değil.