Dickover คืออะไร?

• dickover คือสิ่งรบกวนที่เว็บไซต์หรือแอปใช้แผงโมดัล ป๊อปโอเวอร์ หรือ UI แบบม่านมาบังเนื้อหาของตัวเอง และบังคับให้ผู้ใช้โต้ตอบโดยไม่จำเป็น
• คำขออย่างการยอมรับคุกกี้ สมัครจดหมายข่าว ติดตั้งแอป หรือยอมรับข้อกำหนดการใช้งาน เป็นตัวอย่างเด่นของสิ่งที่ไม่เกี่ยวโดยตรงกับเนื้อหาที่ผู้ใช้ตั้งใจจะอ่าน
• ตัวอย่างสำคัญได้แก่ม่านเต็มหน้าจอบนหน้าแรกของ Substack, การบังคับสมัครรับ SMS ของ Philadelphia Inquirer และความขัดแย้งของแกน Z บน Tom’s Hardware
• dickbar บังเพียงบางส่วนของหน้าและบังคับการกระทำที่จำเป็นน้อยกว่า แต่ก็ยังทำลายประสบการณ์ด้วยการทับข้อความและรบกวนการเลื่อนด้วยสเปซบาร์
• ขั้นตอนสมัครสมาชิกหรือล็อกอินของเพย์วอลล์แตกต่างจาก dickover เพราะเป็นกระบวนการที่จำเป็นต่อการเข้าถึงเนื้อหา โดยเกณฑ์สำคัญคือ ความไม่จำเป็น และการขัดขวางความสนใจ

---

นิยามและปัญหาของ Dickover

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

ประเภทและกรณีที่พบบ่อย

• dickover ที่ขอให้ยอมรับคุกกี้พบได้บ่อยมาก โดยมี กรณีของ Euronews และ กรณีของ Gallup
• การบังคับสมัครจดหมายข่าวก็ใช้รูปแบบเดียวกัน รวมถึง กรณีของ Om Malik ซึ่งเป็นบล็อกส่วนตัว และ กรณีของ Field Notes ซึ่งเป็นเว็บไซต์แบรนด์
• หน้าแรกของบล็อกที่โฮสต์บน Substack จะแสดง dickover ในรูปแบบที่เลวร้ายเป็นพิเศษ
  • เป็น ม่านเต็มหน้าจอ ที่ไม่ได้ดูเหมือนแผงชัดเจน แต่สื่ออย่างแรงว่าหากอยากอ่านบทความต้องสมัครอีเมลจดหมายข่าวก่อน
  • ปุ่มปิดถูกวางเป็นลิงก์ข้อความเล็ก ๆ ที่ไม่ได้ดูเหมือนปุ่ม
  • กรณีของ Paul Krugman และ กรณีของ Matt Yglesias ใช้ข้อความอย่าง “No thanks”
  • กรณีของ Volts ใช้ถ้อยคำหวานเลี่ยนเกินไปอย่าง “Just gimme that content!”
• กรณีของ The Philadelphia Inquirer บังคับให้แม้แต่ผู้สมัครสมาชิกเดือนละ 20 ดอลลาร์ ที่ล็อกอินอยู่แล้ว ต้องสมัครรับ SMS เกี่ยวกับ Jersey shore ก่อนจึงจะอ่านบทความได้
• กรณีของ Tom’s Hardware แสดงให้เห็นความขัดแย้งของ JavaScript บนแกน Z ที่ทำให้ dickover ของเว็บไซต์ถูกโฆษณาของตัวเองบังซ้ำอีกชั้น

หน้าเว็บควรทำหน้าที่อะไร

