ทำไมเว็บไซต์ของเราถึงดูเหมือนระบบปฏิบัติการ

• เว็บไซต์ เทคโนโลยีขนาดใหญ่ จำนวนมากมักเจอ ปัญหาแท็บล้น เมื่อต้องเปิดหลายหน้าพร้อมกันเพื่ออ้างอิง
• PostHog.com เองก็เผชิญ ปัญหาคล้ายกัน และได้นำ UI สไตล์ระบบปฏิบัติการ มาใช้เพื่อแก้ปัญหานี้
• โครงสร้างใหม่นี้รองรับฟังก์ชันการโต้ตอบหลากหลาย เช่น มัลติทาสกิง, การจัดหน้าต่างแบบ snap, คีย์ลัด
• มีการนำแนวคิดทางเทคนิคมาใช้ เช่น ลำดับชั้นการมองเห็นและการแยกคอนเทนต์, การจัดการคอนเทนต์ด้วย JSON, และฐานข้อมูลลูกค้า
• แม้ช่วงแรกจะรู้สึกแปลกใหม่ แต่ทั้งประสบการณ์การพัฒนาและการใช้งานดีขึ้นในทางบวก พร้อมได้ความยืดหยุ่นและการขยายระบบที่มากขึ้น

---

จุดตั้งต้นของปัญหา: แท็บล้นในเว็บไซต์เทคนิค

• ในเว็บไซต์เทคนิคขนาดใหญ่หลายแห่ง เมื่อพยายามอ้างอิงหลายหน้าพร้อมกัน ก็มักจะใช้ CMD + คลิก เพื่อเปิดแท็บใหม่จำนวนมาก
• ด้วย favicon ที่เหมือนกันและดีไซน์ที่คล้ายกัน จึงแยกแต่ละแท็บได้ยาก
• PostHog.com ก็เริ่มเจอ ปัญหาเดียวกัน เมื่อบริการเติบโตขึ้น และเมื่อมีการรองรับผลิตภัณฑ์แบบเสียเงินมากขึ้นรวมถึงจำนวนหน้าเพิ่มขึ้น ปัญหาการแยกความต่างก็ยิ่งรุนแรงขึ้น

การสำรวจทางเลือกและนวัตกรรมด้าน UI

• เกิดคำถามกับ อินเทอร์เฟซที่เน้นการเลื่อน ของเว็บไซต์การตลาดและเอกสารแบบเดิม ๆ รวมถึง footer ขนาดใหญ่และพื้นที่ว่างที่มากเกินไป
• ตระหนักว่าจำเป็นต้องมี วิธีบริโภคคอนเทนต์ ที่ดีกว่าการบังคับให้เลื่อนแบบไร้ความหมาย
• เพื่อแก้ปัญหานี้ PostHog.com เวอร์ชันใหม่จึงถูกออกแบบให้รองรับ มัลติทาสกิง, การเปิดอ่านหลายบทความพร้อมกัน และการเคลื่อนย้ายบนหน้าจอได้อย่างอิสระ

เว็บไซต์ที่ทำงานเหมือนระบบปฏิบัติการ

• UI ใหม่นี้มีฟังก์ชันอย่าง การจัดหน้าต่างแบบ snap, คีย์ลัด, แอปบุ๊กมาร์ก
• มอบประสบการณ์คล้ายระบบปฏิบัติการภายในเบราว์เซอร์ ที่ให้ทำหลายงานพร้อมกันได้
• ตัวอย่างเช่น สามารถเปิดดูจดหมายข่าวสำหรับวิศวกร, ดูวิดีโอเดโม และเล่นเกม (โหมด Hedgehog) ไปพร้อมกันได้

การปรับตัวช่วงแรกและเสียงตอบรับจากผู้ใช้

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

กระบวนการสร้างและไฮไลต์ทางเทคนิค

