Projeto Grace
OBS: esse post é um conteúdo um pouco diferente do tradicional aqui do forum é um post de noticia misturado com post opinativo aos moldes de post de dev blog. Eu gostei da experiencia de escrever esse tipo de conteúdo, se gostarem respondam com feedback de vocês. Se a recepção for positiva eu adoraria criar mais posts desse tipo
O que é?
Nesta quinta feira a equipe do HA fez uma live no youtube anunciando o projeto Grace. O projeto Grace é uma nova versão da dashboard do HA.
Para a primeira parte deste post tentarei seguir a ordem cronológica da apresentação.
Por que precisamos de uma dashboard nova?
A live começou introduzindo a visão do projeto.
De acordo com a equipe da Nabu Casa, o objetivo é que o HA se torne o melhor software para smart homes no mercado. Para isto é importante que todos os seus aspectos sejam acessíveis ao usuário comum. O projeto lovelace ainda deixa a desejar em alguns aspectos para poder se considerado acessível.
A equipe levantou os seguintes problemas:
- A dashboard padrão do lovelace, gerada automaticamente, não é muito util para maioria dos usuários.
- Criar dashboard customizadas é difícil para maioria dos usuários e leva muito tempo.
O que é? (Em mais detalhes agora)
O projeto grace é uma iteração do sistema de dashboard construído em cima do lovelace visando endereçar os dois problemas citados a cima, alem de ser acessível para todos tipos de Usuários e funcionando bem em qualquer tamanho de tela.
O projeto Grace NÃO IRÁ SUBSTITUIR O LOVELACE, porem, será a nova opção padrão.
A falha do lovelace
É tudo uma questão de layout
Em seguida a equipe passou um bom tempo explicando o algoritmo de layout padrão do lovelace, que é a falha mais obvia do lovelace.
Não é incomum aparecem relatos aqui no forum do tipo: “Troquei de monitor e minha dashboard quebrou”, “A dash que tinha feito para o celular fica horrível no tablet”, “O lovelace não parece nem ser determinístico”.
Antes de analisarmos os comentários vamos entender qual a causa das reclamações.
A equipe prosseguiu em explicar que o algoritmo padrão se chama masonry. Se você usa o Home Assistant em ingles deve estar familiarizado com o termo, em português ele se chama layout alvenaria. Ele é usado em softwares com boards, como, por exemplo, pinterest. O objetivo do algoritmo é usar o espaço de tela da maneria mais eficiente possível
O algoritmo
O algoritmo é simples, o próximo card sempre entra na menor coluna possível em caso de empate ele vai na coluna mais para esquerda.
Vamos exemplificar usando cards com alturas diferentes:
O preenchimento da primeira linha é bastante obvio independentemente de altura.
Se quisermos adicionar mais um card, em qual coluna você acha que ele vai?
Ele aparece na coluna 3, a menor. Se continuarmos adicionando cards como você acha que ficaria a segunda linha completa?
O sexto card vai na coluna 4, a próxima menor.
Em seguida a 1 e 2 tem mesmo tamanho então o sétimo card vai na 1 (mais da esquerda).
O software parece confirmar isso:
Acredito que a maioria de vocês lendo conseguiu intuir o resultado acima. Mas e se eu te dissese que ele poderia ser incorreto? A regra diz que a menor coluna recebe o próximo card e não a com menos cards. Nesse caso a chance de isso acontecer era muito baixa pois a diferença de altura entre os cards da primeira linha era pequena. Mas em alguns casos isso pode acontecer:
Uma coluna pode receber seu terceiro card antes de outra coluna ter recebido seu segundo.
Isso nos mostra que para prever o resultado final precisamos saber a altura de todos os cards que estão por vir. O que torna o comportamento um pouco confuso para os usuários.
Mas isto o torna não deterministico? Não. Se eu rodar o mesmo programa 1000 vezes, todas as vezes ele terá exatamente o mesmo resultado. O que analisei até aqui claramente não seria um problema tão grande. Seria um pouco estanho para configurar a primeira vez mas depois disso não faria diferença alguma ao usuário, mas eu deixei passar uma coisa importante: o contexto!
O verdadeiro problema.
O algoritmo não depende apenas do tamanho do card mas também de variáveis do contexto. Qual a largura da coluna? Qual tamanho da tela?
Vamos agora dar nomes aos cards:
A letra de cada card é seu nome. Em todos exemplos a seguir um card com uma determinada letra terá a mesma altura em todas imagens. O numero é a ordem em que ele foi posicionado.
O que acontece se eu aumentar ou diminuir a tela a tela?
Não apenas cards que estavam em canto da tela pulam para cantos opostos, mas a ordem em si parece mudar ! Cards que antes estavam visualmente antes de outro agora estão depois. Reparem que o numero de cada letra permanece o mesmo. Para o algoritmo a ordem permanece a mesma pois ele le em ordem de menor coluna. Nossa intuição é ler da esquerda para direita, de cima para baixo e por isso para nós parece que a ordem mudou.
Mais um problema ou um sintoma?
A equipe trouxe mais um problema do algoritmo. É quase impossível implementar drag and drop. Nesse momento comecei a perder meu interesse na live, eles começaram construindo uma narrativa e argumentação muito coerente mas, parece que ao longo da apresentação as coisas foram ficando confusas. Essa explicação do drag and drop foi onde comecei a notar isso. Mas antes de nos aprofundarmos nessa questão vamos entender o argumento deles.
Vamos voltar na primeira imagem com letras.
O que acontece se trocarmos a ordem dos dois primeiros cards?
Como esperado eles mudam de ordem, o B vem primeiro agora. Repare que dessa vez o numero muda e o B passa a ser o numero 1. Agora sim realmente mudamos a ordem do algoritmo e não apenas o output visual.
E se agora mudar o C com o F?
Como esperado o F passa a ser 3 e o C 6. O F foi para a posição esperada mas o C foi parar do outro lado da tela. Alem disso vários outros cards mudaram de posição. Isso não aconteceu antes pois A e B tinham mesmo tamanho.
Isso torna drag and drop inviavel.
Até aqui concordo com tudo, por exemplo:
Digamos que estamos implementando drag and drop para esse software. O usuário pega o F e arrasta até o C. O F permanece no lugar onde o usuário arrastou mas varios outros cards mudam de lugar. Não é ideal mas é aceitável ja que o foco do usuario era o F.
Mas e se arrastar o C até o F? Assim que soltar o C ele mudaria de lugar. Não é uma UX aceitável. Mover card para tras na lista é aceitável, mover para frente só se ambos tiverem mesmo tamanho.
A próxima fala da equipe que começou a me perder. Após demostrar esse problema eles argumentam que drag and drop é um problema não por causa dessa discussão acima mas sim pois a ordem não seria mantida depois de mudar tamanho da tela.
Isso não era um problema a parte que ja foi discutido?
a inviabilidade do drag and drop, é realmente o problema, ou é so um sintoma do problema?
Se for só um sintoma será que ao focar nele, não corremos o risco de não solucionar o problema?
Por enquanto vou deixar as indagações no ar. Vamos analisar o final da live.
Por que usamos masonry então?
Se esse layout é tão problemático porque ele foi escolhido para o lovelace? Otimização de espaço.
Vamos renderizar de novo os cards na ordem da ultima imagem porem agora usando um algoritmo de grid.
A ordenação agora é muito mais intuitiva, segue a ordem da nossa leitura. O drag and drop passa a ser viável pois o comportamento é previsível. As mudanças com tamanho da tela agora também são,
porem agora há espaço de tela desperdiçado. O problema pode se tornar ainda mais exacerbado dependendo da altura dos cards.
A equipe que desenvolveu o lovelace escolheu prioritizar essa eficiencia de espaço usado.
A solução
O projeto Grace propõe solucionar os problemas com 3 princípios de design:
- Sistema de Seções
- Sistema de Grid
- Grid com ordem em Z (mesma ordem do meu exemplo)
Seções
Ao entrevistar usuários a equipe percebeu que quase todos users mais experiente de HA criavam Seções. Pequenas colunas de cards relacionados. Para trazer essa pratica também para usuários menos experientes eles decidiram tornar isso parte do sistema.
Grid
A grid é uma parte fundamental do sistema Grace. Todos elemento de UI tem de estar alinhado a uma grid global. Tanto sections quanto seus cards. A questão do Z ficou meio confusa na fala deles mas parece ser so para as sections, ja que aparentemente as colunas tem tamanho fixo e portanto não precisam ser reoordenadas independete de tela. Apesar do sistema Z ser só para sections tudo esta na grid. Isso tem uma implicação interessante para custom cards. A altura e largura de todos cards tem de agora ser multiplos da unidade base da grid (tamanho do quadradinho na imagem acima).
A grid dos cards
Como mencionei acima os cards parecem se comportar de maneira diferente das sections. Um aspecto em especifico não ficou nada claro para mim:
Como funciona o algoritmo de posicionamento nas proximidades de cards com tamanho maior?
Um possível palpite seria que não ha algoritmo e o usuário posiciona os cards como quiser. Mas isso quer dizer que se eu tiver uma coluna de 30 itens de altura. E remover 15 do meio eu continuaria com um coluna com altura 30 porem com um grande buraco no meio até que eu manualmente movesse os cards do fim para cima. Acho pouco provável que essa tenha sido a solução escolhido. Eu acredito que qualquer algoritmo implementado passe a sensação inicial de ser mais intuitivo mas na pratica também vai causar bastante incomodo. Quem conhece bem esse problema é a Apple, que se recusou a implementar widgets na home do iOS por muito tempo, por ser apegada a simplicidade da sua grid. Apesar de eu achar positivo que haja widgets agora, é inegável que editar a home do iOS tenha ficado mais complexo.
A minha opinião
Agora após apresentar todo o projeto vamos analisar será que a solução realmente faz sentido?
Para mim é obvio que esta solução é melhor do que o lovelace para a maioria dos usuarios. O que não é tão obvio para mim é que essa seja melhor solução possível. Parece estranho para mim dizer que o grande vilão do lovelace é o masonry, e que o grande salvador será drag and drop.
Vamos analisar por etapas.
Comecando pelo drag and drop. Como perguntei anteriormente ele é o problema ou um sintoma?
Para mim esta claro que a dificuldade da implementação de drag and drop é causada por uma dificuldade de reordenção.
Podemos pensar naqueles 2 problemas trazidos pela equipe como.
- layout dinâmico pouco previsível (mudança de tamanho de tela)
- dificuldade de reordenação (drag and drop)
Se analisarmos de novo o segundo problema é causado pelo primeiro. A raiz do problema é a previsibilidade de ordenação.
Como vimos antes implementar drag and drop no masonry é possível, mas a UX é péssima. Ou seja drag and drop não é a solução, é só um enfeite. A verdadeira solução são as sections e a grid.
Possivelmente ter a grid sem o drag and drop seria suficiente para atingir os objetivos.
Claro que ter drag and drop é positivo e deveria ser adicionado alguma hora mas nesse momento me parece falta de foco.
A propria equipe disse que dependendo do feedback vai começar do zero. Então por que gastar tempo com coisas que não solucionam o problema raiz?
Vamos analisar tambem as sections. As sections como a propria equipe menciona ja sãp uma solução pensada pelos powerusers do HA para solucionar os problemas do masonry. Será então que elas sozinhas sem a grid não seriam o suficiente? E se as sections fosse adicionadas como parte integral do sistema e dentro das sections houvessem grids locais mas as sections fossem organizadas como masonry? As informações relacionadas não seriam separadas, a eficiência de espaço é mantida. Talvez essa outra solução ou a proposta pela equipe sejam só uma questão de gosto. Mas a existência dela coloca em xeque a argumentação utilizada.
O que me incomoda não é a solução mas o raciocínio apresentado para chegar nela. Pode até ser um problema só de comunicação, talvez a apresentação não foi boa, ou eu tive dificuldade de interpretação mas o motivo disso me incomodar tanto tem raízes mais profundas.
O rumo do HA
A algum tempo venho sentido que o HA trilha um caminho estranho. O HA originalmente era um projeto para entusiastas. Era difícil de usar, viável apenas para pessoas técnicas. Em algum momento a equipe decidiu mirar no publico mainstream o que acho ótimo. Mudanças incriveis fora desenvolvidas nos ultimos anos porem algumas mudanças tem sido desnecessariamente em detrimento do usuário avançado.
Por exemplo a migração para tornar a configuração padrao ser por UI é ótima. Mas porque deprecar yaml? Porque não fazer a UI simplesmente gerar o yaml? Configuraçao por texto tem varias vantagens: Facilidade de backup, facilidade de reutilização, facilidade de configuração em escala…
A parte de backup foi parcialmente solucionado recentemente com um sistema de backup mais robusto integrado diretamente ao HA core. Mas isso não seria uma solução parcial para um problema que eles mesmos criaram?
No lovelace isso é ainda pior pois essa tecnologia de interoperabilidade de yaml e UI existe. Mas se você quer manter modo UI ativado tem que usar o editor de texto ruim embutido e não consegue separar em arquivos as diferentes views.
Eles ja estão meio do caminho andado porque não polir os detalhes?
Tendo isso em mente, assistir uma apresentação de um novo sistema de dash focado em usuários novatos, com argumentos aparentemente incoerentes me preocupa.
Ainda mais eles dizendo que entrevistaram 21 usuários. Considerando apenas usuários que ativaram analytics (de acordo com a estimativa do HA 1/3 dos users totais) temos cerca de 300.000 usuários. O HA core foi o segundo repositório do github com mais contribuidores de 2023.
Mais de 15.000 pessoas consideraram em 2023 o HA valioso suficiente para gastar seu tempo propondo alguma mudança no código ou documentação do HA. Desses 300.000 ou até desses 15.000, só 21 estavam disponíveis para entrevista? Será que eles realmente representam bem uma comunidade tão diversa? Desde os que nem usam dashboard e fazem tudo por automação ate aqueles que passam horas a customizando? Desde aqueles que gastam dinheiro melhorando sua redde para usar so devices wifi ate aqueles que morreriam defendendo tecnologias mesh? Desde os que quer a integração mais fácil e barata até aqueles que se matam de trabalho para garantir que nada na sua casa se comunica com cloud?
Conclusão
O projeto grace parece ser bem interessante mas traz a tona alguns problemas que acredito vem acontecendo faz algum tempo. Sinto que a equipe da nabu casa tem ficado meio perdida e ao tentar fazer um software ótimo para todos estão correndo risco de criar um software bom para ninguém.
Apesar de tudo isso o HA é parte integral do meu dia a dia. Uma ferramente que eu dependo e gosto muito. Não vou tambem ser 100% pessimista, muita coisa melhorou bastante e ha muito chão pela frente antes de termos certeza para qual caminho o HA realmente vai seguir.
Na atualização desse mes será lançada uma versão beta do projeto Grace, vamos aproveitar para testar e trazer feedback para a equipe para que a versão final seja de fato a melhor solução possível!
E vocês o que acham do projeto Grace e do rumo geral do HA?