Qual é a visão para o sistema de design do Discourse?

[manuel (Manuel Kostka)]

Gostaria de criar temas e componentes personalizados que estejam alinhados com o sistema de design do Discourse e que se integrem ao aplicativo de forma consistente e harmoniosa.

Apenas olhando o código e como os estilos são definidos e aplicados no core, acho difícil entender e ter uma ideia do quadro geral e da direção vislumbrada do sistema de design.

Tentarei dividir isso em três tópicos principais: cor, tipografia e espaçamento.

Cor

Houve uma introdução de uma escala numérica para alguns valores há dois anos. Acho que foi mencionado que isso serve apenas para complementar as transformações de cores nomeadas. Para o valor de cor terciária, agora parece assim:

Vejo ambos os modelos aplicados em código novo no core. A ideia a longo prazo é continuar usando-os lado a lado ou há uma visão diferente?

Em qualquer caso, não deveria haver uma escala numérica para todos os quatro valores de cor principais? No momento, existe apenas para primária e terciária, mas não para secundária e quaternária.

Tipografia

Atualmente, existem três tipos diferentes de progressão de tamanho de fonte definidos:

Também não houve atualizações nisso em mais de dois anos. Eles devem ser usados em código novo? Honestamente, nunca mexi nas definições de multiplicador, pois é difícil definir o tamanho da fonte final real. Mas também não entendo as definições de fonte base. A escala definida seria:

• 13px - 14px - 15px - 17px - 19px

Mas quando olho para os tamanhos de fonte reais, a escala padrão em uso é mais ou menos:

• 13px - 15px - 17,25px - 22px - 26px

Espaçamento

Vejo que novos elementos como a barra lateral introduzem variáveis raiz para espaçamento. Por exemplo:

Isso definitivamente facilita o ajuste do layout da barra lateral. Mas não se traduz em nenhum outro elemento de layout. Por outro lado, não vejo variáveis de espaçamento fundamentais sendo introduzidas que permitiriam ajustes de layout mais consistentes em todo o aplicativo. Isso está no roteiro de alguma forma?

Geral

Seria ótimo saber se há planos para avançar em direção a um sistema de design mais consistente e simples?

Parece haver muitas definições não relacionadas e independentes no momento, e elas tornam bastante difícil construir um layout consistente e rítmico com uma noção de facilidade (e alegria ).

Entendo que é um aplicativo grande com uma tonelada de elementos diferentes. No entanto, fiz apenas um pequeno teste na visualização de lista padrão mais recente:

Esta é uma reconstrução com todos os valores de espaçamento escolhidos de uma progressão geométrica muito simples (2px/4px/8px/16px/32px/64px). E tamanhos de fonte de apenas 4 valores:

Parece que, em termos de design, não há necessidade do número de definições exclusivas que existem atualmente em todo o aplicativo?

[awesomerobot (Kris)]

Este é algo que queríamos fazer e para o qual temos trabalhado gradualmente em pequenas partes, mas não é algo que possa acontecer de uma só vez. Cada alteração que fazemos causa potenciais regressões de temas em milhares de sites (e temos de corrigir muitas destas para os nossos clientes), pelo que leva muito tempo a fazer pequenas alterações.

Também temos vindo a realizar trabalhos de modernização do Ember há algum tempo, o que também exige a correção de regressões e a refatoração de temas existentes. Isto ainda está em andamento e também levará tempo para atualizar tudo (substituir o nosso sistema de widgets, por exemplo, pode facilmente levar mais 6 meses). Há muitas prioridades a equilibrar.

@manuel

a direção prevista do sistema de design

Não há uma direção prevista para além de mais consistência. Considerámos desacoplar os nossos estilos base para que o Discourse “sem tema” padrão tenha muito menos CSS (o que pode tornar mais fácil a manutenção de temas)… mas isso é apenas uma ideia no momento.

@manuel

Em qualquer caso, não deveria haver uma escala numérica para todos os quatro valores de cor principais? Atualmente, só existe para primária e terciária, mas não para secundária e quaternária.

Penso que estes foram adicionados “conforme necessário”, pelo que não tivemos necessidade de escalas secundárias/quaternárias adicionais. Não temos planos de remover as versões nomeadas, pelo que qualquer uma delas pode ser utilizada num futuro previsível.

@manuel

Atualmente existem três tipos diferentes de progressão de tamanho de fonte definidos:

Os tamanhos menor/pequeno/maior/maior são para a configuração de tamanho de texto do utilizador. Na maioria das vezes, estes não precisarão de ser alterados.

