ปรัชญาการออกแบบของ Great Tables

• Great Tables คือแพ็กเกจสำหรับสร้างตารางที่มุ่งคงเวิร์กโฟลว์การวิเคราะห์ข้อมูลไว้ภายในโค้ด Python พร้อมฟื้นคืนความสามารถในการนำเสนออันประณีตของ ตารางสิ่งพิมพ์ช่วงกลางศตวรรษที่ 20
• ตารางไม่ได้เป็นเพียงกริดของแถวและคอลัมน์ แต่เป็นรูปแบบการนำเสนอข้อมูลที่ช่วยให้ค้นหาและเปรียบเทียบค่าได้ง่ายผ่าน ลำดับคอลัมน์ ป้ายกำกับ และเส้นแบ่ง
• ตั้งแต่แผ่นดินเหนียวของชาวสุเมเรียนโบราณไปจนถึง Manual of Tabular Presentation ตารางได้พัฒนาไปพร้อมกันทั้งในด้านความหนาแน่นของข้อมูลและรูปแบบ แต่สเปรดชีตรุ่นแรก ๆ ยังขาดพลังในการนำเสนอเมื่อเทียบกับความสะดวกด้านการคำนวณ
• Great Tables แบ่งตารางออกเป็น 6 องค์ประกอบ และแยกโครงสร้าง การจัดรูปแบบ และการตกแต่งสไตล์ออกจากกันด้วย API ตระกูล tab_*, fmt_*, opt_*()
• แพ็กเกจนี้มุ่งยกระดับคุณภาพการตีพิมพ์และการนำเสนอของ ตารางสรุปแบบคงที่ สำหรับบทความวิชาการ หนังสือ และรายงาน มากกว่าการสำรวจข้อมูลขนาดใหญ่แบบอินเทอร์แอ็กทีฟ

---

ภาวะกลืนไม่เข้าคายไม่ออกของการสร้างตารางที่ Great Tables ต้องการแก้

• ตารางมีความสำคัญในขั้นตอนสุดท้ายของการนำเสนอข้อมูลเช่นเดียวกับพล็อต และการออกแบบตารางที่มีประสิทธิภาพก็มี ความประณีตและนัยละเอียดอ่อน มากกว่าที่คิด
• ทุกวันนี้ผู้ทำงานกับข้อมูลมักต้องประนีประนอมระหว่างสองทางเลือก
  • คัดลอกข้อมูลไปสร้างตารางใหม่ในเครื่องมืออย่าง Excel
  • แสดงตารางที่ยังไม่ผ่านการขัดเกลาออกมาตรง ๆ
• Great Tables คือแพ็กเกจที่พยายามแก้ภาวะกลืนไม่เข้าคายไม่ออกนี้ด้วย อินเทอร์เฟซที่อิงโค้ด Python
• เป้าหมายคือสร้างตารางที่มีพลังในการนำเสนอ โดยจัดการตั้งแต่การเก็บข้อมูล การวิเคราะห์ ไปจนถึงการสร้างตารางสรุปทั้งหมดภายใน Python

นิยามพื้นฐานของตารางและองค์ประกอบด้านการอ่านง่าย

• ตารางสรุปได้ด้วยกฎพื้นฐานสองข้อ
  • ข้อมูลถูกแสดงเป็น คอลัมน์และแถว
  • ข้อมูลถูกแสดงเป็น ข้อความ เป็นหลัก
• ตารางตัวอย่างจัดวางบุคคลเป็นแถว และวางคุณลักษณะอย่างชื่อ ที่อยู่ เมือง รหัสไปรษณีย์ วันเกิด ส่วนสูง และน้ำหนักเป็นคอลัมน์
• การจัดวางเช่นนี้ช่วยให้ค้นหาค่าเฉพาะหรือเปรียบเทียบโดยข้ามไปมาระหว่างแถวและคอลัมน์ได้ง่าย
• เส้นแนวนอนระหว่างแถวไม่ใช่เงื่อนไขจำเป็น แต่ทำหน้าที่เสริมในการแยกแต่ละแถวออกจากกันทางสายตา
• ลำดับของคอลัมน์ก็ส่งผลต่อความสามารถในการอ่านโดยตรง
  • หากคอลัมน์ Name อยู่ขวาสุด ผู้อ่านอาจสับสนมากขึ้นเพราะมองไม่เห็นตัวตนของแต่ละเรกคอร์ดได้ทันที
  • ป้ายกำกับคอลัมน์บอกว่ามีข้อมูลอะไรอยู่ในแต่ละคอลัมน์ และในกรณีส่วนใหญ่ช่วยลดการเดา

ประวัติศาสตร์ของตารางยุคโบราณ

