O-One ブログ

SOAのテーマというよりもUIのテーマと考えた方が議論しやすかったかもしれませんね。

メール通知も大量になると意外と時間がかかるという否定側（吉松さん）の話には、なるほどサービス提供者ならではの意見だと感心しました。

利用者への非同期通知の手段として、ローテクのメールがここまで長年に渡って使われ続けているのは驚きです。Webメール、携帯メールと進化しつつも、基本構造は変わりません。とはいえ、スパムメールに苦しめられ、ベイジアンフィルタで大切なメールをうっかり見過ごして大慌て、といった現状を考えると、メールも大きな進化を迫られているような気がします。

利用者への非同期通知には、「限られたりソースである利用者の注意（attention）をどう効率よく使う（消費する）か」という重要な課題があると思います。利用者第一で考えるなら、かつてGUIが進化したように、そろそろ非同期通知UIも進化すべきなのかもしれません。皆さんは、どう思いますか？

非同期通知と言った場合、まずはメッセージキューを思い描いていました。今回、メールが良いか悪いか、だけの論議になってしまったように思いますが、どうだったのでしょうか。主催者側としても「利用者への非同期通知の既存技術」とはメールだけを想定していたのでしょうか。

また既存技術と言ったときに、疑問なのはたとえば、ブラウザのリフレッシュやRSS配信を利用して、利用者に通知をすることは可能と思います。(純粋な通知ではないかもしれませんが。)ほかにも、たとえばブラウザを使用していたら、ログイン時やページ遷移する際に通知しなければいけないメッセージがサーバに届いていたら(ここは同期でもかまわない)、表示する、などでも良いのかなと思っていました。そこでこれらのやり方では不十分なので、新しい通知が必要になる、という展開を期待していましたが、何か間違えているでしょうか。ちょっと「お題」の意図をはかりかねてしまいました。

メール以外の既存技術についても活用方法等の議論があればと思っていましたが、その場合の話の流れとしては、コメントいただいたように「既存技術そのままでは不十分なので新たな拡張等が必要になる」というような否定側の主張になるのだと思います。

例えば、ブラウザのリフレッシュやRSSの活用は考えられると思いますが、利便性や効率等を考えるとAS-ISでは十分でないので、例えばポータル技術の拡張が必要になる、というような議論ができるかもしれません。
また、メッセージキューを「利用者」への非同期通知に利用するには、利用者側にメーラとかブラウザとは別の専用クライアント等が必要だと思いますが、そういった今は未だない利用者インフラ（ある種の新技術だといえると思います）が必要だという議論もできるかもしれません。

その場合、新たな技術（拡張や追加等）が簡単に広まるかどうかは、その技術が優れているかどうかだけの問題ではない、という肯定側からの反論が出てくるとは思います。否定側は普及戦略まで含めて説明する必要がありそうです。

確かに、そんな議論ができると、面白かったかもしれませんね。