O botão de alternância deve mostrar o estado atual ou o estado para o qual vai mudar? (2010)

• Quando ações executadas imediatamente como Play/Pause e configurações persistentes como Shuffle são tratadas com o mesmo tipo de toggle, o usuário pode confundir o estado atual com a próxima ação
• O livro About Face 2.0 recomenda evitar o flip-flop button, que coloca duas opções em um único controle, e considera mais importante comunicar o estado atual do que economizar espaço
• A solução se aproxima de escrever a ação como uma locução verbal, como Switch to portrait mode, ou separar estado e transição com botões de opção, checkboxes ou rótulo de estado + botão de ação
• Em switches no estilo iOS, quando o texto fica dentro do botão, ON pode ser ambíguo: estado atual ou próximo estado; em estilos como OS X e Windows Metro, colocar o texto de estado fora do botão reduz essa ambiguidade
• A convenção de Play/Pause pode, como exceção, mostrar a próxima ação, mas opções como Shuffle, Like e Auto save são mais seguras quando enfatizam o estado atual e o reforçam com tooltip, cor, estado pressionado ou um rótulo separado

---

Conflito entre indicar estado e indicar ação

• Em botões que alternam entre dois estados, como Play/Pause e Shuffle/Regular Play, a questão central é se devem mostrar o estado atual ou o estado de transição que será aplicado após o clique
• Play/Pause tende a ser interpretado pelo usuário como uma ação — “iniciar reprodução” ou “pausar” — por isso a convenção de mostrar Play quando está parado e Pause quando está tocando é familiar
• Shuffle/Regular Play se parece mais com um estado de opção do modo de reprodução; se mostrar o estado para o qual vai mudar, pode ficar confuso saber se está em shuffle ou em reprodução sequencial
• O player de música embutido do Xbox 360 é citado como exemplo de confusão ao mostrar o ícone de reprodução direta quando o modo shuffle está ativo e o oposto na situação inversa

A recomendação do About Face: evitar flip-flop button

• About Face 2.0 classifica esse tipo como um flip-flop button, um “idioma de escolha a evitar”
• Quando um único botão controla duas opções mutuamente exclusivas, ele economiza espaço, mas dificulta cumprir a segunda obrigação do controle: comunicar o estado atual
• Se o botão mostra ON quando o estado atual é desligado, a configuração fica pouco clara; se mostra OFF quando está desligado, pode ficar a dúvida de onde está o botão ON
• Há duas soluções recomendadas
  • Escrever a ação do botão como uma locução verbal, por exemplo Switch to portrait mode
  • Usar outra técnica de UI que deixe a escolha de estado explícita, como dois botões de opção

Diferenciar botões de ação e botões de estado

• action button e state button devem ser projetados de formas diferentes
  • Se for uma ação, como Play/Pause, ele mostra o que vai acontecer ao clicar
  • Se for uma opção, como Shuffle/Linear, ele mostra o estado atual
• Em um botão de Shuffle apenas com ícone, o ideal é manter um único ícone de shuffle e fazê-lo parecer ativo/inativo conforme o estado
  • Quando ligado, pode ficar mais brilhante ou parecer um botão pressionado
  • Quando desligado, deve ficar claro que a reprodução está em sequência normal
  • Em ambientes com hover, um tooltip pode deixar isso ainda mais claro
• Há também a opinião de que até Play/Pause pode causar menos confusão se o rótulo não mudar e o botão Play aparecer pressionado

A ambiguidade criada pelo texto dentro do botão

• ON e OFF, em inglês, podem ser lidos tanto como estado quanto como ação de transição; quando ficam dentro do botão, pode ficar incerto se representam estado ou comando
• Foram sugeridos pares de termos mais explícitos
  • Enable / Disable
  • Enabled / Disabled
  • Start / Stop
  • Running / Stopped
• Ainda assim, a escolha das palavras não elimina totalmente o problema
  • O usuário talvez ainda precise decidir se o texto do botão representa estado ou comando
  • A diferença entre Enable e Enabled pode não ser clara o suficiente dentro da UI

Rótulo fora do botão e separação entre estado e ação

