Dickoverとは何か？

 (daringfireball.net)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • dickover は、ウェブサイトやアプリがモーダルパネル・ポップオーバー・カーテン型UIで自分のコンテンツを覆い隠し、不必要な操作を強要する妨害物である
  • Cookie受け入れ、ニュースレター登録、アプリのインストール、利用規約への同意のように、ユーザーが読もうとしていたコンテンツと直接関係のない要求が代表例である
  • Substack ホームの全画面カーテン、Philadelphia Inquirer のSMS登録要求、Tom’s Hardware のZ軸衝突が主な事例である
  • dickbar はページの一部だけを覆い、必須操作の要求も比較的少ないが、テキストを隠し、スペースバーによるスクロールを妨げて体験を損なう
  • ペイウォールの登録・ログインはコンテンツへのアクセスに必要な手続きであり dickover とは異なり、核心となる基準は 不必要性 と関心の遮断である

Dickoverの定義と問題

  • dickover は、ウェブサイトやアプリが自分のコンテンツを意図的に隠すモーダルパネル、ポップオーバー、カーテン型UIを指す
  • ユーザーが望んでおらず、必要でもない操作を強要し、コンテンツへのアクセスを妨げる
  • 代表的な要求は Cookieの受け入れ、ニュースレター購読、モバイルアプリのインストール、サービス利用規約への同意のように、ユーザーが読もうとしていた内容と直接関係のないものである
  • ウェブやモバイルアプリでますます頻繁に見られるようになっており、一般的なポップオーバーよりもさらに直接的にユーザーの読書の流れを断ち切る

よくある種類と事例

  • Cookie許可を求める dickover は非常に一般的で、Euronewsの事例 や Gallupの事例 がある
  • ニュースレター登録の要求も同じパターンで使われており、個人ブログの Om Malikの事例 やブランドサイトの Field Notesの事例 が含まれる
  • Substack がホスティングするブログのホームページには、特に悪質な形の dickover が表示される
    • パネルのように見えない 全画面カーテン で、記事を読むにはメールニュースレターに登録しなければならないかのように強く示唆する
    • 閉じるボタンは、ボタンに見えない小さなテキストリンクとして配置されている
    • Paul Krugman と Matt Yglesias の事例は “No thanks” のような文言を使っている
    • Volts の事例は “Just gimme that content!” のような、過度に気取った文句を使っている
  • The Philadelphia Inquirerの事例 では、月 20ドル の購読者がログイン済みであっても、Jersey shore 関連SMSの受信登録をしなければ記事を読めないようにしている
  • Tom’s Hardwareの事例 は、サイトの dickover が自サイトの広告に再び隠される JavaScript のZ軸衝突を示している

ウェブページが果たすべきこと

  • ウェブサイトを訪れたなら、ユーザーは ウェブサイトのコンテンツ をすぐに見られるべきである
  • 記事ページで「ニュースレター購読」や「Cookie受け入れ」の dickover を先に表示するのは、ウェブページの基本的な目的に反する
  • ウェブページはウェブページを表示すべきであり、メールはメールの内容を表示すべきである
  • 記事、ストーリー、製品ページに向けられたユーザーの関心は、そのサイトが得た特権であり、その関心を意図的に断ち切る行為は不適切である

表示タイミングが生むより大きな妨害

  • 一部のサイトはページ読み込み直後に dickover を表示し、ユーザーは今やウェブページの読み込み時にこうした障害物をある程度予想している
  • さらに悪いのは、ユーザーがすでに読み始めてスクロールした後で 突然 dickover を出すやり方である
  • 読書中の妨害は、ユーザーがすでに与えた関心とは別のものを要求するために、実際の本や雑誌を手から奪い取る行為と変わらない
  • 物理的な出版物を読者の手から奪えば顔を殴られてもおかしくない、という比喩のとおり、読書体験を断ち切る行為はそれほど攻撃的である