• ตารางเริ่มต้นจาก กริดสี่เหลี่ยมจัตุรัส ซึ่งเป็นภาชนะสำหรับบรรจุข้อมูล
• บนผนังถ้ำ Lascaux และ Niaux ในฝรั่งเศสยังคงมีร่องรอยของการแสดงกริดจากเมื่อประมาณ 25,000 ปีก่อน
• ในศตวรรษที่ 2 ก่อนคริสตกาล Hipparchus ใช้ละติจูดและลองจิจูดแทนตำแหน่งของวัตถุท้องฟ้าและตำแหน่งบนโลก และราวปี ค.ศ. 150 Geographia ของ Ptolemy ก็รวมวิธีการทำแผนที่โดยใช้กริดไว้ด้วย
• centuriation ของโรมันเป็นระบบสำรวจที่ดินที่สร้างกริดสี่เหลี่ยมผ่านถนน คลอง และพื้นที่เกษตรกรรม
• หลังจากเกษตรกรรมแพร่หลายอย่างกว้างขวางราว 10,000 ปีก่อน ความจำเป็นในการบันทึกและจัดการธุรกรรมทางเศรษฐกิจที่เกี่ยวกับเกษตรกรรม ปศุสัตว์ และการแบ่งงานก็เพิ่มขึ้น

โครงสร้างตารางของชาวสุเมเรียนและเมโสโปเตเมีย

• เมืองต่าง ๆ ในเมโสโปเตเมียช่วงสหัสวรรษที่ 4 ก่อนคริสตกาลต้องเก็บบันทึกระหว่างการค้ากับอาณาจักรห่างไกล และแผ่นดินเหนียวที่พบใน Uruk ก็ยังแสดงให้เห็นตารางยุคแรกที่แม้จะเก่าแก่แต่มีความซับซ้อน
• แผ่นดินเหนียวจาก Uruk ราว 3200–3000 ปีก่อนคริสตกาลบันทึกปริมาณการส่งข้าวบาร์เลย์และมอลต์สำหรับการผลิตเบียร์
  • เป็นโครงสร้างที่อ่านจากขวาไปซ้าย
  • แต่ละช่องมีทั้งอักษรภาพแทนคำหรือแนวคิด และตัวเลขแทนปริมาณ
  • ราวสองแถวสอดคล้องกับหนึ่งคน
  • สองคอลัมน์ด้านขวาสุดเก็บปริมาณมอลต์และข้าวบาร์เลย์
  • คอลัมน์ที่สามแสดงผลรวมย่อยรายบุคคล และคอลัมน์ซ้ายสุดแสดงผลรวมทั้งหมด
  • แถวล่างสุดมีชื่อผู้ดูแลรับผิดชอบ จึงทำงานคล้ายฟุตเตอร์
• ราวหนึ่งพันปีต่อมา แผ่นดินเหนียวจากวิหาร Enlil ที่ Nippur บันทึกรายได้และรายจ่ายรายเดือนของกำลังคนในวิหาร 50 คน
  • เห็นกริดที่เป็นระเบียบมากขึ้น
  • มีหัวคอลัมน์เป็นชื่อเดือน และมีหัวแถวเป็นชื่อบุคคลและอาชีพ
  • มีทั้งเซลล์ว่างที่ไม่มีข้อมูล ค่าตัวเลข ผลรวมย่อยทุก 6 เดือน ผลรวมทั้งหมด และหมายเหตุอธิบาย
• หลังจากนั้นสื่อของตารางก็เปลี่ยนจากดินเหนียวเป็นแผ่นขี้ผึ้ง ปาปิรุส และกระดาษ พร้อมกับที่เทคนิคการเขียนและการออกแบบตารางเปลี่ยนแปลงไปด้วย

จุดสูงสุดของการออกแบบตารางในช่วงกลางศตวรรษที่ 20

• ช่วงกลางศตวรรษที่ 20 ถูกมองว่าเป็นยุคที่การออกแบบตารางแข็งแกร่งเป็นพิเศษ
• เทคโนโลยีการผลิตเอกสารอย่างการพิมพ์ออฟเซ็ต เครื่องพิมพ์ดีด และ varitype พัฒนาไปจนสามารถจัดวางองค์ประกอบของตารางได้อย่างแม่นยำ
• แม้จะมีข้อจำกัดด้านพื้นที่บนหน้า แต่ก็มีวิธีแก้หลายแบบทั้งการทำให้ตารางพอดีกับหน้าเดียวหรือแบ่งออกหลายหน้า
• การผสานกันของเทคโนโลยีการพิมพ์ขั้นสูงและองค์ความรู้ด้านการออกแบบตารางทำให้สามารถสร้าง ตารางที่งดงาม ได้
• Manual of Tabular Presentation ของสำนักงานสำมะโนสหรัฐเป็นผลงานที่อธิบายการออกแบบอุดมคติของตารางที่มีความหนาแน่นข้อมูลสูงไว้อย่างละเอียด
  • ตั้งชื่อและอธิบายส่วนต่าง ๆ ของตารางอย่างเคร่งครัด
  • แนะนำอย่างหนักแน่นถึงสิ่งที่ควรทำและไม่ควรทำในสถานการณ์การสร้างตารางหลากหลายแบบ
  • แสดงให้เห็นว่าตารางสามารถทั้งดูดีและบรรจุข้อมูลได้จำนวนมาก