A escala em em baseia-se aproximadamente numa escala tipográfica clássica (The typographic scale, por exemplo). Uma escala mais uniformemente espaçada como 13-15-17-19 não cria muito contraste e tudo permanece um pouco pequeno, a menos que tenha muitos passos. Numa escala clássica, as lacunas entre a escala aumentam juntamente com o tamanho para criar mais contraste.

A ideia por detrás da escala baseada em em é que tudo na aplicação pode escalar proporcionalmente, e secções individuais da aplicação podem ser escaladas proporcionalmente. Assim, eu poderia fazer algo como

.sidebar-wrapper {
  font-size: 20px;
}

e tudo dentro escalaria proporcionalmente sem ter de alterar cada font-size individual e todo o espaçamento relacionado.

Internamente, o feedback é semelhante ao seu, no sentido de que os programadores querem saber exatamente qual o tamanho da fonte que estão a obter, independentemente do contexto, o que é uma desvantagem do sistema. Idealmente, não nos preocuparíamos com tamanhos exatos e poderíamos apenas dizer “isto deve subir um degrau porque quero que seja maior”, mas esse modelo mental não parece vir naturalmente.

Há algum desejo de migrar para um sistema baseado em rem, mas como mencionado anteriormente… isto provavelmente levaria muito tempo a mudar porque afetaria muitos sites existentes. Eu também preferiria a base padrão do navegador de 16px em vez dos nossos 15px, mas a história é semelhante (costumava ser 14px! por isso, fizemos pelo menos um passo).

A escala rem é utilizada para cabeçalhos em conteúdo de posts cozinhados, porque aninhar tags de cabeçalho usando ems significava que os indivíduos podiam aumentar infinitamente o texto e causar problemas de layout.

@manuel

Por outro lado, não vejo a introdução de variáveis de espaçamento fundamentais que permitiriam ajustes de layout mais consistentes em toda a aplicação. Isto está no roteiro de alguma forma?

Sim, já surgiu algumas vezes… (estou a parecer um disco riscado, mas…) teria de ser uma mudança muito gradual para evitar regressões em sites existentes. No momento, temos vindo a adicionar variáveis partilhadas em áreas específicas à medida que as atualizamos, o que é um passo na direção certa.

A velocidade com que estas coisas acontecem é compreensivelmente um pouco frustrante, mas durante a maior parte da história do Discourse não houve um designer a tempo inteiro na equipa. A equipa de design cresceu para 7 nos últimos dois anos (incluindo designers dedicados a trabalhar em projetos de clientes, que acontecem maioritariamente fora da vista pública), pelo que esperamos que agora estejamos a avançar para uma maior consistência mais rapidamente.

[manuel (Manuel Kostka)]

Obrigado pelas explicações, Kris! Isso é muito útil.

@awesomerobot

Cada mudança que fazemos causa potenciais regressões de tema em milhares de sites

Então, eu só enfrento isso em uma escala muito pequena. Às vezes, penso que poderia ser útil mudar a expectativa geral em relação ao Produto. Para estabelecer que o Discourse está avançando rapidamente.

@awesomerobot

Consideramos desacoplar nossos estilos base para que o Discourse padrão “sem tema” tenha muito menos CSS

Isso poderia ser bom, mas acredito que ainda exigiria identificadores mais fáceis. Existem tantos templates. Mesmo que cada um deles tenha um CSS mais simples, se eu não puder modificá-los de forma orquestrada, ainda será muito trabalho.

@awesomerobot

mas esse modelo mental não parece vir naturalmente.

É um belo modelo mental. Eu poderia preferir ter tamanhos exatos porque eles são muito mais fáceis de aplicar. Por exemplo, alguém tem um sistema de design, eu apenas aplico os números e vejo o resultado. Enquanto, de outra forma, sinto que precisaria alinhar dois sistemas. Como se eu precisasse entender o caráter de ambos e encontrar sua sintonia comum.

[manuel (Manuel Kostka)]

Pensando mais sobre isso… Eu poderia ter várias visões para um sistema de design do Discourse.

Um sistema de design prático com blocos de construção atômicos padronizados. Esse seria sempre um primeiro passo necessário, eu acho.

Um sistema que abstrai alguns componentes de alto nível. Para o Discourse, estes poderiam ser sobre moderação, reconhecimento, informação,…

Um sistema comum de padrões para conversação online. Semelhante ao escopo fundamental de um sistema como o Material Design.