Karmaşık Bilgi Sistemlerinde Kategori Ağacı, Navigasyon ve Pano Mimarisi: İlk Prensipler, Kullanıcı Deneyimi ve Teknik Entegrasyon Üzerine Kapsamlı İnceleme

Modern dijital ekosistemlerde, devasa veri yığınlarının anlamlı, erişilebilir ve kullanılabilir bilgiye dönüştürülmesi, ileri düzey bir bilgi mimarisi (Information Architecture) stratejisi gerektirmektedir. Özellikle tıp, mühendislik veya geniş ölçekli kurumsal dokümantasyon gibi yoğun ve spesifik veri barındıran alanlarda, bilginin nasıl yapılandırıldığı, son kullanıcının o bilgiye ne kadar hızlı ve doğru bir şekilde ulaşabileceğini belirleyen temel faktördür. Bilgi mimarisi, yalnızca menülerin sayfaya yerleştirilmesi işlemi değil; bilginin ontolojik olarak nasıl sınıflandırıldığı, hiyerarşik bağların nasıl kurulduğu ve kullanıcı yolculuklarının (user journey) bu yapılar üzerinde nasıl optimize edildiği ile ilgili çok disiplinli bir mühendislik ve psikoloji alanıdır.

Geleneksel web tasarımı, sayfaları birbirinden bağımsız bilgi adaları olarak ele alma eğilimindedir. Ancak bir referans kaynağı, bir wiki platformu veya kapsamlı bir medikal bilgi tabanı (knowledge base) kurgulanırken, sayfalar arasındaki ilişkilerin organik bir bütünlük sergilemesi şarttır. Bir konunun üst başlık ve alt başlık (parent-child) ilişkisine doğru bir şekilde yerleştirilmesi, bu organik bütünlüğün temel taşıdır. Sistemin arayüzü, arka planda yatan karmaşık veritabanı şemasını kullanıcıya en pürüzsüz şekilde yansıtmakla yükümlüdür.

Bu kapsamlı analiz; karmaşık bir bilgi tabanının sıfırdan nasıl kurgulanacağını, “İlk Prensipler” (First Principles) yaklaşımıyla taksonomik ilişkilerin nasıl tesis edileceğini, tıp profesyonelleri ve hastalar için iki ayrı evren sunan Merck/MSD Manuals’ın hiyerarşik yapısını derinlemesine incelemektedir. Ek olarak, Wikipedia’nın Vector 2022 arayüzü ile standartlaştırdığı sayfa içi yönlendirme (TOC) mantığının teknik arka planı ve karmaşık verileri tek ekranda özetleyen pano (dashboard) tipi ana sayfa tasarımları, teknik altyapıları ve kullanıcı deneyimi metrikleriyle birlikte detaylandırılmaktadır.

İlk Prensipler Düşüncesi ve Bilginin Ontolojik Temelleri

Kategori ağaçları, veritabanı tasarımında ve içerik yönetim sistemlerinde (CMS) bilginin tasnif edilmesini sağlayan omurga yapılardır. Doğru bir kategori ağacı kurabilmek için, mevcut ve belki de kusurlu yapıları kopyalamak yerine “İlk Prensipler” (First Principles) düşüncesiyle bilginin temel yapı taşlarına inilmesi gerekmektedir.1 Bu yaklaşım, statükoyu reddeden ve sorunları en temel, inkar edilemez gerçeklerine kadar parçalayan bir analitik çerçevedir.

Bilgiyi Semantik Bir Ağaç Olarak Modellemek

İlk Prensipler yaklaşımı, karmaşık bir problemi en temel bileşenlerine ayırmayı ve çözümü bu temel gerçekler üzerine sıfırdan inşa etmeyi içerir.1 Bilgi mimarisindeki kategori ağacı tasarımı “semantik bir ağaç” (semantic tree) olarak ele alınmalıdır.3 İnsan zihninin bilgiyi depolama kapasitesi sanıldığından çok daha yüksektir; asıl zorluk, bilginin miktarında değil, bilginin zihinde nasıl organize edildiğindedir.2 Semantik bir ağaç modelinde bilginin yapılandırılması üç ana aşamadan oluşur:

Gövde (Trunk) yapısı, bilgi alanının en temel dayanak noktalarını temsil eder.3 Tıbbi bir veri tabanında bu, “İnsan Anatomisi”, “Klinik Farmakoloji” veya “Hastalık Kategorileri” gibi en üst düzey evrensel ayrımları işaret eder. Bu temel kavramlar, bilginin üzerine inşa edileceği zemini oluşturur. Gövde ne kadar sağlam kurgulanırsa, sistemin geri kalanı da o kadar dayanıklı olur.

Büyük Dallar (Big Branches) ise ana kategorilerin altındaki temel disiplinlerdir.3 Örneğin tıp alanında Kardiyoloji, Nöroloji, Pediatri gibi uzmanlık alanları bu büyük dalları oluşturur.4 Yapraklar (Leaves) aşaması, belirli bir konu hakkındaki spesifik detaylardır.3 Koroner Arter Hastalığının teşhis yöntemleri veya spesifik bir ilacın yan etkileri bu kategoriye girer.5

Bu hiyerarşik yapının oluşturulmasındaki en büyük kural, gövde ve büyük dallar (temel ilkeler) sağlam bir şekilde anlaşılmadan ve yapılandırılmadan, yapraklara (detaylara) geçilmemesi gerektiğidir.3 Eğer bilgi ağacının üst yapısı mantıksal bir hataya sahipse, alt dallara eklenen her yeni veri, sistemin genelindeki navigasyon karmaşasını eksponansiyel olarak artıracaktır. Günümüzde yapay zeka (AI) sistemleri karmaşık veri kümelerini optimize etme konusunda son derece başarılı olsa da, bu sistemlerin çoğu hala korelasyon ile nedenselliği ayırt edememektedir.6 Yapay zeka bir sistemi optimize edebilir ancak o sistemin “neden” o şekilde çalıştığına dair temel bir anlayışa (understanding) sahip değildir.6 Bu nedenle, derin bilgi mimarilerinde kategorilerin mantıksal çerçevesinin insan uzmanlar tarafından ilk prensiplere göre kurgulanması zorunludur.6

MECE Prensibi ve Kapsamlı Bölümlendirme Stratejileri

Bilgiyi hiyerarşik olarak dizerken danışmanlık terminolojisinden ödünç alınan MECE (Mutually Exclusive, Collectively Exhaustive) prensibi hayati bir rol oynar.7 Kategori ağaçlarının kullanıcılarda kafa karışıklığı yaratmamasının tek yolu, tasarlanan yapının bilişsel bir netlik sunmasıdır. MECE ilkesi, oluşturulan kategorilerin şu iki şartı aynı anda sağlamasını emreder:

Mutually Exclusive (Karşılıklı Olarak Dışlayıcı) özelliği, aynı seviyedeki hiçbir alt başlığın, bir diğerinin içeriği ile örtüşmemesi gerektiğini ifade eder.7 Eğer bir kullanıcı belirli bir bilgiye ulaşmak için iki farklı kategori arasında kararsız kalıyorsa, sistem “dışlayıcılık” kuralını ihlal etmiş demektir. Kategori ağacındaki her dal, net sınırlarla birbirinden ayrılmalıdır. Bilgi tekrarından ve kesişim kümelerinden kaçınılmalıdır.

Collectively Exhaustive (Kolektif Olarak Kapsayıcı) özelliği ise, alt başlıkların tamamı bir araya geldiğinde, bağlı bulundukları üst başlığın temsil ettiği konunun tamamını oluşturması gerektiğini savunur.7 Hiçbir veri parçası veya muhtemel arama niyeti sistemin dışında bırakılmamalıdır. Bir şemsiye kategorinin altına yerleştirilen alt kategoriler, şemsiyenin kapladığı tüm alanı eksiksiz doldurmalıdır.

Özellik	Doğru Yapılandırma (MECE Uyumlu)	Yanlış Yapılandırma (MECE Uyumsuz)
Üst Başlık (Parent)	İklimlendirme Sistemleri	İklimlendirme Sistemleri
Alt Başlık 1 (Child)	Isıtma Çözümleri	Isıtma Çözümleri
Alt Başlık 2 (Child)	Soğutma Çözümleri	Klimalar (Soğutmanın bir alt kümesidir, hiyerarşi hatası)
Alt Başlık 3 (Child)	Havalandırma Çözümleri	Ev Aletleri (Kapsam dışı ve örtüşen kategori)

