Bloguma Bir Yüz Verdim — ve Tasarımın Çözemediği Şeyi Öğrendim

Yedi gündür altyapıyla uğraşıyordum: site, API, veritabanı, yazma işlemleri. Hepsi çalışıyordu. Ama bloga her girdiğimde aynı şeyi düşünüyordum: binlerce blogdan biri gibi görünüyor. Kullandığım hazır şablon temiz ve düzgündü, ama bana ait hiçbir şey yoktu içinde.

Bugün bunu değiştirdim.

Neden hazır bir tema seçmedim

İlk refleksim “internetten güzel bir tema bulayım” olacaktı. Ama bir şey fark ettim: yazdığım her yazıda farkında olmadan aynı dili kullanıyormuşum. “Bir devre gibi düşünmeyi seviyorum.” “Topraklama hattını yanlış bağlarsan devre çalışır gibi görünür ama güvenli değildir.”

Elektrik mühendisiyim ve her şeyi devre olarak düşünüyorum. O zaman blogun da öyle görünmesi gerekiyordu.

Böylece tasarımın teması belli oldu: baskı devre kartı. Bakır hatlar, lehim noktaları, kartın köşelerindeki montaj delikleri. Süs olsun diye değil — çünkü bu benim zaten konuştuğum dil.

Burada küçük ama önemli bir ders var: iyi tasarım, konunun kendi dünyasından çıkar. Dışarıdan takılan bir tema her zaman takma durur.

Ne istedim, ne öğrendim

“Kaydırdıkça devre çizilsin, üç boyutlu ve hareketli olsun” dedim. Aldığım cevap kısmen hayırdı ve gerekçesi beni ikna etti.

Gerçek 3D (tarayıcıda çalışan üç boyutlu sahneler) için ayrı ve ağır bir kütüphane yüklemek gerekiyor — yarım megabayttan fazla. Bir blog için bu, okuyucunun umursamadığı bir şey için ödediğin yüksek bir fatura. Telefonda açılış yavaşlar, pil yer.

Ama “3D hissi” dediğimiz şeyin çoğu aslında 3D değilmiş: katmanlı derinlik. Arka plan yavaş hareket ediyor, ön plan hızlı; aktif olan şey öne çıkıyor. Bunlar neredeyse bedava ve her telefonda akıcı çalışıyor.

Sonuçta sayfada üç katman var: en arkada yavaş hareket eden soluk devre hatları, ortada sabit duran nokta ızgarası, önde metin. Üçü farklı hızlarda gittiği için sayfa düz bir kağıt değil, üst üste duran yüzeyler gibi hissettiriyor. Hiçbir 3D kütüphanesi yok.

İki yeni araç: GSAP ve Lenis

GSAP, hareketleri yöneten bir araç. “Şu şey, sen sayfayı şu kadar kaydırdığında, şu kadar çizilsin” gibi şeyleri söylemeni sağlıyor. Bunu elle yazmak mümkün ama GSAP bunu hem daha akıcı hem daha az kodla yapıyor. İnternette gördüğün o “nasıl yapmışlar” dediğin kaydırma animasyonlarının neredeyse tamamı bununla yapılıyor.

Lenis çok daha küçük bir araç ve tek bir iş yapıyor: kaydırma hissini değiştiriyor. Normalde fare tekerleğini çevirdiğinde sayfa kademe kademe sıçrar. Lenis bunu yumuşak bir ivmeye çeviriyor — gidip yavaşlayarak duruyor. Küçük bir detay gibi duruyor ama o “pahalı site” hissinin yarısı tek başına bundan geliyor.

Dürüst fatura: ikisi birlikte ziyaretçiye yaklaşık 50 kilobayt ek yük getiriyor. Az değil. Ama bu dosya sayfanın gösterilmesini bekletmiyor; metin hemen geliyor, animasyonlar arkadan yetişiyor. Bu ayrım önemli: ağırlık, gecikme demek değil — nereye koyduğuna bağlı.

Tasarımın çözemediği şey

Tasarıma başlamadan önce bir sorunum vardı: yazılar listede yanlış sırada duruyordu. 6. Gün, 7. Günün üstünde görünüyordu.

Aklımdan geçen şuydu: “Nasılsa listeyi baştan yazacağız, tasarım sırasında düzelir.”

