3 ポイント 投稿者 GN⁺ 2024-06-09 | 1件のコメント | WhatsAppで共有
  • 技術説明は初心者に配慮するとしても、理解する能力のある人が実際の状態を把握できる正確な手がかりを残すべきである
  • Outlook のエラーメッセージは、「存在しないメッセージ」の内容をコピーできると述べ、ユーザーに矛盾したモデルを与えている
  • servercache のような単語を隠さなければ、関心のあるユーザーは検索して学べ、すでに知っているユーザーは問題をより早く理解できる
  • loading… のような見慣れているが不正確な状態表示は、システムが実際に何をしているかを覆い隠し、「入力が終わるのを待っています」のように直接伝えるほうがよい
  • 過度な単純化はユーザーの推論を妨げるため、少なくともエラーコードや可能な対処のような真実につながる手がかりを残すべきである

わかりやすい説明でも間違ってはいけない

  • 「ファインマンの剃刀」は、技術的な内容を一般ユーザーに説明するとき、理解する能力のある人が理解できないなら良い説明ではない、という基準である
  • Richard Feynman は新聞記事について、「7トンの機械」という情報だけでは何の機械かわからず、「atomic bullet」が何を指すのかもわからないと述べた
  • 重要なのは説明がどれだけ易しく見えるかではなく、読む人にその内容を理解する能力があるとき、実際に理解できるかどうかである

Outlook のエラーメッセージが生んだ混乱

  • Hacker News の議論で、次のエラーメッセージが嘲笑の対象になった
    • “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
  • ユーザーは存在しないメッセージの内容はコピーできるが、保存はできないと言われることになる
  • 問題は一般ユーザーが技術用語を知らないことではなく、理解できるユーザーに対してさえ実際の状態を説明していないことにある

servercache を隠さないやり方

  • ある代替文言は、メッセージはメールサーバー上では削除されたが、Outlook がそのデバイスの一時キャッシュに保持していると説明する
    • ユーザーはメッセージ内容をコピーするか、キャッシュから破棄できる
    • キャッシュから破棄すると永久削除される
  • 一部は、一般ユーザーには cacheserver のような単語は理解できないと反応した
  • しかしこのような単語は、関心のあるユーザーにとって検索できる学習可能な手がかりになり、すでに理解しているユーザーには実際の状況をより明確に示す
  • 関心のないユーザーはどんな説明でも大きな助けを得られないが、関心のあるユーザーには手がかりが残されるべきである

ソフトウェアの状態をありのままに伝える

  • substack-proxy ツールは、ユーザーがコピー&ペーストした Substack の投稿 URL をもとに、Twitter の検閲を回避するための URL を生成する
  • ユーザーが URL を入力または修正している間、サーバーリクエストが多くなりすぎるため、約 1 秒の遅延を加えている
  • 最初の状態文言は loading… だったが、実際には読み込みではなく、ユーザーが入力を終えるのを待っている状態だった
  • 「入力が終わるのを待っています」は、機械の実際の状態をより正確に反映している
  • エラーで停止した場合でも、loading… で止まるより「入力が終わるのを待っています」で止まっているほうが問題の状態をよりよく示す

すべてを教えなくても忠実であるべき

  • ソフトウェアはすべてのユーザーにすべてを教える必要はない
  • ユーザーはしばしば原因を知りたいのではなく、ただ正しく動いてほしいだけである
  • それでも説明を提供するなら、コンピューターがどう動くかについて奇妙だったり不正確だったりするモデルを与えてはいけない
  • 単純なエラーコードと対処だけを提供する方法も可能である
    • Error code 1027: file cannot be saved.
    • [Copy contents]
    • [Delete file]
  • 関心のあるユーザーはエラーコードを検索でき、関心のないユーザーは可能な選択肢をすぐに見られる

単純化の基準

  • 良い単純化は、説明しようとする真実へとつながる手がかりを断ち切らない
  • 「平均的なユーザーには理解できない」という前提で、すべてのユーザーを同じ水準まで引き下げて見るアプローチは危険である
  • “bits and bytes” は、初めてコンピューターを使う人に電源の入れ方や enter 入力を説明しながら、同じエピソードで二進コードまで扱った事例である

