Veri Görselleştirme Araçları ve Doğru Grafik Seçimi
Veri görselleştirmede asıl karar araç seçimi değil, grafik türü. Karşılaştırma mı yapıyorsunuz, zaman içindeki değişimi mi izliyorsunuz, yoksa iki değişken arasındaki ilişkiyi mi arıyorsunuz? Bu soruya cevap vermeden kütüphane karşılaştırmak, duvar örülmeden boya seçmeye benzer. Aşağıda önce grafik türlerinin nerede işe yaradığını, sonra beş kütüphanenin hangi işte gerçekten iyi olduğunu ayırdım.
Önce soru, sonra grafik
Çizgi grafik zamanı taşır. Çubuk grafik kategorileri karşılaştırır. Saçılım grafiği iki değişken arasındaki ilişkiyi gösterir, ısı haritası yoğunluğu. Bu eşleşmeler keyfi değil: insan gözü uzunluk farkını açı ya da alan farkından çok daha iyi ayırt eder, Cleveland ve McGill'in algısal sıralaması da tam olarak bunu söyler.
Bir pasta grafiği üçten fazla dilime bölmem. Dördüncü dilimden sonra okuyucu dilimleri birbiriyle karşılaştıramaz; sadece en büyüğü görür, geri kalanı için etiketteki sayıyı okur. Sayıyı okuyorsa grafiğe zaten gerek kalmamıştır. Aynı veriyi yatay çubukla verdiğinizde sıralama da, aradaki mesafe de tek bakışta çıkar.
Bu konudaki yazılarda sık geçen bir tavsiye var: çeyrek bazlı satış performansını pasta grafikle özetlemek. Yanlış eşleşme. Çeyrekler bir zaman serisidir, bütünün parçaları değil. Dört çeyreği aynı halkanın dilimlerine böldüğünüzde artış da düşüş de kaybolur, çünkü pasta grafiğin gösterebildiği tek şey oranın kendisidir, oranın nasıl değiştiği değil.
Kütüphaneler ve gerçekten iyi oldukları iş
Google Charts
Dokümantasyonu geniş, grafik yelpazesi kalabalık, kullanımı ücretsiz. Rapor ve panel işlerinde ilk bakılacak yer burası. Karşılığında grafikler Google'ın sunucusundan yüklenen bir betiğe bağlı çalışır; çevrimdışı bir kurulum ya da veri gizliliği kısıtı varsa bu tek başına eleme sebebi olur.
Ember Charts
D3.js üzerine kurulu bir Ember.js kütüphanesi. Zaten Ember kullanan bir uygulamanız varsa mantıklı, yoksa bir grafik için çerçeve seçmek ters bir karar olur. Ember dışında kalıyorsanız doğrudan D3 ya da hafif bir sarmalayıcı daha az bağımlılıkla aynı işi görür.
Cube
Cube grafik çizmez. Veri tabanıyla arayüz arasında duran, toplu sorguları tanımlayıp API olarak sunan açık kaynaklı bir katmandır. Panelinizde aynı metrik beş yerde farklı SQL ile hesaplanıyorsa çözdüğü sorun budur, grafik çizim sorunu değil. Diğerleriyle rakip değil, önünde durur.
Arbor.js
Kuvvet yönelimli ağ yerleşimi için canvas tabanlı bir kütüphane, yerleşim hesabını web worker'a taşıması hâlâ zarif bir fikir. Ama uzun süredir yeni sürüm almıyor. Yeni bir projede ağ görselleştirmesi gerekiyorsa bakımı süren bir alternatife bakın; eski bir sayfada çalışıyorsa dokunmaya değmez.
Pizza Pie Charts
Zurb'un çözümü veriyi HTML işaretlemesinden okur, yani veriyi sayfada zaten yazılı tutanlar için kurulum maliyeti düşük. Sadece pasta grafik üretir. Yukarıdaki üç dilim kuralıyla birleştirince kullanım alanı gerçekten dar: iki ya da üç parçalı bir oranı göstermek.
Ağ grafiği neden hızla okunmaz hale gelir
İlişki haritaları ilk bakışta etkileyici görünür, sonra düğüm sayısıyla birlikte çöker. Sebebi basit aritmetik: n düğümlü bir grafta kenar sayısı en fazla n(n-1)/2 olur. 20 düğüm için bu 190, 50 düğüm için 1225 kenar demek. Ekranda 1225 çizgi varsa orada artık bir yapı değil, gri bir bulut görürsünüz.
Hesaplama tarafı da aynı yönde büyür. Kuvvet yönelimli yerleşim her adımda düğüm çiftleri arasındaki itmeyi hesaplar, yani adım başına maliyet düğüm sayısının karesiyle artar. Barnes-Hut gibi uzaydaki düğümleri gruplayan yaklaşımlar bunu n log n seviyesine çeker, ama görsel kalabalık sorununa çözüm getirmez. Ağı okunur tutmanın yolu genellikle çizim tarafında değil: kenarları eşiğe göre filtrelemek, düğümleri kümeleyip özetlemek ya da tek bir düğümün komşuluğunu göstermek.
Zamanın çoğu grafikte geçmiyor
Görselleştirme yazılarının çoğu araç anlatmakla dolar, oysa bir panelin ortaya çıkma süresinin büyük kısmı veriyi toplamak, eksik alanları kapatmak ve aynı metriğin iki kaynakta neden farklı çıktığını bulmakla geçer. Kütüphane bu işin en son adımı, en kolay değiştirilebilen parçası.
Pratikte işe yarayan sıra şu: hangi kararı vereceğinizi yazın, o karar için gereken tek sayıyı bulun, sayının nasıl hesaplandığını tek yerde tanımlayın, sonra grafiği seçin. Bu sırayla gittiğinizde grafik türü çoğu zaman kendiliğinden belli olur ve kütüphane tartışması yarım saate iner.