Düzelmedi, çünkü sıralama bir tasarım meselesi değil, veri meselesi. Sayfayı ne kadar güzel yaparsan yap, “hangi yazı önce gelir” sorusunun cevabı değişmiyor. İki ayrı katman bunlar: biri verinin ne olduğu, diğeri nasıl göründüğü. Karışık bir veriyi güzel göstermek sorunu çözmüyor, sadece saklıyor.

Veriyi düzeltmek yerine kuralı düzeltmek

Sorunun sebebi basitti: iki yazının tarihi aynıydı, ikisi de 17 Ekim. Sıralama “hangisi daha yeni” diye bakıyor, cevap bulamıyor ve rastgele bir düzene düşüyordu.

Benim ilk çözümüm şuydu: tarihlerin yanına saat ekleyelim, biri 20:00 diğeri 22:00 olsun, sıra netleşsin.

Daha iyi bir öneri geldi: tarihe dokunma, sıralama kuralına ikinci bir ölçüt ekle. Yani “önce tarihe bak; tarihler eşitse gün numarasına bak.”

İkisi de sorunu çözüyor ama aralarında büyük fark var. Benimki tek seferlik bir yama: o iki yazı için çalışır, gelecekte aynı güne denk gelen her yazıda tekrar elle müdahale etmem gerekir. Diğeri ise kuralı düzeltiyor — bundan sonra aynı duruma düşen her yazıda kendiliğinden çalışıyor.

Veriyi düzeltmek tek bir vakayı çözer, kuralı düzeltmek bütün vakaları çözer. Bunu aklımın bir köşesine yazdım.

Hareket istemeyen insanlar

Bu, hiç bilmediğim bir konuydu ve öğrendiğime memnunum.

Bazı insanlar hareketli sayfalarda gerçekten rahatsız oluyor — baş dönmesi, mide bulantısı. İç kulak hassasiyeti, migren, bazı nörolojik durumlar. Bu bir tercih meselesi değil, fiziksel bir tepki.

Bunun için işletim sistemlerinde “hareketi azalt” diye bir ayar var ve tarayıcı bu bilgiyi siteye iletiyor. Yani site, karşısındaki kişinin bunu istemediğini bilebiliyor. Bizim sitede o ayar açıksa: GSAP ve Lenis hiç başlamıyor, hatlar en baştan çizilmiş halde duruyor, hiçbir şey kıpırdamıyor.

Ama bir inceliği sonradan fark ettik. İlk halde o modda okuma ilerleme çizgisini de kapatmıştık. Oysa o çizgi bir hareket efekti değil, konum bilgisi — “yazının neresindeyim” sorusuna cevap veriyor. Hareket istemeyen biri de bunu bilmek ister. Düzelttik: o modda da çalışıyor, sadece yumuşak geçiş olmadan, anında.

Ayrım şu: hareketi kapatmak, bilgiyi kapatmak değildir.

Metin, JavaScript’e bağlı olmamalı

Tasarımda yazılar alttan süzülerek beliriyor. Bunun teknik tarafında bir tuzak var: animasyonun düzgün başlaması için öğeler önce görünmez olmalı.

Peki JavaScript hiç çalışmazsa? Yavaş bir bağlantı, kapatılmış bir ayar, bir hata — o zaman metin hiç görünmez.

Doğru kurulum şu: gizleme işini JavaScript’in kendisi yapar. JavaScript çalışmazsa hiçbir şey gizlenmez, metin olduğu gibi görünür. Yani animasyonun yokluğu içeriği götürmez.

Kural basit: süs eksik olabilir, içerik asla.

Onüçüncü hata: yanlış katmanda hata aramak

Bugünün en çok vakit kaybettiren kısmı buydu.

Tasarım bitti, siteyi kendi bilgisayarımda açmak istedim. Açılmadı — site, yazıları API’den çekemiyordu, bağlantı zaman aşımına uğruyordu.

İlk düşüncem: “Demin kodu değiştirdik, bir şeyi bozmuş olmalıyız.”

Sonra kontrol ettim: API tarayıcıda sorunsuz açılıyordu. Komut satırından da çalışıyordu. Bağlantı testi de geçiyordu. Sadece sitenin kendi içinden çalışmıyordu.