• ทีมได้ออกแบบและพัฒนา UI รวมถึงสร้างเว็บไซต์ร่วมกับ Eli Kinsey โดยใช้ Typescript และ Tailwind
• ระหว่างคิดหาวิธี จัดระเบียบคอนเทนต์ตลอด 5 ปีให้ขยายต่อได้ ก็ได้ทดลองแนวทางเทคนิคหลายรูปแบบ

ประเด็นเทคนิคสำคัญ

• การแยกลำดับชั้นการมองเห็นและคอนเทนต์

  • ทุกหน้าของผลิตภัณฑ์ถูกเรนเดอร์บนพื้นฐานของ ไฟล์ JSON
  • JSON ควบคุมทั้งเลย์เอาต์ของหน้า, การจัดลำดับคอนเทนต์, การเปรียบเทียบกับคู่แข่งในแต่ละฟีเจอร์, และภาพหน้าจอธีมต่าง ๆ (โหมดสว่าง/โหมดมืด) โดยตรง
  • ในระยะยาวมีแผนย้ายโครงสร้างนี้ไปยัง repository ที่ใช้ร่วมกับแอป PostHog เพื่อให้เป็นแหล่งข้อมูลเดียว

• ธีมและการสกินสี

  • มีการคงทั้งโหมดสว่างและโหมดมืดไว้ พร้อมพิจารณาวิธีใช้ธีมหลากหลายอย่างกลมกลืน เช่น สีหลัก/สีรอง/สีลำดับที่สาม
  • ตั้งใจจะแชร์ประสบการณ์ส่วนนี้แยกเป็นบทความอีกชิ้นในภายหลัง

• ฐานข้อมูลลูกค้าอ้างอิง

  • มีการกำหนดระเบียนลูกค้าเดี่ยวไว้ในโค้ด เพื่อเก็บข้อมูลการใช้งานแยกตามผลิตภัณฑ์, คำพูดอ้างอิงจากลูกค้า, และโลโก้ SVG (รองรับโหมดสว่าง/โหมดมืด)
  • ทำให้แต่ละหน้าสามารถดึงคำพูด ชื่อ รูปภาพ และโลโก้บริษัทที่เกี่ยวข้องกับผลิตภัณฑ์ต่างกันได้โดยอัตโนมัติ จึงมีความยืดหยุ่นมากขึ้น

วิธีพัฒนาและการทำต้นแบบ

• สร้าง UI ด้วย Typescript และ Tailwind โดยดำเนิน การออกแบบเว็บไซต์และการพัฒนาไปพร้อมกัน
• เลือกวิธีทำต้นแบบภายในสภาพแวดล้อม production เพื่อให้คิดไอเดียใหม่และขยายฟีเจอร์ได้ง่าย
• เมื่อจำเป็นก็ใช้เครื่องมือทำ mockup ภายนอกอย่าง Balsamiq ควบคู่กันเพื่อทำให้คอนเซปต์ชัดเจนขึ้น

บทสรุปและทิศทางการปรับปรุงในอนาคต

• ปัจจุบันยังอยู่ในช่วงต้นระดับ MVP และยังมีจุดที่ต้องปรับปรุงอีกมาก
• คาดหวังให้ผู้ใช้สนุกกับ UX ใหม่ของ PostHog.com และเพลิดเพลินกับการสำรวจเว็บไซต์ไปพร้อมกัน
• เอกสารเชิงเทคนิคเกี่ยวกับหลักการทำงานของเว็บไซต์จะมีการเผยแพร่แยกต่างหาก

[GN⁺]

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

