Ogni tanto, per risolvere problemi pratici merdosi, mi invento soluzioni tecniche complesse e cursate… del tipo di reimplementare la API di WordPress dentro HTMLy per poter gestire il blog basato su quello con la app di WordPress… ma, questo è uno spoiler che non dovrei fare, almeno fintanto che non finisco di lavorarci, cazzarolina. Tuttavia, qualche altra volta, se il caso vuole, mi escono piuttosto soluzioni tecniche semplici ed eleganti… come, in questo caso, aggiustare l’editor di post già presente in HTMLy, senza sostituirlo, per risolvere i problemi pratici merdosi in un modo banalissimo: aggiungere una modalità fullscreen. 🤯
L’editor Markdown base dentro quel coso, fatto di una semplice <textarea> con una barra degli strumenti bonus (e scorciatoie da tastiera) per la formattazione, con un’anteprima a parte (che, tra l’altro, non è accurata rispetto a come il Markdown viene poi renderizzato dal frontend del sito, ma questa è un’altra rogna), per qualche motivo infatti non mi ha mai completamente convinto, ma non mi sono mai messa a riflettere abbastanza da capire come mai ciò fosse il caso… Almeno fino a prima di adesso (cioè, di qualche giorno fa), quando ho capito che il problema è il layout assoluto della pagina admin; non l’editor intrinsecamente, insomma, ma il contesto in cui questo è inserito. 👌
In breve, pensandoci, tutti gli editor di testo normali e i programmi di videoscrittura, e le interfacce di blogging di conseguenza, non hanno ‘sta cosa dove la pagina è un form classico con tremila campi, che scrolla pure verticalmente perché ovviamente è bella grande, e il contenuto sta in una delle tante scatoline… bensì è circa tutto il contrario, cioè che il contenuto è al primo posto e tutto il resto sta attorno. In qualcosa come il Blocco note di Windows, questo “attorno” è solo barra dei menu + barra di stato, mentre in WordPress è una serie di tasti importanti sopra e campi misti di lato (o in un menu a parte nella app Android), su Word è la barra gigante in alto, e così via… 🎐
Ma quindi, la soluzione a questo apparentemente insignificante dettaglio di UI/UX, che però mi causa (e penso a molti causerebbe) dei mal di testa (o, almeno, uno stato di controvoglianza nell’uso), — come sempre, perché le interfacce fatte per bene sono invisibili, mentre quelle che non lo sono causano sempre dolore — potrebbe sintetizzarsi in, semplicemente, aggiungere una funzione per cui il campo di testo dell’editor possa andare a finestra intera, prendendo precisamente tutto lo spazio, e non di più o di meno (più la barra degli strumenti fissata). ⚗️
Ora, ovviamente l’ideale massimo sarebbe in ogni caso solo rifare da capo l’intera pagina per farle avere alla base una struttura decente, ma significherebbe appunto ricostruire tutto; e sicuramente con JavaScript potrei riuscirci senza dover rompere ogni cosa, ma per ora chiaramente non c’ho voglia. Già questa piccola modifica tanto basterà per alleviare tantissimo il mal di capa causato da quello che spesso è un doppio scrolling (specialmente su mobile, dove la sofferenza viene credo triplicata), della pagina + l’area di testo (che non si ridimensiona mai automaticamente), o in alternativa il dover scrollare troppo la pagina per raggiungere altri campi se l’area fosse alta quanto il contenuto… e le controindicazioni sono assolutamente zero, quindi ho fatto subito una pull request al capo del progetto, fiduciosa che verrà accettata (quando si sveglia domani, che lui è indonesiano, quindi ora starà nel lettino). 🔧
Pure a livello di codice, ribadisco, non è stato difficile; è bastato un po’ di puro CSS per dichiarare il layout, e del JavaScript integrato nell’editor già esistente per attivare e disattivare l’ambaradan a necessità, col bottoncino o con la combinazione da tastiera che ho registrato (CTRL+P). Per mobile ho in realtà aggiunto anche una proprietà del meta viewport che ho scoperto letteralmente stasera, cioè interactive-widget=resizes-content, per indicare al browser (almeno, per Chromium e Safari si, su Firefox chi lo sa) di ridurre il l’area della pagina quando la tastiera virtuale è aperta, così da evitare un altro doppio scrolling che altrimenti ci sarebbe… e ora si che è comodo lì, pare nativo! 👄
Va detto comunque che l’idea di base non l’ho inventata io, anche se mi è dovuta comunque arrivare come intuizione personale perché io potessi considerarla (poiché non arriva mai nessuno da me a suggerirmi le cose in anticipo e semplificarmi così le missioni, mannaggia alla polvere). Infatti, pensandoci lo fa anche un plugin di cui non ricordo il nome che ho sulla mia DokuWiki, che aggiunge un tasto al campo di editing anch’esso semplice vecchio stile da <textarea> buttata in una pagina alla bene e meglio, per mandare a schermo intero… ma quell’implementazione è mezza rotta e meno elegante di cosa ho fatto io qui, che ho riutilizzato gli elementi già presenti nel DOM, senza duplicare il campo di testo o fare strane scemenze. Detto questo, però, è proprio strano che questa idea non solo non sia mai venuta al grande capo di HTMLy, ma nemmeno ad altri contributori… non esistono issue o pull request al riguardo, a parte qualcuno che vorrebbe sostituire l’intero editor Markdown con altri più avanzati (che no, non risolverebbe direttamente questo specifico mal di cervello, e lo so perché sulla mia installazione ci ho provato; non è la mancanza di WYSIWYG che mi uccide, è il layout che scrolla e fa cose che bleh… ma ora grazie al cielo non più). 🙌
VCs are still hiring MBAs, but firms are starting to need other experience more