Dickbarとの違い

  • Dickbar は dickover と関係があるが、デザインとユーザー体験の面ではより軽い違反と分類される
  • dickbar は非モーダルのポップオーバーで、下にあるコンテンツ全体ではなく一部だけを覆う
  • dickbar が比較的ましなのは、ページ全体を隠さず、閉じるための 必須操作 も要求しないためである
  • それでも dickbar はコンテンツを隠し、注意をそらしてユーザー体験を損なう
  • 特に最も一般的な横長の dickbar は、スペースバーで1画面ずつ送るときに問題を起こす
    • ページは dickbar の高さを差し引かず、ウェブページ全体の高さぶんだけスクロールされる
    • その結果、次の画面へ移動するたびに dickbar がまだ読んでいないテキストを隠してしまう

モーダル遮断物とDickoverの境界

  • すべての dickover はモーダル遮断物だが、すべてのモーダル遮断物が dickover というわけではない
  • 有料コンテンツの登録またはログインパネルは dickover ではない
  • ペイウォールは時に煩わしいこともあるが、dickover の核心条件の一つは 不必要性 である
  • Cookie権限の要求やメールニュースレター登録の要求は、コンテンツを読むために必要ではない
  • 一方でペイウォールのコンテンツでは登録やログインが必要であるため、dickover とは区別される