• Great Tables หยิบยืมหลักการออกแบบตารางจากเอกสารนี้มาอย่างมาก และเริ่มต้นจากสมมติฐานว่าหลักการเหล่านั้นยังคงใช้ได้ในปัจจุบัน

การถอยหลังและข้อจำกัดหลังยุคสเปรดชีต

• เมื่อเทคโนโลยีคอมพิวเตอร์เข้าถึงได้มากขึ้นในทศวรรษ 1970–1980 ผู้คนก็สามารถสร้างตารางได้ทั้งในรูปแบบอิเล็กทรอนิกส์และสิ่งพิมพ์
• การแพร่หลายของตารางที่คำนวณได้อาจถือว่าเริ่มต้นพร้อมกับ VisiCalc ในปี 1979
• VisiCalc ช่วยคำนวณค่าได้รวดเร็ว แต่มีข้อจำกัดด้านการนำเสนอเมื่อใช้สร้างตารางสำหรับการเผยแพร่
  • ไม่สามารถกำหนดสไตล์เส้นขอบสำหรับการนำเสนอให้กับเซลล์กริดได้
  • ไม่สามารถจัดรูปแบบค่าได้
  • ไม่สามารถพิมพ์ตารางได้
• หลังจากนั้นอีก 10–15 ปี ตารางจากสเปรดชีตก็ดูดีขึ้น
  • ในช่วงต้นทศวรรษ 1990 Excel สามารถใส่เส้นขอบให้ตารางได้
  • การรองรับงานไทโปกราฟีดีขึ้น
  • ความสามารถด้านการจัดรูปแบบค่าก็ครบถ้วนขึ้น
• ถึงอย่างนั้น ตารางใน Excel ตลอด 30 ปีหลังมานี้ก็ยังถูกประเมินว่ายากจะไปถึงระดับของ Manual of Tabular Presentation
• เมื่อการวิเคราะห์ข้อมูลเกิดขึ้นนอก Excel ด้วย ก็เกิดสามสถานการณ์ที่ไม่มีประสิทธิภาพ
  • ทำทั้งการวิเคราะห์และการสร้างตารางใน Python แต่คุณภาพตารางต่ำ
  • ทำทั้งการวิเคราะห์และการสร้างตารางใน Excel แต่ความยืดหยุ่นในการวิเคราะห์ต่ำ
  • วิเคราะห์ใน Python แล้วคัดลอกไปทำตารางใน Excel แต่ไม่สามารถทำซ้ำได้

โมเดลตารางของ Great Tables

• Great Tables คือแพ็กเกจ Python ที่ต้องการผสานความสง่างามของตารางช่วงกลางศตวรรษที่ 20 เข้ากับพลังของอินเทอร์เฟซแบบโค้ด
• มันแทนตารางเป็นการผสมกันของ 6 องค์ประกอบอิสระ
  • Table Header: พื้นที่สำหรับใส่ชื่อเรื่องและคำบรรยายรองเพื่ออธิบายเนื้อหาของตารางอย่างกระชับ
  • Column Labels: นิยามเนื้อหาของแต่ละคอลัมน์ โดย spanner คือชื่อที่วางครอบอยู่เหนือกลุ่มคอลัมน์หลายคอลัมน์
  • Stub Head: ตำแหน่งซ้ายบนที่สามารถวางป้ายกำกับได้หลายรูปแบบ
  • Row Stub: พื้นที่สำหรับข้อมูลแถวและป้ายกำกับกลุ่มแถว
  • Table Body: พื้นที่ที่มีเซลล์และเป็นตำแหน่งของข้อมูล
  • Table Footer: พื้นที่สำหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับเนื้อหาของตาราง
