Atualmente, na lista de tópicos, mostramos apenas categorias de nível superior no menu suspenso de categorias:
Em algumas condições, um campo de pesquisa aparece, onde você pode acessar diretamente as subcategorias:
Mas isso não aparece incondicionalmente (acho que depende de quantas categorias se pode ver, talvez?)
No composer e em outras áreas do aplicativo, por outro lado, as pessoas sempre podem navegar diretamente para uma subcategoria.
Alguns pensamentos:
(a) Devemos atualizar a lógica que determina quando o campo de pesquisa aparece?
Em particular, seria útil que ele aparecesse para todos no meta agora enquanto estamos experimentando uma estrutura de categorias mais aninhada
(b) Devemos considerar torná-lo mais parecido com o restante dos menus suspensos de categoria, como o do composer?
Esta seria uma mudança maior do que (a), mas talvez valha a pena considerar torná-lo mais consistente com outros seletores de categoria?
“ocultar a entrada de pesquisa no menu suspenso de filtros se a lista tiver menos de 10 opções”
Para mim, parece que, embora não sejam mostradas por padrão, as subcategorias que a pesquisa retornaria devem ser contadas para determinar se há mais de 9 opções.
Pode valer a pena pensar se devemos mesclar também os menus suspensos de categoria + subcategoria — temos um único menu suspenso no compositor, então mostrar subcategorias lá é necessário.
Na navegação, os menus suspensos são meio que também “trilhas de navegação” (breadcrumbs), então desconstruímos e temos menus separados de categoria + subcategoria + tags.
Como você quer suportar a opção “sem subcategorias” em um único menu suspenso?
O conceito de selecionar se você quer ver
publicações da categoria principal e de todas as subcategorias
apenas publicações da categoria principal
publicações de uma das subcategorias
faz sentido para mim. Você precisa da opção “sem subcategorias” para obter o que costumava ser Support, agora que tem muitas subcategorias. Então, não tenho certeza de como isso funcionaria dentro de um único menu.
