Font monospace nell'editor solo Markdown

Non sono ancora deciso se trovo il monospace necessario o meno, ma il font aggiornato è un netto miglioramento rispetto a quello precedente (in contrasto con la situazione precedente, direi, ora potrebbe essere di nuovo leggermente più grande).\n\nMa in ogni caso, è bello che il buon vecchio ASCII art possa ora fare il suo ritorno :slightly_smiling_face:\n\n\n\n|-----------|\n| LONG LIVE |\n| THE BUNNY |\n|-----------|\n(\\__/) ||\n(•ㅅ•) ||\n/ づ\n

4 Mi Piace

L’ho menzionato in precedenza nell’argomento, abbiamo bisogno che il cambiamento respiri un po’ più a lungo, diamogli almeno un’altra settimana.

La risposta qui è assolutamente forse. Continuate a inviare feedback, buoni o cattivi, li stiamo leggendo tutti.

Un problema con cui sto combattendo internamente è il targeting di diverse “persone”/“pubblici”

  1. Pubblico generale → usa semplicemente il “rich composer” il 99% delle volte, nessuno di questi è un problema
  2. Utenti altamente tecnici → usa semplicemente il “raw markdown” - generalmente abituati a questo tipo di visualizzazione e molti soddisfatti del cambiamento
  3. Non tecnici MA non vogliono usare l’editor rich → il monospace li infastidisce - ad esempio: @Jagster - preferiscono un font diverso

È un problema complicato, siamo sempre restii ad aggiungere altre impostazioni utente, ma riconosco che c’è qualcosa qui, voglio solo vedere come ci sentiamo tra una settimana.

5 Mi Piace

Stavo cercando di capire diversi segnali visivi non intrusivi, ma è difficile. :sweat_smile:

L’unico che sembra accettabile è un’etichetta da qualche parte, come:

Un'interfaccia di Slack mostra una finestra di creazione di un nuovo post all'interno del canale "Annunci", suggerendo che l'utente può digitare un titolo o incollare un link. (Didascalia dell'IA)

E magari con un cambio di colore per migliorare la memoria visiva:

L'immagine mostra una finestra modale di nuovo argomento all'interno di un'interfaccia di forum, dove un utente può creare un argomento con un titolo e tag opzionali. (Didascalia dell'IA)

È abbastanza visibile senza essere intrusivo. Ha i suoi svantaggi, di sicuro. Occupa un po’ di spazio, ma va bene nel contesto di una transizione temporanea. Non sono convinto al 100%, ma sembra un’alternativa interessante. Volevo solo condividere l’idea. (sentiti libero di aprire le gif in una nuova scheda per vederle a grandezza naturale; manca un pulsante a schermo intero)

4 Mi Piace

questo per qualche motivo è uno dei migliori argomenti contrari che abbia sentito finora. Ho appena dovuto controllare il font nel mio editor VS code, quindi vedete, sono un programmatore. Avevo un editor di codice aperto sul mio desktop e, indovinate un po’, è un font monospace. Non l’avevo mai notato. Ma per qualche motivo, qui e nella mia istanza personale mi sembra strano. Darò una settimana, come chiede Sam, il cambiamento è stridente, forse tra una settimana non lo noterò nemmeno.

3 Mi Piace

Sono d’accordo. Ho appena scritto un post molto lungo e, onestamente, il font monospace mi sta dando mal di testa. Rileggo attentamente i miei post e tendo a passare avanti e indietro tra la lettura del markdown grezzo e la lettura del post formattato mentre lo faccio. Ora è molto difficile farlo nella sezione dell’editor.

In generale, non mi piace nemmeno il WYSIWYG. Nella mia esperienza sono molto scattosi e non ho intenzione di usarlo. Quindi, per me, l’editor markdown che esiste da sempre deve continuare ad essere un’esperienza utente fluida.

Sono d’accordo con @schneeland. Sono un ingegnere del software e uso regolarmente IDE che ovviamente usano font monospace, ma questo è semplicemente un contesto diverso. Sarebbe davvero stridente se Jira iniziasse a usare un font monospace.