• สำหรับคำถามว่าทำไมมันถึงดูมีเสน่ห์ผิดปกติเมื่อเทียบกับงานออกแบบเดิม ๆ แบบนี้ ผมคิดว่านักจิตวิทยา นักวิทยาศาสตร์ด้านการรับรู้ หรือไม่ก็นักประสาทวิทยาน่าจะตอบได้ดีกว่า และน่าจะต้องมีงานวิจัยที่ลึกกว่าบล็อกโพสต์ที่วงการซอฟต์แวร์รีบ ๆ เขียนกันอยู่ตอนนี้
  ส่วนตัวมีอยู่เรื่องหนึ่งที่พอพูดจากประสบการณ์ได้ ผมเคยทำงานที่บริษัทซึ่งสร้างเว็บไซต์และวางกลยุทธ์ให้ผลิตภัณฑ์ SaaS ขนาดใหญ่ และผมเองก็เป็นกลุ่มเป้าหมายของเว็บแบบนี้ด้วย (เช่น Engineering Director หรือ VP)
  ในมุมของลูกค้าที่อาจสนใจ ความเร็วและความสะดวกในการค้นหาข้อมูลที่ต้องการนั้นเหนือกว่าสิ่งที่ผมเคยเห็นมาอย่างชัดเจน
  ตัวอย่างเช่น มองแวบเดียวก็รู้ได้ทันทีว่ามี 34 ผลิตภัณฑ์อยู่ใต้ 7 หมวดหมู่ และเห็นได้ทันทีว่ามี 5 ตัวที่ได้รับความนิยมกับอีก 4 ตัวที่เพิ่งมาใหม่
  ถ้าอยากลองใช้ผลิตภัณฑ์: Docs > Product OS > Integration > Install and configure > Install PostHog
  ถ้าอยากรู้เรื่องวัฒนธรรมวิศวกรรม: Company > Handbook > Engineering > Internal Processes > Bug prioritization
  ถ้าอยากดูราคา: Pricing calculator > เลือกผลิตภัณฑ์ > ตั้งค่าปริมาณการใช้งาน แล้วเลือก add-on
  ปฏิสัมพันธ์ทั้งหมดนี้เกิดขึ้นได้ภายในไม่กี่วินาที และยังสลับไปมาระหว่างหน้าภาพรวมที่เปิดค้างไว้กับหน้าราคาที่เพิ่งเปิดใหม่ได้ทันทีโดยไม่ต้องรีโหลดทั้งเว็บไซต์ ไม่ต้องเปิดแท็บใหม่หรือเลื่อนหน้าจอให้เสียเวลา
  เพราะงั้นผมเลยคิดว่ามันมีอะไรบางอย่างที่เป็นแก่นสำคัญมากกว่าแค่เรื่องความสวยงาม และอาจสรุปได้ด้วยซ้ำว่าปรัชญา UI/UX ในปัจจุบันกลับกลายเป็นไม่เป็นมิตรต่อผู้ใช้ไปแล้วหรือเปล่า

  • ผมจำได้ว่า Cory กับ Eli (วิศวกรฟรอนต์เอนด์) เคยคุยกันเรื่องการออกแบบเว็บไซต์ในประเด็นว่า “ทำไมทุกเว็บถึงเป็นหน้าเดียวที่ยาวและต้องเลื่อนเยอะกันหมด แบบนี้เหมาะกับธุรกิจเราจริงหรือ?”
    เพราะเรามีทั้งผลิตภัณฑ์จำนวนมากและคอนเทนต์ที่กว้างมาก (ผลิตภัณฑ์มากกว่า 10 ตัว, handbook, jobs, newsletter ฯลฯ) เราเลยสรุปว่าโครงสร้างแบบแบนที่เหมาะกับบริษัทที่มีผลิตภัณฑ์เดียวไม่เหมาะกับเรา
    เว็บไซต์ส่วนใหญ่พยายามจะสื่อทุกอย่างเกี่ยวกับตัวเองให้ครบภายใน 3 วินาที แต่บริษัทเรามีหลายมิติเกินกว่าจะยัดใส่บทแนะนำ 3 วินาทีได้ เราเลยตั้งใจทำโครงสร้างให้คนสำรวจเว็บและทำความเข้าใจเนื้อหาได้ลึกขึ้น
    เพราะเหตุนี้ผู้เข้าชมบางส่วนอาจออกไปเร็ว แต่คนที่อยู่ต่อ (บางครั้ง!) จะชอบ UX แบบนี้มากจริง ๆ
    ตัวโปรเจกต์เองก็สนุกด้วย และเราอยากลองทำอะไรที่ทำให้โดดเด่นแบบพิเศษได้
    มันเจ๋งกว่าและคุ้มค่ากว่าการทำ outbound sales แบบดั้งเดิมมาก
    เรากำลังดำเนินงานด้วยระยะเวลาคืนทุน CAC 3 เดือนในฐานะตัวชี้วัดของสตาร์ตอัป
    แต่กลยุทธ์แบบนี้จะเวิร์กจริงได้ก็ต่อเมื่อมีเงื่อนไขว่าต้องทำให้ “ลึก” จริง ๆ ถึงจะติดอยู่ในความทรงจำของผู้คน

  • ไม่คิดเลยว่าจะเห็นมุมมองแบบนี้บน HN
    ปกติบน HN มักมีทัศนคติครอบงำว่าใช้ JavaScript เยอะคือการออกแบบที่แย่ ใช้งานไม่ได้ และพกพาไม่ดี
    กรณีนี้พูดได้ว่าเป็นเวอร์ชันสุดทางของ JavaScript เลย

  • การที่ค้นหาข้อมูลที่ต้องการได้เร็วและง่าย ทำให้รู้สึกเหมือนเว็บย้อนกลับไปสู่การออกแบบแบบเน้นเมนูในอดีตจริง ๆ
    UI ยุคใหม่มักขายความเรียบง่ายและ “ประสบการณ์ที่เพลิดเพลิน” แต่ก็ยากจะสู้ประสิทธิภาพของแถบเมนูที่จัดมาดี ๆ ได้

  • ควรระวังในการเหมารวมความรู้สึกสบายจากอินเทอร์เฟซแบบนี้
    เมื่อเทียบกับ CLI หรือ command palette แล้ว UI นี้ให้ความรู้สึกหนักและล้าในเชิงการรับรู้

  • ถ้าผมจำไม่ผิด บริษัทนี้เอาคอนเทนต์ทั้งหมดเข้า CMS เดียวกัน โดยเฉพาะการรวม discussion/help forum เข้าไว้กับเว็บหลัก
    จากประสบการณ์ที่เคยทำโปรเจกต์คล้ายกันมา ผมรู้สึกว่าคอนเทนต์ทั้งหมดบนหน้าแรกอยู่ภายใต้การนำและการควบคุมขององค์กรเดียวกัน ไม่มีร่องรอยของการแย่งพื้นที่กันระหว่างแผนกหรือการโยนลิงก์ไปหลายซับโดเมนแบบรก ๆ
    ผมคิดว่าเว็บแบบนี้จะทำได้ก็ต่อเมื่อมีระบบรวมคอนเทนต์ (CMS) อยู่ที่ฝั่งแบ็กเอนด์
    และในระดับองค์กรก็ต้องต่อต้านแรงโน้มเอียงไปสู่การกระจายอำนาจอย่างหนักด้วย (เช่น VP แต่ละคนดูแลอาณาเขตของตัวเอง) ถึงจะรักษาโครงสร้าง CMS แบบนี้ไว้ได้

