ฟีเจอร์เว็บธรรมดา ๆ ที่ควรมี
(heather-buchel.com)- เมื่อแพลตฟอร์มโซเชียลมีเดียใหม่ ๆ รวมถึงไคลเอนต์ แอป และเว็บพอร์ตที่ใช้ React Native เพิ่มขึ้น เว็บไซต์จำนวนมากกลับสูญเสีย พฤติกรรมพื้นฐานของเว็บ ที่ผู้ใช้คาดหวัง
- สาเหตุหลักมักมาจากแรงกดดันให้เปิดตัวเร็ว การไม่มี UI engineer ในทีม การออกแบบแบบ touch-first สำหรับมือถือ และการใช้ JavaScript แทนที่พฤติกรรมพื้นฐานของเบราว์เซอร์
- ฟีเจอร์พื้นฐานของเบราว์เซอร์ อย่างการคัดลอกข้อความ การคลิกขวาที่ลิงก์และ
ctrl + clickการซูมของเบราว์เซอร์ เลย์เอาต์แบบ responsive,:hoverและ:focusการอัปเดต URL/ประวัติการเข้าชม scrollbar และctrl + fควรทำงานได้ตามเดิม - การทำให้
pointer-eventsหายไปจากการ์ดที่คลิกได้ หรือการซ้อนเลเยอร์ รวมถึงการใช้divกับon-clickเพื่อเปลี่ยนหน้าแทน anchor จะทำลาย ประสบการณ์ลิงก์ตามปกติ - แม้จะมีหลายส่วนที่ทับซ้อนกับการละเมิดด้าน accessibility แต่เว็บแอปควรรักษา ฟีเจอร์เว็บธรรมดา ๆ ที่ผู้ใช้คาดหวังไว้ มากกว่าพยายามทำให้ดูเหมือนแอปมือถือ
พฤติกรรมพื้นฐานที่เว็บไซต์ทำหายไป
- โปรเจกต์เว็บมักขัดขวาง ฟีเจอร์เว็บธรรมดา ๆ ที่ผู้ใช้คาดหวังมากขึ้นเรื่อย ๆ
- เมื่อแพลตฟอร์มโซเชียลมีเดียใหม่ ๆ เพิ่มขึ้น ก็มีการสร้างไคลเอนต์และแอปหลายแบบ และมีกรณีที่พยายามแชร์โค้ดข้ามแพลตฟอร์มอย่าง React Native มากขึ้นด้วย
- ความพยายามเหล่านี้เป็นเรื่องดีในตัวมันเอง แต่บางครั้งไม่เพียงข้อกำหนดพื้นฐานด้าน accessibility เช่นข้อความ
altของรูปภาพจะหายไป วิธีการใช้งานเว็บตามปกติก็หายไปด้วย - สาเหตุอาจมาจากสิ่งต่อไปนี้
- แรงกดดันให้เปิดตัวเร็วพอสำหรับการทดสอบ
- สถานการณ์ที่โปรเจกต์ไม่มี UI engineer
- การออกแบบที่ให้ความสำคัญกับอินพุตแบบสัมผัสบนมือถือก่อน และละเลยวิธีป้อนข้อมูลหรืออุปกรณ์แบบอื่น
- การนำไปใช้งานที่ใช้ JavaScript เพื่อเลี่ยงหรือแทนที่พฤติกรรมพื้นฐานของเบราว์เซอร์
ฟีเจอร์เว็บธรรมดา ๆ ที่ควรรักษาไว้
- ต้องสามารถ คัดลอกข้อความ ได้
- ในคอมโพเนนต์การ์ดที่คลิกได้ หากเอา
pointer-eventsออกหรือซ้อนเลเยอร์เป้าหมายการคลิก อาจทำให้เลือกและคัดลอกข้อความไม่ได้
- ในคอมโพเนนต์การ์ดที่คลิกได้ หากเอา
- องค์ประกอบที่นำทางเหมือนลิงก์ต้องให้ ฟังก์ชันลิงก์ ตามเดิม
- ต้องสามารถคลิกขวาเพื่อเปิด context menu แล้วคัดลอกข้อความลิงก์หรือที่อยู่ได้
- คีย์ลัดลิงก์ทั่วไปอย่าง
ctrl + clickบน Windows เพื่อเปิดในแท็บใหม่ต้องทำงานได้ - ควรใช้องค์ประกอบ anchor แทนวิธีติด
on-clickกับdivเพื่อเปลี่ยนหน้า
- เมื่อซูมในเบราว์เซอร์ เลย์เอาต์ต้องไม่พัง และผู้ใช้ต้องซูมเพื่ออ่านได้
- เว็บแบบ responsive ไม่ควรเปลี่ยนเป็นเลย์เอาต์มือถืออย่างง่ายทันทีเมื่อแคบกว่า 1200px แต่ควรใช้พื้นที่อย่างเหมาะสมแม้ใน viewport ที่แคบ
- Mastodon และ Twitter เป็นตัวอย่างที่ UI ยังดูคุ้นเคยเมื่อทำให้ความกว้างของเบราว์เซอร์แคบลง และโดยรวมใช้พื้นที่ได้ดี
- เว็บแอปต้องให้ สถานะการโต้ตอบ อย่าง
:hover,:focus,:activeได้ตามปกติ- ในกรณีของแอป React Native ที่พอร์ตมาลงเว็บ อาจพบว่าไม่มีสไตล์
:hoverหรือ:focusหรือมีสไตล์:activeที่ดูแปลกเหมือนถูกปิดใช้งาน
- ในกรณีของแอป React Native ที่พอร์ตมาลงเว็บ อาจพบว่าไม่มีสไตล์
- หากหลังคลิกแล้ว UI เปลี่ยนไปทั้งหมดเหมือนเป็นหน้าใหม่ ประวัติการเข้าชมและ URL ของเบราว์เซอร์ก็ควรเปลี่ยนตามด้วย
- หากไม่สามารถลิงก์ไปยังสถานะ UI ที่ดูเหมือนหน้าอิสระได้ และสถานะหายไปหลังการนำทาง usability ก็จะแย่ลง
- ไม่ควรซ่อน scrollbar
- ผู้ใช้อาจต้องการคลิก scrollbar แล้วลาก
- ไม่ควรดักคีย์ลัดเบราว์เซอร์ทั่วไปไปใช้เป็นฟังก์ชันภายในแอป
- หากทำให้
ctrl + fเปิดช่องค้นหาภายในแอปแบบ custom การค้นหาในหน้าตามปกติอาจไม่ทำงาน
- หากทำให้
- มีหลายรายการที่ทับซ้อนกับสิ่งที่ถือเป็นการละเมิด accessibility แต่จุดเน้นคือการทำให้เว็บแอปไม่ทำลาย ความคาดหวังพื้นฐานต่อเบราว์เซอร์ ของผู้ใช้
- กรณีที่ตกหล่นสามารถพูดคุยต่อได้ที่ Mastodon
3 ความคิดเห็น
ดูเหมือนว่าเนื้อหาหลักจะไม่ถูกต้อง
อ้อ น่าสนใจดีนะครับ ดูเหมือนว่าการครอว์ลตัวบทความบล็อกนั้นเองจะทำงานแปลก ๆ อยู่
คงต้องลองไปดูส่วนของครอว์ลเลอร์สักหน่อยแล้วล่ะครับ
ความคิดเห็นบน Hacker News
หากเรียนเว็บด้วย React ก่อน แล้วค่อยมาเรียน HTML ทีหลัง ก็อาจทำให้ไม่ใส่ใจ พฤติกรรมพื้นฐานของลิงก์
ตอนที่ผมเข้าร่วมทีม ลิงก์ทั้งหมดเป็นปุ่มบ้าง เป็นองค์ประกอบตามใจบ้าง หรือถูกจัดการด้วย
onClickและแม้ไม่มีใครบ่น แต่Ctrl+คลิกก็ใช้ไม่ได้ผล และเมนูคลิกขวาก็ไม่มีตัวเลือกตามที่คาดหวังสำหรับเรื่องลิงก์ ผมมองว่าไม่มีพื้นที่ให้ต่อรอง
แม้แต่แพลตฟอร์มเอกสารชื่อ archbee ที่ได้รับเงินลงทุนจาก YC ก็ยังเปิดผลการค้นหาในแท็บใหม่ไม่ได้ ต้องเปิดหนึ่งรายการในแท็บปัจจุบัน ถ้าไม่ใช่ก็ย้อนกลับไปค้นหาใหม่แล้วเปิดผลลัพธ์ถัดไป
ดูตัวอย่างได้ที่นี่: https://docs.sparklayer.io/
มันแปลกมากและชวนหงุดหงิดสุด ๆ ที่บริการอินเทอร์เน็ตขนาดใหญ่แบบนี้มีปัญหาด้านการเข้าถึงที่ชัดเจนเช่นนี้
นอกจากไม่ต้องมีบัญชีแล้ว ยังสามารถคลิกขวา เธรดทวีต เพื่อเปิดในแท็บใหม่ได้
ด้วยลักษณะของบทสนทนาบน Twitter ผมมักอยากเปิดหลายเธรดขึ้นมาดูใหม่โดยยังคงตำแหน่งเดิมของหน้าต้นทางไว้ แต่ UI ของ Twitter จริง ๆ ทำให้เรื่องนี้ยากมาก
แทบไม่มีอะไรน่ารำคาญไปกว่านี้แล้ว ถ้าต้องยกอีกอย่างก็คงเป็นการทำให้ ประวัติการท่องเว็บของเบราว์เซอร์ พัง
ถ้าการกดย้อนกลับทำงานได้ทันทีและลื่นไหลก็ยังพอให้อภัยได้ แต่ในความเป็นจริงต้องรอโหลดเนื้อหาใหม่และยังเสียตำแหน่งการเลื่อนไปด้วย
ที่หนักกว่านั้นยังมีไซต์อย่าง Facebook ที่บังคับสถานะป๊อปอัปแชตเดียวกันในหลายแท็บ ปิดในแท็บหนึ่งก็ปิดในแท็บอื่นด้วย ทั้งที่เหตุผลที่เปิดหลายแท็บไว้นั้นมีอยู่ต่างหาก
ทันทีที่ไปแตะพฤติกรรมที่มีมาให้โดยพื้นฐาน ก็เท่ากับรับ ความรับผิดชอบ ต่อสิ่งนั้นไปด้วย
“ฟีเจอร์” ที่สร้างขึ้นไม่ได้จำกัดอยู่แค่ขอบเขตแคบ ๆ ตามที่ผู้ออกแบบตั้งใจ แต่กลายเป็นประสบการณ์ทั้งหมดที่ผู้เยี่ยมชมพบจริง
หากเปลี่ยนตรรกะของปุ่มย้อนกลับ ก็เท่ากับเปลี่ยนความหมายที่การย้อนกลับมอบให้บนไซต์นั้น และต้องรับผิดชอบต่อผลลัพธ์ที่ผู้ใช้สับสนและโกรธจนด่าว่าเป็น “ไซต์พัง” ด้วย
ควรคิดให้ดีว่าพร้อมรับผิดชอบจริงหรือไม่ แม้กระทั่งพฤติกรรมที่แตกต่างกันไปตามเบราว์เซอร์และระบบปฏิบัติการอย่างแถบเลื่อน
สุดท้ายก็เท่ากับทำให้เว็บไซต์พูดภาษาลูกผสมแบบหนึ่ง จึงไม่น่าแปลกใจหากผู้เยี่ยมชมฟังภาษานั้นไม่เข้าใจหรือ “ตีความผิด”
ฟีเจอร์เหล่านี้ไม่ใช่แค่สิ่งที่ควรหลีกเลี่ยงเพื่อความเป็นมิตรต่อผู้เยี่ยมชมเท่านั้น แต่ดูเหมือนประโยชน์ที่ได้จะจำกัด ในขณะที่ความเสียหายแทบไม่มีขีดจำกัด
ไซต์ที่มองข้ามสำนวนเหล่านี้จะใช้งานยากขึ้น เพราะไม่ได้พูดภาษาที่ผู้ใช้คุ้นเคย
มีบทความที่เขียนยาว ๆ เกี่ยวกับการสูญหายของสำนวนการออกแบบด้วย: https://loeber.substack.com/p/4-bring-back-idiomatic-design
ผมมองว่านี่คือ การทำให้เว็บไซต์กลายเป็นแอป และถึงเวลาต้องหยุดได้แล้ว
เว็บไซต์ควรกลับไปสู่การเรนเดอร์ฝั่งเซิร์ฟเวอร์ แล้วเติม JavaScript เท่าที่จำเป็น
ในทางกลับกัน เว็บแอปอาจจัดการ UX เพิ่มขึ้นได้เล็กน้อยหากมีคุณค่าต่อผู้ใช้ แต่ตราบใดที่ยังอยู่ในเบราว์เซอร์ หลักการพื้นฐานก็ยังคงใช้บังคับอยู่
ผมสนับสนุนเว็บแอปในฐานะแพลตฟอร์มพัฒนาที่ทุกคนเข้าถึงได้จากนอกกำแพงของแอปสโตร์ แต่ควรหยุดปฏิบัติต่อเว็บไซต์ทุกแห่งเหมือนเป็นแอป
ถ้าเป็นหน้าที่ต้องการให้ปรากฏในผลลัพธ์ของเสิร์ชเอนจิน นั่นคือเว็บไซต์ ไม่ใช่เว็บแอป
Accept: text/markdownสำหรับเอกสารดิบได้ก็คงดี แต่ผมคิดว่าเรือลำนั้นออกไปแล้วตั้งแต่ CSS ปรากฏตัวโชคดีที่สิ่งอย่าง React Server Components ดูเหมือนจะพาเรากลับไปสู่ทิศทางของการ ค่อย ๆ เติม JavaScript ลงในเว็บไซต์ จึงเป็นเรื่องดี
เป็นปัญหาที่ทำได้หากทุ่มเวลาให้เพียงพอ
ไม่เข้าใจว่าทำไมเว็บธนาคารถึงบล็อกการ วาง
พอรู้ตัวว่าวางไม่ได้ ก็เป็นหลังจากคัดลอกข้อความไปแล้ว
ถ้าพิมพ์เองก็ยิ่งมีโอกาสผิดพลาดมากขึ้น และถ้าคลิปบอร์ดปนเปื้อนอยู่แล้ว ตอนที่สังเกตว่าห้ามวาง การคัดลอกก็เสร็จไปแล้วอยู่ดี
ดูเหมือนผู้คนจินตนาการว่ามันเป็นมาตรการความปลอดภัย แล้วก็สมัครใจลอกต่อกันไป
ตั้งแต่แรกก็ไม่เข้าใจว่าทำไมต้องห้ามผู้ใช้วางด้วย
“รหัสผ่าน” นั้นเป็นแค่ ตัวเลข 6 หลัก และตั้งเองก็ไม่ได้ ราวกับว่า 6 หลักปลอดภัยกว่าสตริงสุ่ม 16 ตัวอักษรที่ตัวจัดการรหัสผ่านสร้างขึ้นมาก
มันบังคับให้ป้อนผ่านปุ่มตำแหน่งสุ่มในหน้า แต่ถ้าอุปกรณ์ติดมัลแวร์จนถูกบันทึกการกดปุ่มและการคลิกได้แล้ว ผู้โจมตีก็น่าจะอ่านรหัสผ่านจากหน่วยความจำของเบราว์เซอร์ได้ตรง ๆ อยู่ดี
จากมุมมองด้านความปลอดภัย นี่เป็นการตัดสินใจที่แย่อย่างไม่น่าเชื่อจริง ๆ
พวกเขาลองสารพัดวิธีเพื่อรบกวนบ็อต แล้ววันหนึ่งนักพัฒนาที่ถูกผู้จัดการระดับกลางกดดันให้ทำอะไรสักอย่างก็ไปบล็อกการคัดลอก·วางบนหน้าเข้าสู่ระบบ แล้วบ็อตก็หยุดไปชั่วคราว
ไม่กี่วันต่อมาบ็อตก็เลี่ยงได้ แต่ “การแก้ไข” ก่อนหน้านั้นยังคงอยู่ด้วยความคิดว่า “อาจกันบ็อตบางตัวได้”
แล้ว JavaScript ราว ๆ 10 บรรทัดนั้นก็อยู่รอดไปจนถึง rewrite v6 และหลังจากเริ่มโปรเจกต์ใหม่ไปไม่กี่เดือนหรือไม่กี่ปี ข้อห้ามแบบเดิมก็ถูกใส่กลับมาอีก
ไม่ได้พูดจากประสบการณ์แน่นอน
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
อาจเป็นไปได้ว่าพวกเขานึกถึงของประเภทนั้น
น่าหงุดหงิดเวลานักพัฒนา JS สายจัดเต็มเอาความซับซ้อนและฟีเจอร์ที่ไม่มีใครขอไปซ่อนไว้หลัง เมนู select ที่ดูเหมือน HTML เนทีฟ
เห็นบ่อยในช่องกรอกเมืองกับรัฐ โดยเมืองเป็นช่องข้อความ ส่วนรัฐเป็นดรอปดาวน์/เมนู select
ในฐานะคนเท็กซัส ผมมักพิมพ์ชื่อเมือง แล้วกด Tab ไปยังเมนูเลือกรัฐ จากนั้นกด
t,tแล้วข้ามไปยังองค์ประกอบถัดไปของฟอร์มแต่เดี๋ยวนี้มันเป็นช่องค้นหาข้อความที่ตกแต่งให้ดูเหมือนดรอปดาวน์ ทำให้
t,tไม่ได้เลือก Tennessee แล้วต่อด้วย Texas แต่กลายเป็นการค้นหาคำว่าttตามตัวอักษรมันทำงานตามคาดเฉพาะกับคนที่ใช้เมาส์คลิกสามเหลี่ยมแล้วเลื่อนรายการรัฐเท่านั้น
ถ้ามันไม่ได้พัง ก็ไม่ควรไปซ่อม
ในอดีต
<select>จริง ๆ นั้นปรับสไตล์หรือขยายพฤติกรรมได้ยากมากหรือเป็นไปไม่ได้ ทำให้แอปจำนวนมากต้องสร้างขึ้นใหม่เอง และส่วนใหญ่ก็ทำได้แย่ดูเหมือนกำลังมีตัวทดแทนในตัวแบบใหม่ที่กำหนดสไตล์ได้ออกมา
อีกทั้งเพราะการแชร์โค้ดระหว่างแอป·เฟรมเวิร์ก·บริษัททำได้ยาก ตัวทดแทนคอมโพเนนต์ในตัวที่มีฟีเจอร์ครบ การเข้าถึงครบ และปรับแต่งได้ จึงมีแต่บริษัทใหญ่เท่านั้นที่ทำได้
Web Components สามารถแก้ปัญหานี้ได้ โดยทำให้เกิดความร่วมมือทั่วโลกกับคอมโพเนนต์ปลายทางที่ใช้ร่วมกันอย่าง
<select>บทความที่เกี่ยวข้อง: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
ผมคิดว่าพฤติกรรมลิงก์ที่พังจำนวนมากเกิดจากการขาด เมธอดระดับสูง สำหรับแทนที่พฤติกรรมลิงก์พื้นฐาน
เช่น ถ้าจะให้ลิงก์เปิดเป็นโมดัล ผมไม่อยากต้องผูก click event listener เพราะ click event อยู่ระดับต่ำเกินไป ต้องตรวจ modifier key เอง
สิ่งที่ต้องการจริง ๆ คือบอกเบราว์เซอร์ว่า “ถ้า URL ของหน้าต่างปัจจุบันกำลังจะเปลี่ยนเพราะองค์ประกอบ anchor นี้ ให้เรียกฟังก์ชันนี้แทน”
แบบนั้นผู้ใช้ก็ยังเปิดลิงก์ในหน้าต่างใหม่หรือแท็บใหม่ได้อย่างอิสระ และในกรณีนั้นโค้ดของผมจะไม่ถูกเรียก
CSS ก็เช่นกัน ผมไม่อยากกำหนดรูปเคอร์เซอร์ให้ทุกองค์ประกอบและทุก pseudo-class สิ่งที่อยากบอกคือ “ตรงไหนที่ตั้งใจจะใช้เคอร์เซอร์มือ/รอ/ปรับขนาดแบบพื้นฐาน ให้ใช้รูปกำหนดเองนี้แทน”
แบบนั้นต่อให้มีองค์ประกอบหรือ UI ใหม่เกิดขึ้น โค้ดก็ปลอดภัยต่ออนาคต
บางครั้ง API ของเบราว์เซอร์บางตัวก็ดูเหมือนเจอปัญหาแบบ XY problem
แค่ลงทะเบียน
onclickบนแท็ก แล้วใน event handler ก็ยกเลิกพฤติกรรมการนำทางพื้นฐานแม้ผู้ใช้ปิด JavaScript เว็บก็ยังทำงานได้ดี และพฤติกรรมในตัวของเบราว์เซอร์อย่างเมนูลิงก์คลิกขวาหรือ
Ctrl+คลิกก็ยังทำงานเหมือนเดิมเพียงแต่มันเป็น “ทริก” ที่ค่อนข้าง obscure จึงอยากให้ DOM API ทำให้ง่ายกว่านี้
ผมมองว่านี่เป็น use case ของ Navigation API
สิ่งที่ต้องการไม่ใช่ click หรือ pointer event แต่เป็น visit event ระดับสูง
ตอนเห็น Flutter Gallery ครั้งแรก ผมตกใจเพราะในเว็บเบราว์เซอร์ทุกอย่างรู้สึกเหมือนพังไปหมด: https://gallery.flutter.dev
โดยเฉพาะตัวอย่าง Reply น่าจะเป็นแบบนั้น
Ctrl+คลิกหรือปุ่มกลางของเมาส์บนลิงก์ใช้ไม่ได้, คลิกขวาก็ไม่ได้, เลือกและคัดลอกข้อความก็ไม่ได้, ด้วยโครงสร้างทางเทคนิคแล้วตรวจสอบองค์ประกอบก็ไม่ได้ และพอลองซูมหน้าก็ไม่มีอะไรเกิดขึ้นเมื่อนึกถึงประสบการณ์นั้นกับการทำ SPA บางส่วนที่ใช้เทคโนโลยีแบบดั้งเดิมกว่า บทความนี้ก็ดูพูดถูก
ไม่ว่าจะเว็บหรือมือถือ ก็ยังไม่มีเดโม Flutter ไหนที่ทำให้ผมเชื่อว่าเป็น UX ที่น่าใช้ได้เลย
ถ้าคำสัญญาของ Flutter คือเหมือนกันทุกที่ เดโมนี้ก็คงแย่เหมือนกันบนเดสก์ท็อป
พฤติกรรมการเลื่อน ก็อยากให้ไม่ถูกเขียนทับเช่นกัน
ไม่ควรพยายาม “ปรับปรุง” ให้การเลื่อน “ลื่นขึ้น”
บน Windows อาจดูใช้ได้ แต่บน Mac หากใช้อุปกรณ์ป้อนข้อมูลของ Apple การขยับนิ้วบนแทร็กแพดหรือเมาส์จะสอดคล้องแบบ 1:1 กับการเคลื่อนไหวของสิ่งที่กำลังเลื่อน
“การปรับปรุง” แบบนี้มักให้ความรู้สึกเหมือนกำลังเลื่อนอยู่ในกากน้ำตาล
โดยทั่วไปไม่ควรพยายามปรับปรุงพฤติกรรมเริ่มต้นของเบราว์เซอร์
หนึ่งในสิ่งที่ไม่ชอบเกี่ยวกับเว็บยุคใหม่ที่เละเทะคือการไปยุ่งกับ History API
เมื่อกดลิงก์ที่ดูน่าสนใจจากที่อย่าง HN เข้าไปยังหน้าเว็บแล้วเลื่อนดู มันจะเพิ่มรายการในประวัติการเข้าชมให้กับทุกเฮดเดอร์หรือแม้แต่องค์ประกอบที่ไม่ได้สำคัญเท่าไร
ถ้าจะกลับไปยังไซต์เดิมก็ต้องกดปุ่มย้อนกลับเป็นล้านครั้ง
เกลียดทุกคนที่ทำเรื่องแบบนี้
ใช้การแบ่งหน้าแบบปกติก็พอแล้ว
มันลิงก์ได้ ค้นหาได้ นำทางได้ และทำงานร่วมกับประวัติการเข้าชมได้อย่างถูกต้อง
การเลื่อนแบบไม่สิ้นสุดทำลายทั้งหมดนี้โดยแทบไม่มีเหตุผล
ที่จริงแล้วตรงนี้มีปัญหาอยู่สองอย่างที่เก่าแก่พอ ๆ กับเว็บ: ความคาดหวังที่ต่ำ และการขาดมาตรฐานหรือเกณฑ์ที่กำหนดว่าคนหรือการทำงานจริงควรเป็นอย่างไร
ทุกวันนี้ดูประกาศรับสมัครงานก็มีแต่ “Senior Fullstack Engineer” แต่พอเข้าไปดูจริง ๆ สิ่งที่ต้องการมักเป็นชุด Java หรือ Python, R, Spring, SQL
ถ้าไม่ใช่ฟูลสแต็กแต่เขียนแบบนั้น ก็เท่ากับทำให้คนเสียเวลา และส่งสัญญาณต่อสาธารณะว่าคุณไม่เข้าใจหรือไม่ใส่ใจเทคโนโลยี
ในการเขียนโปรแกรมเรียกสิ่งนี้ว่า “ปัญหา X/Y” เป็นแอนติแพตเทิร์นที่ควรแก้สถานะปลายทาง X ที่ต้องการ แต่กลับพูดถึงแค่แนวทาง Y ที่ตัวเองอยากใช้แทน
ผลคือผู้จ้างงานได้รับเรซูเม่ 500 ฉบับจากประกาศเดียว แต่ก็ยังรู้สึกว่าไม่มีใครเหมาะสม
จุดเริ่มต้นควรเป็นเป้าหมาย เช่น “เรากำลังจ้างเพื่อสร้างแอปไคลเอนต์/เซิร์ฟเวอร์แบบนี้ ผู้สมัครต้องเขียนและซัพพอร์ตฟังก์ชัน X, Y, Z และมีข้อจำกัด A, B, C”
เหตุผลที่บริษัททำแบบนี้ไม่ได้มักเป็นเพราะพวกเขาไม่รู้จริง ๆ ว่าตัวเองทำอะไรอยู่ และแบกรับเทคโนโลยีที่พังจากการเดินผิดทางมาหลายต่อหลายครั้ง นั่นจึงเรียกว่าหนี้ทางเทคนิค
เมื่อเป้าหมายชัดเจนแบบนี้ ทั้งบริษัทและผู้สมัครจะรู้ว่าต้องตรวจสอบอะไรในการสัมภาษณ์ และคัดกรองกันและกันได้อย่างเหมาะสม ไม่เช่นนั้นมันจะกลายเป็นกระบวนการอันเลวร้ายที่เหมือนเอานัดบอดมาผสมกับเกมโชว์
ตัวอย่างเช่น สามารถระบุได้ว่ากำลังจ้างเพื่อสร้างแอปพลิเคชันประชุมสื่อที่กระจายตัวสูง โดยนักพัฒนาต้องเขียน TypeScript เชื่อมต่อข้อมูลสตรีมของซ็อกเก็ตด้วยไปป์ ทำงานทั้งฝั่งเบราว์เซอร์และเซิร์ฟเวอร์ และเขียนระบบทดสอบอัตโนมัติ
ข้อจำกัดด้านการปฏิบัติงานรวมถึงการปฏิบัติตาม WCAG AA เช็กลิสต์การปฏิบัติตามข้อกำหนดด้านความเป็นส่วนตัวที่ฝ่ายกฎหมายจัดทำ และข้อพิจารณาด้านประสิทธิภาพที่มุ่งเป้าไปที่ความเร็วในการทำงานและความหน่วงของเครือข่าย ส่วนผู้สมัครในอุดมคติควรแสดงแนวทางแก้ปัญหาความหน่วงของเครือข่าย ลอจิกแอปพลิเคชันบนเบราว์เซอร์ และการจัดการสถานะของข้อมูลสตรีมมิงได้ในการสัมภาษณ์