• เมื่อผู้ใช้เข้าเว็บไซต์ ผู้ใช้ควรเห็น เนื้อหาของเว็บไซต์ ได้ทันที
• การแสดง dickover อย่าง “สมัครจดหมายข่าว” หรือ “ยอมรับคุกกี้” ก่อนบนหน้าบทความ ขัดกับจุดประสงค์พื้นฐานของหน้าเว็บ
• หน้าเว็บควรแสดงหน้าเว็บ และอีเมลควรแสดงเนื้อหาอีเมล
• ความสนใจที่ผู้ใช้มอบให้กับบทความ เรื่องราว หรือหน้าสินค้า เป็นสิทธิพิเศษที่เว็บไซต์ได้รับ และการตั้งใจตัดความสนใจนั้นถือว่าไม่เหมาะสม

จังหวะเวลาการแสดงที่สร้างการรบกวนยิ่งกว่าเดิม

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

ความแตกต่างจาก Dickbar

• Dickbar เกี่ยวข้องกับ dickover แต่ในแง่การออกแบบและประสบการณ์ผู้ใช้ถือว่าเป็นการละเมิดที่เบากว่า
• dickbar คือป๊อปโอเวอร์แบบไม่เป็นโมดัล ซึ่งบังเพียงบางส่วน ไม่ใช่ทั้งเนื้อหาด้านล่างทั้งหมด
  • โดยทั่วไปมักอยู่ในรูปแถบแนวนอนสั้น ๆ และมี ตัวอย่างบนเดสก์ท็อป กับ ตัวอย่างบนมือถือ
  • กรณีของ Apple Newsroom อยู่ในรูปแบบที่ดูดีพอสมควร
  • กรณีของ Acquired podcast ถูกวางไว้ที่มุมหน้าจอจึงรบกวนน้อยกว่า
  • กรณีของ Four Seasons มีขนาดใหญ่เกินไปจนแทบใกล้เคียง dickover
• เหตุผลที่ dickbar แย่น้อยกว่าคือมันไม่ได้บังทั้งหน้า และไม่ได้บังคับให้ต้องทำ การกระทำที่จำเป็น เพื่อปิด
• ถึงอย่างนั้น dickbar ก็ยังบังเนื้อหาและดึงความสนใจออกไป ทำลายประสบการณ์ผู้ใช้
• โดยเฉพาะ dickbar แนวนอนซึ่งพบได้บ่อยที่สุด จะสร้างปัญหาเมื่อเลื่อนทีละหน้าด้วยสเปซบาร์
  • หน้าเว็บจะเลื่อนตามความสูงของทั้งหน้า โดยไม่หักความสูงของ dickbar ออก
  • ผลคือทุกครั้งที่เลื่อนไปหน้าถัดไป dickbar จะยังคงบังข้อความที่ยังไม่ได้อ่าน

เส้นแบ่งระหว่างตัวบล็อกแบบโมดัลกับ Dickover

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

ที่มาของคำนี้

• ในปี 2022 เริ่มมีการเรียก UI แบบนี้ว่า dickpanel แต่ต่อมา dickover กลายเป็นคำที่เหมาะกว่า
• คำใหม่นี้ผุดขึ้นมาในระหว่างที่กำลังจะ เขียนถึง ยูทิลิตี “ชั้นวาง” drag-and-drop สำหรับ Mac ชื่อ Dropover
• ก่อนหน้านั้นไม่นาน มี โพสต์บ่น เกี่ยวกับตัวบล็อกคุกกี้แบบโมดัลของ Euronews ที่ชวนขำเป็นพิเศษ และทำให้รู้สึกว่าคำว่า dickpanel เดิมไม่ค่อยลงตัว
• ใน แบบสำรวจบน Mastodon มีการถามว่าควรเรียก “กล่องโต้ตอบปลอมในหน้าต่างที่มาปิดทับเนื้อหาบนเว็บไซต์และบางแอป” ว่าอะไรดีกว่า และจากคำตอบ 1,130 รายการ dickover ชนะเฉียดฉิวที่ 51 ต่อ 49
• เกณฑ์ที่ทำให้คำใหม่ติดตลาดไม่ใช่ความอธิบายได้ชัดหรือความชัดเจนเสมอไป แต่อยู่ที่การถูกใช้งาน และ dickover ดูเป็นคำที่คมและใช้แล้วสะใจ

