- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 08 Dec 2009 05:43:06 +0900
- To: public-html-ig-jp@w3.org
皆様， W3C/慶應の芦村と申します． 私は，Mike Smithおよび一色とともに，HTML5 Japanese Interest Groupの活動 支援を担当しております．この度は，矢倉さんからいただいた課題に関して， 活発な議論をご展開いただき，本当にありがとうございます． ところで，私は，もともと，音声ブラウザ [a] およびマルチモーダル対話 [b] という，(いわゆるHTMLベースのWebアプリケーションとは少し毛色の異な る) 活動を担当していることもあり，それらの観点から見ていくつか，皆さんに ご考慮いただきたい点についてお知らせいたしたく存じ ます． [a] 音声ブラウザ: http://www.w3.org/Voice/ [b] マルチモーダル対話: http://www.w3.org/2002/mmi/ 個人的には，私は小久保さんのお考え [c] に賛成で，UIの詳細をどこまで HTMLで制御するかについては，特に，日本語処理の観点も含めて，もう少し検 討いただくのがよいような気がしています．なお，皆さんのメールに直接お答 えする形とすることが困難だったため，とりあえず，小久保さんのメールにリ プライする形とさせていただきました．また，「inputmodeをHTML5の仕様にど う組み込むかを議論する」という，もともとの矢倉さんからのお題 [d] に直接 お答えする形とはなっていなくて申し訳ありません． [c] 小久保さんのご意見: http://lists.w3.org/Archives/Public/public-html-ig-jp/2009Dec/0054.html [d] 矢倉さんのお題: http://lists.w3.org/Archives/Public/public-html-ig-jp/2009Dec/0008.html --- 以下，ご検討いただきたい，いくつかの点 --- 私の理解では，小久保さんのメール，およびそこから派生したトピックには， 以下の三点が含まれているものと思われます． 1. 基本フレームワークと言語依存の部分との切り分け 2. 多様な機器および入出力方法への対応 3. 入力情報の妥当性検証メカニズム それぞれの点について，「将来の様々な環境，各国言語等への対応」という点 から，関連するいくつかの情報を以下にご提供いたしたく存じます． 1. 基本フレームワークと言語依存の部分との切り分け ---------------------------------------------------------- -> 日本語組版処理の要件 「Webドキュメント中において日本語テキストをどのように配置するか」につい ては，W3C日本語レイアウト・タスクフォースが作成した「Requirements for Japanese Text Layout [e] (日本語組版処理の要件 [f])」ワーキンググループ・ ノートに詳細な記述があります．なお，上記ワーキンググループ・ノートには， inputmode以外に矢倉さんが触れておられた「ルビ (ruby)」の扱いについても， 非常に詳しく説明されています． [e] Requirements for Japanese Text Layout (英語原本): http://www.w3.org/TR/jlreq/ [f] 日本語組版処理の要件 (上記ノートの日本語翻訳): http://www.w3.org/TR/jlreq/ja/ ただし，個人的には，このような各言語に強く依存する処理をHTML5の基本フレー ムワークに組み込むのは得策とは思われません．おそらく，例えば，何らかの レジストリ (例: Language Sub Tag Registry [g] のような) にもとづいて使 用言語を識別した上で，言語ごとに異なる処理は，上記ノートのような各言語 ごとの詳細仕様にもとづいて行なうのが望ましいのではないかと思われます． [g] Language Sub Tag Regisrry: http://www.iana.org/assignments/language-subtag-registry レジストリによる識別の例として，例えば，音声合成のためのマークアップ言 語であるSSML 1.1 [h] では，音声出力のもとになる発音記号について，各国対 応のレジストリをマークアップとは別途作成し，例えば「カタカナ」や「ピン イン(中国語の発音記号)」などを識別するようにしています．マークアップ言 語自体は，レジストリに登録されたキーワードにより言語識別を指定するだけ で，言語ごとに異なる具体的な発音記号の詳細は，レジストリの方で厳密に定 義されます． [h] SSML 1.1: http://www.w3.org/TR/speech-synthesis11/#S3.1.10.1 2. 多様な機器および入出力方法への対応 -------------------------------------------- -> マルチモーダル対話処理 一言で「Webアプリケーション」と言っても，具体的に動作する機器やソフトウェ アには様々なバリエーションがあります．キーボードやマウスを備えたパソコ ンはもちろんのこと，ご存知の通り，近年では携帯電話だけで電子メールの送 受信やWebページの閲覧ができるようになっています． しかしながら，機器同士，あるいはアプリケーション同士のインタフェースは， まだまだ統一されておらず，例えば，「今，私がパソコン上のWebブラウザに入 力したメールアドレス」を「携帯電話にそのまま転送」するには，機器やソフ トベンダごとに異なる複雑なメカニズムを経由する必要があります．なお，小 久保さんもご指摘の通り，日本語の場合は，入力情報はIMEをも経由する可能性 があります．したがって，少なくとも，「(HTMLの処理系である)Webブラウザ側 でinputmode により入力モードを設定する」だけでは，他の機器やソフトウェ アとの連携を保証することは難しいと思われます．仮に，Webブラウザ自体が直 接機器を制御するOSになってしまえば，多少楽になるかもしれませんが，UIと してのブラウザがどこまでの仕事を担当するかについては，もう少し検討の余 地があるのではないかと思われます． なお，上記したような「さまざまな機器やソフトウェアの連携」を考慮した技 術として，W3Cでも長年取り組んでいる，マルチモーダル対話処理が挙げられま す．マルチモーダル対話処理については，簡単な資料 [i] を作成しましたので 是非ご覧ください．例えば，iPhoneでは (iPhoneは電話でありマイクもスピー カも組み込まれているので) Web ブラウザのみならず音声インタフェースをも 活用することが可能です．これにより，面倒くさいソフトウェアキーボードの 代わりに，電話に話しかけることにより情報入力をすることができます． [i] マルチモーダル対話処理の概要: http://www.w3.org/2009/Talks/1130-ci-seminar-ka/ [j] iPhoneで動くマルチモーダルアプリ: http://www.youtube.com/watch?v=OURZpqh-35A&eurl=&feature=player_embedded 3. 入力情報の妥当性検証メカニズム --------------------------------------- -> 認識文法 W3Cでは，HTML以外のみならず，「音声ブラウザ」という音声インタフェースを 用いてWebにアクセスするための各種標準仕様 (VoiceXML, SSML, SRGSなど) に 取り組んでいます．「音声ブラウザ」は，電話をかけて普通に話すだけでWebア プリケーションを利用できる仕組みです (厳密には，いわゆるテキスト・リー ダとは異なる概念です)．音声ブラウザでは，サーバ側で検索エンジンが利用す るために，利用者が入力した音声をテキスト情報に変換 (=音声認識) します． その際，例えば「食べ物屋を探しているなら，レストラン名」というように， HTML のフォームに相当するような「ここでは，何を受け付けるか」という「音 声のフォーム」があり，patterで制限するのと同様に，「このフォームで入力 されるべき妥当な内容」をリストとして指定することができます．このリスト のことを音声認識の用語では「認識文法」と呼びますが，認識文法の記述方法 もSRGSという仕様としてW3C標準化されています． 今後，Webアプリケーションを各国語対応させていくを考慮すると，pattern属 性を使って毎回要素中に条件パターンを埋め込むよりも，「このフォームで入 力されるべき内容」をもっと柔軟に指定するための (音声認識文法のような) 仕組みを別途提供し，世界中で共通利用できるようにした方がよい可能性もあ ろうかと思われます． SRGS: http://www.w3.org/TR/speech-grammar/ 以上 よろしくお願いいたします． Kazuyuki > はじめまして。小久保と申します。 > Information Architects, Inc.( http://informationarchitects.jp/ > )でインターフェイスデザイナーをやっています。 > > 私は実際のところHTML5に関してはあまり最新事情も追いかけておらず、これ までの経緯を把握できてるわけでもないのですが、そんな自らを省みて何とか キャッチアップできればということでMLに参加させていただきました。よろしく お願いします。 > > さて、そんな事情に暗い身ではありながら矢倉さんからお題を頂いた inputmodeについて思うところがあったのでポストさせていただきます。まずは 矢倉さんのポストのinputmodeについての箇所を転載します。 > > > 2. 入力モード (inputmode) > > > > HTML5ではフォーム機能が拡張されていますが、入力モード（ひらがなや英 数、カタカナの）については仕組みが存在していません。フォーム機能がまだ Web > > Forms 2.0という別の仕様だったときには、XFormsより inputmode > > という属性が取り込まれていたのですが、現在のHTML5には存在しません。 -wap-input-format というWAP > > CSSのプロパティがあるからという理由でしたが、これを実装するデスク トップブラウザがあるかどうかは分かりません。 > > > > XHTML Basic 1.1にも inputmode 属性が持ち込まれていますが [5]、こち らも同様に実装があるかどうかは不明です。 > > > > [5] http://www.w3.org/TR/xhtml-basic/#s_inputmode > > > > というわけで、以下のことができないか考えています。 > > * 入力モードを指定する機能が便利と思われるユースケースを考える > > * ユースケースの文書化を行う > > * inputmode属性の定義を簡略化し、HTML5に提案する > > > > （最後については、少し欲を出してみました。） > > 一部のブラウザではime-modeというCSSプロパティが実装されており、適用し た要素のIMEの振る舞いを制御するというinputomode属性と同じような機能が提 供されています。またこれと同様の機能を他のブラウザでも提供するために Flash経由で同じくIMEの状態をコントロールするライブラリもあります。 > > これは便利かも、と思って自分でも使ってみたこともありますし、これらを 使ったサイトを利用したこともあります。しかし、実際に導入してみるといくつ かのユーザビリティ上の問題が浮上しました。 > > > 1. ユーザーが認識している入力モードとの齟齬 > > 一般的に、複数の入力モードを持ちそれを切り替えて使うようなシステムの ユーザーは一定の入力が続くようなシーンではカレントのモードを常に意識して いると考えられます。しかし通常能動的に行うこのモード切り替えが外部から強 制的に行われ、そのことがわかりやすく通知されない場合、ユーザーが認識して いるモードと実際に選択されているモードの状態に齟齬が発生します。 > > Windows版ATOKなど一部のIMEソフトは入力箇所の近くに入力モードを表示し てくれるためそれなりにストレスは軽減されますが、もちろんこれは HTML文書 やブラウザの外のソフトウェアに頼った解決(?)であるため、文書側から入力 モードを操作することによる問題の本質的な解決ではないのは言うまでもありま せん。モードの変更をユーザーに明確に通知することまでも仕様に含めて担保し ない限りはこの問題は不可避であるように思えますが、それがマークアップ言語 の仕様がカバーする範囲なのか、という疑問はあります。(とか言い出すとForm 関連全体が、という話にもなりかねないかもしれませんが…) > > > 2. 多様な入力方法に対する低い許容性 > > たとえば、メールアドレスの入力欄だから英数字に限定しよう、なんてやっ てしまうと、IMEの単語登録で「メール」をメールアドレスに展開するような使 い方をしている人はこれが出来なくなってしまいます。IMEが必要な場合だけで なく、アルファベット圏のユーザーももしかしたら入力した abbreviationを展 開するようなソフトを使っているかもしれません。 > > ユーザーインターフェース(UI)デザインの基本は「入り口は広く、出口は狭 く」です。この考えに照らすと、ユーザーからの入力を受け付ける最初期段階で 何らかの制限を加えるべきはないと思います。ユーザーからの入力は許容性を持 たせ、クライアント側のスクリプトやサーバー側での後処理でそれを可能な限り 正規化し、それでも不都合がある場合に初めてユーザー側に対応を求めるのがUI としてはより良いデザインと言えそうです。 > > > ということで、矢倉さんはinputmodeについて具体的な提案まで持って行けた ら、というスタンスでの話題提起でしたが、以上のような理由から私は inputmode属性は無くて良いのでは、と考えています。みなさんはどのようにお 考えでしょうか? > > > 以下蛇足気味ですが、このようなUIに関する部分をHTML文書側で具体的に定 義することはそもそも不適切だと思います。HTML文書は最終的に人間が利用する シーンにおいては非常に抽象度の高いデータであり、人間とのインターフェイス (境界面)からは遠いレイヤーにあるように思います。 inputmodeのようにUIに関 して具体的な言及をするのではなく、たとえばpattern属性の内容に応じて、ス クリプトやブラウザやOSやハードウェアといったより人間に近いレイヤーで適切 な補助を行うような形などの方が望ましいと思います。 > > -- > 小久保 浩大郎 (Kotaro Kokubo) > http://hemiolia.com/ > http://twitter.com/kotarok -- Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead mailto: ashimura@w3.org voice: +81.466.49.1170 / fax: +81.466.49.1171
Received on Monday, 7 December 2009 20:44:01 UTC