Rostos dos Assistants: emoji no lugar do mascote

Onde o tamanho mais pesa: o rosto tem 18 px. Hoje são oito quadrados azuis quase iguais.

Painel lateral de 320 px. As respostas usam o rosto de 22 px.

O rosto fica parado. Enquanto o Assistant não está pronto, o estado aparece ao lado do nome, no lugar do modelo.

O movimento fica só no ponto, um pulso lento: Working

Largura real de 390 px.

Vários Assistants falam em seguida, e quem fala precisa ser reconhecido sem ler o nome.

Interativo, com o conjunto inteiro. O Studio vira este editor. Os textos estão em inglês, como no produto.

O Mascot Studio de hoje, que este editor substitui

Os números que sustentam as decisões.

O que o conjunto inteiro acrescenta

• O executável tem hoje 136,1 MB. Com o conjunto, passa a cerca de 156,6 MB, mais 15%.
• Primeira carga do app: nada muda. Hoje são 18,6 MB de JS e CSS no computador e 15,6 MB no celular, sem compressão, e o editor entra numa parte carregada à parte.
• Ao abrir o editor: índice de 82 KB e os desenhos visíveis, cerca de 170 KB no total. É estimativa, 60 desenhos pela mediana de 2,9 KB comprimidos.
• Cada rosto na tela pede só o próprio desenho, uma vez, e fica em cache. A mediana é 7,7 KB; o maior tem 287 KB.
• No celular, nada vai junto no aplicativo: a página e os desenhos vêm do computador.

A lista com todos os emoji

Medido num navegador sem placa de vídeo, que desenha tudo no processador. O número absoluto é pessimista; serve para comparar. A travessia em 3 s é um caso extremo, e nela a virtualização não ganha nos quadros, ganha na abertura. Na construção a medição se repete no app real.

O custo de desenhar o fundo

Uma tela real tem de 8 a 30 rostos, cerca de 50 vezes menos que este teste. Recomendo só CSS estático: nenhum filter nem backdrop-filter por linha. As variantes em SVG ficaram de fora porque o teste de redesenho delas não mediu o que devia.

O que quebra, medido

• Legibilidade a 18 px: degradê de duas cores aparece; degradê de um tom, sombra, ruído e borda sobre cor sólida não se distinguem da cor sólida.
• Transparência: a 60% segura. A 30% só com borda. Sem fundo, os emoji claros somem no tema claro e a cor deixa de identificar.
• Contraste: mesmo a 100%, o magenta fica em 2,68:1 no escuro, abaixo da meta de 3:1. Quem identifica é o emoji; o fundo ajuda.
• Vidro (o fundo translúcido da janela no computador): a barra lateral continua opaca mesmo nele, e a captura confirmou isso. Só o cabeçalho do painel fica sobre o material. Ali, num papel de parede claro e no tema escuro, o fundo cai a 1,03:1 mesmo sólido. Por isso a transparência mistura com uma cor conhecida e nunca deixa ver o que está atrás.
• Não testado: o Vidro real do Windows. Simulei o material no navegador de teste.

Cada imagem segue o tema escolhido aqui.

1. D1. Qual desenho usar

   Recomendo Noto Emoji. A 18 px, ele se distingue melhor que o Twemoji. A pasta com os desenhos tem licença própria, Apache 2.0, e pode ir no produto levando o aviso de copyright e o texto da licença. A OFL do arquivo principal cobre as fontes. As bandeiras são de domínio público ou isentas de direito autoral. Os nomes vêm do emojibase, MIT. Tudo fica listado no arquivo NOTICE. É leitura das licenças, não parecer jurídico.

2. D2. Como enviar o conjunto inteiro

   Recomendo um único zip dentro do executável, 20,5 MB, com os desenhos servidos um a um e só quando pedidos. Funciona sem internet, usa só a biblioteca padrão do Go e não muda a primeira carga. Tirar os tons economizaria 9,8 MB, mas você pediu o conjunto inteiro. Entram 259 bandeiras de países. Inglaterra, Escócia e País de Gales não têm desenho nessa pasta e ficam de fora.

3. D3. O que fica guardado no Assistant

   Recomendo guardar só o código do emoji e o fundo, cerca de 200 bytes, sem copiar o desenho. Você sugeriu levar o desenho junto. Com o conjunto dentro do programa, celular e computador buscam o mesmo desenho no mesmo lugar e veem o mesmo rosto, sem carregar o conjunto. Copiar custaria três coisas:

   • Hoje a aparência salva é só dado, nunca um desenho que o navegador executa. É uma decisão registrada, e mudá-la é escolha sua.
   • 201 desenhos são maiores que o limite de 32 KB para salvar um Assistant.
   • Cada lista de Assistants levaria todos os desenhos junto.

   Se um dia o conjunto sair do programa, a cópia passa a valer. Um emoji sem desenho disponível, como um mais novo restaurado numa versão antiga, mostra a inicial do nome no fundo escolhido.