[GN⁺]

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

• ประสบการณ์ของผมน่าจะเป็นไปตามที่ตั้งใจไว้พอดี ผมกดลิงก์ “What is a dickover?” พร้อมจินตนาการว่ามันคืออะไร พอหน้าเว็บโหลดขึ้นมา หลังจากค้างไปแวบเดียว ป๊อปอัปขนาดใหญ่ที่น่ารำคาญพร้อมข้อความ “This is a Dickover” ก็เด้งมาตบหน้า และผมก็เข้าใจทันที
  ตอนนี้อย่างน้อยก็รู้แล้วว่าคราวหน้าถ้าเจอสิ่งนี้บน Substack จะเรียกมันว่าอะไร

• ผมมีสมมติฐานว่าประมาณ 97% ของนักพัฒนาและผู้ดูแลระบบ กดผ่านอะไรอย่างการยินยอมคุกกี้ของผลิตภัณฑ์ตัวเองไปตั้งแต่ 5 ปีก่อน แล้วก็ไม่เคยเห็นมันอีกเลย เลยไม่รู้ว่าประสบการณ์ของลูกค้าใหม่จริง ๆ มันแย่แค่ไหน
  นักพัฒนากับหัวหน้าคิดว่าตัวเองทำได้ยอดเยี่ยมและหน้าแรกก็ขัดเกลามาดีแล้ว แต่ผู้ใช้ทั่วไปกลับต้องเจอ Cloudflare captcha, โมดัลคุกกี้, โมดัลจดหมายข่าว, โมดัลติดตั้งแอป เรียงกันมาเป็นชุด และทั้งหมดก็ขวางการเข้าถึงปุ่ม ‘ซื้อสินค้า’

  • ที่สุดคือพอปฏิเสธแล้ว หน้าถัดไปก็มาถามอีก
    สงสัยจะไม่รู้ว่าคำว่า functional cookies หมายถึงอะไร ในภาษาการตลาดอาจมีแค่ YES ก็ได้
  • ถ้า “ไม่เคยเห็นอีกเลย” ก็ฟังดูเป็นการทำที่ดีกว่า dickover 99.9% ที่ผมเจอ
    ส่วนใหญ่นี่ปิดแล้วเดี๋ยวก็กลับมาอีก บางอันเหมือนโผล่มาทุกครั้งที่เข้าเว็บ
  • อีกสมมติฐานหนึ่งคือพวกเขาไม่สนว่าลูกค้าจะคิดยังไง
  • นักพัฒนาไม่ได้เก่งในการตัดสินว่าอะไรดีที่สุดสำหรับประสบการณ์ผู้ใช้ จะให้ไปหักล้างชั่วโมงการวิจัยในอุตสาหกรรมหลายแสนชั่วโมงที่ดีไซเนอร์และ PM ทุ่มให้กับหน้าแรกที่สวยงามและลื่นไหล พร้อมโมดัลที่โหลดตามมาติด ๆ ได้ยังไง
    จะบอกว่าช่วยปล่อยให้เป็นหน้าที่ของ ผู้เชี่ยวชาญ เถอะ
  • เว็บไซต์ควรทดสอบใน หน้าต่างไม่ระบุตัวตน เสมอ

• หนึ่งในเกณฑ์ที่จะได้อยู่ใน Kagi Small Web คือไม่มี dickover ขอบคุณ John ที่ตั้งชื่อให้มันได้ตรงจริง ๆ
  [1] https://kagi.com/smallweb

  • น่าจะทำให้แชร์ ลิงก์ต้นฉบับ ของบทความใน Small Web ได้ง่ายกว่านี้ ตอนนี้มันยากเกินไปจนเหมือนกำลังบังคับให้คนแชร์ URL เวอร์ชันของ Kagi
  • หน้านี้น่าจะมีข้อยกเว้นได้
  • อ้างอิงจากที่ผมกด “next” สามครั้ง ก็เจอหน้าที่มี คุกกี้ dickover แล้ว ดูเหมือนต้องปรับฟิลเตอร์อีกหน่อย
  • ช่วงเวลาที่เป็น dickover ของจริงคือหลังจากเริ่มใช้บริการไปแล้ว แล้วเพิ่งมารู้ว่าพวกเขาทำธุรกิจกับ Yandex

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

