Dickover là gì?

• dickover là một dạng cản trở khi website hoặc ứng dụng che nội dung của chính mình bằng bảng điều khiển dạng modal, popover hoặc UI kiểu rèm, rồi ép người dùng thực hiện những tương tác không cần thiết
• Những yêu cầu điển hình là chấp nhận cookie, đăng ký nhận bản tin, cài ứng dụng, đồng ý điều khoản sử dụng — các thứ không liên quan trực tiếp đến nội dung mà người dùng định đọc
• Các ví dụ tiêu biểu gồm rèm toàn màn hình trên trang chủ Substack, yêu cầu đăng ký SMS của Philadelphia Inquirer, và xung đột trục Z trên Tom’s Hardware
• dickbar chỉ che một phần trang và đòi hỏi ít hành động bắt buộc hơn, nhưng vẫn làm hỏng trải nghiệm vì đè lên văn bản và cản cuộn bằng phím cách
• Paywall với bước đăng ký hoặc đăng nhập khác với dickover vì đó là thủ tục cần thiết để truy cập nội dung; tiêu chí cốt lõi là tính không cần thiết và việc chặn sự chú ý

---

Định nghĩa và vấn đề của Dickover

• dickover là thuật ngữ chỉ các bảng modal, popover hoặc UI kiểu rèm mà website hay ứng dụng cố tình dùng để che nội dung của chính mình
• Nó cản trở việc truy cập nội dung bằng cách ép người dùng thực hiện những tương tác mà họ không muốn và cũng không cần
• Những yêu cầu điển hình gồm chấp nhận cookie, đăng ký nhận bản tin, cài ứng dụng di động, hoặc đồng ý điều khoản dịch vụ — những thứ không liên quan trực tiếp đến nội dung mà người dùng định đọc
• Chúng xuất hiện ngày càng thường xuyên trên web và trong ứng dụng di động, và còn ngắt dòng đọc của người dùng trực diện hơn cả popover thông thường

Các kiểu phổ biến và ví dụ

• Dickover yêu cầu cho phép cookie là loại rất phổ biến, với ví dụ Euronews và ví dụ Gallup
• Yêu cầu đăng ký nhận bản tin cũng dùng cùng một mô thức, gồm ví dụ Om Malik trên blog cá nhân và ví dụ Field Notes trên website thương hiệu
• Trang chủ các blog do Substack lưu trữ đặc biệt hay hiện ra một dạng dickover rất tệ
  • Nó dùng một rèm toàn màn hình trông không giống bảng điều khiển, tạo cảm giác rất mạnh rằng muốn đọc bài thì phải đăng ký bản tin qua email
  • Nút đóng được đặt thành một liên kết chữ nhỏ trông không giống nút bấm
  • Các ví dụ Paul Krugman và Matt Yglesias dùng những câu như “No thanks”
  • Ví dụ Volts dùng câu chữ quá ngọt kiểu “Just gimme that content!”
• Ví dụ The Philadelphia Inquirer buộc cả người đăng ký trả 20 USD mỗi tháng, dù đã đăng nhập, vẫn phải đăng ký nhận SMS về Jersey shore mới xem được bài báo
• Ví dụ Tom’s Hardware cho thấy xung đột trục Z của JavaScript khi dickover của chính website lại bị quảng cáo nội bộ đè lên lần nữa

Trang web nên làm gì

• Khi truy cập một website, người dùng phải có thể nhìn thấy nội dung của website ngay lập tức
• Việc hiển thị dickover “đăng ký bản tin” hay “chấp nhận cookie” trước trên trang bài viết đi ngược lại mục đích cơ bản của một trang web
• Trang web nên hiển thị trang web, và email nên hiển thị nội dung email
• Sự chú ý mà người dùng dành cho bài viết, câu chuyện hoặc trang sản phẩm là một đặc quyền mà website có được, và việc cố tình cắt ngang sự chú ý đó là không phù hợp

Thời điểm hiển thị tạo ra sự quấy rối lớn hơn