MECE prensibi doğrultusunda yapılandırılmış bir kategori ağacı, kullanıcının sezgisel olarak doğru yolu bulmasını sağlar. Kullanıcı, aradığı içeriğin nerede olabileceğini mantıksal bir çıkarım yoluyla bulabilir. Bu yaklaşım, karmaşık sorunların çözümünü hızlandırdığı gibi, bilginin iletişimini de kusursuzlaştırır.7

Üst Başlık – Alt Başlık İlişkilerinin (Parent-Child) Hiyerarşik Tasarımı

Bir konunun üst başlık-alt başlık ilişkisine doğru bir şekilde yerleştirilmesi, bilgi mimarisinin teknik ve taksonomik bütünlüğüne bağlıdır. İlişkisel veritabanlarında ve gelişmiş içerik yönetim sistemlerinde bu ilişki çeşitli teknik kurgularla sağlanır, ancak tasarımın temelinde insan bilişini temel alan kavramsal bir mimari yatar.

Hiyerarşik Semantik Bilişim Çerçevesi (HSCM)

Tıbbi belgeler veya bilimsel ansiklopediler gibi yapılar okunurken, sadece metinlerin değil, aynı zamanda bağlamın da yorumlanması gerekir. Bu bağlamda, hiyerarşik semantik kompozisyon modeli (Hierarchical Semantic Compositional Model – HSCM), insan bilişinin mekanizmalarından ilham alarak metinlerin mantıksal bir temsilini çıkarmak için kullanılır.8 İnsanlar bir metni okurken cümleleri yapısal bir sırayla ayrıştırır; semantik hafıza ve semantik aktivasyon süreçleri sayesinde eski bilgileri yeni bilgilerle birleştirerek hiyerarşik bir anlam haritası oluştururlar.8

Bilgi ağaçları kurgulanırken bu bilişsel yapı taklit edilmelidir. Kök düğüm (root node), bilginin en soyut ve kapsayıcı formunu temsil ederken; yapraklara (leaf nodes) doğru inildikçe bilgi özelleşir, spesifikleşir ve uygulanabilir hale gelir. Örneğin bir tıbbi veritabanında “Patojenik bulgular” doğrudan ana akışta görünmesi gereken (Primary) bilgilerken, testin metodolojisi gibi detaylar ikincil (Secondary) veya üçüncül (Tertiary) bilgi hiyerarşisinde yer almalıdır.10 Bu durum, kullanıcının (örneğin bir genetik uzmanının) acil eylem gerektiren veriye (örneğin patojenik varyantlar) anında ulaşmasını sağlarken, daha az acil olan meta verilere ancak bilinçli bir tıklama eylemi sonucunda (derin hiyerarşiye girerek) ulaşmasını sağlar.10

CMS Tabanlı Hiyerarşi Engelleri ve Geçici Çözümler

WordPress gibi dünya çapında en yaygın kullanılan CMS altyapıları üzerinden bir bilgi tabanı geliştirilirken, sistemin veri yapısı (data structure) ile bilgi mimarisinin hedefleri arasında çatışmalar yaşanabilir. WordPress mimarisinde içerikler temelde ikiye ayrılır: Sayfalar (Pages) ve Yazılar (Posts).11

Sayfalar (Pages) doğası gereği hiyerarşiktir. Bir sayfa, başka bir sayfanın “Ebeveyni” (Parent) olabilir, böylece iç içe geçmiş klasör mantığı (Örn: Hakkımızda > Ekibimiz > Vizyonumuz) kolaylıkla kurulabilir.11 Buna karşın Yazılar (Posts), kronolojik bir yapıda dizilirler ve aralarında doğrudan bir ebeveyn-çocuk hiyerarşisi kurmak standart WordPress çekirdeğinde mümkün değildir.11 Yazılar, hiyerarşik bağlarını Kategoriler (Categories) ve Etiketler (Tags) adı verilen taksonomiler aracılığıyla sağlarlar.

Bir tıp ansiklopedisinde, binlerce makale ekleneceği için bunları “Sayfa” olarak yapılandırmak performans ve içerik yönetimi açısından yanlıştır; bu metinler “Yazı” veya “Özel Yazı Tipi” (Custom Post Type – CPT) olarak kurgulanmalıdır. Ancak, bir yazının URL yapısını Ana Kategori > Alt Kategori > Yazı şeklinde dizmek veya site içindeki dolaşım haritasını buna göre göstermek istediğinizde, yazılar arasındaki ebeveyn eksikliği sorun yaratır.11 Özel bir makaleyi doğrudan başka bir sayfanın altına (örneğin: Eğitimler > Araştırma Merkezi > Makale Adı) hiyerarşik olarak bağlamak varsayılan ayarlarla imkansızdır.12

Bu sorunu çözmek için Özel Yazı Tipleri (CPT) yapılandırılırken hierarchical => true parametresi tanımlanarak yazılara tıpkı sayfalar gibi bir ebeveynlik özelliği kazandırılabilir veya çok katmanlı, MECE prensibine uygun, disiplinli bir “Kategori” ağacı oluşturularak yazılar bu kategorilere atanır.12

Derin Hiyerarşilerde Ekmek Kırıntısı (Breadcrumb) Stratejileri

Kullanıcı derin bir kategori ağacının içerisine girdiğinde, bulunduğu konumu kaybetmemesi için yön bulma araçlarına (wayfinding) ihtiyaç duyar. Bu araçların en önemlisi Breadcrumb (ekmek kırıntısı) navigasyonudur. Breadcrumb, kullanıcının sitenin genel yapısı içinde şu an nerede olduğunu ana sayfadan başlayarak mevcut sayfaya kadar yatay bir link dizisi şeklinde gösterir (Örn: Ana Sayfa > Tıbbi Konular > Kardiyoloji > Kalp Yetmezliği).13

Breadcrumb navigasyonunun temel görevleri şunlardır:

1. Görsel Konumlandırma: Ziyaretçilere, web sitesinin geri kalan kısmına göre mevcut konumlarını tam olarak gösterir.13 Özellikle organik arama sonuçlarından veya sosyal medyadan sitenin derinliklerindeki bir makaleye doğrudan inen ziyaretçiler için hayati bir pusuladır.13
2. Yönelim Kolaylığı: Kullanıcının, ana sayfaya veya daha üst kategorilere geri dönebilmesi için net, tıklanabilir bir yol çizer, böylece tarayıcının “Geri” tuşuna basma veya siteyi terk etme oranını düşürür.13
3. Arama Motoru Optimizasyonu (SEO): Arama motorları botları (örneğin Googlebot), breadcrumb işaretlemelerini (schema.org microdata) okuyarak sitenin yapısal hiyerarşisini çözer. Hatta arama sonuç sayfalarında (SERP) düz bir URL göstermek yerine bu breadcrumb dizisini görüntüleyerek listelemelerin tıklanma oranlarını (CTR) artırır.13

Ancak karmaşık bilgi sistemlerinde breadcrumb kurulumu bir onay kutusunu işaretlemekten çok daha karmaşık bir mühendislik problemidir. WordPress sistemleri niyeti değil, sadece mevcut yapıyı takip eder. Eğer yapı dağınıksa veya kategoriler çok sık değişiyorsa, breadcrumb yolları uyarı vermeksizin kırılabilir veya anlamsızlaşabilir.16 Örneğin bir tıbbi makalenin hem “Beslenme” hem de “Kardiyoloji” gibi iki farklı ana kategoriye atanması (polyhierarchy), breadcrumb algoritmasının hangi yolu seçeceği konusunda belirsizlik yaratır.

Uzun vadeli bir stabilite sağlamak için şu prensipler uygulanmalıdır: Kısa yollar her zaman uzun yollardan daha iyidir ve her türlü durum için optimize edilmiş mükemmel bir hiyerarşidense, nadiren değişen stabil bir yapı tercih edilmelidir.16 Ayrıca önbellekleme (caching) sistemlerinin, nesne önbelleklerinin (object cache) veya CDN’lerin güncel olmayan breadcrumb yollarını ziyaretçilere gösterme riski bulunduğundan, yapısal değişiklikler sonrasında tüm önbelleklerin temizlenmesi sistem kararlılığı için zorunludur.16

