バグブラインドネス

最初に著者が見える「バグ」の例が検索結果だった時、他の人には見えないのを見て、もう諦めるしかなかった。「場合によっては、実際の検索結果を送ってくれた人もいたけど、どれも私が見える良い結果は含まれてなかった。」期待に応えられないソフトウェア、特にSEOと検索エンジンの間の長い戦争のような分野では、これは「バグ」じゃないよね。たとえば、ランダムな本を手に取った時にそれがつまらないからって、出版業界に「バグ盲目」があるって言ってるようなもんだ。確かに何かが間違ってるかもしれないし、改善の余地もあるけど、「バグ」って言葉はもっと具体的なものに使おうよ。

ここには二つの逆の原因があると思う。過度に一致したメンタルモデルか、まったく一致していないメンタルモデル。開発者の場合、バグ盲目は彼らのメンタルモデルがシステムのモデルに非常に近いため、両者に同じ盲点があって、開発者はシステムの外で効果的に考えられないことが多いんだ（典型的な例として「QAがバーに入って、ビールを0杯注文し、-1杯注文し、0.999杯注文する」対「顧客がバーに入って、トイレはどこかと尋ねると、バーがすぐに炎上する」）。一方で、普通の人がシステムと関わる一般的な方法は、彼らが単に…モデルを持っていないこと。全くない。何かをクリックして、それが何をするかを見るだけで、期待通りに動かなければ、肩をすくめて別のものをクリックする。ソフトウェアを使っている非技術者を見ると、彼らが期待される動作と予期しない動作の違いを通常は判断できないことに気づく。なぜなら、そもそも期待を形成していないから。コンピュータは機械というよりもジンのような存在だ。この記事の中でもこう言ってるよね。「Google Docsは、ドキュメントを開いた直後にタイトルボックスに入力した内容が上書きされるような遅延を追加した。」これは開発者がシステムのモデルを形成している例。一般の人は、時々ボックスに入力するとテキストが表示されることを学ぶだけ。表示されない時もある。表示されなければ、もう一度試す。システムが理解されるように設計されているという前提を捨てれば、システムを理解する必要はない。実際には、ひどいエンジニアリングやアンチ機能、ユーザーへの敬意の欠如が広がっていて、それがこのモデルを情報理論的に最適なものにしていることが多い。そういう意味では、私たちを不幸にするものは、Google Docsをエンジニアリングされた製品として扱いたいという歪んだ欲求なんだ。

これはdanluuに賛成だな、少なくとも見出しについては、実際の詳細には関係なく。私は毎日10〜20のソフトウェアバグに遭遇してる（もっと多い気がする）。プライベートデータを漏らすことがなければ、時々1週間くらい画面キャプチャをして、入力データ（キーボード/マウス/タッチパッド/画面）を記録して、その週に遭遇した100のバグを投稿したいと思うこともある。開けた時に黒い画面になるMacOSのバグにも遭遇したことがあるし、iOSのカメラアプリがカメラを開けないこともあった。iOSのキーボードが電話の幅の80%しか使わないことにも遭遇した（すべてのキーが小さい）。それをどうやって直すのか分からない。キーボードを閉じて再度開いてもダメだし、アプリを終了させるのも無理。なぜなら、フォームを入力中で、最初からやり直したくないから。最近、電話の画面がフリーズすることが多くて、指で押しても反応しない。ロックして再ロックすると復帰する。これは新しい問題で（1〜2週間前から発生）、一般的/非一般的。電話のカメラを使って物をスキャンするアプリ（チェックやIDなど）は、ほぼ常に何らかの形で失敗する。物を認識できなかったり、タイムアウトしたり。彼らがテストしたのはオフィスの完璧な条件だけで、実際のユーザーで試したことがないから。

これがコンピュータの使い方に関係してると思ってたけど、時間が経つにつれて、実際にはみんな同じバグにぶつかって気づいてないだけだって気づいた。なんで気づかないのか、理由は分かる気がする。下を見て。 >ちゃんと動くけど、開いて試してみると、直感的じゃない作業をいくつかしないと動かない状態になってる。ほとんどの人はUIのナビゲーションが下手なのは、良いUIでも直感的じゃないからだと思う。悪いUIも同様に直感的じゃない。彼らはそれがバグだと気づかない。だって、彼らにとっては全てがバグだから。新しいUIを使って、必要なものをすぐに見つけることができるけど、一般の人たちは、僕より10年も長くそのソフトを使ってても、いまだにいくつかの機能を理解できず、僕が数分や少しのリサーチでできることをできないことが多い。https://grumpy.website/に感謝。大好きだよ。