• Một số website bật dickover ngay sau khi tải trang, và ngày nay người dùng phần nào đã dự đoán trước những chướng ngại như vậy khi trang web mở ra
• Tệ hơn nữa là khi người dùng đã bắt đầu đọc và cuộn xuống rồi mà dickover bất ngờ xuất hiện
• Việc ngắt giữa lúc đang đọc chẳng khác nào giật cuốn sách hoặc tạp chí khỏi tay người đọc để đòi hỏi một thứ khác ngoài sự chú ý mà họ đã dành sẵn
• Giống như phép ví von rằng nếu giật ấn phẩm giấy khỏi tay độc giả thì có thể bị đấm vào mặt, việc cắt ngang trải nghiệm đọc cũng mang tính công kích đến mức đó

Khác biệt với Dickbar

• Dickbar có liên quan đến dickover, nhưng về mặt thiết kế và trải nghiệm người dùng thì được xem là một mức vi phạm nhẹ hơn
• dickbar là một popover không theo kiểu modal, chỉ che một phần nội dung bên dưới chứ không che toàn bộ
  • Thường là một thanh ngang ngắn, với ví dụ trên desktop và ví dụ trên di động
  • Ví dụ Apple Newsroom là một dạng trông tương đối ổn
  • Ví dụ podcast Acquired được đặt ở góc màn hình nên ít gây phiền hơn
  • Ví dụ Four Seasons quá lớn đến mức gần như là dickover
• Dickbar tương đối đỡ tệ hơn vì không che toàn bộ trang và không yêu cầu hành động bắt buộc để đóng
• Dù vậy, dickbar vẫn che nội dung và làm phân tán sự chú ý, từ đó làm hỏng trải nghiệm người dùng
• Đặc biệt, kiểu dickbar nằm ngang phổ biến nhất gây vấn đề khi dùng phím cách để cuộn từng màn hình
  • Trang vẫn cuộn theo toàn bộ chiều cao của webpage mà không trừ đi phần chiều cao của dickbar
  • Kết quả là mỗi lần chuyển sang màn hình tiếp theo, dickbar lại che mất phần văn bản mà người dùng vẫn chưa đọc

Ranh giới giữa modal blocker và Dickover

• Mọi dickover đều là modal blocker, nhưng không phải mọi modal blocker đều là dickover
• Bảng đăng ký hoặc đăng nhập cho nội dung trả phí không phải là dickover
• Paywall đôi khi có thể gây khó chịu, nhưng một trong những điều kiện cốt lõi của dickover là tính không cần thiết
• Yêu cầu quyền cookie và yêu cầu đăng ký bản tin email không cần thiết để đọc nội dung
• Ngược lại, với nội dung sau paywall thì đăng ký hoặc đăng nhập là cần thiết, nên được phân biệt với dickover

Bối cảnh ra đời của thuật ngữ

• Năm 2022, kiểu UI này từng bắt đầu được gọi là dickpanel, nhưng sau đó dickover dần trở thành cách gọi phù hợp hơn
• Thuật ngữ mới nảy ra trong lúc tác giả định viết về tiện ích “kệ” kéo thả cho Mac là Dropover, trong quá trình viết này
• Ngay trước đó có một mục phàn nàn về modal chặn cookie đặc biệt lố bịch của Euronews, và lúc ấy tác giả cảm thấy cách gọi dickpanel không còn thật sự khớp
• Trong một khảo sát trên Mastodon, tác giả hỏi nên gọi “hộp thoại giả trong cửa sổ che phủ nội dung trên website và một số ứng dụng” là gì, và trong 1.130 câu trả lời thì dickover thắng sít sao với tỷ lệ 51–49
• Tiêu chí để một từ mới bám rễ không phải là tính mô tả hay độ rõ ràng mà là việc nó có được dùng hay không, và dickover có vẻ là một cách gọi sắc bén, thú vị để sử dụng

[GN⁺]

Ý kiến trên Hacker News

