Motivaciones y principios

  • Artículo

A continuación, se muestran las motivaciones y los principios que rigen la evolución del formato de Tarjetas adaptables.

Motivaciones en que se basa el formato

A comienzos de 2016, varios equipos de Microsoft (incluidos Outlook, Windows y Bot Framework) llegaron a la conclusión de que todos querían algo muy similar ("tarjetas") y que cada uno de ellos diseñaba sus propias soluciones de forma independiente:

  • Windows tenía su propio formato de iconos dinámicos y notificaciones.
  • Bot Framework usaba un conjunto de plantillas de tarjeta predefinidas que los desarrolladores podían elegir al enviar mensajes de bot.
  • Outlook usaba su propio formato MessageCard para su característica de mensajes que requieren acción.

Al mismo tiempo, otras plataformas, como LINE, Messenger de FaceBook, Slack, etc., definieron su propio formato de "tarjeta" de propiedad. Por tanto, algunos empleados de Microsoft se reunieron e iniciaron un esfuerzo por definir un único formato de tarjeta abierta y un conjunto de SDK que:

  • Facilitaría el intercambio de tarjetas entre hosts.
  • Permitiría que cada host mantuviese el control sobre el estilo de las tarjetas para garantizar la coherencia visual.
  • Facilitaría a una aplicación host la visualización de tarjetas con el mínimo esfuerzo a través de SDK listos para usar.
  • También proporcionaría valor a terceros y, finalmente, sería adoptado en gran medida por el sector.

Principios que rigen las Tarjetas adaptables

  1. Tarjeta adaptable es un formato de tarjeta simple y declarativo.

    1. No está diseñado como una alternativa o un reemplazo de HTML o XAML.
    2. No hay "código subyacente" con las Tarjetas adaptables.
      1. Los autores de tarjetas no pueden incrustar código personalizado ni arbitrario con sus cargas y, como resultado, un host de Tarjetas adaptables nunca necesita ejecutar código de terceros.
      2. Dinamismo e interactividad se logran únicamente a través del marcado declarativo.
    3. Esto garantiza que el esfuerzo necesario para compilar un SDK de Tarjeta adaptable para una nueva plataforma siga siendo razonable.

  2. El formato de Tarjeta adaptable no puede imponer el uso de ninguna tecnología subyacente determinada.

    1. El formato de Tarjeta adaptable no se basa en JavaScript, C#, Python ni en ningún otro lenguaje.
    2. Del mismo modo, no se basa en HTML ni XAML ni en ningún otro marco de interfaz de usuario o gráfico.
    3. De este modo, las Tarjetas adaptables se pueden representar de forma nativa en cualquier plataforma mientras exista un representador.

  3. El formato de Tarjeta adaptable es una propiedad compartida.

    1. Junto con sus SDK, el formato será de código abierto y su evolución controlada por la comunidad.
    2. Por lo tanto, el formato no es propiedad ni está bajo el control de ningún equipo.

  4. El formato de Tarjeta adaptable no está diseñado "solo para el uso de Microsoft".

    1. En su lugar, se ha diseñado para satisfacer las necesidades de una amplia variedad de aplicaciones y casos de uso.

  5. El grupo de trabajo de Tarjeta adaptable rige la evolución del formato.

    1. Este grupo de trabajo está formado por un conjunto de empleados de Microsoft que están muy implicados en el éxito del formato.
    2. El grupo de trabajo realiza reuniones semanales (actualmente los lunes) durante las cuales se revisan propuestas de características, se discuten problemas abiertos y se realiza un seguimiento del progreso general de los elementos de trabajo de vNext.
    3. El grupo de trabajo utiliza comentarios de la comunidad en general, incluidos los equipos internos de Microsoft, para decidir cómo evoluciona el formato.
      1. Cualquier persona puede participar en el grupo de trabajo mediante la apertura de problemas en GitHub (ver a continuación).
      2. Los problemas y las solicitudes de características cuya raíz es el uso real del marco de Tarjetas adaptables (ya sea como un host o como autor de la tarjeta) tienen el mayor impacto en el futuro del formato.
    4. Para que las apruebe el grupo de trabajo, las nuevas características propuestas:
      1. Deben justificarse en casos de uso reales.
      2. Deben tener una especificación funcional.
    5. La nueva característica aprobada se agrega al trabajo pendiente y se considera para vNext.
      1. Los criterios que se usan para clasificar por orden de prioridad las nuevas características incluyen el alcance de los escenarios que la característica habilita, su complejidad y mantenimiento, etc.
      2. En caso de duda, se debe dejar fuera. Es mucho más fácil introducir una característica bien diseñada más adelante que que contenga un error indefinidamente.
    6. Todas las características nuevas se implementan en todos los SDK compatibles.
    7. Todas las características nuevas se documentan y asocian a una tarjeta de prueba publicada en la carpeta de ejemplos.
    8. Las nuevas versiones del formato y los SDK pasan por una fase beta.
    9. La programación de versión para el esquema de Tarjeta adaptable y las versiones del SDK se basa en la calidad, no en la fecha.

  6. Interoperabilidad

    1. Las tarjetas creadas de acuerdo con el formato documentado (por ejemplo, sin usar extensiones específicas del host) se representarán correctamente en cualquier host compatible con Tarjetas adaptables.
    2. Las únicas excepciones a estos principios son las siguientes:
      1. Es posible que algunos hosts no permitan la interactividad y, por tanto, no representen entradas ni acciones.
      2. La ejecución de acciones Action.Submit es a discreción del host y no todos los hosts controlarán correctamente todas las cargas de Action.Submit. Además, es posible que algunos hosts no admitan Action.Submit.

  7. El formato debe ser extensible.

    1. Los hosts deben tener la libertad de agregar compatibilidad para elementos personalizados o acciones personalizadas que vayan más allá de lo que el formato es capaz.
    2. Esto es especialmente importante para las acciones, ya que varios hosts no admiten necesariamente el mismo conjunto de acciones.
    3. Estas adiciones son a discreción del host.
      1. No suponen una adición de hecho a la especificación de la Tarjeta adaptable.
      2. Como tal, realizan una carga que las usa de forma incompatible con el formato de Tarjeta adaptable estándar.
      3. Sin embargo, se pueden presentar al grupo de trabajo y se deben proponer como nuevas características para una versión futura del formato, como se describe en el punto 5.

  8. Los autores de tarjetas son propietarios del contenido y la aplicación host es propietaria del aspecto.

    1. Las aplicaciones host imponen su estilo para que las tarjetas tengan el aspecto de extensiones nativas de la experiencia de la aplicación.
    2. Los autores de tarjetas todavía pueden especificar el estilo, pero solo a través de expresiones semánticas de colores, tamaños, etc.

  9. Se proporcionarán SDK para las plataformas de desarrollador más populares.

    1. Los SDK facilitan la representación de cargas de Tarjetas adaptables en cualquier host.
    2. Esto garantiza que la barrera que se va a especificar sea tan baja como puede ser tanto para desarrolladores de terceros como para Microsoft Teams.