Not Başlıkları API Gibidir: Konu Adı Yerine İddia Yazmak

"Karar verme" kötü bir başlık mı?

Kaynak notu veya klasör için hayır.

Kalıcı düşünce notu için çoğu zaman evet.

Şu başlıkları karşılaştır:

• Karar verme
• Choice overload
• Seçenek sayısı arttıkça karar kalitesi her zaman artmaz

Üçüncü başlık notun içinde ne bulacağını yaklaşık olarak söyler. Ayrıca başka bir paragrafın içine doğal biçimde yerleştirilebilir:

"Fiyatlandırma ekranında seçenek eklemek her zaman faydalı değildir; [[seçenek sayısı arttıkça karar kalitesi her zaman artmaz]]."

Başlık artık basit dosya etiketi değil, düşüncenin kullanılabilir bir tutamacıdır.

API benzetmesi ne anlatıyor?

Andy Matuschak ["Evergreen note titles are like APIs"](…) notunda iyi başlığın tüm notun fikirlerine erişmek için bir arayüz gibi çalıştığını söyler.

Yazılım API'sinde dışarıdaki kod modülün bütün iç detaylarını bilmez. Doğru isimlendirilmiş bir fonksiyon veya arayüz yeterlidir.

Notta da benzer bir durum vardır. Keskin başlık, ayrıntıları her seferinde yeniden okumadan düşünceyi çağırabilmeni sağlar.

Konu başlığını iddiaya dönüştürmek

Konu: Alışkanlıklar

Zayıf: "Alışkanlıklar"

Daha iyi: "Çevredeki işaretler alışkanlığın başlamasını kolaylaştırır"

Konu: PKM

Zayıf: "Not alma"

Daha iyi: "Yakalanan her bilgi kalıcı nota dönüşmemelidir"

Konu: Ürün tasarımı

Zayıf: "Onboarding"

Daha iyi: "Onboarding ilk değere ulaşma süresini azaltmalıdır"

Bu başlıklar tartışılabilir. Bu iyi bir özelliktir; çünkü not artık yalnız etiket değil, desteklenmesi gereken bir düşüncedir.

Tam cümle neden yardımcı olur?

Matuschak ayrıca tam ifadelerin düşüncedeki bulanıklığı görünür kıldığını savunur. Başlık yazmakta zorlanıyorsan notun kendisi henüz net olmayabilir.

Örneğin:

"AI ve not alma ve bağlam"

başlığı üç farklı yönü aynı anda taşımaya çalışıyor.

Bunu ayırabilirsin:

• "Yapay zekâ kaynak notlarını sınıflandırabilir"
• "Kalıcı notun ana iddiasını kullanıcı yazmalıdır"
• "Kaynak izi olmayan AI özeti güvenilir bilgi notu değildir"

Birinci ve üçüncü not farklı projelerde tekrar kullanılabilir.

Her başlık iddia mı olmalı?

Hayır.

Sorular da güçlü başlıklardır:

• "Bir not ne zaman bölünmeli?"
• "Günlük not ne zaman kalıcı nota dönüşmeli?"
• "Bir kaynağın güvenilirliğini nasıl kaydederiz?"

Ayrıca kişi, kitap, proje veya toplantı notları doğal olarak isim başlığı kullanabilir.

Kural yalnız düşünce notları içindir: başlık düşüncenin **ne söylediğini** taşısın.

Başlık değişirse linkler bozulur mu?

Kullandığın araca bağlıdır. Obsidian gibi bazı uygulamalar yeniden adlandırırken iç bağlantıları güncelleyebilir; düz Markdown sisteminde slug veya kalıcı kimlik kullanmak daha güvenli olabilir.

Bu teknik detay yüzünden kötü başlığı sonsuza kadar korumak gerekmez.

Evergreen yaklaşımda düşünce keskinleştikçe başlık da değişebilir.

Uygulama

Bugün on eski notu aç.

Her biri için şu soruyu sor:

**Bu dosyayı açmadan başlıktan ana düşünceyi anlayabiliyor muyum?**

Anlayamıyorsan konu adını bir iddiaya veya soruya dönüştür.

Başlığı değiştirdikten sonra ilgili iki nota bağlantı ekle. Birkaç hafta sonra arama sonuçlarında ve bağlantı cümlelerinde farkı görürsün.

İyi başlık notu süslemez. Notu kullanabileceğin bir düşünce parçasına dönüştürür.

