拡張機能の問題点・要望議論

いよいよ、本日のメインとなる拡張機能の問題点と要望議論についてとなった。司会進行は、Piro氏が行った。

  • 図5 Piro氏

テーマによっては、かなり細かな部分もあり、雰囲気のみのレポートとさせていただきたい。Piro氏から、開発ツールや環境、さらに開発方法などについて、実際に便利かやりやすいか、ベストプラクティスになりうるか、といったことがざっくばらんに出席者と語られていた。その議論の土台となったのが、図6である。

  • 図6 議論の土台となった書き込み

これは今後も使われる可能性もあるので、公開されている(内容も、適宜、変更される可能性があるので注意いただきたい)。興味があれば、ぜひご覧いただきたい。

途中、懇親会もスタートし、さらにゆるい雰囲気で議論が進んだ。そのいくつかを紹介しよう。

  • 採用されやすいAPI
  • Bugzillaにアップしたことある
  • 日本語・英語以外のロケールの対応
  • 機能拡張や追加仕様の要求があったら
  • 英語でのコミュニケーション

APIであるが、やはりXUL拡張からの移行を考えると、実装されていないAPIが多い。これは、参加者の多くが語っていた。そこで、APIの追加を依頼することになる(Bugzillaなどが使われる)。Piro氏によれば、従来のXUL拡張の機能を1対1で対応するようなAPIは、採用されないことが多い。逆に採用されやすいAPIは、ある程度、抽象化されたものが多かったとのことだ。さらに、Webの開発者がこういうAPIがあると使いやすいといった提案をしたほうが、採用されやすいだろうとも語っていた。他の参加者からも、トリアージュされた経験などが報告された。

英語のコミュニケーションであるが、これも関心を集めた。Bugzillaでの提案だけならば、日本語でも不可能ではない。しかし、実際に採用され、実装までの流れのなかでは、本社スタッフとやりとりを重ねる必要がある。そこで、英語が必要になる。多くの日本人にとって大きな壁になる可能性がある。しかし、高校生の英語で十分であるとの指摘があった。逆にGoogle翻訳などで、こなれた英語にしてしまうと、英語力があると判断され、容赦のないメッセージが送られることがあるとのことだ。ちなみに、三単現の「s」を忘れるような、ネイティブが絶対しないような文法ミスがあっても、問題ないとのことだ。英語力がないことを理解して、それなりの対応をしてくれるとのことである。こういった不安や体験なども、リアルに話し合うことができていた。開発だけでなく、環境的な部分での負荷についても語り合う機会だったといえるだろう。

今後の予定

最後に今後の予定などが紹介された。Daisuke氏によれば、できれば3か月に1度くらいのペースでやっていきたいとのことであった。また、取り上げるテーマについても、要望があれば、できるだけ応えていきたいとのことだ。当日、図7のような候補が紹介された。

  • 図7 今後のTokyo WebExtensions Meetupの予定テーマ