ทำสิ่งที่ผู้คนสามารถลิงก์ไปใช้ในการพูดคุยได้
(simonwillison.net)- หากคุณต้องการให้ผู้คนเข้าใจและแชร์โปรเจ็กต์หรือฟีเจอร์ของผลิตภัณฑ์ สิ่งที่ต้องมีก่อนการอธิบายซ้ำๆ คือ หน้าเว็บเฉพาะ
- แม้ ChatGPT Code Interpreter จะเป็นฟีเจอร์ที่ทรงพลัง แต่ชื่อและการค้นพบบนเอกสารทางการกลับไม่ชัดเจน ทำให้คำอธิบายที่คนอื่นทำไว้กลายเป็นลิงก์ที่มีประโยชน์กว่า
- กรณีของ Claude Artifacts และ GitHub Codespaces·Copilot แสดงให้เห็นว่า เมื่อฟีเจอร์กลายเป็น สิ่งที่ลิงก์ถึงได้ ก็จะทำให้การแชร์และการอธิบายง่ายขึ้น
- เช่นเดียวกับ Boring Technology ของ Dan McKinley เมื่อแนวคิดถูกจัดไว้ในหน้าแยกต่างหาก คนที่เพิ่งได้ยินครั้งแรกก็สามารถตามบริบทได้อย่างรวดเร็วผ่านลิงก์เดียว
- คุณค่าของหน้าเฉพาะไม่ได้มีแค่เรื่องการปรากฏในผลค้นหา แต่ยังช่วยให้ไม่ต้องอธิบายเรื่องเดิมซ้ำๆ ในการสนทนาบนเว็บ
ทำไมจึงต้องมีหน้าที่ลิงก์ถึงได้
- สิ่งที่คุณอยากให้คนอื่นเข้าใจและพูดถึงได้ เช่น โปรเจ็กต์ ไอเดีย หรือฟีเจอร์ของผลิตภัณฑ์ จำเป็นต้องมี หน้าที่ลิงก์ถึงได้
- ไฮเปอร์ลิงก์คือวิธีพื้นฐานในการขยายบทสนทนาบนเว็บ ทำให้เชื่อมไปยังคำอธิบายที่เป็นแกนหลักได้ โดยไม่ต้องเขียนคำอธิบายใหม่ทุกครั้ง
- หากไม่มีหน้าเฉพาะ ความสนใจและทราฟฟิกจากการค้นหาอาจไหลไปยังคำอธิบายที่คนอื่นสร้างไว้ หรือหน้าอื่นที่ยึดคำค้นนั้นไปก่อนแล้ว
ปัญหาการค้นพบของ ChatGPT Code Interpreter
- ChatGPT Code Interpreter เป็นฟีเจอร์ที่ทำให้ ChatGPT สามารถเขียนและรันโค้ด Python ระหว่างการตอบกลับได้
- ตัวฟีเจอร์นั้นทรงพลัง แต่ถ้าไม่รู้วิธีเปิดใช้งานผ่านพรอมป์ต์ ก็ยากจะสังเกตว่ามันมีอยู่
- หากค้นหา Code Interpreter บนเว็บไซต์ OpenAI คุณอาจเจอ เอกสารเทคนิค เกี่ยวกับฟีเจอร์ API หรือ กระทู้ฟอรัม เก่าๆ ซึ่งทำให้สับสน
- เมื่อต้องแนะนำฟีเจอร์นี้ ลิงก์ที่มีประโยชน์กว่าหน้าอย่างเป็นทางการของ OpenAI กลับเป็น หน้าแท็ก code-interpreter
- ภายหลังพบเอกสารจริง แต่ชื่อคือ Data analysis with ChatGPT และในหน้ายังไม่มีคำว่า “Code Interpreter” จึงยิ่งค้นหาได้ยาก
- OpenAI เปลี่ยนชื่อฟีเจอร์นี้มาโดยตลอดระหว่าง Code Interpreter, Advanced Data Analysis และ Data analysis with ChatGPT
ตัวอย่างของหน้าฟีเจอร์ที่ทำได้ดี
- ฟีเจอร์ Artifacts ของ Claude อย่างน้อยก็มี หน้าช่วยเหลือ ที่หาเจอได้ง่าย
- อย่างไรก็ตาม บทความเปิดตัว Artifacts ถูกแชร์พร้อมกับการเปิดตัว Claude 3.5 Sonnet จึงทำให้มองเห็น Artifacts ได้ยากในฐานะเป้าหมายลิงก์ที่ชัดเจนของตัวเอง
- GitHub แยกหน้า landing page สำหรับแต่ละฟีเจอร์ไว้โดยเฉพาะ
- เมื่อฟีเจอร์มี หน้าเฉพาะ ของตัวเอง ก็จะมีจุดอ้างอิงสำหรับการลิงก์และการแชร์
Boring Technology: ตัวอย่างที่แนวคิดกลายเป็นเว็บไซต์
- Dan McKinley สร้างคำว่า Boring Technology ขึ้นในบทความ Choose Boring Technology เมื่อปี 2015
- ใจความสำคัญคือ ทีมพัฒนามีขีดความสามารถจำกัดในการแก้ปัญหาใหม่ๆ ดังนั้นควรใช้ขีดความสามารถนั้นกับส่วนที่ทำให้ผลิตภัณฑ์มีเอกลักษณ์
- สำหรับส่วนที่เหลือ ควรเลือกเทคโนโลยีที่น่าเบื่อที่สุดและเป็นที่รู้จักดีที่สุด ซึ่งบั๊กและข้อจำกัดของมันถูกทำความเข้าใจและถกเถียงกันบนออนไลน์มาอย่างยาวนาน
- ไอเดียนี้ยังถูกสรุปไว้เป็นเว็บไซต์ boringtechnology.club
- เมื่อใครบางคนไม่รู้จักคำนี้ การแชร์ลิงก์เพียงอันเดียวก็ช่วยให้ตามบริบทได้ภายในไม่กี่นาที
แม้แต่ไอเดียส่วนตัวก็ต้องมีหน้าที่แชร์ได้
- ไอเดียอย่าง baked data, git scraping และ prompt injection ก็ถูกจัดไว้เป็นหน้าที่สามารถแชร์ซ้ำได้บ่อย
- แต่หากไม่ได้มีโดเมนแยกต่างหาก ข้อความที่ว่า “นี่คือหน้าหลักที่ควรลิงก์ถึง” ก็อาจไม่หนักแน่นพอ
- เป้าหมายลิงก์ที่ชัดเจนช่วยเพิ่มความสามารถในการแชร์และการสนทนาของไอเดีย
คุณค่าที่มีผลต่อการสนทนามากกว่า SEO
- หนึ่งในเป้าหมายที่ชัดเจนของหน้าเฉพาะคือ SEO
- เมื่อผู้ใช้ค้นหาฟีเจอร์ของผลิตภัณฑ์ ควรทำให้พวกเขาเข้ามายังเว็บไซต์ของตนเอง แทนที่จะไปยังหน้าที่คนอื่นสร้างไว้
- แต่คุณค่าที่ใหญ่กว่านั้นปรากฏชัดในการสนทนา
- เมื่ออธิบายแนวคิดบางอย่าง คุณสามารถแชร์ลิงก์ที่มีคำอธิบายชี้ขาดได้ แทนที่จะต้องเขียนย่อหน้าเดิมขึ้นมาใหม่
- หากคุณต้องการให้ผู้คนเข้าใจและถกเถียงเกี่ยวกับไอเดีย โปรเจ็กต์ หรือฟีเจอร์ ก็ควรสร้างหน้าเว็บที่เหมาะสมกับสิ่งนั้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
rsync.net เป็นบริการที่ทำเรื่องแบบนี้ได้ดี เช่น ไม่ค่อยเห็นบริการอื่นมีอะไรอย่าง หน้า CEO แบบนี้
ไม่แน่ใจว่าใช้งานได้มีประโยชน์จริงแค่ไหน และผมก็ไม่เคยต้องส่งอะไรถึง CEO แต่ทั้งที่ยังไม่ได้เป็นลูกค้า พออ่านบทความนี้ปุ๊บก็นึกถึงหน้านี้ขึ้นมาก่อนเลย
[1]: https://www.rsync.net/products/ceopage.html
เป็นหน้าที่ออกแบบมาให้ส่งต่อถึงหัวหน้าได้ทันที โดยที่ผู้เข้าร่วมไม่ต้องไปแต่งเหตุผลเชิงงานให้ดูน่าเชื่อถือเอง
ถ้าเป็นระดับ OpenAI ก็น่าจะคิดว่าเดี๋ยวนี้คงจ้าง technical writer แล้ว แต่ดูจาก LinkedIn เหมือนจะยังไม่ใช่ เลยไม่ค่อยแปลกใจนักที่สภาพเอกสารออกมาแย่แบบนี้
ไม่เข้าใจว่าทำไมถึงไม่รับคนมาดูแลงานเอกสารโดยตรง ดูเหมือนจะมองว่าไม่สำคัญ หรือไม่ก็ให้ความสำคัญกับการเติบโตมากกว่าเอกสารแบบเย็นชา ไม่ว่าเหตุผลคืออะไร สุดท้ายก็ทำให้ตัวเองเสียประโยชน์
ในบทความมีอ้างถึง https://boringtechnology.club/ ซึ่งเป็นสไลด์เด็คที่ยอดเยี่ยมมากว่าด้วยการเก็บความพยายามด้านนวัตกรรมไว้เฉพาะกับทางแก้ที่เป็นเอกลักษณ์จริง ๆ
ที่เหลือก็ควรใช้ เทคโนโลยีน่าเบื่อ ให้มากที่สุด เห็นบ่อยเกินไปว่าทีมพัฒนาพยายามจะนวัตกรรมไปทุกชั้นจนสุดท้ายหลงโฟกัสว่าตัวเองกำลังส่งมอบคุณค่าอะไรอยู่ ผมอยากสลักสไลด์เด็คนี้ไว้ในโลกทัศน์ของตัวเองเลย
เป็นอีกบทความดี ๆ ของ Simon เมื่อคืนผมเอาแนวคิดนี้ไปใส่ในโปรเจ็กต์ใหม่ทันที อยากแสดงหลักฐานว่า Google Gemini App เซ็นเซอร์ yt-dlp แต่ Gemini API ไม่ทำแบบนั้น และในขณะเดียวกันก็อยากสร้างทั้งช่องทางให้คนไหลเข้ามายังโปรเจ็กต์และเหตุผลเชิงธุรกิจตามที่ Simon พูดถึง
https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
ผมยังใช้ localStorage เพื่อเก็บรายการแชตสาธารณะที่เคยเปิดดูไว้ด้วย พอกลับมาอีกครั้งก็จะเห็นแชตอื่นที่เคยอ่าน และหาง่ายกว่าการไปคุ้ยประวัติข้อความว่าเดิมทีได้ลิงก์มาจากไหน
ลิงก์ตาย นี่แย่ที่สุดแล้ว มีใครทำส่วนขยายเบราว์เซอร์ที่ให้ GPT หลอนสร้างเว็บไซต์ของลิงก์ตายขึ้นมาได้ไหม?
ศิลปินมักลิงก์แค่ไปยังโซเชียลมีเดีย แต่บัญชีอาจถูกระงับได้ และชื่อผู้ใช้ก็อาจเปลี่ยนได้ นักพัฒนาก็อ้างอิง dependency เป็น “ลิงก์” โดยไม่คิดว่า repository อาจหายไปได้ และถ้าไม่มีใครสำรองไว้ ซอร์สโค้ดของเวอร์ชันนั้นก็อาจหายไปด้วย หรือเวอร์ชันของแพ็กเกจอาจถูกลบออกจาก registry หรือเอกสารออนไลน์ของ dependency อาจหายไปได้
[1]: แค่เพิ่มชื่อ+เวอร์ชันลงในไฟล์ manifest แล้วลืมมันไปตลอดกาล ต่อให้มี cache เพิ่มเข้ามา มันก็ยังไม่ใช่ mirror ที่ถูกต้อง และยิ่งไม่ใช่วิธีที่จะทำให้คุณ build dependency เองได้ในยามเกิดภัยพิบัติ
ถ้ามีคนช่วยกันบรรยายว่าหน้านั้นเมื่อก่อนหน้าตาเป็นอย่างไรทีละนิด หรือคลานเว็บเพื่อหาเบาะแส ก็น่าจะเป็นไอเดียที่น่าสนใจมาก แถมยังเอาแบนเนอร์ “กำลังก่อสร้าง” กลับมาได้อีกด้วย
ผมชอบบล็อกของ Simonw ตั้งแต่กันยายนปีที่แล้ว ผมใช้ Python interpreter อ่านบล็อกของเขาอยู่ เขาเคยบอกว่าเริ่มทำแบบนั้นคนเดียวเพื่อจะได้สร้างแอปพลิเคชันทั้งตัวแบบสด ๆ ได้ทันที
แต่ผมก็ยังไม่ค่อยเข้าใจชัดว่าต้องทำยังไง ผมนึกว่าจะมีตัวเลือกหรือปุ่มง่าย ๆ แต่หาไม่เจอ อาจจะลองพยายามหาต่อก็ได้ แต่ถ้ามีลิงก์หรือบทสอนที่เข้าถึงง่ายกว่านี้ ผมก็น่าจะลองใช้ GPT ต่อไปมากกว่าที่จะเมินมันไปเกือบหมด
ในบริบทนี้ มีมรับมือเหตุขัดข้อง ของ Square ก็ยังคงอยู่ที่ https://outage.party/
ฉันเคยเกลียดผลิตภัณฑ์ของ Microsoft หลายตัวมากก็เพราะเหตุผลนี้นี่แหละ โดยเฉพาะพวกสินค้าที่เปลี่ยนชื่อไปมาอย่าง VSTS/VSO/Dev Ops หรือ Sharepoint มันแย่มาก ลิงก์แบบ deep link อันหนึ่งยาว 700 ตัวอักษร มีทั้ง query string แบบ base64 เป็นสิบ ๆ ตัวและพาธประหลาด ๆ ติดมาด้วย ประมาณว่า “มีปัญหาอะไรเหรอ? ก็ใช้บริการย่อ URL สิ? URL มันก็ยาวแบบนี้แหละ ช่วยไม่ได้” ฟังแล้วแทบคลั่ง
ในปี 2014 เครื่องมือภายในทีมตัวหนึ่งแสดงสถานะทรัพยากรของระบบ และทรัพยากรกับสถานะทั้งหมดก็อยู่ในฐานข้อมูล SQL แต่เว็บแอปนั้นเป็น SPA ตั้งแต่ก่อนจะมีอะไรอย่าง router มันไม่อัปเดต URL และไม่รองรับ deep link ถ้าจะส่งปัญหาของทรัพยากรบางตัวทางอีเมลหรือเมสเซนเจอร์ ก็ต้องอธิบายว่า “เข้าไปที่เครื่องมือ X แล้วค้นหา Y จากนั้นกด Z -> W -> M -> O -> K แล้วจะเจออยู่ตรงนั้น” ฉันหงุดหงิดมากว่าทำไมถึงแชร์สถานะที่ซ้อนลึก ๆ ด้วยลิงก์ https://X.com/Y/Z/W/M/O/K ไม่ได้สักที พูดไปหลายครั้งก็ได้แต่คำตอบว่า “ยังไม่ใช่ลำดับความสำคัญ และก็ไม่ใช่เรื่องใหญ่ขนาดนั้น”
ครั้งหนึ่งฉันมีโอกาสได้ทำสิ่งที่อยากแก้อยู่ 2 สัปดาห์ เลยตัดสินใจสร้างทางเลือกที่รองรับ deep link แล้วก็ทำให้ deep link ทุกอันถ้าเติมคำนำหน้า
/api/จะคืนเนื้อหาออกมาเป็น JSON ด้วย มันดังมากทั้งในทีมและทั้งบริษัท ทั้งที่เครื่องมือของฉันเรียบง่ายกว่ามากและฟีเจอร์ก็น้อยกว่า แต่การใช้งานเครื่องมือ X กลับลดลงแทบจะข้ามคืน สุดท้ายแล้วคนส่วนใหญ่ต้องการวิธีแชร์ลิงก์ได้ง่าย มากกว่าจะได้ “SPA ทรงพลังที่ขุดลึกและสืบค้นได้”หนึ่งเดือนต่อมา ทีมของเครื่องมือ X ก็ประกาศใหญ่ทางอีเมลทั้งบริษัทว่ารองรับ deep link แล้ว แต่พวกเขามองว่าฟังก์ชันง่าย ๆ ที่คืนข้อมูล JSON ผ่านคำนำหน้า
/api/ไม่สำคัญ ผ่านไป 5 ปี UI ของเครื่องมือฉันอาจจะล้าสมัยไปแล้ว แต่ตัวบริการจริงกลับถูกยกระดับเป็น บริการภายในแกนหลัก เพราะหลายทีมสร้างระบบอัตโนมัติโดยยึด URL ที่มีคำนำหน้า/api/เป็นศูนย์กลาง และสุดท้ายทีมนั้นก็ต้องรับโค้ดไปดูแลต่อเองในฐานะแฟนของ Simonw ขอยกอีกประเด็นที่ยังไม่มีใครพูดถึง: ตัวอย่างอื่น ๆ ของการที่ Simon สร้างสิ่งให้ผู้คนเอาไปลิงก์ต่อได้ ก็ได้ผลมากบน HN เหมือนกัน: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
คนที่อยู่ใกล้วงการ AI มักจะรู้กันอยู่แล้ว แต่ Simon มักจะสรุปข่าวที่กำลังดำเนินอยู่ซึ่งคนวงกว้างกว่ายังไม่รู้ ได้อย่างรวดเร็วมาก เขาทำให้ข้อเท็จจริงที่เกี่ยวข้องถูกลิงก์และเข้าถึงได้อย่างรวดเร็ว จนแม้แต่คนที่อยู่ไกลจากประเด็นนั้นก็ยังเข้ามาร่วมถกเถียงได้
เห็นด้วยกับคำพูดที่ว่า “ไฮเปอร์ลิงก์คือสิ่งที่ดีที่สุดของเว็บ” จะให้แม่นกว่านั้นคือ ไฮเปอร์ลิงก์และ URL
URL คือรากฐานสำคัญของเว็บ มันทำให้เราอ้างอิงงานเขียนและทรัพยากรอื่น ๆ ได้อย่างแม่นยำ เป็นสากล และในแบบที่หวังว่าจะคงอยู่ได้นาน รู้สึกหงุดหงิดเสมอเวลาคนไม่เห็นคุณค่าของสิ่งนี้ เช่น แทนที่จะวางลิงก์ในข้อความกลับบอกว่า “ไปค้นอันนี้ใน YouTube” การให้บทความมีที่อยู่ถาวรบนเว็บยังช่วยเพิ่มการมองเห็น และลดการที่ผู้เขียนต้องเขียนความคิดเดิมซ้ำอีกครั้ง
บทความคลาสสิกที่เกี่ยวข้อง: Cool URIs don't change. [0][1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://news.ycombinator.com/item?id=23865484
ผลในทางปฏิบัติคือแบบนี้ ระหว่างคุยกับใครสักคนหรือช่วงถาม-ตอบหลังการบรรยาย ถ้าอยากพูดว่า “ใช่ เราก็คิดเรื่องนั้นไว้แล้ว และมีข้อมูลที่ acmeinitiative.example.com/skub” ต่อให้ยังไม่ได้เขียนบทความ
/skubก็ยังสามารถกำหนด/skubให้เป็นแฮนเดิลที่ใช้เรียกบทความนั้นได้ทันที ณ ตอนนั้น บทความค่อยเขียนทีหลังก็ไปแสดงที่นั่น และคนที่สนใจก็กลับมาหาที่ URL นั้นเมื่อไรก็ได้ กับบทความที่คนอื่นเขียนหรือทรัพยากรภายนอกก็เหมือนกัน สร้าง URL เฉพาะกิจในเนมสเปซของตัวเองไว้ก่อน แล้วค่อยมารีไดเร็กต์ไปยังลิงก์ต้นทางตอนมีเวลาก็ได้ผมได้ยินหลายครั้งเกินไปแล้วในงานบันทึกเสียง พอดแคสต์ ฯลฯ ที่มีวิศวกรเก่ง ๆ ซึ่งเห็นชัดว่าถือครองโดเมนของตัวเอง แต่กลับไม่ใช้วิธีนี้ ปกติจะพึมพำคำบรรยายที่อาจค้นเจอหรือไม่ก็ได้ หรือพยายามนึกชื่อแล้วพูดผิดไปครึ่งหนึ่ง สุดท้ายผู้ฟังทุกคนที่สนใจต้องเสียเวลาและความสนใจไปค้นกันเอง และเมื่อรวมกันแล้วก็เป็นการรั่วไหลของพลังงานมหาศาล
FB บล็อกหลายเว็บไซต์รวมถึงบล็อกสุ่ม ๆ โดยอ้างเรื่องการแชร์เนื้อหาละเมิดลิขสิทธิ์, reddit บล็อก
.ruทั้งหมด รวมถึงหลายเว็บคลังข้อมูลและลิงก์ Telegram ส่วน Twitter ก็เคยบล็อกบางแพลตฟอร์มบล็อก และเว็บเล็ก ๆ อีกมากก็มีกรณีบล็อก Discord เหมือนกัน การบล็อก Discord อาจพอมีเหตุผลรองรับได้ แต่ก็หวังว่าแนวโน้มแบบนี้จะเป็นแรงผลักให้คนย้ายออกจากที่เหล่านั้นอย่างแรก มันกระตุ้นความรู้สึกขยะแขยงแบบ AOL Keyword ในทันที อย่างที่สอง มันมองข้ามแนวคิดเรื่อง search bubble ไปโดยสิ้นเชิง ต่อให้ใส่คำค้นเดียวกัน คุณกับผมก็อาจได้ผลลัพธ์ที่ต่างกันมาก อย่างที่สาม ในเมื่อมี URL และไฮเปอร์ลิงก์อยู่ตรงนั้นแล้ว ก็ไม่มีเหตุผลต้องโยนงานเพิ่มมาให้ผม ถ้าคุณลิงก์ตรง ผมก็จะเห็นได้ว่าคุณอ้างถึงอะไรแน่ โดยไม่ต้องหลงไปกับวิดีโอรีแอ็กชันนับไม่ถ้วน
แต่หลายเว็บไซต์และบริการไม่ชอบสิ่งนี้ เพราะมองว่าเป็นการรุกล้ำ อาณาเขตแห่งความสนใจ ของพวกเขา ในฐานะผู้เขียน ถ้าผมลิงก์ไปยังไอเดียที่เคยเรียบเรียงไว้อย่างรอบคอบแล้วในบล็อกโพสต์หรือหนังสือ คอมเมนต์นั้นอาจถูกลบหรือเซ็นเซอร์ด้วยเหตุผลว่าเป็น “การโปรโมต” ช่วงนี้บน HN เพื่อหลีกเลี่ยงการถูกลงโทษ ผมจึงมักคัดลอกข้อความต้นฉบับที่ตัวเองเขียนมาแปะตรง ๆ มากกว่าจะให้ลิงก์สำหรับให้ผู้อ่านไปสำรวจต่อได้ลึกขึ้น มันมีช่องว่างที่ชัดเจนระหว่างสิ่งที่เราพร่ำสอนว่าเป็นวิธีเผยแพร่ข้อมูลแบบ “เชิงวิชาการ” ที่ดี กับความเป็นจริงของระบบที่ควบคุมการแสดงออก