• PostHog.com บอกว่าใช้เพียงคุกกี้ภายในตัวเดียวโดยไม่มี third-party cookie
  ตามกฎหมาย ถ้าคุกกี้นั้นไม่ได้จำเป็นต่อฟังก์ชันหลักของเว็บไซต์ ก็ต้องมีตัวเลือกให้ opt out (ปฏิเสธ)
  แต่ถ้าจำเป็นต่อฟังก์ชันหลักจริง ก็ไม่จำเป็นต้องมีแบนเนอร์เลย

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

  • ผมว่าหลักเกณฑ์ว่าเมื่อไรต้องมีแบนเนอร์คุกกี้น่าจะง่ายกว่านี้
    ถ้าไม่ได้ใช้คุกกี้เพื่อการติดตาม ก็ไม่ควรต้องมีแบนเนอร์
    ตัวอย่างเช่น คุกกี้ที่จำลำดับการ sort ซึ่งไม่ได้มีไว้เพื่อติดตาม ผมคิดว่าไม่ควรต้องมีแบนเนอร์
    สุดท้ายประเด็นสำคัญไม่ใช่ “คุกกี้” แต่คือ “การติดตาม”

  • อยากรู้ว่ามีประเทศไหนที่บังคับแบนเนอร์คุกกี้สำหรับคุกกี้ทุกประเภทบ้าง
    EU บังคับเฉพาะคุกกี้สำหรับการติดตามเท่านั้น และ PostHog ก็ไม่ได้ระบุจุดประสงค์นั้น
    ผมเองก็เคยใส่ไว้ทั้งที่จริง ๆ ไม่มีคุกกี้ เพียงเพราะคิดว่า “คงจำเป็นแหละ”
    ความเชื่อที่ว่าทุกเว็บไซต์ต้องมีแบนเนอร์คุกกี้ อาจเป็นอันตรายยิ่งกว่าตัวแบนเนอร์เสียอีก

  • มีระบบล็อกอินอยู่แล้ว จึงมีโอกาสสูงที่คุกกี้ภายในจะเก็บข้อมูลล็อกอินไว้ (เช่น JWT)
    ในกรณีนี้คุกกี้ถือเป็นคุกกี้สำหรับฟังก์ชันหลัก จึงไม่ต้องมีแบนเนอร์
    พูดอีกอย่างคือ ไม่ได้จำเป็นตามกฎหมาย แต่พอไม่มีแบนเนอร์ก็อาจมีคนถามว่า “ทำไมไม่มีแบนเนอร์คุกกี้?” เลยใส่ไว้เฉย ๆ
    สรุปคือไม่มีภาระตามกฎหมายจริง ๆ มีแค่ความจำเป็นในเชิงธรรมเนียมหรือการรับรู้เท่านั้น

  • ตอนนี้ก็ปี 2025 แล้ว ยังสงสัยว่าทำไมคนถึงยังอยากเห็นคุกกี้ด้วยตาตัวเองแล้วค่อยกดปฏิเสธ
    ผมคิดว่าให้เบราว์เซอร์จัดการอัตโนมัติก็น่าจะพอแล้วไม่ใช่หรือ

