単語の下に赤と緑の波線を残した Tony Krueger をしのんで

 (devblogs.microsoft.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 2件のコメント | WhatsAppで共有
  • Tony Krueger は、Microsoft Word でスペルや文法の問題を 赤と緑の波線 で即座に表示する機能に関わり、ほぼすべてのユーザーが目にした UI の痕跡を残した
  • 初期の Word のスペルチェックはユーザーが自分で実行する必要があり、Auto Spell Check も保存や終了といった前面の作業を止める ブロッキング処理 だったため、多くのユーザーが無効にしていた
  • Krueger は、チェック処理がユーザーを立ち止まらせないよう、より 煩わしくない方法 を作り、問題が見つかると別途実行を待たずに単語の下へ表示するようにした
  • 彼は Word 1.0、1.1、2.0、Word for OS/2、Word for Mac、Word 6.0 とその後の複数バージョンに関わり、Chip’s Challenge の Windows 移植も担当した
  • 今日では赤だけでなく、緑や青の波線もワープロや他のソフトウェア全般に広がっており、Krueger の仕事は 日常的な編集フィードバック UI として残っている

Tony Krueger と Word の波線 UI

  • Tony Krueger は、成果物は広く知られている一方で、名前は比較的あまり知られていない人物だった
  • Wikipedia では、Windows Entertainment Pack 向け Chip’s Challenge を Windows に移植した人物として記されている
    • この移植は、MS-DOS 版のソースコードなしにリバースエンジニアリングを行い、その後 Windows 向けに再実装した作業だった
  • より多くの人に届いたコードは、Microsoft Word の スペル・文法表示機能 だった

複数の Word バージョンに残した足跡

  • Krueger は複数の Word バージョン開発に参加した
    • Word 1.0
    • Word 1.1
    • Word 2.0
    • Word for OS/2
    • Word for Mac
    • Word 6.0 とその後の複数バージョン
  • 彼は「最も多くの Word バージョンをリリースした人物」の記録を持っている可能性がある人物として言及されている

初期のスペルチェックが不便だった理由

  • 初期の Word の Spell Check は、ユーザーが明示的に実行しなければならない機能だった
  • ユーザーは、プログラムが潜在的なタイプミスをすべて見つけるまで待ち、その後各単語を 1 つずつ見ながらどう処理するかを決める必要があった
  • Word は、ユーザーがアイドル状態のときに事前にスペルチェックを行う Auto Spell Check を導入した
    • ユーザーが Spell Check ボタンを押したときに結果が準備できているようにする方式だった
    • しかし Auto Spell Check も依然として、ユーザーの次の操作を妨げる ブロッキング処理 のままだった
  • 多くのユーザーがこの機能を無効にしていた理由もここにあった
    • 文書を保存して終了しようとした瞬間にスペルチェックが始まると、チェックが終わるまで待たなければならなかった

赤と緑の波線の導入

  • Krueger は、スペルチェックが前面の作業を妨げないよう、はるかに 煩わしくない方法 へと変更した
  • 問題が見つかると、ユーザーが Spell Check を実行するまで待たず、潜在的なタイプミスの下に 赤い波線 を即座に描画した
  • その後、潜在的な文法エラーには 緑の波線 が使われるようになった
  • この方式は、今日ではほぼすべてのワープロで見られ、ワープロの外でもよく使われている
    • 赤だけでなく、緑や青の波線も広く使われている

この機能を覚えていた人々

  • Krueger は、マジック・コメディデュオ Penn and Teller の初期からのファンだった
  • ある友人であり同僚でもある人物が、公演後に 2 人へ Tony 宛てのサイン入り写真を頼み、彼が Word の赤と緑の波線チームにいたと伝えた
  • Penn Jillette は劇場全体に響くほどの声で “The red and green squiggles!? I love the red and green squiggles!” と反応し、Teller も静かに同意した
  • Krueger は誕生日プレゼントとしてそのサイン写真を受け取ったが、写真そのものと、Penn and Teller が彼の機能を気に入っていたという事実のどちらをより喜んだのかははっきりしなかった
  • 後に “Weird Al” Yankovic のパロディ動画 Word Crimes に Word の赤い波線が一瞬登場し、同じ友人がその画面キャプチャにもサインをもらった

残された痕跡

  • 赤い波線は、ユーザーのミスを見つける日常的な編集フィードバックとして残っている
  • Krueger が最初に行った仕事は、その後さまざまなソフトウェアの テキストエラー表示方式 へと広がっていった

関連記事

2件のコメント

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

  • 会社でソフトウェアを作る業界に居続けてソースコードに名前を残していると、いつか思いもよらなかった製品や機能で記憶されることになる
    当の本人が最も熱心に作り、それで知られたいと願っていたものは、時が経つにつれて忘れられていく。何かを作る過程は完全に自分のコントロール下にあるが、何で知られるかは完全にコントロール外にある

  • AmigaのProwriteはWordより先にリアルタイムのスペルチェックを提供していた
    それ以前に同じ機能を持つプログラムがほかにもあったかもしれないが、Prowriteは間違った単語の下に赤い波線の下線を引いてくれた
    https://www.atarimagazines.com/compute/issue123/P215_1_REVIE...

    • 本当に確かなのか？ リンク先のページには「10万語のスペルチェッカーがテキスト範囲チェック、単語単位の検索、連続チェック、ユーザー辞書の追加をサポートする」とあるだけで、単語の下線には言及していない
      その機能のスクリーンショットも見つけられなかった。AmigaOS 1.xのカラーパレットなら標準色は黒/白/青/オレンジだったはずなので、波線はたぶん赤ではなくオレンジだったのではないか。AmigaOS 2以降は3D効果のために黒/白/灰色/青だったので、強調色は青だったかもしれない
    • DOSのPC-Writeにもあった

  • 複数の言語で作業する環境では、波線の下線が役に立たないことが多い
    システムは自分が書いているテキストの言語を推測しようとするが、たいてい外れる。その結果、視覚的ノイズになって、戦うか無視するしかなくなる。やり取りのたびに言語設定を手動で切り替えるのも面倒すぎる

    • 校正言語を指定する文字スタイルにショートカットを割り当てて使っていた。たとえば shift-alt-1 で英語、shift-alt-2 でドイツ語に設定するといった具合だ
      文字スタイルなので入力中の現在位置にも適用できるし、選択した範囲にも適用できる。事前に設定するのを忘れて1行に波線が大量についたときでも対処できる。あるいはテキスト全体の校正言語を None に設定して、スペル・文法チェックをすべて消すこともできる
    • 同じ問題がある。プログラムごとに対応レベルが違うが、Affinity製品群は特にひどい

  • 興味深いことに、Chenの記事はTony Kruegerが移植した根拠としてWikipediaのページを指している
    ところが最新版では、その項目の根拠がまたChenの記事へ戻るリンクになっている

    • 時系列で見るとこうだ。Chenの記事が参照として追加される前のWikipediaページは https://en.wikipedia.org/w/index.php?title=Chip%27s_Challeng... で、「Tony Kruegerがコーディングした」という内容は「ゲームのAboutボックス」を、「[Kruegerが]ある夏に書いた」という内容はフォーラム投稿を出典にしていた
      Chenの記事は「Tony KruegerはWikipediaで…を移植した人物として記憶されている」と書いたうえで、「彼がソースコードなしでこれをやってのけたことは、おそらくそれほど広く文書化されていないだろう。彼はMS-DOS版をリバースエンジニアリングしてからWindows向けに再実装した」という脚注を添えている。その後、Wikipediaの記事がこの追加情報のためにChenの記事を引用した。まったく問題なく適切であり、先ほど引用が再び明確になるよう編集しておいた
    • ちなみに Raymond Chen のブログへの引用は、具体的にはソースコードがなかったのでMS-DOS移植版をリバースエンジニアリングしたという主張について付いている
      編集前はゲーム自体がTonyとEd Halleyを開発者として記している根拠だったのだが、Chenブログのリバースエンジニアリングの逸話を追加した人が文を分割したことで、開発者名に対する引用が別の人にしかかからない形になってしまっていた
      https://en.wikipedia.org/w/index.php?title=Chip%27s_Challeng...
    • ChenはKruegerがゲームを移植した根拠としてWikipediaを使っているわけではない
      Wikipediaが彼の最もよく知られた仕事として何を書いているかを示したうえで、Kruegerについてもう1つ注目すべきこと、つまり波線の下線を付け加える構成になっている。Chenの記事全体を読めば、下の方に移植に関する詳細も補っているので、その事実を明確に認識していることがわかる。この記事を移植の根拠として使っても問題ない。Wikipediaでこうした循環的な根拠の連鎖が実際に生じることはあるが、この件はそうではなさそうだ

  • こういう記事は好きだ。あり得た無数の分岐の中からよりによって波線が選ばれ、それも1人の人間が即興で下した決定だったのに、最終的には世界を完全に変えてしまった

    • すべての分岐が実際に起きていて、今の私たちはそのうち波線になった宇宙にいるだけだ

  • 波線の下線はいつも好きというわけではないが、UIパターンとしては認めるに値する
    「この単語に何か問題がある」を示す視覚表現の中では、最も直感的でわかりやすい部類に入る

  • 投稿タイトルと microsoft.com ドメインを見るだけで、いつも Raymond の記事だとわかる。本当に好きな人だ

  • 「彼はソースコードなしでこれをやってのけた」とは、そりゃそうだ。ここはHNなんだから、誰がソースコードなんか必要とする？
    ただ、リバースエンジニアリングの代わりに、自分ならエミュレータを探すか作ったと思う。ほかのソフトウェアも「移植してくれ」と頼まれるかもしれないからだ。私たちが使うソフトウェアの良い機能や悪い機能を誰が担ったのかを、たいてい誰も知らないというのは実に悲しい。映画には最後にクレジットを長々と流す慣習があり、私はそれを細かく読むのが好きだ。ソフトウェア開発にもそういう文化があるべきだ。一部のゲームはそうしているし、いくつかの Easter egg もその役割を果たしている

  • スペルチェックを完全にオフにできたら本当にいいのにと思う
    かなりニッチな好みなのはわかっているが、自分のミスと一緒に生きても構わないし、スラング・技術用語・略語のようなものを毎回「学習」させたくない。非標準的な英語で書く人たちが最近どうやって耐えているのか、よく気になる。James Joyceがこれを好んだとはとても思えない

    • 何が邪魔しているんだ？ 自分はすべてのデバイスでスペルチェックをオフにしている
      ネイティブでもないので確かに助けにはなるはずだが、意図して書いた文字列に文句をつけたり自動修正したりされるのが嫌だという点は同じだ
    • MS Wordには「入力中にスペルチェックする」オプションがあり、オフにできる。文法チェックも同様だ

  • Larry Constantine は波線の下線を本当に嫌っていたと記憶している
    彼の表現によれば、文章を書くときには常に次の単語を考えるべきなのに、波線はすでに書いた単語へ注意を引き戻してしまう。「おい、聞いてくれ！ 自分は本当にスペルを書けると思ってるのか？ たった今書いた『fatouos』っていったい何だ？」と叫び、立ち止まって波線が引かれた単語をクリックして直すまで、延々と悩ませる。実質的にはClippyの原始的な形だ
    Wordがviのように2つのモードを持てば解決できるかもしれない。書き込みモードでは何にも邪魔されず文章だけを書けるようにして、編集モードに切り替えるボタンを押した瞬間に波線やAI提案を好きなだけ浴びせればいい
 
GN⁺ 4 시간 전
Lobste.rs の意見
  • 面白い遺産だね。波線の下線が好評だったのはよかった
    それにこの脚注はかなりすごい: 「おそらく広く知られてはいないが、彼は[Chip's Challenge の移植]をソースコードなしでやってのけた。MS-DOS版をリバースエンジニアリングした後、Windows向けに再実装した。」
    • Penn and Teller / Weird Al への言及も、きっとかなりうれしかっただろうね
      今調べてみたら、Tony は 1989年から Microsoft に在籍して最後まで勤めていて、計算が合っていれば 37年ちょっと勤務したことになる
  • 最初の反応は「うわ、これを止まらずに数秒ずつ食わないようにするのは簡単そうに見えるけど」だった
    でもすぐに、90年代初頭なら RAM は 4〜8MB だったはずで、英単語リスト全体をそのままメモリに載せておくことはできなかっただろうと思った。しかも90年代初頭の C++ でマルチスレッド処理がどうだったかは知らないが、2000年代後半でも不快だったのだから、かなり厄介な問題だった可能性が高い
    • Word ’95 は Windows 95/NT 上で動いていたので、すでにプリエンプティブ・マルチタスクと Win32 を使っており、Windows 3.x よりマルチスレッド化は簡単で安定していたはず。赤い波線の下線 UI が実現できた主な理由もそこにありそう
      辞書サイズについて言えば、初期のスペルチェッカーのひとつは 1970年代後半に英語辞書を 64KB RAM に収めることに成功していた（Jon Bentley の Programming pearls 参照）。DAWG を使えば、中規模の英語辞書10万語を 400KB に圧縮でき、スペル候補の検索も高速だった: https://www.strchr.com/ternary_dags
  • 良い機能ではあるけど、人々がスクリーンショットを使うせいか、波線の下線が印刷物やプレゼンスライドにそのまま入っているのを見るたびにギョッとする
    • たいていは Google Docs や Apple Notes 由来に見えて、デフォルトスタイルを見るだけでも区別できる