[ Sugestão ] Avisar que o user já marcou a publicação como "Achei relevante"

[AlisonSarto]

Descrição do Problema:

Atualmente, ao usar o recurso "Achei relevante" em um post, não há indicação de que o usuário já marcou aquele post como "Relevante" antes. Isso pode levar a situações em que os usuários não têm certeza se já marcaram um post como relevante ou não.

Sugestão de Solução:

Minha sugestão é adicionar uma indicação visual para informar aos usuários que eles já marcaram um post como "gostei". Isso não impediria o usuário de marcar o post novamente, mas serviria como um lembrete visual.

Detalhes da Implementação:

A implementação dessa sugestão pode ser feita de várias maneiras. Uma abordagem possível é deixar a seta azul, ou um modal de aviso.

Benefícios:

Melhor experiência do usuário, pois eles podem ver imediatamente se já marcaram um post como relevante.
Redução de confusões e cliques acidentais.

Outras Observações:

Ficarei feliz em discutir mais detalhes ou esclarecer qualquer dúvida sobre esta sugestão. Obrigado pela consideração!

[Rafatcb]

Eu acho isso útil mas, a princípio, não imagino como poderia ser indicado. Se alguém ter uma sugestão, seria legal colocar aqui (pode até ser feita no Paint mesmo). É preciso levar em consideração que atualmente o usuário pode dar mais de um voto, e pode tanto dar votos positivos quanto negativos na mesma publicação.

Enquanto escrevia, passou uma ideia na minha cabeça que, apesar de não ser uma boa solução final, pode ajudar na discussão:

[Poveii]

Tive uma ideia. Que tal adicionarmos badges de achei relevante e não achei relevante em cima do título do post?

Isso seria controlado por uma conta simples entre os votos positivos e negativos do usuário no post em específico. O que acham?

Isso até me lembra que temos uma issue aqui que pode ajudar, quem sabe um histórico de votos seja necessário? (#1341)
E sim para ver a ideia aplicada ao outro tema, é só trocar o tema do github ou do seu sistema. Valeuuuu!!

[faelpinho]

Gostei da sugestão do @Rafatcb. Outra coisa que podia ser feita é mostrar uma borda em torno do botão clicado e alterar a mensagem no Tooltip se já teve um voto. A contagem poderia ficar no Tooltop também ("Você votou 2 vezes: Achei interessante"). Segue exemplo abaixo:

[Rafatcb]

O problema de deixar essa informação apenas na tooltip é que ela esconde a informação, e num dispositivo touch seria uma experiência ainda pior do que usando mouse.

Referência: https://primer.style/components/tooltip

Tooltips as a UI pattern should be the last resort for conveying information as they are hidden by default and often with zero or little visual indicator of its existence. See tooltip alternatives before using this component.

[aprendendofelipe]

Acho que é uma funcionalidade muito útil, mas é importante pesar o custo/benefício de como mostrar essa informação.

É bastante viável se for algo que o usuário possa consultar sempre que tiver dúvida se já votou em um conteúdo específico (deliberadamente executar alguma ação para disparar a consulta), mas poderá ser uma revolução no sistema do TabNews se for uma informação que já deverá estar presente em cada página de conteúdo visitada, já que isso exige passarmos de um sistema baseado principalmente em páginas estáticas (onde poucas ações dos usuários necessitam da API) para uma nova forma onde, para cada página de conteúdo que o usuário visitar, será preciso buscar dados exclusivos desse usuário (as qualificações dele para os conteúdos e comentários visitados). Só isso já vai aumentar consideravelmente o uso das lambdas e do banco de dados do TabNews.

E essa se tornaria a consulta mais frequente do sistema, então será preciso rever a modelagem dos dados de qualificações. Talvez criar uma tabela que armazene no mínimo user_id, content_id e amount para cada qualificação, pois hoje a consulta precisa usar a tabela de eventos, o que até pode ser otimizada com um índice específico, mas acredito que seria muito mais eficiente se criarmos uma tabela exclusiva das qualificações.

[AlisonSarto]

Pensando melhor, acho que podemos pensar melhor nessa funcionalidade após o histórico de TabCoins discutido no issue #1341. Dependendo de como for feito esse sistema de histórico, podemos usar os dados do histórico para indicar se a publicação já foi marcada pelo user ou não, não sei se essa seria a melhor lógica, mas pode ser uma possibilidade

[iget-master]

Boa tarde! O que precisa para esse issue ir pra frente? gosto da forma que o @faelpinho sugeriu. Eu posso tentar trabalhar nessa issue

[Rafatcb]

@iget-master da parte do frontend, falta uma boa solução. Sobre a sugestão do @faelpinho, mostrar o quadrado verde em volta (e talvez um vermelho no botão negativo) são indicadores interessantes, mas acho que poderíamos fazer uma imagem para ver como ficaria com o número. E também precisaria verificar como seria o comportamento dessa estilização com o botão focado.

Podemos ir experimentando soluções como fizemos até agora, colocando imagens aqui e juntando opiniões de pessoas com diferentes bagagens/experiência.

Da parte do backend, parece que será mais complicado. Precisará resolver os problemas indicados no comentário #1510 (comment).

[hiroshimorowaka]

Boa tarde! Eu gostaria de dar uma ideia pra essa Issue, já que sinto muita falta de saber se já qualifiquei um conteúdo, seja como relevante ou não.

A minha ideia é a seguinte:

Adicionar no endpoint /api/v1/contents/{username}/{slug}/tabcoins

Uma opção de GET que retorna quantos votos você deu em cada opção.

Armazenamento no banco de dados.

Eu não fui muito a fundo verificar, mas pelo que eu entendi que o @aprendendofelipe falou foi que vocês não tem uma tabela separada pra contagem de "likes" e "dislikes", certo?

Então como ele mesmo disse, teria que criar uma tabela pra contabilizar isso, porque utilizar a mesma tabela de eventos fica meio estranho, eu acho.

Nova tabela
Se fosse criar uma nova tabela, acho que seria praticamente como o aprendendofilipe falou

• user_id
• content_id
• relevent - Int
• irrelevant - Int

Ou talvez algo melhor, eu não sou muito experiente então esse foi o melhor jeito que eu pensei.

Custo disso

O custo realmente vai ser mais alto, porque as páginas (pelo que eu entendi) são geradas de forma estáticas e somente são revalidadas de tempos em tempos, se precisar gerar uma página pra cada usuário seria complicado.

Acho que talvez gerar a página inteira no back-end, entregar de forma estática, e gerar os votos no Client-Side com requisições pra API, mas não sei se isso resolveria o problema, porque vai criar uma rota que é muito acessada, já que precisa ser acessada em toda publicação visitada.

Alguém mais experiente no projeto poderia informar melhor sobre o quanto isso custaria pra infra.
Como usuário e na questão de experiência do usuário, eu creio que seja algo importante.

Desculpe se falei algo de errado, eu não tenho tanto conhecimento assim sobre o projeto mas gostaria de tentar ajudar de alguma forma.