動機と原則

  • [アーティクル]

アダプティブ カード形式の発展を管理するうえでの動機と原則について説明します。

形式を管理する動機

2016 年初旬に、Microsoft のいくつかのチーム (Outlook、Windows、Bot Framework を含む) では、すべてのチームが非常によく似たもの ("カード") を必要としており、各チームが別々に独自のソリューションを設計していることに気が付きました。

  • Windows には独自のライブ タイルと通知形式がありました
  • Bot Framework では、Bot メッセージを送信するときに開発者が選択できる、事前定義済みのカード テンプレートのセットを使用していました
  • Outlook では、アクション可能メッセージ機能用の独自の MessageCard 形式を使用していました

同時に、LINE、FaceBook Messenger、Slack などの他のプラットフォームでは、独自の専用 "カード" 形式を定義していました。 このため、Microsoft の数名の従業員が集まり、次のような機能を持つ、単一のオープンなカード形式と SDK のセットを定義する取り組みを開始しました。

  • ホスト間のカードの交換を促進する
  • ビジュアルの一貫性を確保するために、カードのスタイル設定に対する制御を各ホストが保持できるようにする
  • すぐに使える SDK により、ホスト アプリケーションで最小限の労力によって簡単にカードを表示できるようにする
  • サードパーティにも価値を提供し、最終的に業界で広く採用されるようにする

アダプティブ カードの管理における原則

  1. アダプティブ カードは、単純で宣言型のカード形式である

    1. HTML や XAML に置き換わるものではありません
    2. アダプティブ カードに "コードビハインド" を作成しない
      1. カードの作成者は、カスタム/任意のコードをペイロードに埋め込むことはできません。このため、アダプティブ カードのホストは、サードパーティのコードを実行する必要はありません
      2. ダイナミズムと対話機能は、宣言型マークアップのみによって実現されます
    3. これにより、新しいプラットフォーム向けにアダプティブ カードの SDK を構築するために必要な労力を妥当に抑えます

  2. アダプティブ カードの形式により、特定の基盤となるテクノロジの使用を強いてはならない

    1. アダプティブ カード形式では、JavaScript、C#、Python、およびその他の言語を使用しません
    2. 同様に、HTML、XAML、その他のグラフィック/UI フレームワークも使用しません
    3. これにより、アダプティブ カードは、レンダラーが存在する限り、どのプラットフォームでもネイティブにレンダーできます

  3. アダプティブ カード形式は、共有プロパティである

    1. SDK と共に、形式はオープン ソースであり、その発展はコミュニティによって促進されます
    2. そのため、形式は 1 つのチームが所有するものでも促進するものでもありません

  4. アダプティブ カードの形式は "Microsoft 専用" として設計しない

    1. そうではなく、多様なアプリケーションやユースケースにおけるニーズに適合するように設計されます

  5. "アダプティブ カード ワーキング グループ" が形式の発展を管理する

    1. このワーキング グループは、全員が形式の成功に深く関与する、Microsoft の従業員によって構成されます
    2. ワーキング グループは、週次の会議 (現在は月曜日) を実施し、機能の提案の検討、未解決の問題に関する議論とトリアージ、vNext の作業項目の全体的な進捗の追跡を行います
    3. ワーキング グループでは、形式の発展に関する決断において、Microsoft 内部のチームを含む、コミュニティ全体からのフィードバックを活用します
      1. GitHub で問題を作成する (下記を参照) ことによって、だれでもワーキング グループに参加できます
      2. アダプティブ カード フレームワークの実際の使用に基づく問題/機能に関する要望は、(ホストまたはカード作成者のどちらの場合も) 形式の今後の発展に最も大きな影響を及ぼします
    4. ワーキング グループによって承認されるためには、新しい機能の提案では以下を満たす必要があります
      1. 実際のユース ケースにおいて妥当である
      2. 機能仕様を持つ
    5. 承認された新機能は、バックログに追加され、vNext で検討されます
      1. 新機能の優先順位付けに使用される基準には、その機能によって可能になる幅広いシナリオ、複雑さ、保守容易性などが含まれます
      2. 不確かな場合は見合わせましょう。 適切に設計された機能を後で導入する方が、間違ったまま進むよりはるかに簡単です。
    6. すべての新機能は、すべてのサポートされる SDK に実装されます
    7. すべての新機能は、文書化され、samples フォルダーで公開されるテスト カードと関連付けられます
    8. 形式と SDK の新しいバージョンは、ベータ フェーズを経ます
    9. アダプティブ カード スキーマと SDK のバージョンのリリース スケジュールは、日付ではなく、品質によって決まります

  6. 相互運用性

    1. 文書化された形式 (例: ホスト固有の拡張機能を使用しない) に従って作成されたカードは、アダプティブ カード対応のすべてのホストで適切にレンダリングされます
    2. この原則に対する例外は以下のみです。
      1. 一部のホストでは相互運用性が許可されない場合があります。このため、入力もアクションもレンダリングされません
      2. Action.Submit アクションは、ホストの判断で実行されます。このため、すべてのホストがすべての Action.Submit ペイロードを適切に処理するとは限りません。 また、ホストによっては Action.Submit がまったくサポートされていない場合があります

  7. 形式は拡張可能でなければならない

    1. ホストでは、形式の機能を超えて、カスタムの要素やカスタムのアクションへのサポートを自由に追加できるようにする必要があります
    2. アクションについては、ホストによってサポートするアクションのセットが異なるため、これは特に重要です
    3. これらの追加は、ホストでの裁量に任されます
      1. これらは、アダプティブ カードの仕様に対して "事実上" 追加されるものではありません
      2. このため、これらを使用するペイロードは、メインストリームのアダプティブ カード形式との互換性がなくなります
      3. ただし、5 で説明したように、ワーキング グループにこれらを提示し、形式の今後のバージョン向けの新機能として提案できます

  8. カードの作成者はコンテンツを所有し、ホスト アプリは外観を所有する

    1. ホスト アプリによってスタイル設定が適用され、カードの外観が、アプリのエクスペリエンスのネイティブな拡張機能のようになります
    2. カードの作成者はスタイル設定を指定できますが、色やサイズなどのセマンティックな表現に限定されます。

  9. 一般的な開発プラットフォーム向けに SDK を提供予定

    1. SDK により、すべてのホストでアダプティブ カードのペイロードを簡単にレンダリングできます
    2. これにより、サードパーティの開発者と Microsoft チームの両方にとって、参加への障壁が非常に低くなります