Great Tables'ın Tasarım Felsefesi
(posit-dev.github.io)- Great Tables, veri analizi akışını Python kodunun içinde tutarken 20. yüzyıl ortası basılı tabloların incelikli ifade gücünü yeniden canlandırmayı amaçlayan bir tablo oluşturma paketidir
- Tablolar, yalnızca satır ve sütunlardan oluşan basit ızgaralar değil; sütun sırası, etiketler ve ayırıcı çizgiler sayesinde değerleri bulmayı ve karşılaştırmayı kolaylaştıran bir bilgi sunum biçimidir
- Antik Sümer kil tabletlerinden Manual of Tabular Presentation'a kadar tablolar, bilgi yoğunluğu ve biçimi birlikte geliştirerek evrildi; ancak ilk elektronik tablolar, hesaplama kolaylığına karşın ifade gücü açısından yetersiz kaldı
- Great Tables, tabloyu 6 bileşene ayırır ve
tab_*,fmt_*,opt_*()API aileleriyle yapı, biçimlendirme ve stil vermeyi birbirinden ayırır - Bu paket, büyük ölçekli etkileşimli keşiften çok; makale, kitap ve raporlarda yer alan statik özet tabloların yayın ve sunum kalitesini yükseltmeye odaklanır
Great Tables'ın çözmeye çalıştığı tablo üretim ikilemi
- Tablolar, grafikler gibi bilginin sunulduğu son aşamada önemlidir ve etkili tablo tasarımında beklenenden daha fazla incelik ve nüans vardır
- Günümüzde veriyle çalışan kişiler genelde iki seçenek arasında ödün vermek zorunda kalır
- Veriyi Excel gibi araçlara kopyalayıp tabloyu yeniden oluşturmak
- Cilalanmamış bir tabloyu olduğu gibi göstermek
- Great Tables, bu ikilemi Python kodu tabanlı bir arayüzle çözmeye çalışan bir pakettir
- Amaç, veri toplama, analiz ve özet tablo üretimini Python içinde yürütürken aynı zamanda ifade gücü yüksek tablolar oluşturabilmektir
Tablonun temel tanımı ve okunabilirlik unsurları
- Tablo, iki temel kuralla özetlenebilir
- Veriler sütunlar ve satırlar halinde sunulur
- Veriler ağırlıklı olarak metin olarak ifade edilir
- Örnek tabloda kişiler satırlara, ad, adres, şehir, posta kodu, doğum tarihi, boy ve kilo gibi özellikler sütunlara yerleştirilir
- Bu düzen, tekil değerleri bulmayı ya da satırlar ve sütunlar arasında karşılaştırma yapmayı kolaylaştırır
- Satırlar arasındaki yatay çizgiler zorunlu değildir; ancak tek tek satırları görsel olarak ayıran destekleyici bir rol oynar
- Sütunların sırası da okunabilirliği doğrudan etkiler
Namesütunu en sağda olursa, her kaydın öznesi hemen görünmez ve bu durum okuyucu için daha fazla kafa karışıklığı yaratabilir- Sütun etiketleri, her sütunda hangi verinin bulunduğunu gösterir ve çoğu durumda tahmini azaltır
Antik tablonun tarihi
- Tablolar, bilgiyi taşıyabilen bir kap olan kare ızgaradan yola çıkar
- Fransa'daki Lascaux ve Niaux mağara duvarlarında yaklaşık 25 bin yıl öncesine ait ızgara betimleri bulunur
- MÖ 2. yüzyılda Hipparchus, gök cisimlerini ve yeryüzündeki konumları enlem ve boylamla gösterdi; MS 150 civarında Ptolemy'nin Geographia eseri, ızgara kullanan harita üretim yöntemlerini içeriyordu
- Roma'nın centuriation sistemi, yollar, kanallar ve tarım arazileri üzerinden kare ızgaralar oluşturan bir arazi ölçüm düzeniydi
- Yaklaşık 10 bin yıl önce tarımın yaygınlaşmasından sonra, tarım, hayvancılık ve iş bölümüyle ilgili ekonomik işlemleri kaydetme ve yönetme ihtiyacı büyüdü
Sümer ve Mezopotamya'da tablo yapısı
- MÖ 4. binyılda Mezopotamya şehirleri uzak krallıklarla ticaret yapıyor ve kayıt tutmak zorunda kalıyordu; Uruk'ta bulunan kil tabletlerde erken dönemden kalma ama gelişmiş tablolar yer alır
- MÖ 3200-3000 civarına tarihlenen Uruk tabletleri, bira üretimi için gönderilen arpa ve malt miktarlarını kaydeder
- Yapı sağdan sola okunur
- Her hücrede sözcükleri ya da kavramları gösteren piktogramlar ve miktarı gösteren sayılar bulunur
- Yaklaşık iki satırın her biri bir kişiye karşılık gelir
- Sağdaki iki sütun malt ve arpa miktarlarını içerir
- Üçüncü sütun kişi bazında ara toplamı, en soldaki sütun ise genel toplamı gösterir
- En alttaki satırda sorumlu yöneticinin adı yer alır ve bir dipnot bölümü gibi çalışır
- Yaklaşık bin yıl sonraya ait Nippur Enlil tapınağı tableti, gelir kaynaklarını ve 50 tapınak çalışanının aylık harcamalarını içerir
- Daha düzenli bir ızgara görülür
- Ay adlarından oluşan sütun başlıkları ile kişi adları ve mesleklerden oluşan satır başlıkları vardır
- Boş hücreler, sayısal değerler, 6 aylık ara toplamlar, genel toplamlar ve açıklayıcı notlar bulunur
- Sonraki dönemlerde tabloların ortamı kilden balmumu tabletlere, papirüse ve kâğıda geçti; yazma teknikleri ve tablo tasarımı da bununla birlikte değişti
20. yüzyıl ortasında tablo tasarımının zirvesi
-
- yüzyıl ortası, tablo tasarımının özellikle güçlü olduğu bir dönem olarak ele alınır
- Ofset baskı, daktilo ve varitype gibi belge üretim teknolojileri, tablo öğelerini hassas biçimde dizmeye yetecek kadar gelişmişti
- Sayfa alanı kısıtlıydı, ancak tabloyu tek sayfaya sığdırmak ya da birden fazla sayfaya bölmek için çeşitli çözümler vardı
- İleri baskı teknolojileri ile tablo tasarımı bilgisinin birleşmesi, güzel tablolar üretmeyi mümkün kıldı
- ABD Nüfus Sayım Bürosu'nun Manual of Tabular Presentation yayını, bilgi yoğun tabloların ideal tasarımını ayrıntılı biçimde ele alan bir çalışmadır
- Tablonun çeşitli bölümlerini adlandırır ve titizlikle açıklar
- Farklı tablo hazırlama durumları için yapılması ve yapılmaması gerekenleri güçlü biçimde önerir
- Tabloların hem iyi görünüp hem de çok bilgi taşıyabileceğini gösterir
- Great Tables, bu belgedeki tablo tasarım ilkelerinin çoğunu benimser ve bu ilkelerin bugün de geçerli olduğu varsayımından hareket eder
Elektronik tablolardan sonra yaşanan gerileme ve sınırlar
- 1970'ler ve 1980'lerde bilişim teknolojileri daha erişilebilir hale gelince, insanlar tabloları hem elektronik hem de basılı biçimde üretebilir oldu
- Hesaplama yapılabilen tabloların yaygınlaşması, 1979'daki VisiCalc ile başlamış sayılabilir
- VisiCalc değerleri hızlı hesaplayabiliyordu, ancak sunum amaçlı tablolar için ifade gücü sınırlıydı
- Izgara hücrelerine sunum amaçlı kenarlık stilleri verilemiyordu
- Değerler biçimlendirilemiyordu
- Tablolar yazdırılamıyordu
- Sonraki 10-15 yılda elektronik tablo görünümleri iyileşti
- 1990'ların başında Excel, tablolara kenarlık ekleyebiliyordu
- Tipografi desteği gelişti
- Değer biçimlendirme özellikleri arttı
- Buna rağmen, son 30 yılın Excel tablolarının Manual of Tabular Presentation düzeyine ulaşmakta zorlandığı değerlendirilir
- Veri analizi Excel dışında da yapılmaya başlayınca üç verimsiz senaryo ortaya çıktı
- Analiz ve tablo üretimi tamamen Python içinde yapılır ama tablo kalitesi düşüktür
- Analiz ve tablo üretimi tamamen Excel içinde yapılır ama analiz esnekliği düşüktür
- Analiz Python'da yapılır, tablo oluşturmak için Excel'e kopyalanır ama süreç yeniden üretilebilir değildir
Great Tables'ın tablo modeli
- Great Tables, 20. yüzyıl ortası tabloların zarafetini kod arayüzlerinin gücüyle birleştirmeyi amaçlayan bir Python paketidir
- Tabloyu 6 bağımsız bileşenin birleşimi olarak ifade eder
- Table Header: Başlık ve alt başlık içeren, tablonun içeriğini kısa biçimde açıklayan alan
- Column Labels: Her sütunun içeriğini tanımlar; spanner ise birden fazla sütun grubunun üzerinde yer alan başlıktır
- Stub Head: Sol üstte yer alır ve farklı türlerde etiketler içerebilir
- Row Stub: Satır bilgileri ve satır grup etiketleri için ayrılan alan
- Table Body: Hücreleri barındırır ve verinin bulunduğu bölümdür
- Table Footer: Tablo içeriğiyle ilgili ek bilgileri içeren alan
- Great Tables, önce kodla tablo gövdesini oluşturup ardından stil, biçim ve diğer bileşenleri yinelemeli olarak ekleme yaklaşımıyla kullanılır
- Örnek kod
GT(simple_table, rowname_col="Name")ile başlar; ardından başlık, stub head, column spanner, source note, tarih ve tam sayı biçimleri ile stil seçenekleri eklenir - Örnek tabloda mavi row stub, satır etiketlerini tablo gövdesinden ayırır
- Her kişi benzersiz bir gözlem olduğundan satırın öznesini vurgular
- Başlık, tablonun ne içerdiğini açıklar
LocationvePersonal Characteristicsspanner'ları, sütunları anlamlı gruplar halinde toplar- Mavi çizgilerin ve hücre arka planlarının tutarlı kullanımı profesyonel bir görünüm oluşturur
- Tablo bileşenleri ekleyen metotlar
tab_ile başlar- Örneğin
tab_header(), Table Header oluşturur
- Örneğin
Biçimlendirme ve nanoplots
- Yalnızca tabloyu yapılandırmak yeterli değildir; farklı alanların değer gösterimi için farklı ihtiyaçları vardır
- Tek bir sayı bile, topluluğun normlarına ve beklentilerine göre birçok farklı biçimde gösterilebilir
- Tarih, saat ve para birimi de eklendiğinde biçimlendirme aralığı daha da genişler
- Ham değer
134,000, gereksinime göre farklı şekillerde sunulabilirfmt_scientific(): bilimsel gösterim1.34 × 10^5fmt_number(): Alman yerel ayarına uygun sayı134.000,00fmt_integer(): sıkıştırılmış tam sayı134K
- Değerin bir görsel ya da grafik olarak aktarılması gerektiğinde biçimlendirme sorunu daha da büyür
- Tıbbi analiz yapan biri, hasta test sonuçlarındaki iyileşme ve kötüleşme eğilimlerini aktarmak istiyorsa, tüm satırdaki sayısal diziyi okuyarak anlam çıkarmak yorumu yavaşlatabilir
fmt_nanoplot(), nanoplots aracılığıyla tablo içinde küçük trend görselleştirmeleri sunar- Veri noktalarının üzerine gelindiğinde her tarihteki değer görülebilir
- Nanoplots, grafiklerin hızlı görsel yorumlanması ile tabloların kompaktlığı arasında denge kurmayı hedefler
- Great Tables'ın biçimlendirme metotları
fmt_ile başlar- Örneğin
fmt_date(),fmt_integer(),fmt_nanoplot()
- Örneğin
- Paket, farklı kullanıcıların ihtiyaçlarına uyacak çok sayıda biçimlendirme metodu ve yararlı seçenek sunmayı amaçlar
Yayın ve sunum için statik özet tablolara odaklanma
- Great Tables, tablolarla etkileşimin birçok biçimi arasından özellikle yayın ve sunum amaçlı gösterime odaklanır
- Veritabanı analizinde yüzlerce, binlerce veya daha fazla kaydı gezmek ve filtrelemek için basit tablo gösterimi uygun olabilir
- Sonuçları yayımlamak farklı bir iştir; burada yapılandırma, biçimlendirme ve stil verme öne çıkar
- Güzel bir tablo sunumu şunları sağlamalıdır
- Bilgiyi daha kolay sindirilebilir hale getirir
- Gereken yerde ek bağlam sağlar
- Belgenin ya da kurumun stilini izler
- Hedef kullanım alanı; dergi makaleleri, kitaplar ve raporlarda görülen veri sunum biçimidir
- Great Tables, statik özet tabloların ayrı bir odak alanını hak ettiğini savunur ve
opt_*()metotlarıyla okuyuculara daha iyi tablolar sunmayı kolaylaştırmayı amaçlar - Paketin başarı ölçütü, üretebildiği tabloların kalitesidir ve API'yi geliştirme çalışmaları sürecektir
- Topluluk geri bildirimi için Discord Server açıktır
1 yorum
Hacker News yorumları
Daha fazla projenin felsefesini ve hedeflerini bu şekilde açıklamasını isterdim.
Jupyter için Buckaroo adlı başka bir tablo kütüphanesi yaptım; yaklaşımı farklı.
Buckaroo, etkileşimli çalışırken çeşitli formatları ve son işleme fonksiyonlarını hızlıca deneyerek tablolardan önemli içgörüler elde etmeyi amaçlıyor.
Temel keşifsel veri analizi yaparken aynı komutları tekrar tekrar yazmak gerekiyor; bu yüzden bu komutların ve içgörülerin tablonun içinde yer alması gerektiğini düşündüm.
Great Tables ise daha çok sunum amaçlı tabloları elle biçimlendirmek için yapılmış gibi görünüyor.
https://github.com/paddymul/buckaroo
https://youtu.be/GPl6_9n31NE
print()ve IPythondisplay()ölü, statik çıktı sınırlamasına sahip ve eskiprintfhata ayıklaması gibi hissettiriyor; anladığım kadarıyla Buckaroo bunu çözmek için yapılmış.Visidata’nın kısayolları ve etkileşim biçimi hakkında ne düşündüğünü merak ediyorum.
Eskiden Visidata kullanıyordum ve veri çerçevesi keşfi için neden eninde sonunda Jupyter’in içine giremeyeceğini hep merak etmişimdir.
Great Tables’ın tablo gramerini resmileştirmeye yönelik bir başka girişim gibi göründüğüne katılıyorum; tablo biçiminin gücü ve R/pandas/Arrow/polars ekosistemi üzerinden veri çerçevesi kavramının yayılması düşünüldüğünde bu yaklaşım memnuniyet verici.
Ancak bildiğim kadarıyla bu terim ilk olarak 90’larda istatistik dili S’te kullanılmıştı.
[1] https://towardsdatascience.com/preventing-the-death-of-the-d...
Altta biraz boşluk bırakıp kalın yazı tipi kullanmak, görsel hiyerarşiyi gürültü oluşturmadan verebilir gibi.
Satır etiketi arka planı çok koyu ve yazı kalınlığı yüzünden okunması zor; çok açık bir mavi daha iyi olurdu.
Satır grubu etiketi olan “Name”in italik bırakılması da hoşuma gitmiyor.
Ortada havada duran üst sütun etiketi, tabloyu gözle taramayı zorlaştırıyor; sola hizalama çok daha iyi olur gibi.
Son olarak yazı tipini de gerçekten beğenmiyorum; gerçi bu tarayıcıdan kaynaklanıyor olabilir.
Birkaç değişikliği yansıtan bir mockup hazırladım; bence bu çok daha okunabilir bir tablo.
https://i.imgur.com/iMMf5vo.png
Okunabilirlik ve verinin mesajını ya da ana fikrini engelleyen unsurlar gibi az önce değindiğin konuları ele alıyor.
Sparkline gördüysen, bu terimi ortaya atan kişi de Tufte’dir.
UI incelemesi yaptığımız her seferinde kaçırdığımız bir şey var mı diye bu kitabı karıştırıyorum; rastgele bir sayfa açıp okumak bile ilginç.
Üstelik PowerPoint’in neden berbat olduğuna dair uzun bir deneme de var.
[1] https://www.edwardtufte.com/tufte/books_be
[2] https://en.wikipedia.org/wiki/Sparkline
Bir sütunun üstüne sola hizalarsanız, genelde doğru olmayan ya da amaçlanmayan bir şekilde o başlık tablo bilgi hiyerarşisinin en üst seviyesiymiş gibi görünür.
Yukarıdaki modernist düzeltmede başlık “names, addresses, characteristics” diyor ama hizalama açısından adları dışarıda bırakıyormuş gibi göründüğü için hemen rahatsız edici geldi.
Buna karşılık nüfus sayımı kılavuzu, neredeyse tüm etiketleri ilgili kutunun içinde ortalar; ortalamadığı durumlarda da çoğunlukla girinti kullanır.
Ayrıca sütun genişliklerini etiketlere göre değil, verilere göre belirler; girinti ve tirelemeyi ayarlamaktan da çekinmez.
Sonuçta yatay olarak yoğun ama sezgisel biçimde anlaşılabilir hale gelir.
Biraz daha düşününce başlığın kendisi de pek iyi değil.
Başlıklar ve açıklamalar bağlamı, kapsamı ve amacı aktarmalıdır; bunu yapamıyorlarsa, varlıklarını gerekçelendiremedikleri editoryal kusur nedeniyle tamamen çıkarılabilirler.
Mevcut başlık, bilgi ya da genellik kaybı olmadan “Table 1” olarak değiştirilebilir.
Tablo gösterimini ilk ilkelerden tartışıp yeniden kurmayı amaçlayan bir yazı için biraz hayal kırıklığı yaratıyor.
Tablo başlıkları bilgi kataloğunun önemli bir katmanını oluşturduğundan, nüfus sayımı kılavuzunun başlık oluşturmaya koca bir bölüm ayırması şaşırtıcı değil.
Biraz alana özgü ve eski tarz bir üslubu olsa da bakmaya değer.
Mavi vurgu da artık başlıkla tekrar ediyor, o yüzden tamamen çıkarılmalı; “personal characteristics” ve “location” ayrımı da organizasyona anlamlı biçimde yardımcı olmuyor, bu nedenle kaldırmak daha iyi.
Daha yakın dönemden bir örnek olarak CALS tablolarının oluşturulması var: https://en.wikipedia.org/wiki/CALS_Table_Model
Datalogics https://en.wikipedia.org/wiki/Datalogics CALS tabloları fikrine derinden dahil olmuştu.
Datalogics çalışanları SGML’i oluşturan ISO komitesinde yer aldı ve dokümantasyonla ilgilenen ABD Savunma Bakanlığı çalışanları ile yükleniciler de dahil olmak üzere pek çok kişiye SGML eğitimi verdi
SGML tabanlı bir belge düzenleyicisi geliştiren ekipte yer aldım; özelliklerinden biri, öğeleri ilgili öğenin SGML bağlamına göre biçimlendirmekti
Bu, XSLT ve ailesinden önceydi
Datalogics’ten gelenler Microsoft’un XML’i anlamasına yardımcı oldu. “Hayır, XML öğe etiketlerinin büyük/küçük harflerini keyfinize göre değiştiremezsiniz” gibi
TeX kullanıcılarının da tablo biçimlendirme konusunda epey incelikli fikirleri var
İlginç bir yan not olarak, o dönemde bir savaş uçağının tüm dokümantasyonu basılsa uçağın kendisinden daha ağır olacağını ve bir futbol sahası büyüklüğünde dosya dolabı yığınını dolduracağını öğrenmiştim
Ve bugün pek çok kişi XML’i sevmese de, SGML dünyasından gelen biri için XML büyük bir nimet
İlk sürümde de sınırlı da olsa biçimlendirme desteği olduğunu hatırlıyorum
http://www.bricklin.com/history/refcard3.htm adresine göre
/Fkomutuyla hizalama belirtilebiliyor ve sayı biçimi örneğin dolar ve sent olarak ayarlanabiliyorduBu belge 1.35 sürümünü temel alıyor, ama ilk çıkan sürümün de en azından dolar ve sent gösterimini desteklediğini sanıyorum
Örneğin maliyetler $1500, $130, $110, $210 ise son üç satırdaki metin, ilk satırdaki metnin 4/5’i kadar büyük görünür
Oysa üçünü toplasanız bile en üstteki tutarın yalnızca 1/3’ü eder
İnsanlar sayıların basamak sayısını görsel olarak algılıyor; bu da kabaca log10’a benziyor
Bu sorun o kadar sık yaşanıyor ki, finansla ilgili elektronik tablolara her seferinde hücre içi çubuk grafikler koymaya başladım
Aksi halde toplantılar, mutlak tutar açısından en büyük maliyetin yanında tamamen önemsiz kalan kalemleri tartışmakla yoldan çıkıyor
Nitekim aylık lisans maliyeti tek başına $15K olan bir veritabanı motorunu çalıştıran VM’de, bulut sunucu log toplama için aylık $15’lık maliyet üzerine birkaç toplantı harcadığımız oldu
Rich Iannone ile birlikte yönetiyorum
Paket felsefesini açıklaması istendiğinde tablo gösteriminin 5.000 yıllık tarihini anlatacak başka bir yazılım geliştiricisi tanımıyorum
Giderek kötüleşen veri tablosu gösteriminin bu kadar uzun süre böyle bırakılmış olması şaşırtıcı
Yazıda işaret edilen 20. yüzyıl ortası modern tablolar gerçekten parlak örnekler gibi görünüyor
Python ile yeniden veri analizi yapmak istedim; yapmak istediğim birkaç API iyileştirmesi ve genişletmesi de aklıma geldi
HTML tabloları oluşturmak için harika, ancak PDF ve DOCX çıktıları biraz daha az cilalı
Son dönemde odağın Python sürümünü R sürümünün seviyesine çıkarmaya kaymasıyla R tarafındaki geliştirme hızının yavaşlamış olmasından biraz endişeliyim
Yine de hangi dili kullanırsanız kullanın, göz atmaya değer
SAS dışında ana aracımız, kısaca TPL denen eski bir dil olan Table Producing Language idi
Kökeni 1970’lere kadar gidiyor, ama sözdizimini çözdüğünüzde TPL inanılmaz derecede esnek, ifade gücü yüksek ve verimliydi
Great Tables tasarımcılarının TPL’ye bakması iyi olur
Great Tables’ın hedeflediği her şeyi kapsıyor; hatta birkaç ek numarası da olabilir
https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
Her hâlükârda Great Tables’ı geliştirdiğiniz için teşekkürler
Python’da tablo üretim kalitesini çok daha iyi hâle getirmeye büyük katkı sağlıyor
Show HN’ye bir şey koyanlar bakıp öğrenmeli
İlginç bir yan not olarak, elektronik tablolarla eğitilen yapay zeka modellerinin bağlamı anlayabilmesi için sütun adları, başlıklar gibi “iyi tablolara” ihtiyacı var
Fortap buna bir örnek: https://arxiv.org/abs/2109.07323