Merck/MSD Manuals Örneği: Tıbbi Bilgi Ağacının Çok Katmanlı Mimarisi

Kategori ağaçlarının devasa boyutlara ulaştığı projelerde referans alınması gereken en önemli vakalardan biri Merck/MSD Manuals ekosistemidir. 1899 yılında hekimler ve eczacılar için küçük, cep boyutu bir referans kitabı olarak yola çıkan Merck Manual, yıllar içinde genişleyerek bugün küresel çapta profesyoneller ve tüketiciler tarafından en çok başvurulan, en saygın tıbbi başvuru kaynaklarından (knowledge base) birine dönüşmüştür.17 2015 yılında başlatılan “Global Medical Knowledge” girişimi ile 2020 yılına kadar her kıtada 3 milyar profesyonel ve hastaya ücretsiz, doğru tıbbi bilgi ulaştırma hedefiyle tamamen dijitalleşmiştir.18

Böylesine devasa (her 18 ayda bir iki katına çıkan klinik bilgiler 21) ve sürekli güncellenen bir veritabanını (350’den fazla tıbbi uzman tarafından 19) web üzerinde yönetmek, sıradan bir blog veya haber portalı tasarımından tamamen farklı bir IA metodolojisi gerektirir. Merck/MSD tarzı bir bilgi ağacı kurmanın altında yatan mantık, katı bir klinik sınıflandırma sisteminin son derece esnek, kullanıcı odaklı bir arayüz ile birleştirilmesidir.

Kullanıcı Temelli İçerik Ayrımı: Profesyonel ve Tüketici Görünümleri

Merck Manual bilgi mimarisinin en yenilikçi ve dikkate değer özelliği, tek bir devasa birleşik veri havuzunu iki tamamen farklı hedef kitlenin (ve bu kitlelerin bilişsel kapasitelerinin) ihtiyaçlarına uygun şekilde ikiye ayırmasıdır: Profesyonel Sürüm (hekimler, tıp öğrencileri, veterinerler) ve Tüketici Sürümü (hastalar, ebeveynler, hasta yakınları).17

Bir kullanıcı siteye ilk girdiğinde veya uygulama üzerinden erişim sağladığında, bu iki görünümden birini seçmesi istenir.18 Bu basit gibi görünen seçim, platformun arka planındaki dinamik filtreleme mantığını tetikler. Seçime göre platformdaki navigasyon araç çubuğunda (toolbar) gösterilen kategoriler, kullanılan klinik terminolojinin ağırlığı ve gösterilen verinin derinliği anında değişir.18

 

Özellik	Profesyonel Sürüm (Professional Version)	Tüketici Sürümü (Consumer Version)
Hedef Kitle	Hekimler, tıp öğrencileri, araştırmacılar.5	Hastalar, hasta yakınları, bakıcılar.18
Görsel Renk Kodu	Mavi tonlar.18	Kırmızı tonlar.18
Dil ve Terminoloji	İleri düzey tıbbi terminoloji, klinik bulgular, etiyoloji ve farmakolojik detaylar.	Gündelik dil, sadeleştirilmiş açıklamalar, hastalıkların temel mekanizmaları ve evde bakım pratikleri.
Kategori Odakları	Prosedürler, klinik hesaplayıcılar, normal laboratuvar değerleri, vaka çalışmaları.5	Semptomlar, ilk yardım, temel kaynaklar, mitleri çürüten podcast’ler.19

İki farklı kullanıcı evreninin birbirinden kopuk silolar halinde işlemesi, bilgi mimarisinin doğasına aykırıdır. Bu nedenle sistem, bu iki farklı bilgi ağacı arasında yatay bir köprü kurmuştur. Sitenin her sayfasında bulunan basit bir geçiş butonu (version toggle) aracılığıyla iki versiyon arasında zahmetsizce geçiş yapılabilir.18 Yani, doktorunun kendisine koyduğu “Koroner Arter Hastalığı” teşhisini profesyonel bir makaleden 5 okumaya çalışan bir hasta, içeriğin ağırlığı karşısında zorlandığında, aynı sayfanın tüketici dostu versiyonuna tek tıkla geçiş yapabilir.20

Kurumsal Anlatı ve Regülatif Sınırların Bilgi Mimarisini Şekillendirmesi

Bir medikal bilgi platformunun yapısı, sadece klinik bilginin doğasıyla değil, platformun arkasındaki kurumun hedefleri ve tabi olduğu yasal düzenlemelerle de doğrudan şekillenir. Merck (Kuzey Amerika) ve MSD’nin (Kuzey Amerika dışı) devasa kurumsal ağlarının yeniden tasarlanma süreci bu durumun mükemmel bir örneğidir.23

Tasarım süreci, “İnovasyon”, “Performans” ve “Vatandaşlık (Citizenship)” olarak belirlenen üç itibar yönlendiricisi etrafında inşa edilmiştir.23 Ancak sitenin navigasyon mimarisi bu soyut kavramlara göre değil, gerçek kullanıcı gruplarının (Hastalar/Bakıcılar, Yatırımcılar, Medya, İş Arayanlar) site içindeki somut yolculuklarına (user journey) göre optimize edilmiştir.23

• Hastalar ve Bakıcılar Seksyonu: Kullanıcı yolculuğuna göre yeniden şekillendirilerek; hastalıkların yönetimi, ürün bilgileri, ürün destek/finansman programları ve klinik araştırmalara katılım gibi işlevsel alanlara bölünmüştür.23
• Yatırımcılar Seksyonu: Şirketin mali sağlığına, ürün geliştirme hattına (pipeline) ve finansal raporlara doğrudan erişim sağlayacak bir dikey ağaç olarak kurgulanmıştır.23

En dikkat çekici IA sorunu ise regülatif (yasal) sınırlandırmalardır. Merck.com (ABD) ile MSD.com (Uluslararası) sitelerinin sitemap yapıları genel hatlarıyla aynı olmakla birlikte, ABD dışındaki sıkı ilaç regülasyonları nedeniyle MSD web sitesinde “Ürün Bilgileri”, “Yatırımcı İlişkileri” ve “Hasta Destek Programları” gibi hayati dalların tamamen sistemden gizlenmesi gerekmiştir.23 Bu durum, çok uluslu bir bilgi ağacı kurulurken CMS altyapısının ülkeye veya IP adresine göre dinamik olarak belirli dalları görünmez yapabilen (conditional logic) gelişmiş bir izin mimarisine sahip olması gerektiğini göstermektedir.

Tıbbi Konuların Taksonomik Sınıflandırılması ve Endeksleme Yöntemleri

Merck Manual gibi platformlarda verilerin dikey dizilimi genellikle “Sistem Temelli” veya “Disiplin Temelli” bir taksonomiye dayanır. Üst bilgi hiyerarşisi tıp biliminin temel branşlarından oluşur: Kardiyoloji, Dermatoloji, Endokrinoloji, Pediatri, Onkoloji gibi ana bölümler.4

Ancak her kullanıcının zihinsel modeli veya arama niyeti aynı değildir. Kullanıcıların farklı arama davranışları sergilediği gerçeği göz önünde bulundurularak bilginin bulunabilirliği (findability) birden fazla giriş noktasıyla (entry point) güçlendirilmelidir:

1. Tematik Gezinme: Üst başlıkların altında organ sistemleri veya hastalık gruplarına göre kademeli olarak inilen geleneksel kategori ağacı.
2. Alfabetik İndeks: Konuyu bilip sadece baş harfine göre arama yapmak isteyen kullanıcılar için oluşturulan A’dan Z’ye tıbbi konular dizini.4
3. Çapraz (Cross) Kaynak Filtreleme: Sadece bir hastalık metni aramak yerine; 3D Modeller, Klinik Hesaplayıcılar, Ses kayıtları (Oskültasyon sesleri vb.) ve Normal Laboratuvar Değerleri gibi multimedya ve araçların, hastalık makalelerinden bağımsız olarak ayrı bir üst kategoride (Resources/Kaynaklar) listelenmesi.5

Bu tür bir ağ kurgulanırken, tıbbi veri tabanları için küresel bir standart olan MeSH (Medical Subject Headings) gibi kontrollü kelime dağarcıkları (controlled vocabulary) kullanılmalıdır.24 MeSH, bir içeriğin yalnızca tek bir katı klasörde bulunması zorunluluğunu ortadan kaldırarak çok boyutlu (polyhierarchical) bir etiketleme sistemi sunar.24 Böylelikle aynı makale, hiyerarşiyi kırmadan farklı alt dallardan gelen kullanıcıların karşısına çıkarılabilir.