• Se o botão não tiver texto e o texto ficar fora dele, é possível mostrar ao mesmo tempo o estado atual e o estado para o qual é possível mudar
• No switch estilo OS X, o botão não “diz” ON nem OFF; o texto ao redor do switch indica o estado, reduzindo a dúvida entre “estado atual” e “próxima ação”
• No estilo Windows Metro, a cor do botão indica o estado atual, e o texto On/Off abaixo da opção confirma esse estado
• Também é possível separar em rótulo de estado + botão de ação, como em Online [Go offline]
  • Online é um rótulo do estado atual e não é clicável
  • Go offline é a ação clicável de transição
  • Depois do clique, passa a Offline [Go online]
• Esse modelo pode ser mais compacto que botões de opção e ainda assim separar visualmente o papel de estado e ação

Checkboxes, botões de opção e estado pressionado

• Opções como Shuffle causam menos confusão quando são representadas por uma checkbox com o rótulo Shuffle
• Quando se usa uma única palavra e o estado marcado indica se está ativo, reduz-se a carga de ter de interpretar o significado entre várias palavras
• É melhor evitar expressões com prefixo negativo
  • Prefixos como Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- podem soar como dupla negação quando combinados com um estado desmarcado
• O botão Like no app Android do Facebook é citado como exemplo: cinza quando desligado e destacado em azul quando ligado
  • Ainda assim, usar apenas cor pode não ser suficiente para pessoas com deficiência na percepção de cores

Exemplos reais de UI e cuidados

• Há uma solução intermediária em botões como o Shuffle no web app do Spotify: cor neutra quando desligado e cor de destaque quando ligado
• A mudança no estilo do Twitter ao passar o mouse mostra o estado atual e, no hover, passa a mostrar a ação
  • Isso pode funcionar em ambientes com hover, mas não necessariamente em telas sensíveis ao toque
• O switch estilo iOS mostra os dois estados dentro de um único controle, mas também recebe críticas porque ON pode ser interpretado como estado atual ou como estado após o clique
• A UI de configurações do Discord é citada como exemplo de toggle em estilo checkbox que torna mais claros o estado atual e o estado futuro
• Também são lembrados exemplos como o toggle por mouseover do Evernote e o interruptor de maçaneta de banheiro de avião, em que estado e possibilidade de ação ficam visíveis ao mesmo tempo

Princípios de design

• Quando um único controle assume ao mesmo tempo a função de comunicar estado e comunicar ação, surge ambiguidade
• O estado atual precisa sempre ser comunicado de alguma forma
  • Em Play/Pause, o próprio contexto externo — música tocando ou tempo avançando — pode complementar a informação de estado
  • Em Shuffle, é difícil saber o estado antes de observar como a próxima faixa será escolhida, então a indicação no próprio botão se torna mais importante
• Fazer um único botão percorrer vários estados pode compactar a UI e agrupar configurações mutuamente exclusivas, mas o usuário precisa conseguir identificar rapidamente o estado atual
• Play/Pause pode ser uma exceção, por causa da força da convenção, em que se mostra a próxima ação; para toggles de opção em geral, enfatizar o estado atual tende a ser mais consistente

[GN⁺]

Opiniões do Hacker News

