Konu Başlıkları
Yükleniyor...

PDF mi Web Sayfası mı? Ekranda Okunabilirlik Kararı

Ekranda okunan içerik nereye konur: PDF ve HTML karşılaştırması

Ekranda okunacak bir içeriği PDF olarak yayımlamak, baskı için dizilmiş bir kalıbı telefona sıkıştırmak demek. Öte yandan “PDF kötüdür” genellemesi tek başına karar vermeye yetmiyor. Sorunun tam olarak nerede çıktığına ve dosyanın hangi durumda hâlâ doğru tercih olduğuna ayrı ayrı bakmak gerekiyor.

Ekranda tıkanan şey: sabit sayfa

PDF’in temel kararı şudur: sayfa geometrisi içerikle birlikte dondurulur. A4 için dizilmiş bir metin 390 piksel genişliğindeki bir ekranda ya okunamayacak kadar küçülür ya da yatay kaydırma ister. HTML’de metin kabına göre akar, okuyucu punto büyütünce satır yeniden kırılır. PDF’de punto büyütmek yakınlaştırmaktan ibarettir, satır aynı satırdır.

Buna bir de bağlamdan kopma ekleniyor. Kullanıcı bağlantıya tıklar, sitenizden çıkar, başka bir görüntüleyicinin içinde bulur kendini. Geri düğmesi bazen çalışır, arama kutusu başka yerdedir, menünüz ortada yoktur.

Bu farkı “yüzde üç yüz daha kötü” diye sayıya bağlayan bir cümle yıllardır UX yazılarında dolaşıyor. Kaynağına inmeye çalışan kişi genelde birbirini alıntılayan blogların içinde kaybolur. Sayıya da ihtiyaç yok: yukarıdaki iki mekanizma, kendi belgenizi telefonda beş dakika açıp okumaya çalışarak doğrulanabilir.

“PDF indekslenmez” doğru değil

Arama motorları metin katmanı olan PDF dosyalarını uzun süredir indeksliyor, bu dosyalar sonuçlarda çıkıyor. Gerçek problem indekslenmemesi değil, indekslendiğinde ziyaretçinin sayfanıza değil dosyanın ortasına düşmesi. Oradan iç bağlantı yok, ilgili yazıya geçiş yok, kayıt formu yok.

Bağlantı birikimi de dosyanın üzerinde toplanır. İçeriği bir gün HTML sayfasına taşımaya karar verdiğinizde, o birikimi yönlendirme kurmadan taşıyamazsınız. Ölçüm tarafı ayrıca kör: dosyanın içinde nereye kadar okunduğunu, hangi bölümün atlandığını göremezsiniz. İndirme sayısı okuma göstergesi değildir.

Erişilebilirlikte fark biçimden değil ihmalden geliyor

PDF etiketli (tagged) üretilirse ekran okuyucu başlık yapısını, tablo hücrelerini ve okuma sırasını takip edebilir. Sorun şu ki ofis ve tasarım araçlarından çıkan dosyaların büyük kısmı bu etiketleri taşımıyor. İki sütunlu bir sayfa soldan sağa tek satır gibi okunuyor, tablo düz metne dönüşüyor, başlıklar yalnızca puntoyla ayrılmış oluyor.

Aynı hatayı HTML’de yapmak da mümkün. Aradaki fark onarımda: sayfada hatayı bir şablonda bir kez düzeltirsiniz, PDF’de her yeni dosyada baştan uğraşırsınız.

PDF’in doğru olduğu yer

Buraya kadarı PDF aleyhine okunabilir, ancak arşiv ve baskı söz konusu olduğunda PDF’i HTML’den daha güvenilir bulurum. Dosya on yıl sonra aynı sayfa düzeniyle açılır, imzalanabilir, sayfa numarası verilerek atıf yapılabilir; bir web sayfasının on yıl sonra aynı görüneceğinin garantisi yok. Sözleşme, fatura, resmî form, çıktısı alınıp masaya konacak kılavuz: bunların yeri dosyadır.

Ayrımı basit tutun. Ekranda okunacaksa sayfa, saklanacak ya da basılacaksa dosya. İkisi birden gerekiyorsa tek kaynaktan üretin, yoksa altı ay içinde iki farklı sürüm dolaşmaya başlar.

Uzun belgeyi webe taşırken

Elli sayfalık bir kılavuzu tek bir HTML sayfasına dökmek çözüm değil, PDF’in kaydırma sorununu markup ile tekrarlamaktır. Belgeyi bölümlere ayırın, her bölüme kendi adresini verin, üste kısa bir içindekiler koyun. İnsanlar kılavuzu baştan sona okumaz, aradıkları maddeye gider; adres verilebilen bir bölüm başlığı, indirilebilir bir dosyadan çok daha fazla işe yarar.

PDF sürümünü yine de tutacaksanız bağlantının yanına dosya boyutunu ve sayfa sayısını yazın. Araya özet ve yönlendirme barındıran ayrı bir ara sayfa kurmaya gerek yok, o da kullanıcı için fazladan bir tık demek.