Non sono sicuro di aver mai avuto problemi a lavorare con le tabelle in markdown. E inoltre, anche in monospace, le barre verticali tra ogni colonna non si allineeranno poiché è probabile che ogni cella abbia un numero diverso di caratteri al suo interno.


In ogni caso, so che vuoi dare un po’ di respiro al cambiamento, ma spero che questo feedback sia utile. Nota che i miei commenti si basano sul font monospace più recente e non ho visto la versione precedente. Quindi, sto confrontando la mia esperienza solo con quella che esiste da anni, non con il primo font monospace utilizzato un paio di giorni fa.

4 Mi Piace

Quante persone useranno effettivamente le tabelle in una risposta del forum che giustifichi questo? Inoltre, Obsidian usa markdown e usa tabelle con monospace all’interno, mentre il testo all’esterno è sans-serif:

Non capisco perché l’intero composer debba cambiare in monospace quando potrebbero coesistere?

Direi che il 99% di ciò che scriviamo è testo “normale”, non markdown.

La mia onesta opinione è che questa non sia una grande funzionalità da “forzare” sugli utenti, anche se la lasciamo respirare. Non è un cambiamento che gli utenti sono sollevati di avere, e questo è visibile nella maggior parte dei commenti. Dovrebbe essere una preferenza dell’utente.

Non vedo davvero alcun problema nel fatto che il composer abbia lo stesso carattere dell’anteprima. È abbastanza facile capire cosa sta succedendo. Lo è da molti anni, giusto? “Se non è rotto, non aggiustarlo”, dicono. E si applica qui, credo.

3 Mi Piace

Per le persone che hanno difficoltà con questa modifica, una raccomandazione che ho è:

Prova per qualche giorno con l’anteprima disabilitata

Una volta disabilitata l’anteprima, il cambio di font risulta significativamente più naturale.

  • Passare da Rich a Source code risulta molto più naturale
  • È estremamente chiaro in quale modalità ti trovi

Stiamo ancora raccogliendo feedback, nulla è scolpito nella pietra al 100%, potremmo aggiungere altri interruttori utente qui, non lo so.

5 Mi Piace

Questo font dovrebbe essere configurabile su https://\\u003csite\\u003e/admin/config/fonts, ma attualmente non lo è.

4 Mi Piace

Non mi piaceva il font monospaziato (è ottimo per la programmazione ma non per scrivere su un forum) quindi l’ho ripristinato aggiungendo questo CSS al mio tema (fatemi sapere se c’è un modo migliore per farlo!)

.d-editor-container--rich-editor-enabled .d-editor-textarea-wrapper textarea.d-editor-input {
    font-family: var(--font-family) !important;
    font-size: var(--base-font-size) !important;
    line-height: var(--line-height-large) !important;
}
4 Mi Piace

Penso davvero che questa dovrebbe essere un’impostazione utente. Non dovrei essere costretto a usare la visualizzazione wysiwyg per usare un font leggibile. I font monospace sono praticamente illeggibili per me per il testo normale (non codice). Questo è particolarmente evidente su mobile, dove non puoi vedere un’anteprima contemporaneamente affiancate, ma non è comunque ottimale nemmeno su desktop. Non credo che un’impostazione del sito o un override CSS siano sufficienti, poiché non tutti gli amministratori del sito risponderanno al feedback degli utenti per cose del genere.

7 Mi Piace

Assolutamente (e sono così fortemente d’accordo da aver creato un account allo scopo di pubblicare il mio accordo!)

Markdown va automaticamente a capo e ha altre proprietà che sfumano il confine tra “elaborazione testi” e “codice”. Su un forum di discussione, è certamente molto più un elaboratore testi… e sono stato piuttosto contento del comportamento storico. Ho apprezzato la possibilità di copiare e incollare liberamente senza ambiguità. Mi piace poter premere Invio e ottenere un’interruzione di riga, invece di qualche immaginazione WYSIWYG di ciò che potrei aver inteso.

La modifica Markdown non diventa più funzionale o piacevole utilizzando un font a larghezza fissa. Peggiora… e penserei che chiunque lo utilizzi sia d’accordo.

Quindi Markdown viene reso un cittadino di seconda classe, allo scopo di rafforzare l’indicazione visiva della modalità in cui ci si trova.

