Secondo me, penso che il tag Theme component servirebbe meglio al suo scopo come sottocategoria. Almeno per me, sono più facili da trovare rispetto ai tag, e negli ultimi anni, i componenti tematici sono diventati sempre più significativi rispetto alle loro controparti Plugin (molti dei quali vengono convertiti in componenti tematici per un uso più semplice). Per mancanza di un termine migliore, meritano… un trattamento “equo”. Dopotutto, sono estremamente popolari e sono una parte integrante di Discourse ormai.
Spero che lo prendiate in considerazione. Non sono un madrelingua inglese, quindi mi scuso per la mia mancanza di articolazione.
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 quel linguaggio creerà confusione. Admin->Customize è solo per temi e componenti tematici. Theme contiene tutto ciò che può essere introdotto in un sito tramite quell’interfaccia utente.
Vediamo già problemi occasionali con utenti che inseriscono temi nel loro YML e tentano di aggiungere repository git per plugin tramite l’interfaccia utente. L’eliminazione della distinzione rende solo quegli errori più probabili.
I plugin devono davvero rimanere nella loro categoria, non credi?
La differenza tra un componente del tema e un plugin è già sfumata nella mia testa. Qualsiasi cosa possiamo fare per rendere più facile per le persone capire quale sia quale, farà molta strada, ne sono sicuro.
È una cosa divertente, per molto tempo gli sviluppatori di WordPress hanno dovuto decidere dove includere le funzionalità, e sono state fatte discussioni su quanto codice appartenesse a un “tema” rispetto a un “plugin”. Quel dibattito è quasi pittoresco, ora, dove tutto e di più è un blocco JS, ma a causa della sua relazione con il software principale, dobbiamo ancora capire dove va il codice, in un “plugin” o in uno “schema di blocco”.
Non ho mai avuto una tale sensazione con i plugin in Discourse, principalmente perché le persone hanno escogitato 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 disponibile a dare una controllata alle categorie e ai tag. Ci sono stati un paio di buoni suggerimenti sul dare una piccola ritoccata alla struttura di recente, quindi raccoglierò tutto questo e vedremo dove atterriamo. Penso che qualsiasi cosa renda Meta più intuitivo per le persone nuove/utenti occasionali possa essere solo una cosa positiva.
Questo dovrebbe essere meno un problema ora che c’è un Community Moderator dedicato. () Penso che avere me che ordino e organizzo man mano dovrebbe coprire gran parte di questo. E abbiamo un discreto numero di TL3 e TL4, quindi si spera che rafforzare un modello coerente renderà più facile anche per altre persone unirsi.
La penso ancora come modifiche Frontend contro Backend, ma l’aggiornamento a ember ha sfocato cosa significhi per me ora. Sembra che abbia reso molte più cose possibili in un tema/componente tematico rispetto a prima (il che è fantastico se sei ospitato e non hai un facile accesso per aggiungere un plugin ).
Penso che sia una distinzione piuttosto utile per i non sviluppatori. Rosso = /admin/customize, Giallo = app.yml. Penso che sia probabilmente tutto ciò che devi 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.
Una mancanza di chiarezza non significa automaticamente che debbano essere uniti, in particolare con il nome suggerito da Justin sopra. Potremmo ugualmente aggiungere spiegazioni migliori a ciascuna categoria e affrontare in questo modo parte dell’ambiguità.
Theme e Theme component incapsulano le personalizzazioni preconfezionate che possono essere apportate in fase di esecuzione.
Gli argomenti Plugin richiedono una ricompilazione e possono essere eseguiti solo da utenti con accesso root. Sono modifiche a rischio più elevato che influiscono sulla 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.
Qualsiasi cosa possiamo fare per rendere più facile per le persone capire quale sia quale, farà molta strada, ne sono sicuro.
Penso che qualsiasi cosa renda Meta più intuitivo per le persone nuove/utenti occasionali possa essere solo una cosa positiva.
