共用方式為

動機和原則

  • 發行項

以下是管理調適型卡片格式演變的動機和原則。

格式背後的動機

2016 年初，Microsoft 的幾個小組 (包括Outlook、Windows 和 Bot Framework) 意識到他們都想要一個非常相似的東西 (「卡片」)，並且他們都在獨立設計自己的解決方案：

  • Windows 有自己的動態磚和通知格式
  • Bot framework 使用一組預先定義的卡片範本，開發人員可以在傳送 Bot 訊息時從中選擇
  • Outlook 針對其可採取動作的訊息功能使用自己的 MessageCard 格式

同時，其他平台 (例如 LINE、FaceBook Messenger、Slack 等) 會定義自己專屬的「卡片」格式。 因此，一些 Microsoft 員工聚集起來，開始努力定義單一、開放的卡片格式和一組 SDK，這些卡片格式和 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. 因此，此格式不是任何一個小組所擁有或驅動的

  4. 調適型卡片格式不是設計為「僅供 Microsoft 使用」

    1. 相反地，它是為了符合各種應用程式和使用案例的需求而設計的

  5. 調適型卡片工作群組負責控制格式的演進

    1. 此工作小組是由一組 Microsoft 員工所組成，它們全都密切參與到該格式的成功
    2. 工作小組會執行每週會議 (目前在星期一)，在這段期間會審核功能提案、討論和分類未決問題，並追蹤 vNext 工作項目的整體進度
    3. 工作小組會使用來自大型社群的意見反應 (包括內部 Microsoft 小組) 來決定如何演變格式
      1. 任何人都可以透過在 GitHub 中建立問題來參與工作小組 (請參閱下文)
      2. 根據「調適型卡片」架構 (作為主機或卡片作者) 實際使用方式的問題/功能要求，對格式的未來影響最大
    4. 若要由工作小組核准，所提出的新功能：
      1. 必須依實際使用案例合理化
      2. 必須具有功能規格
    5. 已核准的新功能會新增至待處理專案，並針對 vNext 進行考量
      1. 用來設定新功能優先順序的準則包括功能所啟用的各種案例、複雜度/維護性等
      2. 如有疑問，則不予採用！ 引入一個設計良好的功能，比永遠忍受錯誤要容易得多。
    6. 所有的新功能都會在所有支援的 SDK 中實作
    7. 所有的新功能都已記載，並與範例資料夾中發行的測試卡片相關聯
    8. 新版本的格式和 SDK 會經歷搶鮮版 (Beta) 階段
    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 小組的入門門檻一樣低