Başlık bir navigasyon problemi çözer

Bin notluk bir kasada başlık yalnız belge adı değildir. Üç farklı yerde görünür:

• arama sonucunda,
• wikilink önerisinde,
• backlink bağlamında.

Bu üç yüzeyde de notun tamamını okumadan doğru hedefi seçmen gerekir.

"Motivasyon" başlığı on farklı fikri temsil edebilir.

"Başlama maliyetini azaltmak motivasyon ihtiyacını düşürebilir" başlığı ise daha belirgindir.

Bu nedenle iyi başlık yalnız yazma kalitesini değil, sistemdeki **geri bulma maliyetini** de etkiler.

İyi başlık kalıpları

Her not iddia cümlesi olmak zorunda değildir. Farklı bilgi türleri için farklı kalıplar kullanılabilir.

İddia

"Tek bir capture noktası yakalama sürtünmesini azaltır"

Uzun ömürlü düşünce notları için güçlüdür.

Soru

"Bir not ne zaman kalıcılaştırılmalı?"

Araştırma devam ediyorsa yararlıdır.

Karşılaştırma

"MOC ile klasör aynı navigasyon problemini çözmez"

İki kavram arasındaki ayrımı taşır.

Mekanizma

"Hatırlama pratiği bilgiyi yeniden üretmeye zorlar"

Bilimsel veya teknik kavramlarda iyidir.

Karar

"Kaynağı doğrulanmamış AI özeti kalıcı nota alınmamalıdır"

Operasyonel prensiplerde nettir.

Başlık kalıbı notun kullanım biçimini yansıtmalıdır.

Başlığı küçük bir sözleşme gibi düşün

Yazılım API'si belirli bir davranış vaat eder. Not başlığı da okuyucuya bir vaat verir.

Başlık:

"Daily Notes yakalama kararını erteler"

ise gövde şunları açıklamalıdır:

• hangi karar erteleniyor,
• neden bu yararlı,
• hangi durumda zararlı,
• nasıl uygulanır.

Gövde aslında "Daily Notes nedir?" anlatıyorsa başlık ile içerik arasında sözleşme ihlali vardır.

Bu test, notların zamanla scope creep yaşamasını fark etmeyi kolaylaştırır.

Başlık refactoring'i

Evergreen not geliştikçe başlığın değişmesi normaldir.

İlk sürüm:

"Bildirimler"

İkinci:

"Bildirimler kullanıcıyı geri getirir"

Yeni kanıt sonrası:

"Bildirimler yalnız bağlama uygun olduğunda anlamlı geri dönüş üretebilir"

Son sürüm daha uzun fakat daha dürüst olabilir.

Başlığı değiştirirken şu kontrolleri yap:

1. Eski başlığa gelen bağlantılar güncelleniyor mu?
2. Alias gerekiyor mu?
3. URL/slug kalıcı mı?
4. Başlık artık notun tamamını temsil ediyor mu?

Başlık ile slug aynı şey değildir

Web sitesinde veya dosya tabanlı sistemde başlık sık değişebilir; URL'nin sürekli değişmesi istenmeyebilir.

Örnek:

Başlık: "Not Başlıkları API Gibidir: Konu Adı Yerine İddia Yazmak"

Slug: `not-basliklari-api`

Başlık gelecekte değişse bile slug sabit tutulabilir.

Bu ayrım backlink kırılmasını ve dış link kaybını azaltır.

PKM aracında da benzer biçimde:

• kalıcı ID,
• alias,
• display title

ayrıştırılabilir.

Her sistem bunu desteklemek zorunda değil; ama uzun ömürlü arşivlerde faydalıdır.

Arama açısından başlık tasarımı

Başlığı yalnız edebi yapmak da sorun yaratabilir.

"Unutmanın Sessiz Mimarisi"

güzel bir yazı başlığı olabilir; fakat vault içinde aradığın kavram "spacing effect" ise geri bulmak zorlaşır.

Çözüm iki katman:

**Açık kavram + güçlü iddia**

Örnek:

"Spacing Effect: Tekrar Aralığı Hedeflenen Hatırlama Süresine Bağlıdır"

Böylece hem terim hem düşünce başlıkta bulunur.

Çok uzun başlık problemi

Tam cümle başlıkları bazen 20–30 kelimeye çıkar.

Bu da link cümlelerini ağırlaştırır.

Örnek:

`[[Kullanıcının bir üründe ilk değeri görmesine kadar geçen süre onboarding başarısını değerlendirmek için en önemli göstergelerden biridir]]`

Okunabilirliği bozar.

İki çözüm var:

Alias

`[[uzun-slug|ilk değere ulaşma süresi]]`

Daha sıkı başlık

"Onboarding ilk değere ulaşma süresini azaltmalıdır"

Başlık tam düşünceyi taşımalı fakat makale özeti olmamalıdır.

Başlıkta belirsizlik testi

Şu kelimeler uyarı sinyali olabilir:

• şeyler,
• düşünceler,
• notlar,
• genel,
• çeşitli,
• bazı,
• önemli,
• bilgiler.

"PKM hakkında önemli notlar" neredeyse hiçbir şey söylemez.

Bunun yerine notun neden var olduğunu sor:

"PKM sistemi eski bilgiyi yeni projede yeniden kullanabilmelidir."

Bu cümle hem tartışılabilir hem bağlanabilir.

Aynı başlığın duplicate üretmesi

Büyük kasalarda benzer başlıklar ortaya çıkar:

• "Notları bağlamak"
• "Not bağlantıları"
• "Bağlantılı notlar"
• "Backlink kullanımı"

Bu durum aynı düşüncenin dört dosyada dağılmış olabileceğini gösterir.

Periyodik bakımda benzer başlıkları arat:

1. Aynı iddia mı?
2. Biri kaynak notu, biri kalıcı not mu?
3. Birleştirmek gerekir mi?
4. Gerçekten farklıysa ayrımı başlıkta görünür yapabilir misin?

Örneğin:

• "Backlink gelen bağlamları görünür kılar"
• "MOC konu içinde editoryal rota oluşturur"

artık ayrım nettir.

Başlık yazamıyorsan ne yapmalı?

Başlığı zorlamak yerine gövdeyi şu üç cümleyle başlat:

1. Problem nedir?
2. Bu notun iddiası nedir?
3. Neden önemli?

Sonra ikinci cümleyi başlık adayı olarak kullan.

Örnek:

Problem: Kaydettiğim kaynakları bir daha bulamıyorum.

İddia: "Kaydederken kullanım nedenini yazmak, gelecekteki geri çağırmayı kolaylaştırır."

Neden: Çünkü yalnız URL, gelecekteki bağlamı taşımaz.

Başlık neredeyse kendiliğinden ortaya çıkar.

Başlık kalitesi sistem kalitesini nasıl etkiler?

İyi başlık:

• autocomplete'i daha anlamlı yapar,
• backlink panelini okunabilir kılar,
• MOC'larda açıklama ihtiyacını azaltır,
• yazı taslağında notları cümle gibi kullanmayı kolaylaştırır,
• duplicate fark etmeyi kolaylaştırır.

Bu yüzden başlık düzenleme kozmetik bakım değildir. Bilgi sisteminin arayüz tasarımıdır.

Bir kasanın UI'ı yalnız uygulamanın sidebar'ı değildir; notların isimleri de arayüzdür.

Başlığı backlink panelinde test et

Bir başlığın kalitesini yalnız dosyanın üstünde değerlendirme.

Backlink panelinde şu cümleyi gör:

"Bu karar [[Not Başlıkları API Gibidir]] yaklaşımıyla ilişkili."

Başlık cümlede doğal çalışıyor mu?

Başka test:

Arama sonuçlarında yalnız başlıkları gör. Hangisini açman gerektiğini tahmin edebiliyor musun?

Başlık bu iki yüzeyde başarısızsa dosyanın içeriği ne kadar iyi olursa olsun navigasyon maliyeti yüksektir.

Bu nedenle başlık refactoring'i yalnız editoryal temizlik değil, geri bulma performansı optimizasyonudur.

Başlık standardı ekiplerde daha da önemlidir

Tek kişilik kasada kötü başlığı hatırlayabilirsin. Paylaşılan bilgi sisteminde ekip senin zihinsel bağlamına sahip değildir.

Bu durumda başlık:

• açık özne,
• açık iddia,
• mümkünse alan terimi

taşımalıdır.

"Önemli karar" yerine:

"Production deploy build doğrulanmadan başlatılmamalıdır"

gibi başlık, başka bir kullanıcı için de anlamlıdır.

İyi başlık kişisel hafızaya bağımlılığı azaltır.