A mio avviso, il tag Customization > Theme component svolgerebbe meglio la sua funzione se fosse una sottocategoria. Almeno per me, è più facile trovarli rispetto ai tag e, negli ultimi anni, i componenti del tema sono diventati sempre più significativi rispetto ai loro corrispettivi Customization > Plugin (molti dei quali vengono convertiti in componenti del tema per facilitarne l’uso). Per mancanza di un termine migliore, meritano… un trattamento «uguale». Dopo tutto, sono estremamente popolari e costituiscono ormai una parte integrante di Discourse.
Spero che ne tengiate conto. Non sono un madrelingua inglese, quindi scusate per la mia scarsa capacità di espressione.
Nell’interesse della semplicità, mi chiederei se fare un passo ulteriore per etichettare la categoria personalizzare e poi rendere questi quattro tag abbia più senso.
Concordo sul fatto che i componenti del tema siano un po’ più preziosi per la maggior parte dei siti Discourse al giorno d’oggi.
Penso che questa lingua creerà confusione. Amministrazione → Personalizza serve solo per i temi e i componenti del tema. Customization > Theme contiene tutto ciò che può essere introdotto in un sito tramite quell’interfaccia.
Già vediamo occasionali problemi con utenti che inseriscono i temi nei loro file YML e cercano di aggiungere repository Git per i plugin tramite l’interfaccia. Eliminare questa distinzione rende questi errori più probabili.
I plugin hanno davvero bisogno di rimanere nella propria categoria, vero?
La differenza tra un componente del tema e un plugin è già sfocata nella mia testa. Sono sicuro che qualsiasi cosa possiamo fare per rendere più facile per le persone capire quale sia quale farà una grande differenza.
È un po’ divertente: per molto tempo gli sviluppatori di WordPress avevano una chiamata da fare su dove includere la funzionalità, e si discuteva su quanto codice appartenesse a un “tema” rispetto a un “plugin”. Quel dibattito è ormai quasi quaint, dove tutto e niente è un blocco JS, ma a causa della sua relazione con il software core, dobbiamo ancora capire dove va il codice, in un “plugin” o in un “modello di blocco”.
Non ho mai avuto una tale sensazione con i plugin in Discourse, principalmente perché le persone hanno creato alcuni brillanti hack dei componenti del tema nel corso degli anni. Se qualcuno mi chiedesse qual è la differenza tra “plugin” e “componenti del tema”, il mio primo pensiero sarebbe: uno richiede un campo URL per l’installazione, e l’altro richiede una ricostruzione del sito.
E lo sarà, perché la differenza si basa su come installare qualcosa. Non sullo scopo. Questo è uno stile da sviluppatore per vedere il mondo circostante
Solo una nota sulla marcatura: sembra più facile dimenticare di taggare un argomento che dimenticare di scegliere la categoria. Ci sono già alcuni temi senza tag.
Sono assolutamente favorevole a fare un controllo di salute alle categorie e ai tag. Recentemente sono state avanzate alcune buone proposte per apportare qualche modifica alla struttura, quindi raccoglierò tutto e vedremo come andrà a finire. Credo che qualsiasi cosa renda Meta più intuitivo per le nuove persone o per gli utenti occasionali non possa che essere una cosa positiva.
Questo dovrebbe essere meno problematico ora che c’è un Moderatore della Community dedicato. () Credo che il fatto che io ordini e organizzi man mano dovrebbe coprire gran parte di questo. Inoltre abbiamo un buon numero di utenti TL3 e TL4, quindi speriamo che rafforzare un modello coerente renda più facile anche per gli altri partecipare.
Io continuo a vederla come una distinzione tra modifiche al Frontend e al Backend, ma l’aggiornamento a Ember ha offuscato anche per me cosa significhi ora. Sembra che abbia reso possibili molte più cose in un tema o in un componente del tema rispetto al passato (il che è ottimo se sei ospitato e non hai facile accesso per aggiungere un plugin ).
Credo che questa sia una distinzione piuttosto utile per i non sviluppatori. Rosso = /admin/customize, Giallo = app.yml. Penso che questo sia probabilmente tutto ciò che serve sapere se sei un amministratore che installa una personalizzazione esistente, piuttosto che uno sviluppatore che vuole crearne una nuova.
Grazie per il suggerimento @Decorbuz Metterò insieme alcune idee e vedremo cosa possiamo fare.
Stessa domanda: gli smartphone sono computer o no? I confini non sono più così netti.
Ecco perché ogni forum deve fare una scelta logica su come disporre le cose: da qualche parte deve essere per idea o uso (contano UX e target) o sono più importanti le soluzioni tecniche (pensiero basato su sviluppo/codice).
Non ci sono soluzioni giuste o sbagliate, purché gli utenti trovino ciò che cercano.
Beh, ogni tanto ci sono soluzioni sbagliate. Mescolare plugin/temi/componenti sani con quelli rotti in modo tale che si debba scoprire il tag giusto, è davvero una pessima idea
E in generale c’è un altro errore che gli amministratori commettono abbastanza spesso e, se ricordo bene, anche tag-doc o simili di Meta mettono in guardia: la categoria non genera la creazione di contenuti, ma quelle vuote o a basso traffico rendono solo le cose disordinate.
La mancanza di chiarezza non implica automaticamente la necessità di unirli, in particolare sotto il nome suggerito da Justin. Potremmo ugualmente aggiungere spiegazioni più dettagliate a ciascuna categoria e affrontare parte dell’ambiguità in questo modo.
Gli argomenti Customization > Plugin richiedono una ricostruzione e possono essere eseguiti solo da utenti con accesso root. Si tratta di modifiche a maggior rischio che influenzano la disponibilità del sito.
Non li penso nemmeno io in quel modo. Se richiede una modifica nel backend (codice ruby) sia per memorizzare qualcosa nel database o modificare il comportamento di un’API, molto probabilmente è necessario un plug-in.
Se la modifica riguarda solo l’interfaccia utente, è meglio iniziare con un componente del tema e passare a un plug-in in seguito se le cose si complicano, diventano più complicate e si rendono necessarie modifiche nel backend.
Mi piace questa idea. È un po’ più complicata di una singola categoria con tag diversi, ma mi piace un confine più forte tra questi diversi elementi di personalizzazione.
Un tema può riguardare solo l’aspetto, mentre un plug-in richiede l’accesso al sistema operativo della macchina per l’installazione. Sono cose molto diverse e categorie appropriate consentono, ad esempio, al primo argomento della categoria di fornire contesto ai nuovi utenti sulle differenze tra loro. Come installare, documentazione di sviluppo, ecc.
Sono sicuro che qualsiasi cosa possiamo fare per rendere più facile per le persone capire quale sia quale farà una grande differenza.
Credo che qualsiasi cosa renda Meta più intuitivo per le nuove persone o per gli utenti occasionali non possa che essere una cosa positiva.