• ผมสนับสนุนชื่อนี้ ถ้ามันกลายเป็นชื่อมาตรฐานของเทคนิคนี้ คนก็จะต้องใช้คำนั้นเวลานำเสนออย่างจริงจังในที่ประชุม และมันจะทำให้เสนออย่างจริงจังได้ยากขึ้น
  “นี่คือดีไซน์ Dickover ของเรา”
  “ทุกคนครับ ผมว่าเราไม่ควรทำ Dickover กับลูกค้านะ”
  “พอพูดแบบนั้นแล้วมันฟังดูไม่ค่อยดีเลยนะ...”
  บทส่งท้าย: อีก 6 เดือนต่อมา เว็บไซต์ก็เจ๊งเพราะไม่มีใครสมัครจดหมายข่าวเลย

  • คนพวกนั้นเป็นใครกันแน่ หมายถึงคนที่โดน dickover แปะหน้าแล้วยังไม่โกรธแม้แต่นิดเดียว ยังอารมณ์ดีต่อไป และถึงขั้นพิจารณาอย่างจริงจังว่าจะกรอก อีเมล ลงไปใน dickover นั้น

• bookmarklet นี้ดีมากถ้ามีติดไว้

  javascript:(function()%7B let i%2C elements %3D document.querySelectorAll('body *')%3B for (i %3D 0%3B i < elements.length%3B i%2B%2B) %7B if(getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed' %7C%7C getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'sticky')%7B elements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B %7D %7D %7D)()  
  

  บางครั้งหลังใช้ตัวข้างบนแล้ว ก็ยังต้องใช้ตัวที่สองนี้เพื่อแก้ การเลื่อนหน้า

  javascript:var r="html,body{overflow:auto !important;}"; var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode(r)); document.body.appendChild(s); void 0;  
  

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

  • แนวปฏิบัติชวนสงสัยของ Substack ยังไม่แย่เท่าจุดยืนทางการเมืองชวนสงสัยของพวกเขา
    https://www.theguardian.com/media/2026/feb/07/revealed-how-s...

• สำหรับคนอย่างผมที่อ่านเว็บไซต์ด้วยการ ซูมเข้า สิ่งพวกนี้น่ารำคาญเป็นพิเศษ
  ถ้าจะหาปุ่มปิดก็ต้องซูมออกอีก กลายเป็นเกมไล่จับทุกครั้ง และบางทีก็ทำให้ยอมแพ้ไปเลย
  มี EU Web Accessibility Directive อยู่ แต่ผมไม่เข้าใจว่าอะไรแบบนี้ยังถูกปล่อยให้มีได้ยังไง

  • ตัว HN เองก็แย่มากถ้า สเกล UI มากกว่า 1.0
    ต้องเลื่อนแนวนอนไปมาอยู่เรื่อยเพื่อให้อ่านข้อความได้

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

  • ฟีเจอร์ Hide Distracting Items ของ Safari เป็นเหตุผลใหญ่ที่ผมไม่ใช้ Chrome
  • ตอนเห็น dickover แบบตัวพิมพ์เล็กครั้งแรก ผมอ่านเป็น clickover

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

  • สงสัยจริง ๆ ว่า จะมีอะไรในระดับ การทำงานของ JavaScript, DOM หรือฝั่งเบราว์เซอร์ ที่พอจะบล็อก dickover โดยเฉพาะได้ โดยยังคงอนุญาตคอนเทนต์ป๊อปโอเวอร์แบบที่ต้องการ เช่น เมนูดรอปดาวน์, tooltip และแถบนำทางแบบลอยอยู่ได้ somehow ไหม?