Makine Öğrenimi (RAG) ve Bilgi Ağaçlarının Vektörel Modellenmesi

Merck Manual gibi on binlerce sayfadan oluşan derin hiyerarşiler, yalnızca insan kullanıcılar için değil, modern yapay zeka sistemleri ve Büyük Dil Modelleri (LLM) için de kritik devasa veri ambarlarıdır. Retrieval-Augmented Generation (RAG) gibi mimariler kurularak bu tarz bir manuelden tıbbi bilgi çekilmesi istendiğinde, metinlerin parçalanma (chunking) mantığı sistemin doğruluk oranını doğrudan etkiler.25

Mevcut denemeler göstermektedir ki, klasik NLP yöntemleriyle standart olarak uygulanan 500 token (kelime/hece parçası) büyüklüğünde ve 25 token çakışmalı (overlap) parçalama yöntemleri, karmaşık klinik kavramların (örneğin sepsis protokolleri veya travmatik beyin hasarı tedavisi) anlam bütünlüğünün yapay zeka tarafından kaybedilmesine yol açabilmektedir.25 Parçalar klinik konseptler için çok küçük kalmakta ve içerik bölünebilmektedir.25 Ayrıca PDF’lerden veya sayfalardan çekilen verilerdeki sayfa üstbilgileri (header) ve telif hakkı filigranları gibi yapısal gürültüler, metinle birlikte veritabanına girmekte ve vektörel (anlamsal) aramayı yüksek oranda bozmaktadır.25

Makine öğrenimi sistemlerinin bu tarz kompleks sağlık veritabanlarından doğal dilden SQL’e (Natural Language to SQL) hatasız çeviriler yapabilmesi ve yürütülebilir sorgular (executable queries) üretebilmesi için (Amazon Bedrock ve Anthropic Claude 3.5 Sonnet altyapılarında yapıldığı gibi 26), bilgi ağacının net bir taksonomi ile donatılması gerekir.26 İçeriğin sadece metin olarak değil, üst-alt başlık hiyerarşisi (H1, H2, H3) ve net veritabanı şemalarıyla birlikte LLM’ye bağlam (context) olarak verilmesi yapay zekanın başarısı için hayati önem taşır.25

Sayfa İçi Navigasyon: Wikipedia Tarzı İçindekiler (TOC) ve UX Evrimi

Kategori ağaçları, sayfalar veya modüller arası (inter-page) yönlendirmeyi sağlarken; İçindekiler (Table of Contents – TOC) tablosu sayfa içi (intra-page) navigasyonun kalbini oluşturur. Ansiklopedik içeriklerde, kapsamlı rehberlerde veya binlerce kelimelik hukuki belgelerde, kullanıcının sayfayı satır satır okumak yerine doğrudan aradığı bilgiye atlamasını (jump) sağlayan Wikipedia tarzı bir içindekiler modülü, modern web standartlarının vazgeçilmez bir parçasıdır.

İçindekiler tablosunun kullanım faydaları yalnızca teknik bir özellik olmaktan öte, derin bir UX (Kullanıcı Deneyimi) temeline dayanır. Nielsen Norman Group verilerine göre, TOC kullanımı kullanıcılara sayfanın içeriği hakkında hızlı bir genel bakış (scannable overview) sunar, alt kısımlardaki içeriğin (bottom content) keşfedilebilirliğini artırır, spesifik bölümlerin URL aracılığıyla başkalarıyla kolayca paylaşılmasını mümkün kılar ve SEO (Arama Motoru Sonuç Sayfası) görünürlüğünü ciddi şekilde yükseltir.27

Çapa (Anchor) Bağlantıları ve Otomatik Başlık Algılama Mekanizması

Wikipedia’nın devasa içerik arşivini okunabilir kılan sistem, yıllardır başarıyla çalışan otomatik başlık algılama ve “HTML çapa (anchor)” üretim mekanizmasıdır.28 MediaWiki yazılımı, sayfadaki içerik hiyerarşisini belirlemek için özel sözdizimleri kullanır (Örneğin seviye iki başlık için == Başlık ==, seviye üç alt başlık için === Alt Başlık === formülünü kullanır).28

Bu formatlar tespit edildiğinde sistem arka planda iki işlem gerçekleştirir:

1. ID Üretimi: Her başlık için, HTML yapısı içerisinde benzersiz bir “id” özniteliği üretilir (Örn: <h2 id=”Kardiyoloji_Tarihi”>).28
2. Benzersizleştirme: Sayfada aynı isme sahip birden fazla başlık varsa (Örneğin birden fazla kez kullanılan “Tarihçe” başlığı), sistem bağlantı çakışmalarını (conflict) önlemek için ID’lerin sonuna alt çizgi ve rakamlar ekler (Örn: Tarihce_2, Tarihce_3).28

