Qual è la visione per il sistema di design Discourse?

[manuel (Manuel Kostka)]

Mi piacerebbe creare temi e componenti personalizzati che siano allineati al sistema di progettazione di Discourse e che si integrino nell’app in modo coerente e armonioso.

Solo guardando il codice e come gli stili sono definiti e applicati nel core, trovo difficile dare un senso e cogliere l’idea del quadro generale e della direzione prevista del sistema di progettazione.

Proverò a suddividere questo in tre argomenti principali: colore, tipografia e spaziatura.

Colore

C’è stata un’introduzione di una scala numerica per alcuni valori due anni fa. Penso sia stato menzionato che è solo intesa a integrare le trasformazioni dei colori nominati. Per il valore del colore terziario, ora appare così:

Vedo entrambi i modelli applicati nel nuovo codice nel core. L’idea a lungo termine è di continuare a usarli fianco a fianco o c’è una visione diversa?

In ogni caso, non dovrebbe esserci una scala numerica per tutti e quattro i valori di colore principali? Al momento è presente solo per primario e terziario, ma non per secondario e quaternario.

Tipografia

Attualmente sono definite tre diverse tipologie di progressione della dimensione del carattere:

Inoltre, non ci sono stati aggiornamenti a questo da più di due anni. Dovrebbero essere utilizzati affatto nel nuovo codice? Ad essere sincero, non ho mai toccato le definizioni dei moltiplicatori poiché è difficile definire la dimensione effettiva del carattere finale. Ma non capisco nemmeno le definizioni dei caratteri di base. La scala definita sarebbe:

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

Ma quando guardo le dimensioni effettive dei caratteri, la scala predefinita in uso è più o meno:

• 13px - 15px - 17.25px - 22px - 26px

Spaziatura

Vedo che nuovi elementi come la barra laterale introducono variabili root per la spaziatura. Ad esempio:

Ciò rende sicuramente più facile regolare il layout della barra laterale. Ma non si traduce in altri elementi di layout. D’altra parte, non vedo variabili di spaziatura fondamentali introdotte che consentirebbero aggiustamenti di layout più coerenti in tutta l’app. È in qualche modo nella roadmap?

Generale

Sarebbe fantastico sapere se ci sono piani per muoversi verso un sistema di progettazione più coerente e semplice?

Sembrano esserci troppe definizioni non correlate e autonome in questo momento, e rendono piuttosto difficile costruire un layout coerente e ritmico con un senso di facilità (e gioia ).

Capisco che sia un’app grande con una tonnellata di elementi diversi. Tuttavia, ho appena fatto un piccolo test sulla vista elenco predefinita più recente:

Questa è una ricostruzione con ogni valore di spaziatura scelto da una progressione geometrica molto semplice (2px/4px/8px/16px/32px/64px). E dimensioni dei caratteri da soli 4 valori:

Sembra solo che dal punto di vista del design non ci sia bisogno del numero di definizioni uniche che sono presenti ora in tutta l’app?

[awesomerobot (Kris)]

Questo è qualcosa che volevamo fare e verso cui abbiamo lavorato gradualmente a piccoli passi, ma non è qualcosa che può accadere tutto in una volta. Ogni modifica che apportiamo causa potenziali regressioni del tema su migliaia di siti (e dobbiamo risolverne molte per i nostri clienti), quindi ci vuole molto tempo per apportare piccole modifiche.

Abbiamo anche intrapreso un lavoro di modernizzazione di Ember per un po’ di tempo, che richiede anche la correzione di regressioni e il refactoring dei temi esistenti. Questo è ancora in corso e richiederà anche tempo per aggiornare tutto (sostituire il nostro sistema di widget, ad esempio, potrebbe facilmente richiedere altri 6 mesi). Ci sono molte priorità da bilanciare.

@manuel

la direzione prevista del sistema di design

Non c’è una direzione prevista al di là di una maggiore coerenza. Abbiamo considerato di disaccoppiare i nostri stili di base in modo che il Discourse “senza tema” predefinito abbia molto meno CSS (il che potrebbe rendere più facile la manutenzione dei temi)… ma al momento è solo un’idea.

@manuel

In ogni caso, non dovrebbe esserci una scala numerica per tutti e quattro i valori di colore principali? Al momento c’è solo per il primario e il terziario, ma non per il secondario e il quaternario.

Penso che questi siano stati aggiunti “al bisogno”, quindi non abbiamo avuto bisogno di scale secondarie/quaternarie aggiuntive. Non abbiamo intenzione di rimuovere le versioni nominate, quindi entrambe possono essere utilizzate per il prossimo futuro.