• Great Tables ใช้งานโดยสร้างเนื้อหาหลักของตารางด้วยโค้ดก่อน แล้วจึงค่อย ๆ เพิ่มการตกแต่ง การจัดรูปแบบ และองค์ประกอบอื่นแบบวนซ้ำ
• โค้ดตัวอย่างเริ่มจาก GT(simple_table, rowname_col="Name") แล้วเพิ่มชื่อเรื่อง, stub head, column spanner, source note, การจัดรูปแบบวันที่และจำนวนเต็ม, และตัวเลือกสไตล์
• ในตารางตัวอย่าง row stub สีฟ้าช่วยแยกป้ายกำกับแถวออกจากเนื้อหาหลักของตาราง
  • เพราะแต่ละคนเป็นหน่วยสังเกตเฉพาะตัว จึงเน้นให้เห็นตัวตนของแถว
  • ชื่อเรื่องอธิบายว่าตารางมีข้อมูลอะไร
  • spanner อย่าง Location และ Personal Characteristics ช่วยจัดกลุ่มคอลัมน์ตามความหมาย
  • การใช้เส้นสีน้ำเงินและพื้นหลังเซลล์อย่างสม่ำเสมอทำให้เกิดรูปลักษณ์แบบมืออาชีพ
• เมธอดที่ใช้เพิ่มองค์ประกอบของตารางจะขึ้นต้นด้วย tab_
  • ตัวอย่าง: tab_header() ใช้สร้าง Table Header

การจัดรูปแบบและ nanoplots

• การจัดโครงสร้างตารางเพียงอย่างเดียวยังไม่เพียงพอ และแต่ละสาขาก็มีความต้องการในการแสดงค่าที่ต่างกัน
• แม้แต่ตัวเลขเพียงตัวเดียวก็อาจถูกแสดงได้หลายแบบตามบรรทัดฐานและความคาดหวังของชุมชนผู้ใช้
• เมื่อรวมวันที่ เวลา และสกุลเงิน ขอบเขตของการจัดรูปแบบก็ยิ่งกว้างขึ้น
• ค่าดิบ 134,000 อาจถูกแสดงแตกต่างกันไปตามความต้องการ
  • fmt_scientific(): รูปแบบวิทยาศาสตร์ 1.34 × 10^5
  • fmt_number(): ตัวเลขตามโลแคลเยอรมัน 134.000,00
  • fmt_integer(): จำนวนเต็มแบบย่อ 134K
• ปัญหาด้านการจัดรูปแบบจะยิ่งใหญ่ขึ้นเมื่อค่าต้องถูกสื่อสารผ่านภาพหรือพล็อต
• หากนักวิเคราะห์ทางการแพทย์ต้องการสื่อแนวโน้มการดีขึ้นหรือแย่ลงของผลตรวจผู้ป่วย การให้อ่านลำดับตัวเลขทั้งแถวอาจทำให้ตีความได้ช้าลง
• fmt_nanoplot() มอบการแสดงแนวโน้มขนาดเล็กภายในตารางผ่าน nanoplots
  • เมื่อเลื่อนเมาส์ไปเหนือจุดข้อมูล จะเห็นค่าของแต่ละวัน
  • nanoplots ตั้งเป้าสร้างสมดุลระหว่างการตีความเชิงภาพที่รวดเร็วแบบพล็อต กับความกะทัดรัดของตาราง
• เมธอดจัดรูปแบบของ Great Tables จะขึ้นต้นด้วย fmt_
  • ตัวอย่าง: fmt_date(), fmt_integer(), fmt_nanoplot()
• แพ็กเกจนี้พยายามมอบเมธอดการจัดรูปแบบจำนวนมากและตัวเลือกที่มีประโยชน์ เพื่อรองรับความต้องการของผู้ใช้ที่หลากหลาย

มุ่งเน้นที่ตารางสรุปแบบคงที่สำหรับการตีพิมพ์และการนำเสนอ

• Great Tables มุ่งเน้น การแสดงผลเพื่อการตีพิมพ์และการนำเสนอ ในบรรดาวิธีต่าง ๆ ของการโต้ตอบกับตาราง
• ในการวิเคราะห์ฐานข้อมูล การแสดงตารางแบบง่ายที่ใช้สำรวจและกรองเรกคอร์ดหลักร้อย หลักพัน หรือมากกว่านั้นอาจเหมาะสมกว่า
• แต่การเผยแพร่ผลลัพธ์เป็นอีกงานหนึ่ง ซึ่งมีการจัดโครงสร้าง การจัดรูปแบบ และการตกแต่งสไตล์เป็นหัวใจสำคัญ
• การแสดงตารางที่สวยงามควรตอบโจทย์ต่อไปนี้
  • ทำให้ข้อมูลย่อยง่ายขึ้น
  • ให้บริบทเพิ่มเติมในจุดที่จำเป็น
  • สอดคล้องกับสไตล์ของเอกสารหรือองค์กร
