Open aprendendofelipe opened 2 years ago
Cada vez mais estou sentindo falta de diferenciar o que já abri, o que eu não abri e o que é novo.
Se for para ter somente duas visualizações diferentes, uma solução simples, que pode ser a primeira versão, pode ser usar o :visited para diferenciar as publicações já visitadas das não visitadas. Qualquer nova publicação ficará com a mesma formatação das publicações antigas não visitadas.
Eu topo total que essa seja a primeira versão. Mas como isso seria executado com o Primer? A gente sobrescreveria o estilo dele?
Se for para diferenciar os 3 casos, também é simples, pois é só salvar no localStorage qual foi a hora do último acesso e destacar os conteúdos criados após esse horário. Só me preocupa um pouco a poluição visual com 3 formatações diferentes no ContentList.
Eu estava pensando em colocar uma bolinha azul e algum lugar, onde se é a primeira visita da pessoa e não há dado do último acesso, nenhuma bolinha aparece, pois do contrário todas as publicações teriam bolinhas.
Em seguida pode ser feito algo mais complexo, envolvendo também destacar conteúdos com novas respostas (talvez de início destacando se a quantidade de respostas mudar, o que não é o ideal, mas quebra um galho inicialmente).
Isso é muito massa! Deixar azul se algum novo comentário for adicionado. Mas o problema é que para ser perfeito não daria para usar a quantidade de comentários para fazer o diff, uma vez que se um comentário foi adicionado e enquanto isso outro foi deletado, a diferença de quantidade é zero. Mas acho que deveríamos deixar para pensar isso numa próxima fase mesmo 🤝
Daí quando ficar rodando legal de acordo com o feedback dos usuários, partimos para uma forma de salvar no banco de dados para que o usuário tenha essas informações sincronizadas entre diferentes dispositivos.
Isso mais para frente seria sensacional!! Principalmente se usar estratégias de stale-while-revalidate 🤝
Isso pode ajudar na estilização:
https://primer.style/react/overriding-styles#nesting-pseudo-classes-and-pseudo-elements
Tava pensando aqui, o /user
poderia devolver um last_visit
, que poderia ser atualizado toda vez que esse endpoint é chamado. Não sei se é uma boa prática nesse caso um GET
atualizar um valor assim, mas em paralelo, a sessão também é renovada por GET
em rotas que injeta o usuário.
Eu estava pensando em colocar uma bolinha azul e algum lugar
Uma outra solução poderia ser utilizando algo estilo tags
:
Que massa meu caro! O YouTube usa essa mesma estratégia 🤝
Uma preocupação que é necessário ter, é sobre como isso ficaria em Mobile (que não possui muito espaço na esquerda e direita da tela) 👍
Uma preocupação que é necessário ter, é sobre como isso ficaria em Mobile (que não possui muito espaço na esquerda e direita da tela) 👍
No mobile poderíamos encurtar a tag
para uma bolinha, caso precise otimizar o espaço.
No mobile poderíamos encurtar a
tag
para uma bolinha, caso precise otimizar o espaço.
Bom ponto! Mas fico pensando: será que não ficaria mais assimilável para a pessoa que alterna entre um ambiente e outro ter exatamente a mesma dica visual?
Bom ponto! Mas fico pensando: será que não ficaria mais assimilável para a pessoa que alterna entre um ambiente e outro ter exatamente a mesma dica visual?
Entendo, nesse caso a referência visual seria a cor da tag, porem é uma questão a se pensar.
pode ser usar o :visited
Testei o :visited
para uma primeira versão, porem não obtive êxito, parece não funcionar com o Primer
Utilizo o Thunderbird para ler e-mails gosto muito da abordagem, repliquei para o layout do tabnews abaixo:
Opção 01 | Opção 02 |
---|---|
![]() |
![]() |
Opção 03 | Opção 04 |
![]() |
![]() |
Eu gosto da ideia de mudar a fonte, deixando mais destacado o que for novidade e mais apagado o restante.
Nesse exemplo existe destaque para 3 casos diferentes:
Com relação ao destaque para novas respostas, existem duas opções:
Gosto da alternativa 2, pois pode ser um indicador de que o conteúdo antes ignorado, ainda pode estar relevante.
Opção 1 | Opção 2 |
---|---|
![]() |
![]() |
Aproveitando a opção 3 do @rodrigoKulb, eu não acho legal o avatar, pois uma imagem sempre chama mais atenção do que um texto, então o autor vai chamar mais atenção do que o título.
Também sobre essa opção 3, eu gosto da ideia de retirar o número que acompanha o título, pois esse número não acrescenta muita informação para o leitor. Sei que ele ajuda na separação dos conteúdos, mas seria um bom lugar para colocar um ícone de status que faria tanto a função de separar os conteúdos como destacar os que tivessem novidades.
Pensando nisso, poderia acrescentar aos exemplos que coloquei acima uma alternativa em que o número está destacado não só nos conteúdos não lidos, mas também nos que tem novos comentários. E esse destaque poderia bem ser um ícone no lugar do número.
Testei o
:visited
para uma primeira versão, porem não obtive êxito, parece não funcionar com o Primer
O que você tentou alterar no estilo? Não dá pra alterar nada além de algumas cores usando o :visited
.
Fonte: https://developer.mozilla.org/pt-BR/docs/Web/CSS/:visited#restri%C3%A7%C3%B5es_de_estilo
E por questões de privacidade, não conseguiremos obter esse status para fazer alterações em outros elementos, então temos que mudar especificamente o elemento a.
Fonte: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
@aprendendofelipe ótimos pontos!
Gostaria de acrescentar algumas observações:
É verdade @rodrigoKulb, mudar só o negrito, seja no título, nos comentários ou no tempo, parece a melhor opção.
Não acha legal deixar o ícone destacado também quando existir novo comentário? Nesse caso o título continuaria sem negrito se for um conteúdo já lido, mas o número de comentários ficaria em negrito para indicar o motivo do ícone estar destacado.
Sobre quais ícones utilizar, o que acham de algo na linha desses do GitHub?
Não precisa ser exatamente esses, mas um ícone que remeta a um checkbox. Isso permitiria adicionar uma funcionalidade legal como permitir ao usuário clicar no ícone para mudar o status, ou seja, marcar como lido sem precisar abrir o conteúdo ou marcar como não lido mesmo já tendo acessado.
O :visited
não permite alterar o peso da fonte e também não daria para mudar o ícone, então isso já nos leva direto para o uso de algum armazenamento local.
Não acha legal deixar o ícone destacado também quando existir novo comentário? Nesse caso o título continuaria sem negrito se for um conteúdo já lido, mas o número de comentários ficaria em negrito para indicar o motivo do ícone estar destacado.
Acho que podemos estudar algo também, tenho medo de parecer algum bug se não ficar claro que é referente ao comentário novo.
Sobre quais ícones utilizar, o que acham de algo na linha desses do GitHub?
Acho super válido estudar as possibilidades! ✉️
O :visited não permite alterar o peso da fonte e também não daria para mudar o ícone, então isso já nos leva direto para o uso de algum armazenamento local.
Acredito que a melhor opção seria guardar em banco de dados postagem vs usuário, e podemos aguardar um minimo de 10 segundos para realmente contabilizar a leitura. Desta forma independente do dispositivo a leitura sempre vai estar atualizada. E deixar a opção de guardar no localStorage se o usuário não estiver logado.
Gosto do obvio, talvez utilizar 2 elementos no ícone, exemplo abaixo carta aberta e fechada e notificações.
Isso @rodrigoKulb, não tem como fugir de salvar no banco. A ideia é salvar local durante a PoC e depois de implementar no backend usar o local como cache.
E sobre o ícone aberto/fechado, é bem por aí que acredito também 👍
Se alguém fizer algo no estilo da logo do TabNews também ficará show
O conteúdo novo é a logo normal e o aberto pode ser algo assim
Testei o
:visited
para uma primeira versão, porem não obtive êxito, parece não funcionar com o PrimerO que você tentou alterar no estilo? Não dá pra alterar nada além de algumas cores usando o
:visited
.Fonte: https://developer.mozilla.org/pt-BR/docs/Web/CSS/:visited#restri%C3%A7%C3%B5es_de_estilo
E por questões de privacidade, não conseguiremos obter esse status para fazer alterações em outros elementos, então temos que mudar especificamente o elemento a.
Fonte: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
Teste exatamente a cor e o background no elemento a, porem não rolou com o primer.
A ideia do ícone
é boa, porem precisa ver se também não ira causar uma poluição visual com muitos ícones, precisaria que ficasse bem homogêneo, por isso citei as tags
que é algo que estamos acostumados a ver bastante, inclusive aqui no GitHub, já que o layout do site segue um pouco esse estilo ou algo mais discreto que nem a ideia do @rodrigoKulb e @filipedeschamps, inicialmente de que colocar só uma bolinha.
Teste exatamente a cor e o background no elemento a, porem não rolou com o primer.
Pelo jeito não implementaram mesmo isso no Primer, então teria que partir para alguma forma de sobrescrever o css do componente Link, por exemplo com style jsx
.
Mas não vai dar pra trocar ícones com isso, então não acho mais que compense usar o :visited
nem na primeira versão.
O que acham de algo assim?
Esse primeiro muda só o negrito:
Esse também muda a cor da fonte:
E o tamanho do ícone? Talvez um pouco menor? Para terem noção, esses vídeos são recortes da parte superior da tela do meu celular
Turma, vocês são sensacionais!!!! Olha a quantidade de experimentos condensados nessa thread 😍
E nessas horas de experimentação, uma idéia irá conflitar com o outra e isso pode gerar um pouco de ansiedade em algumas pessoas, porque eventualmente o que passa na cabeça é "como fazer então para encaixar todas as idéias ao mesmo tempo?" E a resposta rápida é: não se preocupe, porque não dá! A fase da experimentação precisa ser livre, precisa conflitar mesmo, é o melhor jeito de uma idéia lapidar a outra 🤝
Mas então, qual a saída? A saída é ser simples e dar o menor passo possível, avaliar o que aconteceu, e depois dar o passo seguinte com um pouco mais de sofisticação, se necessário. E eu ser o "chatão da simplicidade" é algo que foi antecipado no diário de desenvolvimento na parte Gostaria de ser o Guia, e não o Mentor, mais para o final daquele parágrafo. Vale a pena a leitura.
E dado a tudo que discutimos, o passo que sugiro dar é apenas marcar com uma cor mais clara um link que já foi visitado... mais nada nesse momento. Só que pelo jeito o Primer não vai nos ajudar nem nisso, então teremos que compensar no lado técnico.... mas de qualquer forma, um link mais claro é a dica visual mais padrão do mundo de que algo já foi clicado (na verdade, não necessariamente a cor "mais clara", mas basta seguirmos o princípio de trocar a cor como o link azul padrão para não lido e roxo para lido).
E com o resultado disso, continuamos a pensar em como encaixar os outros recursos de links novos, comentários novos, etc. O que acham desse primeiro passo ser super simples? 🤝
O mais simples, se for só mudar a cor, é o :visited
mesmo... #609
Item da Millestone 5:
Se for para ter somente duas visualizações diferentes, uma solução simples, que pode ser a primeira versão, pode ser usar o
:visited
para diferenciar as publicações já visitadas das não visitadas. Qualquer nova publicação ficará com a mesma formatação das publicações antigas não visitadas.Se for para diferenciar os 3 casos, também é simples, pois é só salvar no
localStorage
qual foi a hora do último acesso e destacar os conteúdos criados após esse horário. Só me preocupa um pouco a poluição visual com 3 formatações diferentes noContentList
.Em seguida pode ser feito algo mais complexo, envolvendo também destacar conteúdos com novas respostas (talvez de início destacando se a quantidade de respostas mudar, o que não é o ideal, mas quebra um galho inicialmente).
Acho que podemos fazer isso usando o localStorage (ou IndexedDb se precisar de algo melhor). Gostei que o @filipedeschamps falou algo nessa linha em uma das lives.
Mas isso é realmente mais complexo e precisamos pensar na melhor estratégia. Sem pensar muito, me parece que teríamos que salvar no mínimo o id, o horário da visita e a quantidade de respostas de todas as publicações já visitadas pelo usuário.
Ter que salvar o histórico de todos os conteúdos é que é o problema, e por isso talvez seja melhor usar o IndexedDb para poder apagar facilmente o histórico mais antigo.
Uma vantagem da abordagem acima é não precisar de 3 diferentes visualizações, podendo dar ao usuário a escolha do que é novidade para ele, além das publicações após a última visita, pode-se acrescentar: • novas respostas; • conteúdos editados após a última visita; • conteúdos anteriores a última visita, mas que não foram abertos (antigos e não visitados).
Sobre os conteúdos antigos e não visitados, também podemos dar a opção de marcar a publicação como "não destacar" para algo que o usuário não queira acompanhar.
Daí quando ficar rodando legal de acordo com o feedback dos usuários, partimos para uma forma de salvar no banco de dados para que o usuário tenha essas informações sincronizadas entre diferentes dispositivos.