@manuel

Attualmente sono definite tre diversi tipi di progressione della dimensione del carattere:

Le dimensioni più piccole/piccole/più grandi/più grandi sono per l’impostazione della dimensione del testo dell’utente. La maggior parte delle volte queste non dovranno essere modificate.

La scala em si basa approssimativamente su una scala tipografica classica (The typographic scale, ad esempio). Una scala più uniformemente distanziata come 13-15-17-19 non crea molto contrasto e tutto rimane piuttosto piccolo a meno che non ci siano molti passaggi. Su una scala classica, gli intervalli tra la scala aumentano insieme alla dimensione per creare più contrasto.

L’idea alla base della scala basata su em è che tutto nell’app possa scalare proporzionalmente e le singole sezioni dell’app possano essere scalate proporzionalmente. Quindi potrei fare qualcosa come

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

e tutto ciò che è all’interno scalerebbe proporzionalmente senza dover modificare ogni singola dimensione del carattere e tutti gli spazi correlati.

Internamente il feedback è simile al tuo, nel senso che gli sviluppatori vogliono sapere esattamente quale dimensione del carattere ottengono indipendentemente dal contesto, il che è uno svantaggio del sistema. Idealmente non ci preoccuperemmo delle dimensioni esatte e potremmo semplicemente dire “questo dovrebbe aumentare di un livello perché voglio che sia più grande”, ma quel modello mentale non sembra venire naturalmente.

C’è un certo desiderio di passare a un sistema basato su rem, ma come menzionato in precedenza… questo richiederebbe probabilmente molto tempo per cambiare perché influenzerebbe così tanti siti esistenti. Preferirei anche la base predefinita del browser di 16px anziché i nostri 15px, ma storia simile (una volta erano 14px! quindi abbiamo fatto almeno un passo).

La scala rem viene utilizzata per le intestazioni nel contenuto dei post pubblicati, perché annidare i tag di intestazione utilizzando em significava che gli individui potevano aumentare infinitamente il testo e causare problemi di layout.

@manuel

D’altra parte, non vedo l’introduzione di variabili di spaziatura fondamentali che consentirebbero aggiustamenti di layout più coerenti in tutta l’app. È sulla roadmap in qualche modo?

Sì, è venuto fuori un paio di volte… (suono come un disco rotto ma…) dovrebbe essere un cambiamento molto graduale per evitare regressioni nei siti esistenti. Al momento stiamo aggiungendo variabili condivise all’interno di aree specifiche man mano che le aggiorniamo, il che è un passo nella giusta direzione.

La velocità con cui queste cose accadono è comprensibilmente un po’ frustrante, ma per la maggior parte della storia di Discourse non c’è mai stato un designer a tempo pieno nello staff. Il team di design è cresciuto fino a 7 negli ultimi due anni (inclusi designer dedicati a lavorare su progetti per i clienti, che avvengono per lo più fuori dalla vista del pubblico), quindi speriamo che ora ci muoveremo più velocemente verso una maggiore coerenza.

[manuel (Manuel Kostka)]

Grazie per le spiegazioni Kris! È molto utile.

@awesomerobot

Ogni modifica che apportiamo causa potenziali regressioni del tema su migliaia di siti

Quindi io affronto questo problema solo su una scala molto piccola. Penso a volte, però, che potrebbe essere utile cambiare l’aspettativa generale riguardo al Prodotto. Stabilire che Discourse si muove velocemente.

@awesomerobot

Abbiamo considerato di disaccoppiare i nostri stili di base in modo che il Discourse predefinito “non a tema” abbia molta meno CSS

Potrebbe essere bello, ma credo che richiederebbe comunque handle più facili. Ci sono così tanti template. Anche se ognuno di essi avesse un CSS più semplice, se non posso modificarli in modo orchestrato, è comunque un sacco di lavoro.

@awesomerobot

ma quel modello mentale non sembra venire naturale.

È un bellissimo modello mentale. Potrei preferire avere dimensioni esatte perché sono molto più facili da applicare. Ad esempio, qualcuno ha un sistema di design, io applico solo i numeri e guardo il risultato. Mentre altrimenti sento che dovrei allineare due sistemi. Come se dovessi capire il carattere di entrambi e trovare la loro sintonia comune.

[manuel (Manuel Kostka)]

Pensando mais sobre isso… Eu poderia ter várias visões para um sistema de design 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 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.