• กรณีใช้งานเป้าหมายคือการนำเสนอข้อมูลในลักษณะที่พบได้ในบทความวารสาร หนังสือ และรายงาน
• Great Tables มองว่าตารางสรุปแบบคงที่เป็นพื้นที่ที่ควรได้รับความสนใจเฉพาะทาง และต้องการทำให้การส่งมอบตารางที่ดีกว่าแก่ผู้อ่านเป็นเรื่องง่ายขึ้นผ่านเมธอด opt_*()
• เกณฑ์วัดความสำเร็จของแพ็กเกจนี้คือคุณภาพของตารางที่มันสร้างได้ และมีแผนจะพัฒนา API ต่อไป
• มี Discord Server เปิดไว้สำหรับรับฟังความคิดเห็นจากชุมชน

[GN⁺]

ความคิดเห็นจาก Hacker News

• Great Tables ทำงานได้ยอดเยี่ยมทีเดียวในฝั่งตารางของ Python/Jupyter และดูเหมือนกำลังสร้างสิ่งที่เกือบจะเป็น ไวยากรณ์ของตาราง คล้ายกับ grammar of graphics
  อยากให้มีโปรเจกต์อื่น ๆ อธิบายปรัชญาและเป้าหมายของตัวเองในลักษณะนี้มากขึ้น
  ฉันเคยทำไลบรารีตารางอีกตัวสำหรับ Jupyter ชื่อ Buckaroo แต่แนวทางต่างกัน
  Buckaroo มีเป้าหมายเพื่อช่วยให้ทำงานแบบโต้ตอบได้ โดยลองรูปแบบต่าง ๆ และฟังก์ชันหลังการประมวลผลได้อย่างรวดเร็ว เพื่อดึงอินไซต์สำคัญจากตาราง
  เวลาทำ exploratory data analysis ขั้นพื้นฐาน มักต้องพิมพ์คำสั่งเดิมซ้ำ ๆ เลยคิดว่าคำสั่งและอินไซต์เหล่านั้นควรอยู่ภายในตาราง
  ส่วน Great Tables ดูใกล้เคียงกับเครื่องมือที่สร้างมาเพื่อจัดรูปแบบตารางสำหรับการนำเสนอด้วยมือมากกว่า
  https://github.com/paddymul/buckaroo
  https://youtu.be/GPl6_9n31NE
  • ขอบคุณสำหรับงานที่ทำกับ Buckaroo ฉันเข้าใจว่ามันถูกสร้างขึ้นมาเพื่อแก้ข้อจำกัดของ print() ใน Jupyter และ display() ของ IPython ที่เป็นผลลัพธ์นิ่ง ๆ ตายตัว เหมือนกับการดีบักแบบ printf ในสมัยก่อน
    สงสัยว่าคุณมอง คีย์ลัดและวิธีใช้งานของ Visidata อย่างไร
    ฉันเคยใช้ Visidata มาก่อน และสงสัยมาตลอดว่าทำไมมันถึงเข้าไปอยู่ใน Jupyter ในฐานะเครื่องมือสำรวจ dataframe ไม่ได้ในท้ายที่สุด
    เห็นด้วยว่า Great Tables ดูเหมือนเป็นอีกความพยายามหนึ่งในการทำให้ ไวยากรณ์ของตาราง เป็นทางการมากขึ้น และเมื่อคิดถึงพลังของรูปแบบตารางกับการแพร่หลายของแนวคิด dataframe ผ่านระบบนิเวศ R/pandas/Arrow/polars วิธีแบบนี้ก็น่ายินดี
    แต่ฉันเข้าใจว่าคำนี้เดิมทีถูกใช้ครั้งแรกในภาษาเชิงสถิติ S ตั้งแต่ยุค 90
    [1] https://towardsdatascience.com/preventing-the-death-of-the-d...
