あくまでもDOMのJavaScriptについての操作に特化しているのでバックエンドのサーバについては考慮していません。ただし、Liveのコネクションがサーバ経由であるということであれば"できなくもない"といえます。

現状では今まで通りの手続きになります。ただ、デザイナーとデベロッパーの共同作業を考えると新しいテクノロジの採用も考えています。今後開発が進めば、より詳細な情報をご提供できると思います。

DreamweaverとFireworks、Bridge、そしてVersion Cue等を巻き込んでやるのが良いのではないでしょうか。大きなアセットの管理、保持、セグメンテーションの方法についてはアドビからもベストプラクティスを積極的に紹介していきたいと思います。現状のDreamweaverの機能の中でどのようになるかはまだ未定の段階で、もし良いアイデアがあれば是非フィードバックを寄せて欲しいと思います。

現在各プロジェクトのファイルのフォーマットをどのようにするのか等、そのワークフローの積極的な統合を検討しているところです。今後数カ月の間により詳細な情報が提供できると思います。

1フロアの一角が埋め尽くされているのは記憶しているのですが何人だったかな(笑)。私の机はその隣にあります。日本人は2人います。それなりの人数で開発を行っています(笑)

製品の性質上、Webのテクノロジの進化にあわせて進化させていきたいと考えています。Web2.0とAjaxのような大きな流れになったタイミングでSpryを統合させました。さらにDreamweaver自体がコミュニティによる拡張が行えるので、特定の業界や市場固有の拡張が行えるのもポイントだと思います。Webはこれまで進化も革命も繰り返してきましたが、Dreamweaverもそれぞれのタイミングで対応できてきたと考えています。

Dreamweaverはテクノロジに対する窓口と考えています。パーツに分割してバラバラにするよりも、このソフト1つあればWeb上でどんなことができるのかユーザーに対して啓蒙することができる方が重要ではないかと考えています。

コーディングのみによる製品は今後も検討していきたいと思います。ActionScriptにおけるFlex Builderのような存在が良い例かも知れません。Dreamweaverとの競合についてはオープンソースや低価格な製品が他にもあると認識していますので、マーケットの声に耳を傾け、コード開発者のワークフローを改善するという目的で製品を拡充していきたいと思います。

プロ向けとコンシューマ向けの違いとしては、共通の製品テクノロジのどの部分を使わせるのかが重要だと考えています。コンシューマ向けという切り口とは異なりますが、例えばThermoのように、一般的に難解なMXMLを理解しなくても、目で見て、直感的に操作することでコンテンツが産み出せるような、そのようなアプローチで今後も製品を拡充していきたいと考えています。