Chiederei ai designer UX tra voi se esiste un modo migliore per enfatizzare la modalità… che non vi chieda di fare il compromesso quasi mai buono di utilizzare un font a larghezza fissa per modificare ciò che è per lo più testo non di codice.

Se si trovasse una buona risposta a questo, non ci sarebbe bisogno di un’opzione per passare da larghezza fissa a non, perché sarebbe sempre un font proporzionale.

2 Mi Piace

2 punti validi!

1 Mi Piace

È passato molto tempo da quando ci è stato detto di “lasciarlo respirare”. Come possiamo vedere, questo cambiamento non è qualcosa per cui tutti abbiamo detto “cambiamento fantastico!”
Come ha detto qualcun altro, c’è stata una domanda enorme per questo? Non lo so… ne dubito, ma forse mi sbaglio.

Penso che considerare il markdown un linguaggio di “codifica” per giustificare il monospace, non abbia molto senso per me. Vedo il markdown come un modo per formattare il testo, non necessariamente un linguaggio di “codifica”. Non devo essere uno sviluppatore per usare il markdown, a differenza di usare ad esempio VS Code, Cursor, ecc., dove il monospace è appropriato.

Quando creiamo nuovi argomenti o risposte in un forum, non stiamo “codificando”, stiamo “scrivendo” e il testo dovrebbe essere leggibile. Il monospace, semplicemente, non è così leggibile. Posso scrivere un paragrafo di 150 parole in un editor markdown senza mai usare alcuna “sintassi” markdown (se così si chiama?). Quindi vedo il markdown come una cosa in più che possiamo usare per formattare il testo, non necessariamente un “formato” su cui tutto deve basarsi, se questo ha senso?

5 Mi Piace

Aggiungi questo nel tuo CSS @seanblue e @alltiagocom. Ripristinerà il composer al default del tuo sito.

/* Cambia il font nel composer da monospace al default sans-serif */
.d-editor-container .d-editor-textarea-wrapper textarea.d-editor-input {
    font-family: var(--font-family);
    font-size: 1rem; /* o usa 16px, o la tua dimensione di default specifica */
}
2 Mi Piace

Credo nel dare agli utenti una preferenza. Forse alcuni utenti vogliono il monospace. Non lo so. Ho visto alcuni temi folli di VS Code (sfondo verde con testo nero, o peggio), e non li userei mai, ma ognuno è diverso.

Sicuramente cambierò il mio in sans-serif, ma il mio punto qui è che potremmo offrire le opzioni ai nostri utenti. Tutto qui.

1 Mi Piace

Sono di parte in quanto dipendente di Discourse, ma preferisco molto di più il nuovo font monospace. Quindi è molto probabile che le persone che dicono “ah sì, bello” o anche “uhm, non ci ho fatto caso” non si facciano sentire.

Ci devono essere almeno dozzine di noi :smiley:

6 Mi Piace

Certo. Ci sono un sacco di programmatori e sviluppatori là fuori :joy:

(Ma tra la gente comune il monospace non è contato come un font leggibile. Per me e i miei utenti il trucco CSS ha fatto il suo lavoro, quindi per me come amministratore questa è più una domanda accademica. Ma smettiamola di dire che questo cambiamento è fatto per la maggioranza ed è ampiamente in uso, perché non è vero.)

1 Mi Piace

Penso che tu stia facendo supposizioni su di me che non sono vere :slight_smile:

3 Mi Piace

Sono d’accordo: il monospace è inaspettato e brutto. Inoltre, non necessario. C’è già uno slider nella barra degli strumenti che ci dice in quale modalità ci troviamo.

2 Mi Piace

Beh, non l’ho fatto, perché non tutto riguardava o era fatto da te.

Comunque. Mantenere due opzioni come compositore è stata una soluzione meravigliosa. Monospace non tanto, ma finché la modifica CSS funziona, sono felice. Ma capisco il punto di avere un’impostazione utente per questo, ma non mi piace, perché c’è già parecchio da configurare. Ma non sono così sicuro di quanti utenti comuni cambino mai le impostazioni… e poi non importa quanto sia affollato :man_shrugging:

2 Mi Piace