1件のコメント

 
GN⁺ 2024-06-09
Hacker News の意見
  • message-doesn't-exist の例は、行き過ぎた単純化というより、書き手が文脈を忘れたときによく起きるミスに近いように見える。
    プログラマーの視点では、サーバーから何かを取得しようとして、サーバーが「ない」と返したのだから、「存在しない」で正しいのかもしれない。
    しかし、ユーザーがそのメッセージを目の前で見ている文脈では、「存在しない」は明らかに誤り。
    「そのメッセージはサーバー上にはなく、今は一時的にあなたのコンピューター上にだけあるので、コピーしておいてください」のように、文脈を捉え直す必要がある。
    ユーザーが「サーバー」とは何かを知らなくても、「どこかには存在しない」という情報さえあれば、文はずっと筋が通る。
    自動車整備士が車全体を指して「これは交換されます」と言ったら混乱するが、「xxx が交換されます」と言えば、xxx が何かを知らなくても理解はできる。

    • 「このメッセージはもうサーバー上にないため、ダウンロードできません。メッセージをコピーするか削除できます」
    • server の代わりに「こちら側には」と言ってもよい
  • 最近のオンライン設計は、ユーザーが考えないほどついてきやすいという前提のもと、すべてが人をより愚かにする方向へ進んでいる感じがある。
    たとえば Google 検索結果は毎月さらに最小公分母に合わせられているようで、微妙な内容を検索しても、アルゴリズムが役に立たない答えへ押しやってくる。
    多くの人は実際にそういう方式のほうが反応しやすく、データ上は良く見えるのかもしれないが、個人的には嫌いだ。
    システムとやり取りしながら少しずつ学び、複雑さに触れていきたいのであって、その複雑さを隠してほしくはない。

    • いつか Google も Coca-Cola のように、アルゴリズムのClassic バージョンを出すかもしれない。
    • 愚か者のためにシステムを設計すると、結局は愚か者だけがそれを使うようになる。
    • 軍のパイロット用装備がかつて平均的な人を基準に設計されていたが、実際には大半の人が少なくとも一つの面で平均から大きく外れていると気づいた、という話がある。
      そこで装備を調整可能にしたところ、性能が大きく向上し、ミスも減った。
      なのにテック業界では、なぜその正反対に、架空の平均ユーザーに合わせるほど良い、あるいは儲かると言うのか分からない。
      個人の多様性はなぜ無視してよいことになっているのか疑問だ。
  • Norton Disk Doctor が懐かしいのは、ドライブ復旧の仕事をしていたからではなく、ユーザーの知性を尊重するインターフェースを備えていたからだ。
    ほかのストレージ関連システムは、「Mode 5/7? [Y]」のような解読不能な文言を投げてきたり、「Are you sure? [N]」のように過度に間抜けな質問を投げてきたりした。
    何を確信しろというのか、mode 5 が何なのか、7 なのか、両方なのか、分からない。
    一方 Norton は、各選択肢が何を意味するのかを複数の段落で説明し、概念を文脈の中で解きほぐし、利点とリスクを知らせてくれた。
    ただ Y を押し続けて運任せにする代わりに、情報を得たうえで選ばせてくれた。
    こうした読者やユーザーへの敬意は、マニュアル、ユーザーインターフェース、ブログ記事、API ドキュメントのような、あらゆる技術文書に当てはまる。
    「一般人」のために文章を愚かにするより、読んで理解したすべての読者が少しでも技術的に成長できるよう教育するほうがよいと思う。
    ちなみに「Mode 5/7?」は、ある政府機関の全データが入っていた Hitachi SAN アレイで実際に表示された文言で、マニュアルはこのオプションが mode 5/7 をオンまたはオフにするものだとだけ親切に説明していた。
    選択を誤るとアレイが自分自身を消去して猫が死ぬかもしれないし、あるいは何も起きないかもしれない。誰に分かるだろうか。

    • ソフトウェアの設定メニュー、特に詳細設定にも同じようなことが当てはまる。
      設定を作った人たちが各項目に短いツールチップ説明を入れるのに、ほとんど手間はかからないはずなのに、実際にはほとんど行われていない。
  • 目的が情報を伝えることなら、その通りだ。
    しかし目的がクリックを増やし、サポート問い合わせを減らし、エンゲージメントを高めることなら、技術的に具体的で正確な説明が、不正確なくらい単純化された説明より優れているとは言いにくい。
    とはいえ、情報伝達よりエンゲージメントを優先する目標に同意するという意味ではない。

    • クリックの追求が問題を確実に悪化させたが、Murray Gell-Mann が言ったように、ジャーナリズムと単純化はほとんど同義語に近い。
      https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
    • サポート問い合わせ削減という観点は考えたことがなかったが、検討に値する。
    • エンゲージメントと収益化の理論には、単に同意しないというレベルではなく、激しく反対し始めるべきだ。
      そうした目標を追求すると決めた人たちにとって、実際に危険な選択になるようにしなければならない。
  • 仕事でこの問題にかなり苦労している。
    読者が英語に堪能だとも、トピックを理解しているとも、さらには理解する関心があるとも仮定できない。
    そこで平易で曖昧さのない文章を採用し、今はざっと見るだけでも要点をつかめる書式も試している。
    個人的には nhs.uk が学ぶべき最高の例だと思う。
    人々は愚かなのではなく、忙しく、疲れていて、面倒くさがりだったり、細部にそれほど関心がなかったりするだけだ。
    読者の知性を尊重することと、時間を尊重することの間にはバランスがある。

  • Feynmanの剃刀も本来はこういう方向のものだと思っていた。1979年のニュージーランドでのQED講演で、聴衆からの質問への答えが思い浮かぶ
    「世界についての私たちの描像は、確率を含む計算に基づくべきだという考えは気に入っていますか?」という質問に対し、Feynmanは、気に入っているとも気に入っていないとも言わない、と答えた
    科学者として長く訓練を受ける中で、物事を見る特定のやり方が身についたのであり、講演では少し単純化し、少しごまかして、それを嫌っているように聞こえさせることはできるが、実際の意味は「奇妙だ」ということだ、と述べた
    自分にとっては、これが気に入るかどうかではなく、これが何であり何でないのかを考えることであり、好きかどうかはまったく無関係なので頭の中から取り除いた、と述べた
    複雑さや、非専門家に説明する問題では、ウサギの穴はいつもさらに深くなる
    Caltechの講義の空間回転の部分にもよい引用がある。「これらの方程式を完全な一般性のもとで使い、すべての結果を研究することはしない。そうすれば何年もかかるし、まもなく別の主題へ進まなければならないからだ。入門コースでは基本法則だけを示し、特に関心のあるいくつかの状況にだけ適用できる」

    • 実に典型的なFeynman流の答え
      好意的に見れば、専門的な立場から間違ったことを言ったり、事実でないことをほのめかしたりしないようにする態度だが、同時に、質問にきちんと答えずに逃げているようにも見える
      磁石はどう働くのかとインタビュアーが尋ねる動画でも、まったく同じように答えている
  • 「私がいちばん気に入ったコメントはlisperの……」とは素敵だ。誰かが私に気づいてくれた
    科学的方法についてのブログ記事シリーズを一生懸命書いているのに、フィードバックはほとんど得られておらず、こういう軽いコメントが注目を集めるのは妙な感じがする
    人生は時々おかしい

    • プロフィールのリンクが切れているが、どこでもっと読める? 自己宣伝するなら、何を読んでほしい? ここではワイルドカードを渡すよ
  • 筆者自身もFeynmanの引用を正しく再現できていない
    “And there are not sixty two kinds of particles”ではなく、“And there are now sixty two kinds of particles”であるべきだ

  • 技術用語なしでも初心者と専門家の両方を満足させる形で説明できるなら、専門用語に何の役目があるのか?
    この記事の例はどちらにとっても役に立たず、専門用語があってもなくても良くならない
    単に悪い説明なので、議論そのものが弱くなっている

    • 同意する。高度に専門化されたテーマには、たいてい必要な微妙な文脈が多い
      それをすべて伝えるか、そうでなければ専門用語で迂回しなければならない
      場合によっては両方を満足させる説明も可能だが、より難しく、より多くの言葉が必要になる。少なくともメディアの文脈では、これは重要だ
      それでもここにはスペクトラムがあり、たいていは適切な中間点を見つけられると思う
  • 「メッセージが存在しないのに内容をコピーできる? コピーできるなら、なぜ保存はできない? 存在しないなら、なぜ破棄しなければならない?」といった混乱が生じるなら、むしろ説明を減らした書き方のほうがよいかもしれない
    「このメッセージはまもなく利用できなくなります。後で使うには、破棄する前にメッセージの内容をコピーしておいてください」くらいでよい
    キャッシュの話を持ち出してもユーザーの助けにはならない
    本当の解決策は、メッセージの末尾に「メッセージの内容を端末に保存」ボタンを追加することだ
    そうすれば文言が明確になり、すぐ行動につながる

    • そのメッセージは、こうした実行可能な助言と、lisperのより技術的な説明の両方を提供することもできる
      より詳しい説明にはラベルを付けるか、「詳細説明」ボタンから入る2つ目の画面に入れればよい