JSON Canvas – Um formato de arquivo aberto para dados de canvas infinito

Artigo original ↗ Discussão no Hacker News ↗

Um formato aberto baseado em JSON para apps de quadro branco e “canvas infinito”, criado pelos autores da Obsidian, está sendo apresentado como uma forma de tornar portáteis entre ferramentas notas visuais e grafos de nós. Comentadores recebem bem a simplicidade e o alinhamento com a filosofia da Obsidian de “arquivos em vez de app”, mas argumentam que a especificação 1.0 está pouco especificada, é opinativa em alguns pontos e minimalista demais para capturar muitos recursos comuns de canvas ou novos tipos de nó. Há amplo interesse na ideia de um formato de base compartilhado, junto com preocupações sobre interoperabilidade, versionamento e se o design deveria ter sido coordenado com outras grandes plataformas de canvas e diagramas.

Recepção geral

  • Muitos estão entusiasmados por haver um formato aberto e simples para canvases infinitos e elogiam a Obsidian por publicá-lo.
  • Outros acham que a especificação é imatura demais para ser chamada de “1.0” e a veem mais como um formato interno da Obsidian do que ainda como um verdadeiro padrão comunitário.

Projeto da especificação: simplicidade vs. completude

  • A especificação é muito pequena: nós com tipo/posição/cor, arestas com from/to/cor/rótulo, além de alguns subtipos de nós.
  • Alguns apreciam esse minimalismo “ao estilo Markdown” como algo bom para adoção, legibilidade e extensibilidade.
  • Outros argumentam que ela é pouco especificada e opinativa: cores predefinidas, tipos fixos de nó, semântica pouco clara para campos como file, backgroundStyle e coordenadas.

Interoperabilidade, extensibilidade e governança

  • Muitos gostam do objetivo de intercâmbio entre apps de canvas, mas questionam até onde isso pode ir quando os apps inovam principalmente na semântica e no comportamento dos nós.
  • Sugestões:
    • Especificação central de base com metadados extensíveis (semelhante a unist ou frontmatter de Markdown).
    • Suporte explícito a tipos de nós personalizados, estilos e embeds (URIs, tipos MIME, tipos de links mais ricos).
    • Campo de versão no nível superior; convenções para extensões.
  • Alguns criticam o lançamento como um “formato aberto 1.0” sem colaboração prévia com outras ferramentas; outros veem isso como um ponto de partida razoável que pode evoluir com feedback.

Detalhes técnicos e partes ausentes

  • Pedidos por:
    • Bounding box explícita / metadados para a visualização inicial e incorporação.
    • Definição mais clara de coordenadas, unidades, comportamento de zoom e origem.
    • Ordenação z definida (posteriormente adicionada: ordem do array = z-index).
    • Filhos de grupos explícitos em vez de inferir por sobreposição geométrica.
    • Mais estilização (espessura/estilo do traço, formas, rabiscos, transparência, roteamento de arestas).
  • Debate sobre arrays vs. maps para nós, campos obrigatórios vs. opcionais, e se devem existir “point nodes”.

Escolha do formato: JSON vs. alternativas

  • A escolha do JSON é vista como boa para ferramentas, uso na web e filosofia de arquivo de texto; alguns argumentam que SQLite ou formatos binários seriam melhores para integridade e desempenho, enquanto outros observam que portabilidade, diffabilidade e simplicidade favorecem JSON.
  • Comparações com SVG, GraphML, Excalidraw, Argdown, HTML e YAML: vários argumentam que reutilizar ou mapear para padrões existentes seria mais sensato; outros dizem que SVG/HTML são de nível baixo demais ou complexos demais para este modelo semântico em forma de grafo.

UX de canvas infinito

  • Sentimentos mistos: alguns acham canvases infinitos poderosos; outros os consideram esmagadores e pouco alinhados com seus modelos mentais.
  • As sugestões incluem densidade de informação em múltiplas escalas, canvases aninhados e ferramentas que operem sobre subconjuntos/fatias do viewport em vez de documentos inteiros.