• Ultimamente estou realmente frustrado com o Microsoft Teams. No app de desktop, quando o microfone está no mudo, aparece um ícone de microfone com uma linha cortando; quando o mudo é desativado, ele muda para um microfone sem a linha, então é fácil entender
  Mas, ao entrar pelo app no celular, o mesmo ícone de microfone cortado significa “no momento não está no mudo; se você tocar neste botão, ele ficará no mudo”. Mesmo depois de tocar, o ícone continua sendo o microfone cortado, só o fundo é invertido
  Fico pensando se, de um lado, é um botão de “ligar microfone” e, do outro, um botão de “ativar mudo”, e por isso usam o mesmo ícone. No fim, para julgar o estado atual, preciso saber como o botão aparece no estado oposto, então acabo sempre apertando algumas vezes para confirmar qual abordagem esse app usa
  Fico me perguntando se esse é o preço da flat UI que perdeu seus referentes do mundo real

  • Acho que parte dessa confusão vem da mentalidade de que o microfone fica ligado por padrão. O padrão em que “microfone ativo” é o estado padrão e o mudo é tratado como um desvio desse estado vem das UIs de sistemas de teleconferência, dos telefones analógicos e, voltando ainda mais, da época em que havia uma linha física conectando as partes
    Mixers de áudio para música ao vivo ou gravação normalmente usam o mesmo padrão. Há um botão “Mute” que acende uma luz vermelha quando o canal é desligado, e só alguns equipamentos mostram que o canal está ativo com um botão “ON” aceso acima do fader
    Acho que já está na hora de os apps de reunião passarem para uma abordagem em que o áudio fica desligado por padrão. Isso já aparece aos poucos na forma como elementos da UI acendem quando alguém está falando
  • Esse é um botão que realmente não deveria causar confusão
  • No Plex também é frustrante de um jeito parecido, porque a UI varia de um app para outro. No celular, ao ver uma temporada de série, os episódios já assistidos têm uma marca de seleção azul; na TV, ao ver a mesma temporada, não há marca azul, e os episódios não assistidos têm um triângulo amarelo
    Toda vez que alterno entre dispositivos, meu cérebro dá uma travada
  • O Discord é pior. O botão de mutar o microfone e o botão de desligar a câmera funcionam de maneiras opostas
  • A questão de indicação/controle do microfone tem um aspecto bem interessante. Sem feedback visual direto, você não sabe em que modo o microfone está até que outra pessoa reaja ou deixe de reagir
    Mesmo quando está ligado, é uma ferramenta com grande atraso de feedback. A outra pessoa pode ter parado, ou pode estar pensando antes de responder, então muitas vezes é preciso testar duas ou três vezes para ter certeza
    É diferente do modo escuro, que você vê imediatamente quando liga ou desliga. Por isso, uma indicação visual que mostre o estado atual ajuda muito, seja qual for a ação do botão, e não surpreende que haja tantas tentativas de misturar “estado” e “controle” especialmente no caso do microfone

• Quem é dono de um Tesla não tem como não se identificar. Os botões de alternância da UI do carro são tão variados que não há consistência nem padrão
  Por exemplo, o botão do ar-condicionado é um único botão que mostra a temperatura, mas reage de formas diferentes dependendo de como e por quanto tempo você o pressiona. Um toque curto abre um pequeno pop-up; um toque um pouco mais longo abre o painel completo de controle do ar-condicionado; se você mantiver pressionado por alguns segundos, o ar-condicionado que estava ligado pode até desligar. O problema é que tudo isso precisa ser feito enquanto você está dirigindo e precisa olhar para a estrada
  Se a coordenação olho-mão falhar só um pouco — algo especialmente provável ao passar por irregularidades na pista enquanto dirige — basta errar por 1 mm para apertar outro botão e acionar algo não intencional
  Outro desastre é a UX de conexão de dispositivos Bluetooth. Pelo menos na implementação do Model S de 2012 a 2022, foi uma das piores misturas de UI que já vi em um produto lançado. O botão no canto inferior direito continua exibindo “Connect” mesmo depois de já estar conectado, enquanto, no lado oposto da tela, no canto superior esquerdo, aparece “Connecting...” e depois a indicação de conexão concluída
  Isso também é uma UI dentro do carro, então, se você está dirigindo, só consegue olhar por um instante. Só a UI de Bluetooth da Tesla já daria para preencher um capítulo de livro sobre UI de tão magnificamente ruim que é

  • No app móvel da Tesla, até toggles que ficam lado a lado são inconsistentes entre si
    O cadeado fechado significa que as portas estão trancadas e, ao tocar nele, as portas destrancam
    A palavra “Open” no porta-malas significa que o porta-malas está fechado e, ao tocar nela, ele abre
  • Seria bom você escrever esse texto. Esse tipo de análise é sempre interessante e, se o tema for Tesla, ainda envolve o Elon, então acho que atrairia mais atenção
  • Meu jeito de usar o botão do ar-condicionado é este: primeiro olho para o botão; se ele estiver meio transparente e eu quiser ligar, basta clicar que ele liga. Se eu clicar de novo, os controles completos abrem, e deslizar para baixo fecha
    Quando quero desligar, aperto de novo o botão para abrir os controles completos e toco no botão de desligar. Para ajustar a temperatura, clico no botão e deslizo para a esquerda ou para a direita para aumentar ou diminuir
    Para mim, parece bem intuitivo. Da próxima vez que eu dirigir, pretendo tentar o método de pressionar e segurar para desligar, que parece bem útil
  • No Model Y 2023, o Bluetooth realmente funciona bem. Como não era assim nos meus antigos Audi e Ford, estou satisfeito
    Vendo que as implementações são sempre tão ruins, fico pensando se não há alguma parte seriamente enrolada na própria especificação do Bluetooth
  • Isso deveria ser ilegal