4. D4. Tons de pele e gênero

   O conjunto tem 332 emoji com cinco tons e 192 entradas específicas de homem ou mulher. Recomendo mostrar a pessoa neutra em amarelo por padrão, com um único seletor de tom que vale para a lista toda e fica lembrado neste aparelho. As versões de homem e mulher saem da grade e aparecem na busca. Assim a lista fica com 1.728 itens em vez de 4.000.

5. D5. Sugestão por papel, com profissões primeiro

   Recomendo profissões primeiro, como você pediu, com um limite de quatro pessoas por grupo; depois disso, objetos. As profissões renderizam certo, sem desenho quebrado. Mas a 18 px oito pessoas viram cabeças amarelas parecidas, e só a cor separa. A mistura identifica melhor. Exemplos: Developer , DevOps , Research , Finance , Support . A tabela é local, em inglês e português, sem chamar modelo; a sugestão não repete emoji dentro do grupo, e a pessoa pode repetir se quiser. Um agente que cria um Assistant pode mandar o emoji; sem ele, recebe a mesma sugestão.

   

   

   

6. D6. Degradê e transparência

   Recomendo cor sólida por padrão, degradê de 2 ou 3 cores com 8 direções, e transparência de 30% a 100%. Abaixo de 60% a borda liga sozinha. Sem fundo nenhum fica de fora: o emoji claro some e a cor deixa de identificar. Não recomendo modelos prontos de degradê, porque aí seria o produto a desenhá-los.

   

   

   

   

   

   

   

7. D7. Quais efeitos oferecer

   Recomendo só a borda. O brilho está no protótipo para você experimentar, mas não o recomendo: no claro ele borra, e custa 43% a mais. Deixei de fora:

   • Sombra e ruído: a 18 px não se distinguem da cor sólida.
   • Desfoque, mistura de camadas e filtros: são os mais caros e não mudam o que se vê nesse tamanho.
   • Fundo com imagem e degradê animado: viram editor de imagem e movimento em toda lista.

   

   

   

   

   

8. D8. Migração e receitas salvas

   Recomendo dar um emoji a todos os Assistants existentes pela tabela da D5, num campo novo, e deixar a receita do mascote guardada sem uso.

   • Cor: a cor de fundo salva vira a cor do rosto. Quem ainda está no azul padrão recebe as oito cores em ordem, para não continuar tudo azul.
   • Receita antiga: fica intacta no campo atual e nada mais escreve nele. Se esse campo mudasse de formato, uma versão antiga que restaurasse um backup novo não conseguiria mostrar nenhum Assistant, porque hoje uma receita inválida derruba a lista inteira. O campo sai numa versão futura.
   • Templates: os que têm mascote ganham emoji ao serem usados; os novos levam o rosto novo.
   • Sem Assistant: as telas vazias que hoje mostram o mascote padrão passam a mostrar o agent tile.

9. D9. Estados

   Recomendo tirar os estados do rosto e deixá-los no ponto e na palavra. A barra lateral e a lista do celular já têm os seus. O cabeçalho do chat não tem, e a 320 px não cabem nome, modelo e estado; por isso o estado ocupa o lugar do nome do modelo enquanto o Assistant não estiver pronto.

Para saber o que entra e o que fica de fora.

Como o rosto viaja

• Backup: o rosto fica no banco de dados principal, que já entra em todo backup e volta na restauração. Não nasce fonte nova de dados. Um backup antigo, sem rosto, recebe emoji ao abrir, como na migração.
• Celular e computador: os dois leem o mesmo Assistant do mesmo computador e desenham pela mesma função, então o degradê sai igual. Os recentes e o tom ficam em cada aparelho.
• Outro computador: um Assistant não sai da máquina onde mora. O rosto vem de lá, e o desenho também. Se aquele computador tiver uma versão antiga, o editor pede para atualizá-lo em vez de falhar ao salvar.
• Formato: só valores conferidos, como cor em HEX, ângulo e porcentagem. Nunca texto livre de estilo.

A regra contra enfeite continua igual

• A regra vale para o que o produto desenha. Botões, menus e o restante da interface seguem sem emoji como ícone, sem degradê e sem vidro.
• O rosto é escolha da pessoa, guardada na receita. Quem não mexe recebe cor sólida, e o produto não traz degradê pronto.
• Os emoji vêm dos dados, como imagem, sem estarem escritos no código da interface. A distinção fica escrita na regra, sem afrouxá-la.

Não muda

• Logo, agent tile, splash e lockup COGNIX[WS].

O que estas telas não provam

• O proposto foi desenhado por cima da tela real no navegador de teste. O código do produto não mudou.
• Conversas e estados são simulados, sem modelo e sem login.
• Não testei o Windows real, o Vidro real nem um celular físico.
• O editor é protótipo: a navegação por teclado e o salvamento entram na construção.