• หน้า https://posthog.com/404 เป็นการล้อเลียน Blue Screen of Death

• เมื่อก่อนผมคิดมาตลอดว่า 'multiple document interface (MDI)' เป็น anti-pattern
  ทั้งที่มี window manager ที่สมบูรณ์อยู่แล้ว ทำไมแต่ละแอปยังต้องมีเครื่องมือจัดการหน้าต่างในตัวเองอีก?
  แน่นอนว่าบนมือถือไม่มี window manager ระดับระบบปฏิบัติการแบบนั้น ก็เลยเป็นข้อยกเว้น

  • บางแอป (เช่น image editor) จำเป็นต้องมีหลายหน้าต่างภายในแอป
    แต่การทำ MDI แบบทั่วไปแทบทั้งหมด (Win32, Qt) มินิมอลเกินไปจนชวนผิดหวัง
    ใน Krita ผมอยากเปิดหลายหน้าต่าง แต่ MDI ของ Qt แย่ยิ่งกว่า Windows 95 อีก

  • ถ้าเทียบกับแอปอย่าง Gimp ผมกลับชอบโครงสร้างที่ทุกอย่างอยู่ในหน้าต่างเดียวมากกว่า
    พอเปิดแอปพร้อมกันสองสามตัว การหาแต่ละหน้าต่างก็เหมือนเล่นซ่อนหา
    ผมไม่ชอบจริง ๆ เวลาทูลบาร์ถูกแยกเป็นหน้าต่างต่างหาก

  • ในฐานะคนที่ใช้ Mac มานาน ผมรู้สึกว่า MDI เป็นเพียงทางแก้ชั่วคราวที่เกิดจากการที่ OS ขาดความสามารถในการจัดการหน้าต่างในระดับแอปพลิเคชัน
    Photoshop สมัยก่อนบน Mac เปิดหน้าต่างกับพาเลตได้อิสระ แต่พอราว ๆ CS4 มีการนำ MDI แบบนี้เข้ามา จู่ ๆ ก็อึดอัดขึ้นมากจนผมปิดมันทิ้งตลอด
    อย่างน้อยบน Mac มันให้ความรู้สึกแปลกและอึดอัดมาก

  • คำสั่งส่วนใหญ่ใน Unix ต่างก็มีรูปแบบ output เป็นของตัวเอง (คอลัมน์, ตาราง, รายการ, ไฟล์, TTY ฯลฯ)
    abstraction ของ UNIX สุดท้ายก็ยังเป็นโครงสร้างที่ยึด “ข้อความ” เป็นศูนย์กลาง
    แต่เพราะ ecosystem มันหลากหลายมาก แต่ละเครื่องมือก็เลยมีความต้องการต่างกัน
    ถ้ามี abstraction ที่เหมาะกว่าข้อความจริง ๆ ก็คงถูกคิดค้นขึ้นมาแล้ว แต่สุดท้ายทุกอย่างก็ยังเป็น text pipeline อยู่ดี

  • พวก window manager ของ OS ดูเหมือนจะจัดการหลายหน้าต่างเล็ก ๆ บนหน้าจอเดียวได้ไม่ค่อยมีประสิทธิภาพ
    ในทางกลับกัน เครื่องมือจัดการหน้าต่างแบบกำหนดเองของซอฟต์แวร์สายอาร์ตหรือ CAD หลายตัวกลับถูกปรับให้ใช้พื้นที่ได้คุ้มกว่าด้วย title bar ขนาดเล็ก