• Trải nghiệm của tôi có lẽ đúng y như tác giả định làm. Khi bấm vào liên kết “What is a dickover?”, tôi đang tưởng tượng không biết đó là gì, rồi ngay sau khi trang hiện ra và chỉ khựng lại trong tích tắc, một popup to tướng khó chịu ghi “This is a Dickover” đập thẳng vào mặt tôi, và tôi hiểu ngay
  Giờ thì ít nhất lần sau vào Substack tôi cũng biết phải gọi thứ đó là gì

• Có một giả thuyết rằng khoảng 97% lập trình viên và quản trị viên đã tự hoàn tất mấy thứ như đồng ý cookie cho chính sản phẩm của họ từ 5 năm trước, rồi không bao giờ thấy lại nữa, nên họ không biết trải nghiệm của khách hàng mới thực sự tệ đến mức nào
  Lập trình viên và sếp nghĩ rằng họ đang làm rất tốt và trang chủ của họ được chau chuốt kỹ, nhưng người dùng bình thường thì lần lượt bị Cloudflare captcha, modal cookie, modal newsletter và modal cài app nện vào mặt, và tất cả đều chặn đường tới nút ‘mua sản phẩm’

  • Tuyệt nhất là loại mà bạn từ chối xong thì sang trang sau lại hỏi tiếp
    Chắc họ không biết cookie chức năng là gì. Có khi trong từ vựng marketing chỉ có mỗi YES
  • Nếu là kiểu “không bao giờ thấy lại” thì nghe còn như một bản triển khai tốt hơn 99.9% số dickover mà tôi gặp
    Đa số là đóng xong sau lại hiện, có cái còn như thể lần nào vào site cũng nhảy ra
  • Cũng có giả thuyết là họ chẳng quan tâm khách hàng nghĩ gì
  • Lập trình viên không giỏi phán đoán điều gì là tốt nhất cho trải nghiệm người dùng. Chứ nếu không thì làm sao biện minh được cho hàng trăm nghìn giờ nghiên cứu của cả ngành mà designer và PM đã đổ vào cái thiết kế màn hình đầu tiên đẹp đẽ, hiệu năng cao đó và chuỗi modal tự tải tiếp theo sau
    Ý tôi là xin hãy để chuyên gia làm việc đó
  • Website lúc nào cũng nên được thử trong cửa sổ ẩn danh

• Một trong các tiêu chí để được đưa vào Kagi Small Web là không có dickover. Cảm ơn John vì đã đặt đúng tên cho nó
  [1] https://kagi.com/smallweb

  • Sẽ rất hay nếu họ giúp chia sẻ liên kết gốc của bài trong Small Web dễ hơn. Hiện tại khó đến mức có cảm giác như họ đang cố ép mọi người chia sẻ URL bản Kagi
  • Nên có ngoại lệ cho đúng trang này
  • Nhân tiện, tôi bấm “next” ba lần thì ra một trang có cookie dickover. Có lẽ cần chỉnh lại bộ lọc
  • Khoảnh khắc dickover thực sự là sau khi bắt đầu dùng dịch vụ rồi mới nhận ra họ có làm ăn với Yandex

• Nếu thiết lập một tiện ích mở rộng trình duyệt cho phép bật tắt JavaScript, bạn có thể chặn được phần lớn popup, màn hình làm phiền và yêu cầu cookie. Có khá nhiều tiện ích như vậy
  Cách khác là để sẵn một trình duyệt khác với JavaScript bị tắt vĩnh viễn, thu nhỏ ở khay hay chạy nền
  Nhiều website đòi đăng ký, hiện màn hình làm phiền hoặc dùng các kiểu chặn khác sẽ đọc được ngay nếu chỉ cần tắt JavaScript
  JavaScript của website đã trở thành công cụ để doanh nghiệp thao túng, kiểm soát chúng ta, bật màn hình làm phiền hoặc đòi đăng ký
  Nếu gặp site bắt phải có JavaScript ngay từ trước khi tải, tôi bỏ luôn và không bao giờ quay lại