• ตัวอย่างของ Great Tables ดูซับซ้อนเกินไปสำหรับรสนิยมของฉัน เส้นแนวนอนเหนือและใต้หัวเรื่องดูไม่จำเป็น และการจัดให้ตรงกับคอลัมน์แรกซึ่งเป็นป้ายชื่อแถวก็ไม่ค่อยดี
  ถ้าเว้นช่องว่างด้านล่างเล็กน้อยและใช้ตัวหนา ก็น่าจะสร้างลำดับชั้นทางสายตาได้โดยไม่เพิ่มสิ่งรบกวน
  พื้นหลังของป้ายชื่อแถวเข้มเกินไป และด้วยน้ำหนักฟอนต์แบบนั้นทำให้อ่านยาก ดังนั้นสีฟ้าอ่อนมากน่าจะดีกว่า
  ฉันก็ไม่ชอบที่ทำป้ายชื่อกลุ่มแถวอย่าง “Name” เป็นตัวเอียง
  ป้ายชื่อคอลัมน์ระดับบนสุด ที่ลอยอยู่ตรงกลางทำให้ไล่อ่านตารางได้ยากขึ้น คิดว่าจัดชิดซ้ายน่าจะดีกว่ามาก
  สุดท้ายฉันก็ไม่ชอบฟอนต์เอามาก ๆ แต่อันนี้อาจเป็นเพราะเบราว์เซอร์
  ฉันทำม็อกอัปที่สะท้อนการเปลี่ยนแปลงบางอย่างไว้ และคิดว่าฝั่งนี้เป็นตารางที่อ่านง่ายกว่ามาก
  https://i.imgur.com/iMMf5vo.png
  • คุณน่าจะลองอ่าน Beautiful Evidence ของ Edward Tufte
    หนังสือพูดถึงเรื่องที่คุณเพิ่งกล่าวถึงทั้งหมด เช่น ความอ่านง่าย และองค์ประกอบที่รบกวนสารหรือประเด็นหลักของข้อมูล
    ถ้าคุณเคยเห็น sparklines มาก่อน คนที่บัญญัติคำนี้ก็คือ Tufte
    ทุกครั้งที่รีวิว UI ฉันมักหยิบหนังสือเล่มนี้มาเปิดดูเพื่อเช็กว่าเราพลาดอะไรไปหรือไม่ และเป็นหนังสือที่เปิดหน้าไหนมาอ่านก็ยังน่าสนใจ
    แถมยังมีบทความยาวว่าทำไม PowerPoint ถึงแย่อีกด้วย
    [1] https://www.edwardtufte.com/tufte/books_be
    [2] https://en.wikipedia.org/wiki/Sparkline
  • ชื่อตารางควรจัดกึ่งกลางด้านบน หรือไม่ก็เป็นคำบรรยายด้านล่าง
    ถ้าจัดชิดซ้ายไว้เหนือคอลัมน์ใดคอลัมน์หนึ่ง โดยมากมันจะทำให้ชื่อนั้นดูเหมือนเป็นลำดับชั้นข้อมูลสูงสุดของตาราง ทั้งที่ไม่จริงหรือไม่ได้ตั้งใจ
    ในข้อเสนอแก้ไขแบบสมัยใหม่ด้านบน หัวข้อเขียนว่า “names, addresses, characteristics” แต่จากการจัดแนวกลับเหมือนตัดชื่อออกไป จึงทำให้รู้สึกขัดทันที
    ในทางกลับกัน คู่มือสำมะโนประชากร จะจัดป้ายชื่อเกือบทั้งหมดให้อยู่กึ่งกลางภายในกรอบที่เกี่ยวข้อง และถ้าไม่ทำเช่นนั้นก็มักใช้การเยื้อง
    นอกจากนี้ยังตัดสินความกว้างคอลัมน์จากข้อมูล ไม่ใช่จากป้ายชื่อ และไม่ลังเลที่จะปรับการเยื้องกับการตัดคำด้วยยัติภังค์ให้สอดคล้องกัน
    ผลลัพธ์คือได้ตารางที่กระชับในแนวนอนแต่ยังเข้าใจได้โดยสัญชาตญาณ
    พอคิดดูอีกที ตัวหัวข้อเองก็ไม่ค่อยดีด้วย
    หัวข้อและคำบรรยายควรสื่อบริบท ขอบเขต และจุดประสงค์ และถ้าทำไม่ได้ ก็ควรถูกตัดออกไปเลยในฐานะความผิดพลาดทางบรรณาธิการที่ไม่อาจให้เหตุผลการมีอยู่ของมันได้
    หัวข้อปัจจุบันนี้สามารถเปลี่ยนเป็น “Table 1” ได้โดยไม่เสียข้อมูลหรือความทั่วไปใด ๆ
    สำหรับบทความที่ตั้งใจจะอภิปรายและสร้างการแสดงตารางขึ้นใหม่จากหลักการพื้นฐาน ถือว่าน่าผิดหวังเล็กน้อย
    เนื่องจากหัวข้อตารางเป็นชั้นสำคัญของแค็ตตาล็อกข้อมูล จึงไม่น่าแปลกใจที่คู่มือสำมะโนประชากรจะอุทิศทั้งบทให้กับการประกอบหัวข้อ
    แม้จะค่อนข้างเฉพาะทางและใช้สำนวนโบราณ แต่ก็คุ้มค่าแก่การดู
  • ฉันไม่เข้าใจว่าทำไมถึงไม่มีสิ่งอย่าง เส้นคั่นแนวนอนหรือลายสลับแถว เพื่อเสริมความรู้สึกว่าแต่ละแถวเป็นเรคอร์ดของตัวเอง
  • ม็อกอัปของคุณเป็นเวอร์ชันที่ดีกว่า ตัวอย่างในบทความมีปัญหาตรงที่ น้ำหนักทางสายตา ของตัวอักษรและตัวเลขทุกอย่างในตารางสม่ำเสมอกันไปหมด
  • ฉันคิดว่าน่าจะผลักไปได้อีก หัวข้อย่อเหลือแค่ “remote correspondents” ก็พอ เพราะส่วนที่เหลือซ้ำกับชื่อคอลัมน์อยู่แล้ว
    ส่วนการเน้นสีน้ำเงินตอนนี้ก็ซ้ำกับหัวข้อเช่นกัน จึงควรถอดออกทั้งหมด และการแยก “personal characteristics” กับ “location” ก็ไม่ได้ช่วยด้านการจัดระเบียบอย่างมีนัยสำคัญ ควรเอาออกดีกว่า