Kullanıcı, ekranın yanındaki TOC modülünde yer alan bir başlığa tıkladığında, tarayıcının URL satırına bir diyez (#) işareti ve ilgili çapa ID’si eklenir (Örn: tr.wikipedia.org/wiki/Tip#Kardiyoloji_Tarihi). Tarayıcı bu komutu algıladığı anda, sayfayı aşağıya kaydırarak (scroll) kullanıcının ekranını tam olarak hedeflenen başlığın bulunduğu hizaya konumlandırır.28

 

TOC / Başlık Seviyesi	HTML Etiketi	Bilişsel İşlevi	MediaWiki Karşılığı
Ana Başlık	<H1>	Sayfanın ana konusunu belirler. Genellikle TOC’a dahil edilmez.	= Sayfa Başlığı =
Bölüm Başlığı	<H2>	Ana konunun birinci derece kırılımlarıdır. TOC’nin ana öğeleridir.	== Bölüm ==
Alt Bölüm Başlığı	<H3>	İkinci derece kırılımlardır. TOC içinde girintili (indented) gösterilir.	=== Alt Bölüm ===
Detay Başlığı	<H4> – <H6>	Çok uzun makalelerde, TOC sınırlandırılarak ({{TOC limit}}) gizlenebilir.28	==== Detay ====

MediaWiki, yazarların TOC üzerinde tam kontrol sağlaması için çeşitli “Sihirli Kelimeler” (Magic Words) sunar.28 Eğer bir sayfada TOC’nin görünmesi istenmiyorsa __NOTOC__ etiketi eklenir; varsayılan olarak en az 4 başlıkta çalışan TOC’nin daha az başlıkta bile çalışması isteniyorsa __FORCETOC__ etiketi kullanılır.28 Alt başlıkların çok derine inerek menüyü uzatmasını engellemek için {{TOC limit|n}} (örneğin n=3) kullanılarak sadece ana başlıkların gösterilmesi sağlanabilir.28

Vector 2022 Arayüz Güncellemesi ve Yapışkan (Sticky) TOC Devrimi

Wikipedia’nın masaüstü görünümü uzun yıllar boyunca “Vector 2010” adı verilen standart arayüzü kullandı. Bu yapıda, içindekiler tablosu sayfanın en üstünde, ilk başlığın hemen öncesinde (inline) yer alan sabit bir bloktu.28 Kullanıcı sayfayı aşağı kaydırdığında, menü yukarıda kalıyor ve başka bir bölüme geçmek için kullanıcının tekrar sayfanın en üstüne çıkması (veya tarayıcının kaydırma çubuğunu kullanması) gerekiyordu.

2019 yılında başlayan ve 2023 yılının Ocak ayında tamamen standartlaşan “Vector 2022” adlı büyük arayüz güncellemesi ile bu tasarım paradigması tamamen değişti.30 Dünya çapında ayda 1.5 milyar sayfa görüntülenmesine ev sahipliği yapan bu arayüz 30, okuyucuların bilişsel yükünü hafifletmeyi ve okunabilirliği artırmayı amaçladı.

Yeni Vector 2022 tasarımında, içindekiler tablosu metnin içinden sökülerek sol kenar çubuğuna (sidebar) taşındı ve “yapışkan” (sticky) hale getirildi.30 vector-toc-pinned komutu sayesinde 31, kullanıcı yüzlerce satırlık bir makaleyi aşağı kaydırırken bile sol menü sabit bir şekilde ekranda kalmaya devam etmektedir.32 Ayrıca, okunmakta olan mevcut başlık (active state) TOC üzerinde kalın yazı tipiyle belirgin hale gelmektedir.32 Bu UI tasarımı, kullanıcıların metnin neresinde olduklarını kaybetmemelerini, genel bağlamı her an görebilmelerini ve sayfayı başa sarmaya gerek kalmadan alt başlıklar arasında doğrudan yatay geçişler yapabilmelerini sağlar.27 Arayüzün temiz kalmasını isteyen kullanıcılar için ise bu menü, daraltılarak (collapse) havada asılı bir butona (floating button) dönüştürülebilmektedir.31

WordPress Sistemlerinde Wikipedia Tarzı TOC Entegrasyonu

Modern web sitelerinin büyük bir kısmını oluşturan WordPress ekosisteminde, Wikipedia’nın Vector 2022 arayüzündeki yapışkan ve dinamik TOC sistemini kurabilmek için iki temel yaklaşım bulunur: Eklentisiz (Manuel/Kod tabanlı) veya Eklenti tabanlı çözümler.

Eklentisiz Çözüm (Manuel ve Programatik)

Sisteme ekstra bir yazılım yükü bindirmek istemeyen geliştiriciler, TOC sistemini doğrudan HTML/CSS kodlamasıyla ve WordPress’in çekirdek dosyalarını değiştirerek oluşturabilirler. En ilkel yöntemde yazar; her bir başlığa (örneğin Gutenberg blok editörü içinden) manuel olarak HTML çapaları (Anchor ID) atar ve yazının başına bu çapaları işaret eden bir Liste Bloğu (<ul>) ekler.33 Ancak bu yöntem, içerik eklendikçe yönetilemez hale gelir.

Tam otomatik bir eklentisiz çözüm için WordPress temanın functions.php dosyasına programatik bir müdahale yapılır.36 the_content kancasına (hook) bağlanan özel bir fonksiyon yazılarak; içeriğin içindeki tüm H1 ile H6 etiketleri Regular Expression (Regex) (preg_replace_callback) kullanılarak taranır.36 Fonksiyon, yakaladığı her başlığın metnini sanitize_title komutuyla web uyumlu bir ID’ye dönüştürür (Boşlukları tireye çevirir, Türkçe karakterleri temizler) ve başlık etiketinin içine dinamik olarak enjekte eder.36 Daha sonra sayfadaki tüm başlıkları dizi (array) olarak toplayıp bir döngüden geçirir ve sayfanın en üstüne HTML link yapısı olarak (<div class=’table-of-contents’>) çıktılar.36

Eklenti Tabanlı (Plugin) Çözümler ve Karşılaştırmalı Analiz

Çoğu proje için manuel kodlama yerine, özel olarak Wikipedia ilham alınarak geliştirilmiş ve binlerce sitede test edilmiş TOC eklentileri kullanılır. Bu alandaki standartları belirleyen en eski ve sağlam eklentilerden biri “Table of Contents Plus” (TOC+)’tır.37 Eklenti, Wikipedia’nın çalışma prensiplerini baz alarak sayfadaki ilk başlığın hemen öncesine otomatik olarak (en az 4 başlık bulduğunda) tabloyu yerleştirir ve CSS çakışmalarını önleyen benzersiz bir numaralandırma şeması kullanır.37 Ayrıca bileşen (widget) desteği sayesinde menü, sitenin sol kenar çubuğuna kolayca yapıştırılabilir.37

Modern ihtiyaçlar doğrultusunda geliştirilen diğer popüler eklentilerin yetenekleri aşağıdaki tabloda detaylı bir şekilde karşılaştırılmıştır:

 

TOC Eklentisi	Wikipedia Tarzı Uyumluluk	Öne Çıkan Özellikler	Performans ve Kullanım
Table of Contents Plus	Çok Yüksek (İlham Kaynağı) 37	Özel yazı tipleri (CPT) desteği, gelişmiş hariç tutma kuralları (h5, h6 gizleme), Kısa kod ([toc], [no_toc]) ile esneklik, Tüm site haritasını çıkarabilme.37	Ücretsiz, kararlı, eski temalarla bile yüksek uyumluluk. Widget desteği ile kenar çubuğuna eklenebilir.37
LuckyWP Table of Contents	Yüksek	Otomatik veya Gutenberg blok/kısa kod ile manuel ekleme, düzgün kaydırma (smooth scroll), başlık hiyerarşisi (depth) kontrolü, RTL (sağdan sola) dil desteği.38	Hafif mimari, ücretsiz sürümde rakipsiz özellik seti, SEO (no-index TOC) desteği, modern blok editörleriyle uyum.38
Easy Table of Contents	Orta/Yüksek	Elementor, Divi, WPBakery gibi modern sayfa yapılandırıcılarla kusursuz entegrasyon. Yapışkan kenar çubuğu (sticky sidebar) kolaylığı.39	300.000+ yükleme, kullanımı son derece basit (beginner-friendly). Görsel özelleştirmeler (renk, sınır, genişlik) gelişmiştir.40
Joli Table of Contents	Yüksek	Hiyerarşik veya düz (flat) görünüm seçenekleri, genişleme/daraltma butonları için özel CSS ikonları, post tiplerine göre farklı kurallar atama.38	Hız (speed) ve temiz tasarıma (clean design) odaklanır. Premium özelliklerle genişletilebilir.38

Bu eklentilerin hepsi teknik olarak çapalar üretip yönlendirme yapsa da, Wikipedia Vector 2022 deneyimini tam olarak sağlamak için ilgili eklentinin kenar çubuğu bileşeninin kullanılması ve temanın CSS ayarlarından bu çubuğa position: sticky; top: 20px; gibi yapışkanlık komutlarının verilmesi gerekmektedir.

Modüler Pano (Dashboard) Ana Sayfa Mimarisi

Bir medikal referans sisteminin, kapsamlı bir ürün dokümantasyonunun veya devasa bir bilgi ağacının (wiki) giriş sayfası, geleneksel kurumsal siteler (Hakkımızda, Vizyonumuz) veya blog siteleri (son yazılar dizilimi) gibi tasarlanamaz. Arama niyetleri son derece spesifik olan kullanıcıların, girdikleri saniyede aradıklarına odaklanabilmeleri için ana sayfanın bir “Gösterge Panosu” (Dashboard) mantığıyla çalışması gerekir.

Pano tasarımı, bilginin bir “akış” (feed) şeklinde yukarıdan aşağıya yığılmasından ziyade, organize edilmiş kutucuklar (widgets, cards), veri odaklı modüller ve yatay/dikey ızgaralar (grids) ile sunulmasına dayanır.43 Pano, sistemin arka planında gerçekleşen karmaşık veritabanı işlemlerini ön tarafa (front-end) sadeleştirerek yansıtan bir komuta merkezidir.43

Dashboard Mimarisinin Ana Bileşenleri ve Dinamik İçerik Döngüleri

Statik metinlerin aksine, bir pano ana sayfası sürekli olarak veritabanından dinamik sorgular (dynamic queries) çeker. Etkili bir Wiki veya Bilgi Tabanı (Knowledge Base) panosunda genellikle şu yapı taşları bulunur:

1. Merkezi Canlı Arama (Ajax Global Search): Kullanıcıların doğrudan bilgiye sıçramasını sağlayan, genellikle sayfanın tepe noktasına konumlandırılmış, harf girildikçe sonuçları anında getiren (live search) dinamik arama çubuğudur.44
2. Kategori Izgaraları (Category Grids): Tıbbi Uzmanlıklar, Kullanım Kılavuzları, Kurulum Adımları veya “Sık Sorulan Sorular” gibi spesifik bilgi ağaçlarının ana gövdelerini temsil eden ikonlu modüllerdir.47
3. Dinamik Akıllı Listeler: Arka plandaki analitik verilerle beslenen “En Çok Okunanlar” (Popular Articles), “Son Güncellenen İçerikler” veya “Editörün Seçimleri” gibi, sistemin mevcut nabzını tutan ve otomatik olarak yenilenen bloklardır.47
4. Kişiselleştirilmiş Kullanıcı Arayüzü (Conditional Rendering): Kullanıcı girişi gerektiren sistemlerde pano, kişiselleşir. Sistemdeki “Oturum Kapatmış Kullanıcı”, “Abone” veya “Müşteri” gibi roller algılanarak, sayfadaki spesifik blokların dinamik olarak gösterilmesi veya gizlenmesi sağlanır.50 Böylece kullanıcı, sadece kendi yetki ve ihtiyacına uygun verileri görür.

Avada Post Cards ve Modüler Izgara (Grid) Yerleşimi

Bu tür dinamik panoları sıfırdan kodlamak oldukça maliyetliyken, gelişmiş WordPress tema oluşturucuları (Örn: Avada, Elementor, Cornerstone) görsel sürükle-bırak yöntemleriyle karmaşık veritabanı işlemlerini modüler arayüzlere çevirme imkanı sunar.51 Özellikle Avada’nın sunduğu “Post Cards” (İçerik Kartları) elementi, tam olarak bu işlev için tasarlanmış bir yapıdır.52

Bir pano ızgarasının sıfırdan kurulum mantığı şu şekilde işler:

1. Tekil Şablonun (Card) Tasarımı: İlk adım, panoda tekrar edecek olan tekil modülün tasarım şablonunu oluşturmaktır. Avada Builder kütüphanesi açılarak yeni bir “Post Card” elementi oluşturulur.52 Bu şablon, tasarımcının tamamen özgür olduğu bir tuvaldir. Statik metinler yerine sistemden veri çeken dinamik layout elementleri (Post Card Image, Title Element, Meta Element) bu tuvale yerleştirilir.52 2. Dinamik Veri Bağlama ve Görsel Senkronizasyon: Tasarım yapılırken, sistemin neye benzeyeceğini görmek için “View Dynamic Content As” seçeneği aktifleştirilerek bir örnek yazı (post) veya ürün seçilir.52 Panonun nizami ve profesyonel görünmesi için her kartın (başlığı kısa da olsa uzun da olsa) aynı yüksekliğe sahip olması kritik bir UX kuralıdır. Avada sisteminde bu düzen, başlık elementinin üstüne ve altına konulan görünmez ayırıcıların (Separators) “Flex Grow: 1” özelliği almasıyla sağlanır; böylece kısa metinli kartlar, yanındaki uzun metinli karta uyum sağlayarak uzar.52 Butonların hedefleri, manuel URL yerine doğrudan “Permalink” değişkenine bağlanır.52 3. Izgaranın (Grid) Panoya Enjeksiyonu: Oluşturulan şablon, ana sayfada “Post Cards Element” üzerinden sahneye çağrılır.52 Bu elementte, verinin nereden geleceği (Örn: Sadece belirli bir taksonomideki yazılar) filtrelenir ve layout stili olarak “Grid”, “Masonry”, “Carousel” veya “Stacking Cards” seçilir.52 Pano mantığına en uygun olanı, genellikle 3 veya 4 sütunlu (columns) bir grid yerleşimidir.52 4. Alternatif Tasarımlar (Asimetrik Ritim): Bilgi yığınını kırmak ve panonun monotonlaşmasını engellemek için “Alternatif İçerik Kartları” (Alternate Post Cards) devreye sokulur.52 Örneğin, 3 sütunlu bir tasarımda ilk sıradaki makaleyi iki sütun genişliğinde ve farklı bir şablonla gösterirken, diğerlerini tek sütunla göstermek sitenin dinamizmini artırır.53

Kurumsal Wiki ve Bilgi Tabanı (Knowledge Base) Panoları

Şirket içi operasyonları yöneten veya müşterilere yönelik teknik dokümantasyon sunan bir Wiki’nin ana sayfası, sadece veriyi değil, topluluğu da yöneten bir pano olmalıdır. Wikipedia’da bile yeni katılımcıların nereye gideceklerini gösteren devasa “Nasıl Başlarım?” ve “Onboarding” panoları mevcuttur.47

WordPress üzerinde kurumsal bir wiki panosu inşa etmek için “Echo Knowledge Base”, “BetterDocs”, “BasePress” veya “Heroic KB” gibi amaca özel eklentiler oldukça yaygındır.44 Bu eklentiler, varsayılan bir pano kurulum sihirbazı (setup wizard) ile birlikte gelirler.49 İyi tasarlanmış bir wiki panosunda; self-servis (kullanıcının destek birimine ihtiyaç duymadan kendi sorununu çözmesi) alanları, kullanıcıların etkileşime girebileceği ve sorun tartışabileceği entegre forum (örn. bbPress) blokları ve teknik bir belgenin PDF formatında dışa aktarılmasına (PDF Download) izin veren araçlar modüler olarak yerleştirilir.47 Ek olarak, arka plandaki yöneticiler için wiki analitik panosu (Analytics Dashboard), hangi konuların çok tıklandığını, hangi arama terimlerinin karşılıksız kaldığını (content gaps) göstererek sürekli optimizasyona imkan tanır.47

Ayrıca, Avada Form Builder gibi araçlar kullanılarak, dışa kapalı portallar için üçüncü parti eklentilere ihtiyaç duymadan tamamen siteyle görsel uyumlu, özelleştirilmiş üyelik kayıt (Registration), giriş (Login) ve parola sıfırlama (Reset Password) modülleri tasarlanabilir.61 Böylelikle standart, sıkıcı WordPress wp-login.php arayüzü yerine, kurumun kurumsal kimliğini yansıtan profesyonel bir karşılama ekranı oluşturulur.61

Akıllı Kenar Çubukları (Sidebars) ve Akordeon Navigasyon Sistemleri

Pano ana sayfası kullanıcıya haritayı genel hatlarıyla gösterip yatay bir yönlendirme sağlarken; spesifik bir konunun içine girildiğinde kullanıcı derin, dikey bir bilgi ağacıyla karşı karşıya kalır. Hastalıkların, ürün kılavuzlarının veya kurumsal dokümantasyonların onlarca kategoriye ve yüzlerce alt kırılıma ulaştığı senaryolarda (Örn: Tıbbi Onkoloji > Gastrointestinal Kanserler > Kolorektal Kanser > Tedavi Yöntemleri > Cerrahi Müdahale), ana navigasyon menüleri ve standart dropdown (açılır) yapılar işlevsiz hale gelir.

Böylesi derin hiyerarşilerde sayfanın sol veya sağ tarafına konumlandırılmış “Akıllı Kenar Çubukları” (Sidebars) ve dikey “Akordeon” (Accordion) navigasyon yapıları kullanılmalıdır.

Dikey Hiyerarşide Akordeon Menülerin Evrimi

Akordeon (Accordion) kenar çubukları, dikey navigasyonda inanılmaz bir alan tasarrufu (space-saving) sağlayan ve bilişsel karmaşayı radikal bir biçimde engelleyen bir UX örüntüsüdür.63 Adını müzik aletinden alan bu yapı, alt alta listelenmiş ana kategorilerden oluşur; kullanıcı bir ana kategoriye tıkladığında liste aşağıya doğru kayarak o başlığın alt kategorilerini görünür hale getirirken, diğer ana kategorilerin alt başlıkları kapalı (collapsed) konumda kalarak ekranda gereksiz yer işgal etmez.63

Özellikle devasa ürün envanteri olan WooCommerce sitelerinde veya yüzlerce başlığa sahip Wiki sayfalarında, tüm kategorilerin aynı anda açık olması ekranda kilometrelerce uzayan kaydırma (scroll) mesafeleri yaratır. Akordeon yapı bunu engeller.63

WordPress ekosisteminde bu mimariyi kurmak için “WPB Accordion Menu”, “Bellows Accordion Menu”, “JetBlocks” veya “IKS Menu” gibi eklentiler sıklıkla tercih edilir.15

Mevcut Kategorinin Otomatik Genişlemesi (Auto-Expand on Page Load)

Tıbbi veya teknik bir ansiklopedide akordeon kenar çubuğunun en kritik ve sistemin kullanılabilirliğini belirleyen ana özelliği, mevcut kategorinin sayfa yüklenirken otomatik olarak açık gelmesi (expand on page load) işlevidir.64

Kullanıcı “Kardiyoloji” ağacından “Nöroloji” ağacındaki bir hastalık grubuna yatay bir link üzerinden veya arama çubuğundan sıçradığında (jump), sistem yeni açılan makalenin bağlamını okuyabilmelidir. Ziyaretçi sayfayı açtığı an, sol kenar çubuğundaki devasa menü tamamen kapalı gelmemeli; sistem PHP tarafında ziyaretçinin okuduğu sayfanın taksonomik yolunu tespit edip, sadece o yolu işaret eden ilgili akordeon dalını otomatik olarak açmalı (active state) ve hatta özel bir renkle vurgulamalıdır.64

Bu teknik özellik, kullanıcının sayfa içindeki devamlılık hissini (continuity) muhafaza eder.64 Kullanıcının nereye düştüğünü anlaması ve bir üst veya bir yan başlığa kolaylıkla geçebilmesi için menüyü tekrar tekrar açıp kapatarak kendi yerini manuel olarak araması gerekmez.64 Echo Knowledge Base veya Heroic FAQs gibi profesyonel bilgi tabanı eklentileri, bu derin dikey hiyerarşiyi otomatik senkronizasyonlarla, spesifik widget’larla (Örn: Echo KB’de bulunan Categories Navigation sidebar ve Table of Contents widget’ları) bir arada, sayfanın sol veya sağ tarafına zahmetsizce eklemeye olanak tanır.59 Modern tasarımda bu kenar çubukları (örneğin Off-Canvas Sidebars ile) mobilde de mükemmel çalışacak şekilde gizlenebilir ve bir butona tıklandığında ekrana kayarak gelebilir.15

Bilgi Mimarisinin Bütünleştirilmesi

Sonuç olarak, karmaşık bir konunun üst başlık-alt başlık hiyerarşisine oturtularak kapsamlı, yaşayan bir kategori ağacına dönüştürülmesi; hem semantik veri modellemesini (İlk Prensipler ve MECE prensibini kavrama) hem de ileri düzey kullanıcı arayüzü (UX/UI) mühendisliğini gerektirir.

Bilgi mimarisi statik bir dosya dolabı değil, dinamik bir karar alma ağıdır. Merck/MSD örneğinde açıkça görüldüğü üzere, bilginin derinliği tek boyutlu olmak zorunda değildir; aynı klinik veri kümesi, tüketici ve profesyonel bağlamlarına göre katmanlara ayrılarak esnek, kurumsal regülasyonlara duyarlı ve yatay bağlarla birbirine kenetlenmiş bir şekilde sunulabilmelidir. İnsan bilişsel kapasitesinin sınırlılıkları, gelişmiş makine öğrenimi sistemlerinin (RAG mimarilerindeki parçalama sorunları) teknik zorunluluklarıyla örtüşmekte; bilginin her koşulda mantıksal ağaçlara, net etiketlere ve temiz bir HTML formatına ihtiyaç duyduğunu göstermektedir.

Kurulan bu teorik ve veritabanı odaklı mimarinin, son kullanıcı tarafından en düşük bilişsel yükle tüketilebilmesi için üç temel dijital ayağın sistem üzerinde kusursuz bir uyum içinde çalışması elzemdir:

1. Dinamik ve Modüler Ana Kapı: Tüm bilgi ekosistemini yatay düzlemde bir araya getiren, Avada Post Cards gibi modüler kart tasarımları ve canlı arama filtreleriyle çalışan fonksiyonel bir pano (dashboard). Kullanıcıyı doğrudan aradığı bölgeye fırlatacak bir fırlatma rampası.
2. Bağlamsal Derinlik Pusulası: Dikey derinlikte kullanıcının kaybolmasını engelleyen, sayfa yüklenirken kullanıcının konumunu algılayıp açılan akıllı akordeon (accordion) menüler ve üst sekmelere stabil bir dönüş sağlayan hiyerarşik izleme (breadcrumb) araçları.
3. Sayfa İçi Nokta Atışı: Uzun ve klinik metinler okunurken, sayfa içinde hızlı kaydırma ve odaklanma sağlayan, Wikipedia Vector 2022 standartlarına uygun, yapışkan (sticky sidebar) kenar çubuklu İçindekiler (Table of Contents) tablosu.

Bir sistemin gerçek gücü ve sürdürülebilirliği, sahip olduğu bilginin devasa hacminde (petabaytlarla ölçülen büyüklüğünde) değil; o bilginin kullanıcı ihtiyaç duyduğu anda, doğru arayüz parçacığı ve doğru mantıksal hiyerarşi ile yüzeye çıkarılabilme kapasitesinde yatar. Bilgi mimarisi sadece veriyi depolayan bir algoritma değildir; verinin kullanıcı zihnindeki yol haritasını inşa eden bilişsel bir köprüdür.

Alıntılanan çalışmalar

1. First Principles Thinking: Reimagining What’s Possible by Questioning Everything – AbilityPath, erişim tarihi Mayıs 1, 2026, https://abilitypath.org/wp-content/uploads/2025/09/Essential-Lessons-Article-4.pdf
2. What is First Principles Thinking? – FS Blog, erişim tarihi Mayıs 1, 2026, https://fs.blog/first-principles/
3. Mental Models & Product #2: First-Principles Thinking | by Isabel Gan – Medium, erişim tarihi Mayıs 1, 2026, https://medium.com/mental-models-product/mental-models-product-2-first-principles-thinking-57ece8d3c82b
4. Health Topics | Merck Manual Professional Edition, erişim tarihi Mayıs 1, 2026, https://www.merckmanuals.com/professional/health-topics
5. Merck Manual Professional Edition, erişim tarihi Mayıs 1, 2026, https://www.merckmanuals.com/professional
6. First-principle-based systematic thinking is more important than ever | Sijie Yang, erişim tarihi Mayıs 1, 2026, https://sijie-yang.com/blog/2025/systematic-thinking/
7. The MECE Principle: Definition and Examples – Career in Consulting, erişim tarihi Mayıs 1, 2026, https://careerinconsulting.com/mece-principle/
8. Design considerations for a hierarchical semantic compositional framework for medical natural language understanding | PLOS One – Research journals, erişim tarihi Mayıs 1, 2026, https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0282882
9. Design considerations for a hierarchical semantic compositional framework for medical natural language understanding – PMC, erişim tarihi Mayıs 1, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC10019629/
10. Designing visual hierarchies for the communication of health data – PMC – NIH, erişim tarihi Mayıs 1, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC11491599/
11. Customize WordPress Breadcrumbs Using Plugins or Code – SEOPress, erişim tarihi Mayıs 1, 2026, https://www.seopress.org/newsroom/featured-stories/edit-breadcrumbs-wordpress/
12. Add page(s) into the breadcrumbs hierarchy for a post : r/Wordpress – Reddit, erişim tarihi Mayıs 1, 2026, https://www.reddit.com/r/Wordpress/comments/1camwc2/add_pages_into_the_breadcrumbs_hierarchy_for_a/
13. How to Add WordPress Breadcrumbs to Your Site (5 Easy Methods) – SupportHost, erişim tarihi Mayıs 1, 2026, https://supporthost.com/wordpress-breadcrumbs/
14. The Fundamental Guide to Adding WordPress Breadcrumbs – ColibriWP, erişim tarihi Mayıs 1, 2026, https://colibriwp.com/blog/wordpress-breadcrumbs/
15. Top 11 Sidebar Menu WordPress Plugins Compared (2024) – Crocoblock, erişim tarihi Mayıs 1, 2026, https://crocoblock.com/blog/wordpress-sidebar-menu-plugins/
16. WordPress Breadcrumbs: What They Are and How to Add Them – Cloudways, erişim tarihi Mayıs 1, 2026, https://www.cloudways.com/blog/wordpress-breadcrumbs/
17. Overview of the MSD Manuals – MSD Manual Consumer Version, erişim tarihi Mayıs 1, 2026, https://www.msdmanuals.com/home/resourcespages/about-the-manuals
18. Merck Manuals – PMC – NIH, erişim tarihi Mayıs 1, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC5079511/
19. Global Medical Knowledge – Merck Manual Consumer Version, erişim tarihi Mayıs 1, 2026, https://www.merckmanuals.com/home/resourcespages/global-medical-knowledge
20. Merck Manual and MSD Manual Launch Global Medical Knowledge 2020 to Provide Free Access to Credible Medical Information on Every Continent by 2020, erişim tarihi Mayıs 1, 2026, https://www.merck.com/news/merck-manual-and-msd-manual-launch-global-medical-knowledge-2020-to-provide-free-access-to-credible-medical-information-on-every-continent-by-2020/
21. Overview of the Merck Manuals – Merck Manual Professional Edition, erişim tarihi Mayıs 1, 2026, https://www.merckmanuals.com/professional/resourcespages/about-the-merck-manuals
22. Resources – Merck Manual Professional Edition, erişim tarihi Mayıs 1, 2026, https://www.merckmanuals.com/professional/resource
23. Merck & MSD | Anna Deu, erişim tarihi Mayıs 1, 2026, https://www.annadeu.com/merck
24. How to Use Medical Subject Headings (MeSH) to Refine and Expand Searches, erişim tarihi Mayıs 1, 2026, https://library.cumc.columbia.edu/kb/how-use-medical-subject-headings-mesh-refine-and
25. I built a RAG system over the Merck Manual (4,000+ pages) for a class project. It failed in interesting ways. Here’s the autopsy and the V2 roadmap. : r/learnmachinelearning – Reddit, erişim tarihi Mayıs 1, 2026, https://www.reddit.com/r/learnmachinelearning/comments/1s630er/i_built_a_rag_system_over_the_merck_manual_4000/
26. How MSD uses Amazon Bedrock to translate natural language into SQL for complex healthcare databases | Artificial Intelligence – AWS, erişim tarihi Mayıs 1, 2026, https://aws.amazon.com/blogs/machine-learning/how-merck-uses-amazon-bedrock-to-translate-natural-language-into-sql-for-complex-healthcare-databases/
27. Table of Contents: The Ultimate Design Guide – NN/G, erişim tarihi Mayıs 1, 2026, https://www.nngroup.com/articles/table-of-contents/
28. Help:Section – Wikipedia, erişim tarihi Mayıs 1, 2026, https://en.wikipedia.org/wiki/Help:Section
29. Help:Link – Wikipedia, erişim tarihi Mayıs 1, 2026, https://en.wikipedia.org/wiki/Help:Link
30. Wikipedia:Vector 2022, erişim tarihi Mayıs 1, 2026, https://en.wikipedia.org/wiki/Wikipedia:Vector_2022
31. Skin:Vector/2022 – MediaWiki, erişim tarihi Mayıs 1, 2026, https://www.mediawiki.org/wiki/Skin:Vector/2022
32. Design notes on the 2023 Wikipedia redesign | by Alex Hollender – UX Collective, erişim tarihi Mayıs 1, 2026, https://uxdesign.cc/design-notes-on-the-2023-wikipedia-redesign-d6573b9af28d
33. How To Create WordPress Table of Contents Without Plugin In 2026 – WP Messiah, erişim tarihi Mayıs 1, 2026, https://wpmessiah.com/create-wordpress-table-of-contents-without-plugin/
34. How to Create a Table of Contents in WordPress Without Plugin (+Manually Using HTML and CSS) | by Soumi Karan | Medium, erişim tarihi Mayıs 1, 2026, https://medium.com/@soumikaran/how-to-create-a-table-of-contents-in-wordpress-without-plugin-manually-using-html-and-css-b59f58966073
35. How to create a Table Of Contents (TOC) in WordPress without a plugin – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=ir1d0j-DrQI
36. Table Of Contents Without Plugins – David Stockdale’s Scrapcode, erişim tarihi Mayıs 1, 2026, https://davidstockdalescrapcode.co.uk/table-of-contents-without-plugins
37. Table of Contents Plus – WordPress plugin, erişim tarihi Mayıs 1, 2026, https://wordpress.org/plugins/table-of-contents-plus/
38. 7 Best Table of Contents WordPress Plugins for 2026 – SeedProd, erişim tarihi Mayıs 1, 2026, https://www.seedprod.com/best-table-of-contents-wordpress-plugins/
39. 7 Best WordPress Table of Contents Plugins I’ve Tested (2026) – Blog Tyrant, erişim tarihi Mayıs 1, 2026, https://www.blogtyrant.com/best-table-of-contents-plugins-for-wordpress/
40. WordPress Table of Contents Plugin: 6 Best Free Plugins – Themeisle, erişim tarihi Mayıs 1, 2026, https://themeisle.com/blog/wordpress-table-of-contents-plugin/
41. 7 Best WordPress Table of Contents Plugins to Try – Bookster, erişim tarihi Mayıs 1, 2026, https://wpbookster.com/best-wordpress-table-of-contents-plugins/
42. Table of contents (Summary) Blocks: A comparison, erişim tarihi Mayıs 1, 2026, https://gu10.blog/2019/08/15/table-of-contents-summary-blocks-a-comparison/
43. A Detailed Beginner’s Guide to the WordPress Dashboard – Avada, erişim tarihi Mayıs 1, 2026, https://avada.com/blog/a-detailed-beginners-guide-to-the-wordpress-dashboard/
44. 5 Best WordPress Wiki & Knowledge Base Plugins in 2024 – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=0sB_UKKNc4c
45. 10 Best Wiki Knowledge Base WordPress Plugins – HubSpot Blog, erişim tarihi Mayıs 1, 2026, https://blog.hubspot.com/website/best-wordpress-wiki-knowledge-base-plugins
46. How to Set up a Help Center With Avada – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=fkd8CgVitKs
47. How To Create a Wiki Using WordPress (Complete Guide) – HeroThemes, erişim tarihi Mayıs 1, 2026, https://herothemes.com/blog/how-to-build-an-internal-wiki-using-wordpress/
48. Sidebar Layout – Echo Knowledge Base, erişim tarihi Mayıs 1, 2026, https://www.echoknowledgebase.com/documentation/sidebar-layout/
49. Categories and Articles – Echo Knowledge Base, erişim tarihi Mayıs 1, 2026, https://www.echoknowledgebase.com/documentation/categories-and-articles/
50. Setting up a Custom User Page in Avada – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=EyTesn-j4HE
51. Build a Custom Portal & Account Dashboard in WordPress with Cornerstone and ACF, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=vH4C6C5Lr3I
52. How To Use Post Cards In Avada – Avada Website Builder, erişim tarihi Mayıs 1, 2026, https://avada.com/documentation/how-to-use-post-cards-in-avada/
53. Post Cards – Avada Website Builder, erişim tarihi Mayıs 1, 2026, https://avada.com/element/post-cards/
54. How to Use Post Cards in Avada – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=JgUO9aM_92k
55. Post Cards Element – Avada Website Builder, erişim tarihi Mayıs 1, 2026, https://avada.com/documentation/post-cards-element/
56. Avada Design Elements, erişim tarihi Mayıs 1, 2026, https://avada.com/documentation/avada-design-elements/
57. How to Use the Avada Post Cards Element – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=-Tg6eXjzt5w
58. How To Create Multiple Knowledge Base In WordPress – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=pCvs_Ekw1Ng
59. How To Add an Accordion in WordPress (Step-By-Step Guide) – HeroThemes, erişim tarihi Mayıs 1, 2026, https://herothemes.com/blog/how-to-add-an-accordion-in-wordpress/
60. 5 Easy Steps To Create An Internal Wiki With WordPress [2022], erişim tarihi Mayıs 1, 2026, https://basepresskb.com/create-internal-wiki-wordpress/
61. How to Make Custom Avada Registration and Login Pages, erişim tarihi Mayıs 1, 2026, https://avada.com/blog/how-to-make-custom-avada-registration-and-login-pages/
62. How to Make Custom Registration & Login Pages in Avada – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=zUIy4OqwVJY
63. 7 Best WordPress Vertical Menu Plugins (2024) – WPBean, erişim tarihi Mayıs 1, 2026, https://wpbean.com/wordpress-vertical-menu-plugins/
64. WPB Accordion Menu – Collapsible Vertical Sidebar Menu – WooCommerce Category Accordion – WordPress.org, erişim tarihi Mayıs 1, 2026, https://wordpress.org/plugins/wpb-accordion-menu-or-category/
65. Woocommerce Sidebar Category Accordion for WordPress – Common Ninja, erişim tarihi Mayıs 1, 2026, https://discover.commoninja.com/wordpress/plugin/woo-sidebar-category-accordion
66. How to Create a Stunning WordPress Sidebar Menu in Minutes – WPBean, erişim tarihi Mayıs 1, 2026, https://wpbean.com/create-wordpress-sidebar-menu/
67. How to Create a Collapsible Sidebar Menu in WordPress – YouTube, erişim tarihi Mayıs 1, 2026, https://www.youtube.com/watch?v=9gKWdm30GQc
68. Article Sidebars – Echo Knowledge Base, erişim tarihi Mayıs 1, 2026, https://www.echoknowledgebase.com/documentation/article-sidebars/