Bir saat boyunca Node’un ağ ayarlarını kurcaladım. IPv4/IPv6 denedim, çeşitli bayraklar denedim, hiçbiri işe yaramadı.

Sonunda işi bırakıp değişiklikleri GitHub’a göndermeye çalıştım. O da başarısız oldu — GitHub’a da bağlanamıyordu.

İşte o an anladım: sorun ne Node’daydı, ne Astro’da, ne de benim API’mde. İnternet bağlantım aralıklı olarak bozuktu. Bazı HTTPS bağlantıları kuruluyor, bazıları yirmi saniye bekleyip düşüyordu. Sabahtan beri yaşadığım her şeyin sebebi buydu.

Ders şu: bir şey bozulduğunda ilk şüphelimiz en son değiştirdiğimiz şey oluyor. Çoğu zaman haklı bir refleks, ama bu sefer beni saatlerce yanlış katmanda arattı. Keşke en başta “acaba başka bir siteye bağlanabiliyor muyum?” diye sorsaydım — bir dakikalık test, bir saatlik kazanç.

Ve bir düzeltme, kendini anında kanıtladı

Bağlantımın güvenilmez olduğu ortaya çıkınca bir şey daha düzelttik: site, yazıları çekerken bir denemede pes ediyordu. Bağlantı bir an takıldığında her şey duruyordu.

Artık üç kez deniyor, aralarında bekleyerek. Üçü de başarısız olursa yine duruyor — yazısız bir site yayınlamasını istemiyoruz, o kural değişmedi. Sadece ilk aksaklıkta pes etmiyor.

Bu düzeltmenin işe yaradığının kanıtı hemen geldi: sonraki iki derlemede ilk deneme düştü, ikinci deneme kurtardı. Yani bu değişiklik olmasaydı o iki derleme de başarısız olacaktı.

Burada küçük ama sinsi bir detay vardı. “Bekleme süresini 20 saniye yapalım” dedik, ama hata mesajı hâlâ timeout: 10000ms diyordu. Yani bizim koyduğumuz 20 saniye hiç devreye girmiyordu — Node, bağlantı kurma aşamasında kendi ayrı 10 saniyelik sınırını uyguluyormuş. Ayarladığımız yer, sınırı koyan yer değilmiş.

Bir ayarı değiştirdim diye o ayarın işlediğini varsayma. Hata mesajındaki sayı senin yazdığın sayı değilse, yanlış yeri ayarlamışsındır.

Bir not: görmeden yapmak

Tasarımı önce ayrı bir sayfa olarak hazırladım, sonra siteye uyarlattım. Hazırladığım o sayfada bir hata varmış: devre hattının bitiş noktası sayfanın kaydırılabilir alanının dışında kalıyordu, bu yüzden hat hiç tamamlanmıyor ve en alttaki “devre tamam” işareti hiç yanmıyordu.

Ben bunu fark edemedim, çünkü yazdığım sayfayı çalışırken göremiyordum. Uygulama aşamasında fark edildi ve düzeltildi.

Bu bana şunu düşündürdü: yapay zekâya kod yazdırmakla, yazdığı şeyi görebilen bir yapay zekâya kod yazdırmak arasında ciddi fark var. Kör yazan bir denemede ne çıkarsa onu verir; sonucu görebilen beş tur döner ve her turda iyileşir. Aradaki fark modelde değil, geri bildirim döngüsünde.

Sırada ne var?

Blogun artık bir yüzü var. Ama 7. Günde kurduğum yorum sistemi hâlâ arka tarafta, görünmez halde duruyor — ne bir yorum kutusu var, ne de yazıların altında görünen yorumlar.

Sıradaki adım o. Ve orada beni bekleyen bir engel olduğunu biliyorum: siteme bir yorum formu koyduğumda, tarayıcı bu isteği büyük ihtimalle engelleyecek. Çünkü sitem bir adreste, API’m başka bir adreste duruyor ve tarayıcılar bir sitenin başka bir adrese veri göndermesine varsayılan olarak izin vermiyor.

Kasıtlı bir güvenlik kuralı bu. Yarın muhtemelen bir hata ekranıyla başlayacağım — ama bu sefer ne olacağını önceden biliyorum.