• เป็นบทความที่ดีและน่าสนใจในแง่ประวัติศาสตร์
  ถ้าพูดถึงประวัติศาสตร์ที่ใหม่ขึ้นมาหน่อย ก็มีการสร้าง CALS tables: https://en.wikipedia.org/wiki/CALS_Table_Model
  Datalogics https://en.wikipedia.org/wiki/Datalogics มีส่วนร่วมอย่างลึกซึ้งกับแนวคิดของ CALS tables

พนักงานของ Datalogics เคยมีส่วนร่วมในคณะกรรมการ ISO ที่จัดทำ SGML และได้สอน SGML ให้กับผู้คนจำนวนมาก รวมถึงเจ้าหน้าที่และผู้รับเหมาของกระทรวงกลาโหมสหรัฐที่เกี่ยวข้องกับงานเอกสาร
เคยร่วมทีมที่สร้างโปรแกรมแก้ไขเอกสารบนพื้นฐาน SGML โดยหนึ่งในความสามารถของมันคือการกำหนดรูปแบบองค์ประกอบตาม บริบท SGML ขององค์ประกอบนั้น
เรื่องนี้เกิดขึ้นก่อนที่ XSLT และเทคโนโลยีตระกูลเดียวกันจะถือกำเนิด
คนที่มาจาก Datalogics ยังช่วยให้ Microsoft เข้าใจ XML ด้วย เช่น “ไม่ครับ คุณเปลี่ยนตัวพิมพ์เล็ก-ใหญ่ของแท็กองค์ประกอบ XML ตามใจไม่ได้”
ผู้ใช้ TeX เองก็มีแนวคิดที่ค่อนข้างซับซ้อนเรื่องการจัดรูปแบบตาราง
เกร็ดแปลกอย่างหนึ่งคือ เคยได้ยินมาว่าในยุคนั้น ถ้าพิมพ์เอกสารของเครื่องบินขับไล่รุ่นหนึ่งออกมาทั้งหมด จะมีน้ำหนักมากกว่าตัวเครื่องบินเสียอีก และมากพอจะเติมตู้เอกสารขนาดเท่าสนามฟุตบอลได้
และแม้ทุกวันนี้หลายคนจะไม่ชอบ XML แต่ถ้ามองจากโลกของ SGML แล้ว XML ถือเป็นพรอย่างมาก

• มีการบอกเกี่ยวกับ Visicalc ว่า “เซลล์ในกริดไม่สามารถใส่สไตล์เส้นขอบสำหรับงานนำเสนอได้ ค่าไม่สามารถจัดรูปแบบได้ และตารางก็พิมพ์ออกมาไม่ได้เลย” แต่ดูเหมือนจะไม่ถูกทั้งหมด
  จำได้ว่าแม้ในเวอร์ชันแรกก็มี การรองรับการจัดรูปแบบ แบบจำกัดอยู่แล้ว
  ตาม http://www.bricklin.com/history/refcard3.htm คำสั่ง /F ใช้กำหนดการจัดแนวและกำหนดรูปแบบตัวเลขได้ เช่น ดอลลาร์และเซนต์
  เอกสารนี้อ้างอิงเวอร์ชัน 1.35 แต่แม้เวอร์ชันเปิดตัวแรกก็น่าจะรองรับอย่างน้อยการแสดงดอลลาร์และเซนต์