• ผมคิดว่านี่แทบจะเป็นโปรเจกต์ที่สมบูรณ์แบบและสร้างแรงบันดาลใจมาก
  ถ้าลากในพื้นที่ว่างแบบเดสก์ท็อป OS จริง ๆ แล้วมีกรอบสี่เหลี่ยมขึ้นมาให้ขยับได้จะยิ่งดี
  ผมเลยลองเขียน code snippet ที่ทำแบบนั้นได้ขึ้นมาเอง ใครอยากลองก็วางลงในคอนโซลแล้วสัมผัสความฝันให้เป็นจริงได้เลย
  (โค้ด: JS ที่แสดง selection rect บนหน้าจอจากการลากเมาส์ และพิมพ์ผลลัพธ์ลงคอนโซล)

• ทั้งไอเดียและการทำออกมาน่าประทับใจ แต่พูดตรง ๆ คือผมไม่ต้องการแบบนี้
  มันทำให้ต้องเรียนรู้ UI/UX ใหม่ และยังต้องมาจัดการหน้าต่างซ้อนหน้าต่างอีก
  ผมคิดว่าเว็บไซต์ไม่จำเป็นต้องมีอินเทอร์เฟซหวือหวา แค่เป็นบล็อกข้อความธรรมดาก็พอแล้ว

  • เห็นด้วยมาก
    ผมตั้งค่าระบบปฏิบัติการของตัวเองไว้ให้จัดการหน้าต่างได้สมบูรณ์อยู่แล้ว

  • ถ้าลองจินตนาการว่าต้องเอาคอนเทนต์ทั้งหมดของหน้านี้ไปรวมเป็นข้อความก้อนเดียว มันคงยาวมหาศาลจริง ๆ

