license)に基づいて翻訳・編集しています。開発者というのは、往々にして、ページ上に入力フィールドを設定するだけで、UXについて深く考えていないと思うんです。そのページの属性のことでもあるんですが、フォームの全体としての流れは考えたとしても、それぞれの入力やユーザーがどの点でやりづらさを感じるか?について気にする必要性を感じていないのでしょう。オートコンプリート(自動補完)がユーザーエクスペリエンスをスピードアップさせることに役立ち、フォーム入力をかなり「良く」するとわかっているわけです。ユーザーエクスペリエンスという点では、オンラインで何か買おうとしたり、子供の学校に提出する書類を記入しなきゃならない...という経験はありますよね。それを電話でするのはすごく大変なんです。デスクトップでやるのですら大変ですよ。1階に置いてある財布からクレジットカードを取りに立ち上がりたくないじゃないですか。オートコンプリートやオートフィルなどのブラウザ上の機能によって、フォーム入力に関連するユーザーエクスペリエンスをかなり改善することができます。実際、フォーム入力をして送信するのに、オートフィル機能を使用した方が30%早くできることが分かったんです。ウェブディベロッパーにこのことについて考えるように強く打診しています。ユーザーにフォームを提出してほしいんですよね?じゃあ、そのフォームが素早く簡単に提出できるようなものにしなきゃならないですね、なら、オートフィルを取り入れましょう。実際、難しいことではないんですよ。基本的にオートコンプリート属性を設定する必要があって、通常の選択項目や入力要素を他の要素と置き換えるような派手な設定をしないようにするだけですね。私が思うに、そういったディベロッパーのほとんどは、ただオートフィルといったことについて考えていなかったり、気付いていないだけじゃないでしょうか。そのフォームでオートフィル機能が動作するかを確認して、テストランするというちょっとした追加の努力をすればいいだけなんですよ。正直なところ、うまくいかないこともいくつかあるとは思うんですが、それは大きな問題のひとつです。すごく美しいドロップダウンにもこだわりのあるカスタムされたフォームを作りたいとなると、結果として、DIVを使うことになります。すると、ブラウザーは「あれ、これはフォームのはずなのに」と認識することができなくなるんです。なってしまうとオートフィルは機能しなくなります。オートフィル機能に関連してアクセシビリティについての問題も多くあると思います。あなたから見ると、デザイナーとディベロッパーがいて、それぞれ独自の体験を提供できるようなものを作り上げたいと思っているわけです。一方で、ブラウザサイドで作業する人間からすると「ブラウザに仕事をさせてよ」という意見になります。そこに中間点のようなものがあると思いますか?つまりどうすれば、ディベロッパーは、少なくとも、その製品独自でありつつ、同時にスタンダードを守ることができるカスタムエクスペリエンスを作り出すことができるのでしょうか?これはウェブ制作における大きな挑戦のひとつですよね。A:そうですね、今使っているウェブページでもフォームの外観を変更するためにできることはたくさんありますよ。HTMLが提供している選択や入力要素がありますよね。いったものを、カスタマイズする方法がたくさんあります。確かにカスタマイズできないものが一つだけあって、それは選択要素でのドロップダウンの外観はカスタマイズできません。それ以外は全てページの見え方などカスタマイズが可能で、ブラウザもフィールドがそこにあることを認識します。思うのは、ディベロッパーがオートフィルについて考えないということですね。オートフィルを想定したフォームのテストをする必要性が高いという風には考えないんですよ。自分で作成し、自分で100回の入力テストをしたとすれば、ユーザーが異なる精神状態であるという事実について考えません。ユーザーは疲れている状態かもしれないし、電話でできるだけ早くフォーム入力をしようとしているかもしれない。ディベロッパーはちょっとした追加のステップを踏む必要があるという事実について、しっかり考えていないと思います。それは良い質問ですね。オートフィル機能のためのオートコンプリート属性に限って言うと、標準化されていて、異なる全てのブラウザで重要視されています。言いつつ、ひとつ「オートフィルオフ」機能は、オートフィルオフ属性なんですが、それは全てのブラウザで対応していません。クレジットカード情報を入力する必要があるフォームであれば、主要ブラウザでは対応しています。実際の使用感として、それぞれのブラウザに小さな癖のようなものはありますか?当然ブラウザ固有のものになるということですからね。...少し違ったUIもあります。ドロップダウンの代わりにキーボードウィジェットを統合させているものとかですね。どのブラウザでも大体同じ感じだと思います。ChromeのUI自体に関わっていますよね。デザインチームがいて、UIエレメントがどう見えるべきかを導き出すサポートをしてくれています。実は、今年大幅なデザイン改変を予定していて、実装としてもより美しいものになり、コードのクリーンアップにもなると思います。ほとんどの人には影響のないことだとは思いますけどね。見た目としての変化にはならないので。私たちからすると、コードがかなり整頓されることになります。あなたがUIを作成する実際のプロセスというのはどのようなものなんですか?というのも、僕はフロントエンドのコーディングをやっているんですが、ネイティブアプリの話になると、隠れたアートみたいな感じなんです。あなたが実際に取り組んでいることはかなり細かい内容で、通常ユーザーが気付かないかもしれない部分ですよね。問題なく動作しているんですから。それが崩れてしまうと、その作業がユーザーの目に触れるということですよね。プロセスについて少しお話しします。通常は、まず最初に、プロダクトマネージャー、エンジニアとデザイナーが集まって、その機能に望むものについて話し合います。だいたいの場合は、そこでデザイナーが、その機能がどんな感じに見えるのかをいくつかコンセプト的な試作として出してくれます。いったことを詰めていきます。いったことを反復させながら、公開するものに近づけていくような感じです。私は、クロスプラットフォームチームに所属しています。私たちが構築したものは、全てのChromeプラットフォーム上で機能しなければならないということです。「Chrome」はひとつのプラットフォームだと思うかもしれませんが、実際はWindowsとMacがあって、それぞれ以前は異なるUIを使用していました。単一のスタンダードができました。それがAndroidとiOSです。そこで、私たちはそれぞれの異なる試作をして特定のプラットフォームに関連づける作業をする必要があります。あるサブセットでしか機能しないものもあるんです。デザイナーはエンジニアからそういったあらゆるフィードバックを受けます。「こっちではこれはできるけど、あっちでは無理!」みたいな感じです。実際のW3Cでデザイナーの仕事をするという意味で、クロスプラットフォームでなければならないものをデザインしているということだと思うんです。APIとかは、僕もそのチームと仕事をしていたんだけど、他で行われていることをよく理解している必要があって、結果として作成したUXが他と大きく違いがないものになってしまう。それは、デザイナーやディベロッパーにとって試されるところでもあると思うんです。本能的には「より良い」ものにしたい一方で、他とかけ離れたものにはしたくないものですよね。