• Tôi ủng hộ cái tên này. Nếu nó trở thành tên chuẩn của kỹ thuật này, thì khi ai đó nghiêm túc đề xuất nó trong cuộc họp, họ sẽ buộc phải dùng chính từ đó, và như vậy việc đề xuất nghiêm túc sẽ khó hơn nhiều
  “Đây là thiết kế Dickover của chúng ta”
  “Mọi người ạ, tôi thấy áp Dickover lên khách hàng thế này không ổn lắm”
  “Nghe anh nói vậy thì đúng là hơi kỳ thật…”
  Hậu truyện: 6 tháng sau, tỷ lệ chuyển đổi newsletter bằng 0 và site sụp luôn

  • Rốt cuộc những người đó là ai vậy? Ý tôi là những người không hề nổi giận khi bị dickover úp vào mặt, vẫn vui vẻ tiếp tục, rồi còn nghiêm túc cân nhắc nhập địa chỉ email vào cái dickover đó nữa

• Bookmarklet này cực kỳ đáng để có sẵn

  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)()  
  

  Đôi khi sau khi dùng cái trên, còn cần thêm cái thứ hai này để sửa cuộn trang

  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;  
  

• Trên Substack, kể cả khi tôi tắt rõ ràng mấy thứ này thì nó vẫn gắn vào bài của tôi. Tôi không biết đó là bug hay là hoạt động đúng như thiết kế, nhưng như thế cũng đủ khiến tôi bỏ dùng Substack
  Tôi không muốn làm vậy với độc giả của mình

  • Những thực hành mờ ám của Substack còn chưa tệ bằng màu sắc chính trị đáng ngờ của họ
    https://www.theguardian.com/media/2026/feb/07/revealed-how-s...

• Với những người đọc website bằng cách phóng to như tôi, mấy thứ này đặc biệt bực mình
  Muốn tìm nút đóng thì lại phải thu nhỏ ra. Lúc nào cũng như rượt đuổi, và đôi khi tôi đành bỏ cuộc
  Có EU Web Accessibility Directive mà tôi không hiểu sao mấy thứ này vẫn được phép tồn tại

  • Bản thân HN cũng rất tệ nếu tỷ lệ UI lớn hơn 1.0
    Tôi cứ phải cuộn ngang liên tục chỉ để đọc văn bản

• Tôi tự hỏi có ai khác cũng nghĩ đây là một kiểu chơi chữ keming thông minh không
  May là ngay cả ở những site cần JavaScript cho nội dung hoặc cần JavaScript để gỡ dickover, thì dùng công cụ kiểm tra phần tử của trình duyệt để xóa mấy thứ này và các thành phần phiền phức khác cũng không quá khó, mà còn khá hả giận

  • Tính năng Hide Distracting Items của Safari là một trong những lý do lớn khiến tôi không dùng Chrome
  • Lần đầu thấy phiên bản viết thường của dickover, tôi đọc nhầm thành clickover

• Với tôi, việc dickover có thể tồn tại bản thân nó đã là lỗi của mọi trình thông dịch JavaScript
  Một trình duyệt đúng nghĩa lẽ ra phải khiến không chỉ dickover mà cả các hành vi thù địch liên quan như web page sửa menu chuột phải hoặc chặn chọn văn bản cũng trở nên bất khả thi
  Đáng tiếc là tắt hẳn script không phải giải pháp khả thi vì nhiều site sẽ hoàn toàn không hoạt động, nhưng các hành vi kể trên không hề có mục đích hữu ích nào cho người dùng, nên chúng phải không có tác dụng, và cũng không được để cho site thù địch có cách biết được là hành vi đó có hiệu lực hay không
  Cửa sổ modal đôi khi có thể hữu ích trong các ứng dụng do tôi kiểm soát, nhưng trong các ứng dụng do bên ngoài kiểm soát như khi duyệt các site trên Internet, thì nó phải luôn có thể bị bỏ qua hoặc vượt qua

  • Tôi thật sự tò mò, liệu ở phía triển khai JavaScript, DOM hay trình duyệt có thể làm gì để somehow chỉ chặn dickover, trong khi vẫn cho phép các nội dung popover/modal mong muốn như menu thả xuống, tooltip và thanh điều hướng nổi không?