• อธิบายเป็นคำพูดยาก แต่เป็นงานที่ยอดเยี่ยมมากจริง ๆ
  ทำงานสายเว็บมาหลายปี ผมหงุดหงิดกับ UI แย่ ๆ มาตลอด แต่เว็บไซต์นี้โดดเด่นมาก
  มันไม่ใช่แค่ “หน้าตาคล้าย Windows” เท่านั้น แต่ความรู้สึกตอนใช้งานจริงก็ดีที่สุดในบรรดาเว็บจำลองเดสก์ท็อปบนเบราว์เซอร์ทั้งหมดที่ผมเคยลอง
  ถ้าจะมีอะไรให้เสียดายนิดเดียว ก็คือตรงเมนูคลิกขวาที่พื้นหลัง ถ้ามีรายการ “Refresh” อยู่ด้วยจะได้อารมณ์เดสก์ท็อปบนเบราว์เซอร์สมบูรณ์แบบยิ่งขึ้น (ไม่จำเป็นต้องทำงานจริง แค่มีไว้เพื่ออารมณ์ก็พอ)
  สรุปคือ: งานเจ๋ง เว็บไซต์เจ๋ง

  • ขอบคุณที่เสนอมา เดี๋ยวจะลองคิดเรื่องปุ่ม “Refresh” ดู

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

  • ผมเจออาการช้าบน Firefox
    แต่พอเปิดด้วย Edge กลับลื่นดี

  • อยากรู้ว่าอีกฝ่ายเจอปัญหาประสิทธิภาพในสภาพแวดล้อมแบบไหน
    สำหรับผม หน้าต่างแรกยังปกติดี แต่พอหน้าต่างที่สองเริ่มมีกระตุกเล็กน้อย แล้วหลังจากนั้นก็กลับมาวิ่งเต็มความเร็ว
    เดาว่าอาจเป็นเพราะเบราว์เซอร์เพิ่งมาตรวจพบการใช้ฟังก์ชันบางอย่างแล้วค่อยเปิดใช้รูทีนการ optimize แบบช้าหน่อย

  • SEO สมัยก่อนเป็นเรื่องของหน้าเว็บในฐานะ “เอกสาร” แต่ตอนนี้ทุกคนดูเหมือนพยายามทำเว็บให้กลายเป็นเกมกันหมด
    เว็บแนวเกมแบบนี้ก็คงจัดอันดับได้ยากเหมือนกัน

• ผมชอบมากที่เว็บไซต์นี้สดใหม่ขนาดนี้
  มันโดดเด่นท่ามกลางสวรรค์ของเว็บการตลาด SaaS ที่ใช้เทมเพลตวางส่วนซ้อน ๆ กันเหมือนกันไปหมด
  แต่ผมก็ไม่คิดว่าจะมีใครใช้งานมันแบบที่อธิบายไว้ด้านบนจริง ๆ
  คงไม่มีใครอยู่บนเว็บนานพอจะยอมเรียนรู้ระบบจัดการหน้าต่างเฉพาะของเว็บนี้หรอก

  • สำหรับผม UX กลับดูเข้าใจได้เองตามธรรมชาติ
    แถมยังสนุกด้วย
    ปกติเว็บผลิตภัณฑ์แบบนี้ผมปิดทิ้งทันที แต่รอบนี้ผมกลับใช้เวลา 5–10 นาทีเดินดูทั่วเว็บว่ามีอะไรบ้าง

  • ผมก็รู้สึกแปลกใหม่เหมือนกัน
    แต่ดูเหมือนคอมเมนต์ส่วนใหญ่บน HN จะไม่ค่อยชอบเท่าไร

  • ปฏิกิริยาของผมก็คล้ายกัน
    มันน่าประทับใจ สนุก และสะท้อนปรัชญาของบริษัทได้ดี
    ในการใช้งานจริงอาจไม่ค่อยมีประโยชน์นัก แต่ผมไม่คิดว่านั่นเป็นประเด็นสำคัญ

• ตอนทำงานกับ PostHog ผมรู้สึกไม่สบายใจกับปริมาณการวิเคราะห์ข้อมูลที่มันเกินเส้นจริยธรรมของผม แต่ในแง่เทคนิคพวกเขาทำของออกมาได้ดีมาก
  หน้า landing page นี้แสดงให้เห็นเทคโนโลยีและระดับฝีมือเดียวกับที่ใช้กับตัวผลิตภัณฑ์
  มันเป็น landing page ที่สดใหม่และสนุกดี และมุกเรื่อง “cookie banner” ก็ทำให้ผมหัวเราะออกมาได้