用語が生まれた背景

  • 2022年にはこの種のUIを dickpanel と呼び始めていたが、その後 dickover の方がより適切な表現として定着した
  • この新語は、Mac向けのドラッグ＆ドロップ「棚」ユーティリティ Dropover について 書こうとしていた過程 で思いつかれた
  • その直前には、Euronews のとりわけばかげた Cookie モーダル遮断物について 不満を述べた投稿 があり、既存の dickpanel という表現はしっくりこないと感じるようになっていた
  • Mastodonアンケート では、「ウェブサイトや一部アプリがコンテンツを覆うウィンドウ内の偽ダイアログ」を何と呼ぶのがよいかを尋ね、1,130件の回答で dickover が 51対49 で僅差の勝利を収めた
  • 新語が定着する基準は説明性や明確さよりも実際に使われるかどうかであり、dickover は鋭く、使っていて楽しい表現に見える

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • 私の体験は、たぶん意図どおりそのものだったと思う。"What is a dickover?" のリンクをクリックしながら、これは何だろうと想像していたのだが、ページが表示されてごく短い間があった直後に、"This is a Dickover" という大きくてイラつくポップアップが顔面に飛び込んできて、すぐ理解した
    これで次に Substack に行ったとき、これを何と呼べばいいかは分かった

  • 開発者や管理者の 97% くらいは、5年前に自分の製品のクッキー同意みたいなものを一度済ませてしまって以来もう見ておらず、そのせいで新規顧客体験が実際にどれほどひどいか分かっていない、という仮説がある
    開発者や上司たちは、自分たちは素晴らしい仕事をしていてホームページもよく磨かれていると思っているが、一般ユーザーは Cloudflare の CAPTCHA、クッキーモーダル、ニュースレターモーダル、アプリインストールモーダルを順番に食らい、しかも全部が「製品を購入」ボタンへのアクセスを妨げている

    • 断ると次のページでまた聞いてくるやつが最高
      たぶん 機能性クッキー が何か分かっていないのだろう。マーケティング語彙には YES しかないのかもしれない
    • 「二度と表示しない」なら、私が遭遇する dickover の 99.9% よりましな実装に聞こえる
      ほとんどは閉じても後でまた出てくるし、中にはサイトを訪れるたびに出る感じのものもある
    • 顧客がどう思うかなんて気にしていない、という仮説もある
    • 開発者は、ユーザー体験にとって何が最善かを判断するのが得意ではない。デザイナーや PM がその美しくて高性能なファーストビューのデザインと、それに続く自動ロードモーダルに注ぎ込んだ業界研究の何十万時間を、どうやって正当化するのか
      要するに 専門家 に任せろということだ
    • Webサイトは常に シークレットウィンドウ でテストすべき

  • Kagi Small Web に掲載される基準のひとつが dickover がないことだ。きちんと名前を付けてくれてありがとう、John
    [1] https://kagi.com/smallweb

    • Small Web 記事の 元リンク をもっと簡単に共有できるようにしてほしい。今は難しすぎて、Kagi 版 URL を共有させようとしているようにすら感じる
    • この特定のページには例外を設けてほしい
    • ちなみに「next」を3回押したら クッキー dickover のあるページが出てきた。フィルターを少し調整したほうがよさそう
    • 本当の dickover の瞬間は、サービスを使い始めたあとで彼らが Yandex と取引していると気づくときだ

  • JavaScript をオン・オフできる ブラウザ拡張機能 を設定しておけば、たいていのポップアップ、うるさい画面、クッキー要求を防げる。そういう拡張はいくつもある
    代わりに、JavaScript を常時オフにした別ブラウザをトレイやバックグラウンドで最小化しておく方法もある
    購読を要求したり、うるさい画面を出したり、ほかのブロックを使ったりする多くのWebサイトは、JavaScript を切るだけで読める
    Webサイトの JavaScript は、企業が私たちを操作・統制し、うるさい画面を出したり購読を求めたりするための手段になってしまっている
    読み込み前に JavaScript を要求するサイトに遭遇したら、もう見捨てて二度と見ない

  • この名前を支持する。この手法の標準名称になれば、会議で真面目に提案するときに皆がその単語を使わなければならず、そうなれば真面目に提案しづらくなる
    「これが我々の Dickover デザインです」
    「皆さん、顧客に Dickover をかますのはちょっとどうかと思います」
    「そう言われるとちょっとまずいですね……」
    エピローグ: 6か月後、ニュースレター転換率はまったく伸びず、サイトは潰れる

    • いったいそんな人たちは誰なんだ？ dickover を顔に食らってもまったく怒らずに楽しそうにし、その dickover に メールアドレス を入力することを本気で検討する人たちのことだ

  • この ブックマークレット は持っているととても便利

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

    ときどき、これを使ったあと スクロール を直すために、この2つ目も必要になる

    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 を使うのをやめる には十分だ
    読者にそんなことはしたくない

  • 私のようにWebサイトを読むために 拡大表示 している人間にとって、こういうものは特に腹が立つ
    閉じるボタンを探すにはまた縮小しなければならない。毎回追いかけっこで、時にはそのまま諦めてしまう
    EU Web Accessibility Directive があるのに、どうしてこういうものが許されているのか分からない

    • HN 自体も UI倍率 が 1.0 より大きいとひどい
      テキストを読むためにずっと横スクロールする羽目になる

  • これが巧妙な keming の言葉遊びだと思った人が他にもいたのか気になる
    幸い、コンテンツに JavaScript が必要だったり dickover を除去するのに JavaScript が必要だったりするサイトでも、ブラウザの要素検査ツールでこうしたものや他の鬱陶しい要素を削除するのはそれほど難しくなく、かなりスッとする

    • Safari の Hide Distracting Items 機能は、私が Chrome を使わない大きな理由だ
    • dickover の小文字版を最初に見たときは、clickover と読んだ

  • 私に言わせれば、dickover が可能であるという事実そのものが、あらゆる JavaScript インタープリタ のバグだ
    まともなブラウザなら、dickover だけでなく、Webページが右クリックメニューを改変したりテキスト選択を妨げたりするような関連する敵対的挙動も不可能にすべきだと思う
    残念ながらスクリプトを完全にオフにするのは、多くのサイトがまったく動かなくなるので解決策になりにくいが、上で挙げたような挙動はユーザーにとって有益な目的がまったくないのだから、効かないようにすべきであり、敵対的なサイト側にもその挙動が効いているかどうかを知る方法があってはならない
    モーダルウィンドウは、自分が制御するアプリケーションでは時々便利かもしれないが、インターネット上のサイトを閲覧するときのように外部が制御するアプリケーションでは、常に 無視または回避 できるべきだ

    • 本当に気になるのだが、望ましいモーダルポップオーバーコンテンツであるドロップダウンメニュー、ツールチップ、フローティングナビゲーションバーは許容しつつ、どうにか dickover だけを防ぐために JavaScript 実装 や DOM、ブラウザ側で何かできるのだろうか？