• สิ่งที่รบกวนใจมาโดยตลอดใน ข้อมูลตัวเลข อย่างจำนวนเงินในตาราง คือเวลามองด้วยตา การเปรียบเทียบขนาดดูไม่เป็นเส้นตรงแต่เหมือนเป็นลอการิทึม
  ตัวอย่างเช่น ถ้าค่าใช้จ่ายเป็น $1500, $130, $110, $210 ข้อความของสามแถวหลังจะดูเหมือนมีขนาดประมาณ 4/5 ของข้อความแถวแรก
  แต่รวมกันทั้งสามแถวก็ยังมีค่าไม่ถึง 1/3 ของจำนวนเงินบนสุด
  คนเรามองเห็นจำนวนหลักของตัวเลข ซึ่งใกล้เคียงกับ log10 โดยคร่าวๆ
  ปัญหานี้เกิดขึ้นบ่อยมาก จนเริ่มใส่ กราฟแท่งในเซลล์ ลงไปทุกครั้งในสเปรดชีตการเงิน
  ไม่อย่างนั้นการประชุมจะหลุดประเด็นไปเถียงกันเรื่องรายการที่เล็กน้อยมาก เมื่อเทียบกับค่าใช้จ่ายที่มากที่สุดในเชิงมูลค่าสัมบูรณ์
  เคยเสียเวลาหลายการประชุมไปกับค่าเก็บล็อกเซิร์ฟเวอร์คลาวด์เดือนละ $15 ทั้งที่ VM นั้นรันอยู่บนฐานข้อมูลเอนจินที่มีค่าไลเซนส์เดือนละ $15K
• ฉันเป็นหนึ่งในผู้ดูแลร่วมของ Great Tables
  ดูแลร่วมกับ Rich Iannone
  ถ้าจะหานักพัฒนาซอฟต์แวร์ที่เมื่อถูกขอให้อธิบายปรัชญาของแพ็กเกจแล้วเล่าเรื่อง ประวัติศาสตร์ 5,000 ปีของการแสดงตาราง ให้ฟังได้ ฉันรู้จักแค่ Rich
• เจ๋งมาก ขอบคุณที่แชร์
  น่าทึ่งที่เราปล่อยให้ การนำเสนอตารางข้อมูล แย่ลงเรื่อยๆ อยู่นานขนาดนี้
  ตารางสมัยใหม่ช่วงกลางศตวรรษที่ 20 ที่บทความชี้ให้เห็น ดูเป็นตัวอย่างที่โดดเด่นจริงๆ
  ทำให้อยากกลับไปทำ data analysis ด้วย Python อีกครั้ง และนึกถึงการปรับปรุงกับการขยาย API หลายอย่างที่อยากสร้าง
• ชอบแพ็กเกจนี้มากและใช้ใน R มาหลายปีแล้ว
  มันยอดเยี่ยมสำหรับการสร้างตาราง HTML แต่ การส่งออกเป็น PDF และ DOCX ยังเก็บรายละเอียดได้ไม่เนี้ยบเท่าไร
  ช่วงหลังดูเหมือนทิศทางจะย้ายไปที่การยกระดับเวอร์ชัน Python ให้ทัดเทียมกับเวอร์ชัน R เลยกังวลว่างานพัฒนาในฝั่ง R จะช้าลง
  แต่ไม่ว่าจะใช้ภาษาไหนก็ควรลองดู
• ยอดเยี่ยมมาก ในยุค 90 ฉันกับเพื่อนร่วมงานเคยเขียน EBRI Datebook on Employee Benefits ซึ่งหนังสือส่วนใหญ่เป็นตาราง
  นอกจาก SAS แล้ว เครื่องมือหลักคือภาษาเก่าชื่อ Table Producing Language หรือ TPL
  มันย้อนกลับไปได้ถึงยุค 1970 แต่พอเข้าใจไวยากรณ์แล้ว TPL ก็ยืดหยุ่น มีพลังในการแสดงออก และมีประสิทธิภาพอย่างน่าเหลือเชื่อ
  ผู้ออกแบบ Great Tables น่าจะลองดู TPL
  มันครอบคลุมทุกอย่างที่ Great Tables ตั้งเป้าไว้ และอาจมีลูกเล่นมากกว่านั้นอีกเล็กน้อย
  https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
  อย่างไรก็แล้วแต่ ขอบคุณที่สร้าง Great Tables ขึ้นมา
  มันช่วยยกระดับคุณภาพการสร้างตารางใน Python ได้มาก
• คนนี้ควรได้รางวัล 1) งานยอดเยี่ยม 2) ใส่ใจรายละเอียด 3) ค้นคว้าลึก และ 4) วิธีการนำเสนอที่ยอดเยี่ยม ซึ่งช่วยเลี่ยงคำถามพื้นฐานที่พบบ่อยอย่าง “แล้วนี่มันคืออะไรกันแน่?”, “จะเริ่มยังไง?”, “มีตัวอย่างไหม?”
  คนที่โพสต์ใน Show HN ควรเอาเป็นแบบอย่าง
• มีหนังสือเกี่ยวกับหัวข้อนี้ด้วย: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
  เกร็ดที่น่าสนใจคือ โมเดล AI ที่เรียนจากสเปรดชีตต้องการ “ตารางที่ดี” เช่น ชื่อคอลัมน์และหัวตาราง เพื่อทำความเข้าใจบริบท
  Fortap เป็นตัวอย่างหนึ่ง: https://arxiv.org/abs/2109.07323