Compartilhar via

Motivações e princípios

  • Artigo

Abaixo estão as motivações e os princípios que regem a evolução do formato de Cartão Adaptável.

Motivações subjacentes ao formato

No início de 2016, várias equipes na Microsoft (incluindo Outlook, Windows e Bot Framework) chegaram à conclusão de que todas queriam algo extremamente semelhante ("cartões") e de que cada uma delas estava projetando suas próprias soluções de modo independente:

  • O Windows tinha seu próprio formato de Blocos Dinâmicos e Notificações
  • O Bot Framework estava usando um conjunto de modelos de cartão predefinidos dentre os quais os desenvolvedores poderiam escolher ao enviar mensagens de bot
  • O Outlook estava usando seu próprio formato MessageCard para seu recurso de Mensagens Acionáveis

Simultaneamente, outras plataformas, como LINE, FaceBook Messenger, Slack e outras, estavam definindo seus próprios formatos de "cartão" proprietários. Portanto, alguns funcionários da Microsoft se reuniram e iniciaram um esforço para definir um único formato de cartão aberto e um conjunto de SDKs que:

  • facilitariam o intercâmbio de cartões entre hosts;
  • permitiriam que cada host mantivesse o controle sobre o estilo dos cartões para garantir a consistência visual;
  • tornariam fácil para um aplicativo host exibir cartões com o mínimo de esforço por meio de SDKs prontos para uso;
  • também forneceriam valor a terceiros e, eventualmente, seriam adotados amplamente pelo setor

Princípios que regem os Cartões Adaptáveis

  1. O Cartão Adaptável é um formato de cartão simples e declarativo

    1. Ele não é destinado a ser uma substituição/alternativa a HTML nem a XAML
    2. Não há "code-behind" com Cartões Adaptáveis
      1. Os criadores de cartões não podem inserir código personalizado/arbitrário nos conteúdos desses cartões e, como resultado, um host de Cartão Adaptável nunca precisa executar código de terceiros
      2. Dinamismo e interatividade são obtidos unicamente por meio de marcação declarativa
    3. Isso garante que o esforço necessário para criar um SDK de Cartão Adaptável para uma nova plataforma permaneça razoável

  2. O formato de Cartão Adaptável não pode impor o uso de nenhuma tecnologia subjacente específica

    1. O formato de Cartão Adaptável não depende de JavaScript, C#, Python, nem nenhuma outra linguagem
    2. Da mesma forma, ele não depende de HTML, XAML, nem nenhuma outra estrutura gráfica/de interface do usuário
    3. Dessa forma, os Cartões Adaptáveis podem ser renderizados nativamente em qualquer plataforma enquanto há um renderizador

  3. O formato de Cartão Adaptável é uma propriedade compartilhada

    1. O formato, juntamente com os respectivos SDKs, deve ser software livre e a evolução dele deve ser impulsionada pela comunidade
    2. Portanto, o formato não é de propriedade de nenhuma equipe específica, nem é controlado por uma

  4. O formato de Cartão Adaptável não foi projetado "apenas para uso da Microsoft"

    1. Em vez disso, ele foi projetado para atender às necessidades de uma ampla variedade de aplicativos e casos de uso

  5. O Grupo de Trabalho de Cartão Adaptável governa a evolução do formato

    1. Esse grupo de trabalho é composto por um conjunto de funcionários da Microsoft que estão profundamente envolvidos no sucesso do formato
    2. O grupo de trabalho realiza reuniões semanais (atualmente na segunda-feira) durante as quais as propostas de recursos são examinadas, problemas em aberto são discutidos e triados e o progresso geral nos itens de trabalho vNext é acompanhado
    3. O grupo de trabalho usa muito os comentários da comunidade, incluindo equipes internas da Microsoft, para decidir como o formato evolui
      1. Qualquer pessoa pode participar do grupo de trabalho abrindo problemas no GitHub (veja abaixo)
      2. Problemas/solicitações de recurso originadas no uso real da estrutura de Cartões Adaptáveis (como um host ou um criador de cartão) têm o maior impacto no futuro do formato
    4. Para serem aprovados pelo grupo de trabalho, novos recursos propostos:
      1. precisam justificar-se por casos de uso da vida real;
      2. precisam ter uma especificação funcional
    5. O novo recurso aprovado é adicionado à lista de pendências e considerado para o vNext
      1. Os critérios usados para priorizar novos recursos incluem a amplitude dos cenários que o recurso permite, a complexidade/manutenção dele e muito mais
      2. Em caso de dúvida, deixe fora. É muito mais fácil introduzir um recurso bem projetado mais tarde do que conviver com um erro permanentemente.
    6. Todos os novos recursos são implementados em todos os SDKs compatíveis
    7. Todos os novos recursos são documentados e associados a um cartão de teste publicado na pasta de exemplos
    8. As novas versões do formato e dos SDKs passam por uma fase beta
    9. A agenda de lançamento para versões do esquema de Cartão Adaptável e do SDK é orientada por qualidade, não por data

  6. Interoperabilidade

    1. Os cartões criados de acordo com o formato documentado (por exemplo, não usando nenhuma extensão específica a um host) serão renderizados corretamente em qualquer host compatível com Cartões Adaptáveis
    2. As únicas exceções a esses princípios são:
      1. Alguns hosts podem não permitir interatividade e, portanto, não renderizarão entradas nem ações
      2. A execução de ações de Action.Submit fica a critério do host, e nem todos os hosts, necessariamente, manipulam adequadamente todos os conteúdos de Action.Submit. Além disso, alguns hosts podem ser totalmente incompatíveis com Action.Submit

  7. O formato precisa ser extensível

    1. Os hosts devem ter a liberdade de adicionar suporte para elementos personalizados ou ações personalizadas que vão além do que o formato é capaz de fazer
    2. Isso é particularmente importante para ações, pois vários hosts não necessariamente dão suporte ao mesmo conjunto de ações
    3. Essas adições ficam a critério do host
      1. Elas não são uma adição de fato à especificação do Cartão Adaptável
      2. Dessa forma, elas criam um conteúdo que as utiliza e que é incompatível com o formato de Cartão Adaptável principal
      3. No entanto, elas podem ser apresentadas ao grupo de trabalho e propostas como novos recursos para uma versão futura do formato, conforme descrito no ponto n. 5

  8. O conteúdo pertence aos criadores do cartão, enquanto a aparência e a experiência pertencem ao aplicativo host

    1. Os aplicativos host impõem o próprio estilo, de modo que os cartões parecem ser extensões nativas da experiência do aplicativo
    2. Os autores de cartões podem ainda especificar o estilo, mas somente por meio de expressões semânticas de cores, tamanhos, etc.

  9. SDKs serão fornecidos para as plataformas de desenvolvedor mais populares

    1. Os SDKs facilitam a renderização de conteúdos de Cartão Adaptável em qualquer host
    2. Isso garante que a barreira para a entrada seja tão baixa quanto possível tanto para desenvolvedores terceiros quanto para equipes da Microsoft