• Há algum tempo eu tinha alguns interruptores de botão da NASA, com duas lâmpadas dentro. Quando o interruptor estava desligado, as duas ficavam apagadas; ao apertar o botão, a lâmpada amarela acendia, mostrando que o acionamento do interruptor tinha sido registrado
  Quando o dispositivo que se queria ligar de fato ligava, a luz verde acendia e a amarela apagava. O estado amarelo era uma confirmação de que o interruptor tinha sido alternado, e o verde, uma confirmação de que a ação desejada realmente tinha ocorrido — um mecanismo interessante de feedback de estado

  • É uma boa abordagem, e aviões também fazem isso[1]. Esse tipo de problema já foi resolvido por pessoas que levam usabilidade muito a sério, mas a indústria de computadores é lenta para adotar esse tipo de coisa de outras áreas
    Colocar o rótulo do lado de fora do interruptor também funciona bem[2]
    [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
    [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
  • Passei boa parte do início da minha carreira escrevendo software de GUI para controlar hardware remoto e exibir seu estado, e logo passei a excluir todos os elementos de UI que armazenam o próprio estado. Elementos como toggles, interruptores, checkboxes e botões de opção, que mudam de comportamento conforme seu próprio estado, com frequência ficavam desalinhados em relação ao estado do hardware
    Em vez disso, colocávamos um botão para cada opção e fazíamos o botão correspondente ao estado atual acender. Por exemplo, um toggle de ligar/desligar virava dois botões: “on” e “off”. No início, ambos ficavam cinza; quando recebíamos do hardware um SOH indicando que o estado era ligado, o botão on ficava verde; se fosse desligado, o botão off ficava vermelho
    Se a comunicação caísse por algum tempo, esmaecíamos todas as cores para indicar que o estado estava desatualizado. Ao apertar um botão, continuávamos mostrando o estado anterior até que o novo estado voltasse, mas esmaecíamos apenas aquele grupo de botões
    O usuário podia comandar diretamente on ou off a qualquer momento, independentemente do estado que a UI achasse que estava ativo. Já um toggle só permite mudar para “o outro estado”
    Também substituímos botões de opção por grupos de botões com os nomes dos estados, colorindo apenas o item que a UI considerava atual. A maioria dos estados neutros era azul; quando havia um significado de bom/atenção/ruim que o operador queria destacar, usávamos verde/amarelo/vermelho
    Era um design peculiar, mas os operadores em geral entendiam sem treinamento específico. Os botões pareciam botões e, portanto, clicáveis; o espaçamento deixava claro que formavam um grupo; e, nas UIs dos anos 90, cinza era o padrão, então o botão com outra cor naturalmente chamava atenção como o estado atual
    Não sei se isso ainda funcionaria em um ambiente como o de hoje, em que elementos de UI usam qualquer cor por motivos estéticos ou para induzir transições, e só às vezes transmitem informação. Também fizemos experimentos, ao estilo dos botões da NASA, mostrando ao mesmo tempo o estado do comando e o estado recebido, mas todos ficaram mais confusos
  • Gosto disso. Não entendo por que nosso setor não olha com mais frequência para os setores aeroespacial/militar, onde mal-entendidos podem matar pessoas

• Ah, o checkbox, 1990–2009. Era perfeito e inequívoco, mas por algum motivo os designers de smartphones o odiaram

  • O mais engraçado é que dá para pegar algo que é essencialmente um checkbox e deixá-lo bem bonito, com aparência de toggle. Não é um bom exemplo, mas mostra que ele não precisa necessariamente ser um quadrado com uma marca de seleção: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
  • O sistema de videoconsulta/telemedicina que uso estragou o checkbox. Na interface de mensagens diretas, ele muda o rótulo do campo do checkbox conforme está marcado ou não
    Se não estiver marcado, aparece “Not Urgent”; se estiver marcado, “Urgent”. Marquei e desmarquei rapidamente várias vezes achando que tinha indicado que não era urgente, e então apertei enviar
  • Concordo que o checkbox é perfeito. Mas isso também tem a ver com o fato de não tentarmos preencher formulários no smartphone
    O checkbox padrão do navegador é pequeno demais para ser pressionado com o polegar no smartphone, então é difícil usá-lo com frequência
  • Quem criou o widget de checkbox? O System 1 (1984) tinha uma “caixa com x” equivalente à marca de seleção em menus, mas, até onde sei, não era o checkbox propriamente dito
  • Jony Ive é o Thomas Midgley Jr. do design? Ele popularizou com o iOS 7 o design flat de baixa usabilidade, e também é responsável pelo mouse redondo do iMac e pelo teclado frágil dos MacBooks

• O pior exemplo que vi foi a UI da tela do painel da Tesla. Há rótulos sobre o desenho do carro que não parecem botões e dizem “Open”
  Isso é lido claramente como significando que aquela parte está aberta, mas não é isso que quer dizer. O rótulo é um botão para abrir aquela parte, e o usuário não tem como saber

  • Exato. Dirigi um Tesla alugado neste fim de semana e fiquei confuso e assustado várias vezes achando que os porta-malas dianteiro e traseiro estavam ambos abertos
  • Concordo 100%. É a segunda coisa mais frustrante na UX do porta-malas da Tesla. A primeira é a animação longa demais que você precisa esperar depois de mudar para Park para poder abrir o porta-malas
    No geral, a UX da Tesla está muito à frente da de outros carros, mas essas pequenas coisas são muito frustrantes
  • Para mim, não é nem um pouco confuso. A renderização do carro mostra claramente o estado atual do porta-malas, e ao apertar o botão de abrir aparece também uma animação do porta-malas abrindo
    Parece que cada um percebe de um jeito
  • Curiosamente, isso é um problema do inglês. Em inglês, o verbo e o adjetivo muitas vezes são iguais. Em espanhol, “Abrir” (infinitivo verbal) e “Abierto” (adjetivo) são diferentes, então isso não acontece
    Talvez desse para evitar usando algo como “Do open” ou “Is open”, mas será que isso soa estranho para falantes nativos?
  • Será que essa característica existe só no inglês? Por exemplo, em espanhol o verbo e o adjetivo são palavras diferentes

• O problema central dos botões de alternância é que um único objeto contém ao mesmo tempo o estado do sistema e a ação que o altera.
  Por isso, não fica claro se o “ON” mostrado no botão é o estado atual ou a ação que será executada ao pressioná-lo.
  A solução é separar, em alguma medida, estado e ação. Há várias formas de fazer isso; uma delas, como em uma das respostas do link, é colocar o rótulo fora do botão.
  Se não for um switch, mas um botão de alternância como no exemplo do Teams, basta manter o ícone e mudar outra propriedade do botão. Por exemplo, como se fez por décadas sem problemas, deixá-lo em estado pressionado para indicar o estado “ON”.

  • Nas propriedades de som do sistema do Windows 11, há a opção “Allow apps and Windows to use this device for audio” e, ao lado, um botão “Don't allow”. Assim, não dá para saber qual é o estado atual.

• Concordo com a conclusão, mas tanto qual é o estado atual quanto para qual estado ele mudará ao alternar precisam estar claros. Muitas vezes só depois de ficar alternando é que se percebe que nem era necessário mudar.
  O ponto de reproduzir/pausar é interessante, porque parece ir contra a conclusão. Mas ele segue um precedente físico bem compreendido, e geralmente também fica claro se a música ou o vídeo está tocando. Por isso, mesmo que o ícone do botão não mude, o usuário consegue entender o que acontecerá ao pressioná-lo.
  Voltando a toggles e UI, mudar a cor do toggle de cinza-claro para um cinza um pouco mais claro é extremamente inútil. Coloquem um rótulo. Se o rótulo não combina com o motivo visual do design, é preciso arrumar um designer melhor.

  • Se fosse para seguir o precedente físico, a imagem do botão deveria mostrar a ação, isto é, reproduzir, e o estado visual pressionado/não pressionado deveria indicar se aquela ação está ativa.
    Designers de software não seguiram isso e criaram a troca entre ícones de reproduzir/pausar, gerando uma nova confusão. Isso teve menos a ver com motivos de facilidade de uso e mais com o fato de botões 3D esqueumórficos terem saído de moda.
    A única vantagem de mostrar o estado é quando algo dá errado. Em áudio, isso é especialmente comum: mudo ativado, fone desconectado, driver de áudio do Linux quebrando de novo, e assim por diante.
    Até hoje, quando vejo um botão de reproduzir/pausar, sinto uma leve dissonância cognitiva, e quando há algum problema às vezes simplesmente aperto duas vezes, porque não tenho 100% de certeza do que exatamente o botão de pausa significa.
  • Concordo que o estado atual precisa estar claro. Num interruptor de luz, não é preciso saber qual direção significa “ligado”; na prática eu nem sei. Basta ver se a luz acendeu.
  • A frase “coloquem um rótulo; se o rótulo não combina com o motivo visual do design, arrumem um designer melhor” não ajuda e é irrealista, especialmente em dispositivos móveis.
    Por exemplo, no Spotify não há espaço para colocar um rótulo atrás de todos os botões. Também é preciso espaço para mostrar a capa do álbum, e eu quero isso.
    Não é uma questão de designer melhor; restrições de espaço realmente existem. Algumas funções precisam estar disponíveis com um único toque. Não quero esconder o shuffle atrás de um menu pop-up.

• Botões de alternância devem mostrar o estado atual. Caixas de seleção são um bom exemplo.
  Muted [] e Muted [x] são bastante claros.
  O que complica é quando o designer cria uma UI em que a ligação entre as palavras e o design visual não é clara. Por exemplo, algo como Mute Off [---( )], Mute On [( )---] mistura uma ação na descrição do estado, e não dá para saber o que significa.

  • Quando há espaço suficiente, uma imitação de toggle com rótulos nos dois lados funciona bem.
    Loudspeaker [()---] Crossed-out loudspeaker
  • Uma marca de seleção é um tique[1]. Em páginas de status[2], o tique significa “em funcionamento” e a cruz significa falha. Do ponto de vista de “óbvio”, Muted [x] pode ser lido como se algo tivesse falhado.
    Para entender de outro modo, é preciso aprender a UX de computadores, o que é o oposto de obviedade. Ou talvez signifique o alvo em que se deve clicar quando se quer silenciar, como em “X marks the spot”.
    [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
    [2] por exemplo https://www.githubstatus.com/
  • A caixa de seleção mostra junto o estado atual e as opções possíveis em uma forma simples de sim/não.
    Botões de alternância são confusos porque não dá para saber a intenção do designer. É difícil saber, a menos que as duas opções sejam mostradas juntas.
    Mute On[---()]Off
  • Um botão deve dizer o que fará ao ser clicado. Se você quer mostrar o estado atual, isso é um indicador separado, não um botão.
    Botões existem para serem clicados, portanto precisam comunicar o que acontecerá ao clicar.
  • Em sistemas de escrita da direita para a esquerda, os dois lados também deveriam ser invertidos?

• Deve mostrar os dois, como um interruptor analógico. Deve mostrar o estado atual de forma clara e sem ambiguidade e, ao mesmo tempo, também mostrar para qual estado ele mudará.
  O toggle deslizante esquerda-direita da Apple fez isso muito bem. Fica claro onde o toggle está agora, para onde ele mudará e se a configuração atual ativou a função, com o fundo azul, ou a desativou, com o fundo cinza.

• Um design de que eu gostava tinha uma luz de status ao lado do interruptor, e essa luz acendia quando o estado ficava ligado, mas agora não consigo encontrá-lo.
  O melhor era que isso também resolvia o atraso de operações assíncronas. Ao pressionar o interruptor, ele alternava e, pouco depois, a luz acendia. Era muito satisfatório, porque dava a certeza de que a interação realmente tinha feito algo.

  • Sem ver o design real, isso também parece um exemplo da ambiguidade discutida no texto. Não fica claro se o ícone representa o que acontecerá em seguida ou o que está acontecendo agora.
    A questão é se é estado ou ação. Um design específico pode não ter sido ambíguo, mas só pela descrição ele é.
  • Se, depois de muito tempo, você voltasse àquela página e visse a luz acesa, como saberia se aquilo significa que o estado atual é ON ou que clicar mudará para ON? Há alguma forma de distinguir imediatamente só olhando para a luz acesa?
  • Parece um recurso de interface visto em dispositivos “smart”. Só conheço bem os switches TP-Link Kasa, mas acho que a UI do app deles também tinha algo parecido, em que um ícone colorido tinha vários estados, e o estado mais próximo de “ligado” significava que ele tinha confirmado com o switch que estava ligado.
  • Parece um bom caso de uso para telas HDR. Dá para tornar a “luz indicadora” muito mais brilhante que o restante da tela e mostrar com muita clareza que agora a luz acendeu.
    Claro, isso só funcionaria se o usuário não tivesse deixado o brilho da tela alto demais desde o começo.