Gdr Play by chat: come adattare al mezzo standard di design moderni

04/07/2021 16:07:32

pagina unica, index solo, e all'intenro la pagina controlla se sei loggato o meno, e se non sei loggato limita le pagine a cui puoi accedere

quota

04/07/2021 23:04:13 e modificato da ghennadi72 il 04/07/2021 23:09:20

Parto da un presupposto. Quando si costruisce qualcosa, prima si guarda a cosa si deve costruire, poi si sceglie come costruirlo e che materiali utilizzare. Non si ragiona a rovescio.
Il contrario funziona solo se sei un naufrago che finisce su un'isola e deve cavarsela con quello che ha a disposizione. O se devi risolvere un problema teorico per "sport": della serie "ti do a disposizione queste cose, vedi cosa puoi costruirci".

Qui parliamo di costruire interfacce di gioco, non solo siti da consultare. Quindi come premessa generale farei un bel distinguo. Tra "dentro" e "fuori".
Perchè se parliamo di PbC le esigenze dell'interfaccia prendono il sopravvento su standard che non sono pensati per siti che devono fare certe cose.

Per il "fuori" si potrebbe e si dovrebbe fare tutto il possibile per aggiornare i nostri siti agli standard attuali, rivedendo impostazioni e strutturazioni che hanno fatto il loro tempo. Come Quod credo che se e quando mi deciderò a rifarla farò tutto in casa.
Niente framework: solo html5 e css. E JS solo dove serve. La "riusabilità del codice" non deve diventare un ricatto o una gabbia che mi obbliga a piegare quello che mi serve fare a quello che il framework mi permette di fare.

Per parlare chiaro: bootstrap? Manco morto. Ne userei il 5% a dir tanto, appesantendomi inutilmente, e non mi permetterebbe di fare il 90% di quello che voglio fare o mi costringerebbe a impazzire e studiare a fondo come modificarlo. A quel punto 10 volte meglio fare tutto in proprio.

Quindi sull'esigenza per la parte "esterna", ossia sito consultabile da non iscritti / non loggati, massima apertura. Se non lo abbiamo già fatto non è nè per mancanza di percezione del problema, nè per resistenza "intellettuale", nè per pigrizia.
E', come sempre, un problema di tempo. Che esiste per noi gestori e sviluppatori come esiste per i giocatori.

Per la parte "interna" ossia l'interfaccia di gioco vera e propria vedo molti più problemi a individuare uno "standard".

Ci sono molti adattamenti che si potrebbero fare per "modernizzare" le interfacce e qui ognuno, ritengo, sa dove dovrebbe mettere le mani, specie chi l'interfaccia l'ha costruita in proprio senza affidarsi a gdrcd.

Ma qui di solito tende a prevalere, nelle valutazioni, il preservare le funzionalità rispetto allo "standard". Per ovvi e legittimi motivi.

Anche perchè non esiste "standard" di riferimento per applicazioni come le nostre. E forzare uno standard pensato per siti che devono presentare contenuti a diventare uno standard per interfacce che devono garantire certe funzionalità, perchè servono al gioco, lo trovo esattamente quel ragionare a rovescio, che nel nostro ambito non è applicabile o potrebbe fare più danni che altro.

Se e quando riuscirò e avrò tempo di mettere mano all'interfaccia di gioco darò sicuramente la precedenza al cercare di utilizzare meglio gli spazi e al non restare ancorato a un'impostazione che andava per la maggiore quando le definizioni standard (in pixel) dei monitor erano molto più basse delle attuali. Discorso che coinvolge grandezza dei font, suddivisione degli spazi, grandezze di default delle immagini, eccetera.

Ma sia chiaro che darò la precedenza alle funzionalità che mi servono. Non a un ipotetico "standard" che non esiste.
E sicuramente mi concentrerò sul come utilizzare meglio gli spazi a definizioni contemporanee, non sul rendere il gioco fruibile su un dispositivo da 5/6".

Perchè come ho detto altrove, "responsive" e "mobile first" non sono due concetti equivalenti. E per la parte "interna" mi fermerei a un approccio responsive, senza spingermi al mobile first, che può aver senso per la parte consultabile del sito, mentre per l'interfaccia di gioco... dipende.

"ho parlato" (cit.)

---

quota

05/07/2021 15:33:56

Ah e scusate se intervengo di nuovo, ma vorrei riferire un aneddoto che potrebbe essere illuminante, di quello che succede in ambito commerciale.

Un annetto fa la nuova proprietà di DeviantArt (un portale internazionale di content sharing principlamente dedicato ad artisti, con qualcosa come 40 milioni di iscritti) ha deciso per una radicale revisione dell'interfaccia del sito.

Parola d'ordine, modernizzarlo e uniformarlo appunto agli "standard attuali".

La community che lo utilizza ha vissuto una sorta di lunga guerra civile interna fra chi voleva mantenere la vecchia impostazione da CMS "old style", gli entusiasti della nuova interfaccia (che riutilizza parecchio del codice di Wix essendo la proprietà la stessa) e chi chiedeva che pur modernizzandone l'interfaccia venissero mantenute le funzionalità che lo avevano reso un portale unico nel suo genere.
Parliamo, per chi non lo sapesse, di un sito che ha una quarantina di milioni di iscritti.

La proprietà è andata dritta per la sua strada, ignorando e liquidando come "ingiustificati attaccamenti al passato" le obiezioni rivolte alla nuova interfaccia, arrivando a denigrare come "spaghetti code" il lavoro di chi negli anni precedenti aveva creato una community da 40 milioni di utenti e sostenendo che le nuove funzionalità avrebbero compensato e fatto dimenticare quelle vecchie, a cui si doveva rinunciare perchè "spaghetti code" non compatibile coi framework utilizzati per modernizzare il sito.

Risultato, quando la nuova interfaccia é stata imposta nella sua versione definitiva, una fetta importante dell'utenza ha abbandonato la piattaforma e le visite giornaliere sono crollate, nei mesi successivi, di percentuali tra il 25 e il 30%.
Ripeto, parliamo di un portale con un'utenza di una quarantina di milioni di iscritti. Fatevi voi i conti spicci su cosa significa aver perso da un quarto a un terzo della propria clientela.
Senza che si sia ancora visto, ad oggi ossia a diversi mesi dalla "migrazione", un ritorno di nuova utenza "motivata" dall'aver adottato un'interfaccia più standardizzata (omologata) con quanto offre il web oggi.

Nel 99% delle aziende un CEO che avesse perso di botto dal 25 al 30% della clientela verrebbe preso a calci nel deretano in loop e messo al rogo dai suoi stessi azionisti.
E gli azionisti imporrebbero un dietro front immediato (esempio recente: menu Start sparito dalle prime versioni di windows 8 e poi prontamente ripristinato in seguito alla rivolta degli utenti), fregandosene delle pippe mentali sugli "standard", sulla "interfaccia unica fra mobile e PC" e sul "modernizzare".

Perchè anche in chiave commerciale nessuno è tanto stupido da amputarsi di un pezzo importante della propria clientela solo per inseguire un approccio ideologico sul come impacchettare un prodotto che, in ultima analisi, deve essere fruibile per chi lo utilizza e si aspetta di trovarci determinate funzionalità.

In questo caso la proprietà era unica, gli sviluppatori hanno seguito pedissequamente le direttive della nuova proprietà, quindi nessuno è finito al rogo.
Ma soprattutto: la nuova proprietà di Deviantart aveva almeno un palese interesse monetario nell'imporre la "svolta": riutilizzare il codice già usato su Wix e facilitare l'interscambio (sfruttamento) di materiale artistico già pubblicato su deviantart e riciclato (anche all'insaputa degli autori) su Wix.
Nel mondo del PbC non abbiamo neanche l'interesse di bottega che giustifichi la nostra trasformazione in cheerleader/fanboy di bootstrap o di qualsiasi altro framework.

Sta di fatto che quella community è stata amputata di un pezzo enorme della propria utenza; per compensare i minori introiti pubblicitari sono stati introdotti nuovi livelli di utenze premium, per cui chi finora era utente premium ("core member" secondo il gergo deviantart) si trova ora davanti alla spiacevole scelta di continuare a pagare quello che pagava prima ma avendo meno, oppure pagare di più per riavere quello che aveva prima: quindi anche chi è rimasto "a casa" si è trovato il palo nel didietro, doppiamente, avendo perso delle funzionalità e dovendo pagare di più per riaverne alcune che aveva già pagando di meno. Però, ehi... ora Deviantart è più moderno! Fico, tutti contenti.

Quindi scusate se sottolineo il concetto: benissimo standardizzare e modernizzare dove possibile. Che significa componente esterna dei nostri siti, che significa rendere responsive e adattabili a dimensioni di schermo più ampie le nostre interfacce di gioco e mandare in pensione impostazioni grafiche concepite a cavallo tra fine anni 90 e primi anni 2000. Detto questo, però, gran calma.

Dove la "standardizzazione" (a uno standard che non è pensato per supportare determinate funzionalità) mette a rischio la natura stessa delle funzionalità che offriamo all'utenza PbC e che rendono il PbC una cosa unica, io ci andrei coi piedi di piombo.
Deviantart pur avendo perso da 1/4 a 1/3 della sua utenza continua a restare una community enorme, con decine di milioni di iscritti e non è affondata.
Per noi, fare la scelta sbagliata per inseguire gli entusiasti del "mobile first", potrebbe essere il colpo di grazia definitivo.

---

quota

05/07/2021 18:15:05 e modificato da soizora il 05/07/2021 18:15:38

non condivido l'ultimo discorso, primo perchè l'utenza abituata alla classica impostazione grafica numericamente sono massimo 150 utilizzatori di internet che a ruota si creano pg in più land(solito problema del ricambio generazionale) e secondo, nessuno obbliga ad usare bootstrap, specie se si ha una idea ben chiara del risultato che si vuole avere, ma è innegabile che appoggiarsi a bootstrap, o alle mille librerie open source in circolazione ti avita di dover reinventare da zero la ruota, con grande beneficio dei tempi di produzione.

quota

05/07/2021 20:09:56

Posso capire il motivo del paragone, ma mettere in relazione DeviantART con la nostra realtà play by chat ha ben poco senso perché sono due cose completamente diverse. Lo stesso discorso commerciale è poco rilevante perché la stragrande maggioranza dei pbc non apre per incassare denaro (senza contare che con i numeri di oggi servirebbero quattro vite per riprendere gli eventuali soldi spesi per la sua costruzione). Ripeto, capisco il motivo del paragone, ma lo trovo poco rilevante ai fini della discussione.

In merito al "mobile first" io sono il primo a sostenere che giocare da pc è meglio, seppur mi piaccia un gioco più rapido e dinamico. Resta comunque il fatto che il responsive (inteso come l'adattarsi della pagina alla risoluzione del monitor o dello schermo del portatile) c'è e semplifica la vita per diversi motivi. Quanti sono i gdr con una grafica studiata per una singola risoluzione e l'utente che viaggia a 1920x1080 (o maggiore) si ritrova con la pagina praticamente vuota. Questo non significa utilizzare Bootstrap o simili.

I miei interventi precedenti erano mirati a concetti teorici di base che sono fondamentali quando si progetta una UI (intendo anche quelle di un qualunque videogioco o gioco in generale) e che in buona parte dei progetti non vengono considerati. Io credo sia un semplice discorso di progresso.. Ci sono nuove tecnologie che ci permettono di fare un sacco di cose rispetto a 20 anni fa, sfruttiamole.

Ps. Ho seguito diverse discussioni qui sul portale su come apportare modifiche e miglioramenti a questo hobby che ci accomuna tutti qui, ma se non siamo in grado di abbandonare concetti e convinzioni vecchie di due decadi, come possiamo pretendere di migliorare ciò che impiega il nostro tempo libero?

quota

05/07/2021 20:14:39 e modificato da ghennadi72 il 05/07/2021 20:22:43

Ti fermo qui. Mi pare di aver scritto chiaramente che una revisione dell'impostazione grafica "tipica" consolidatasi nei primi anni 2000 sarebbe più che benvenuta.


Fonte? Non discuto che l'ordine di grandezza sia ormai da tempo sceso sotto l'ordine delle migliaia ma solo Lot continua a farne centinaia. E se fossero davvero solo 150 dovrei concludere che la nostra piccola land, da sola, ne concentra quasi un terzo? Perbacco. Motivo in più per tenermeli.


E' negabile eccome. Perche alla frase sul "non reinventare la ruota", che si trova in qualsiasi introduzione di qualsiasi corso di programmazione e nelle prime righe di presentazione di qualunque framework, qualunque corso (e framework) serio fa seguire un'importante specifica: che dipende da COSA devi produrre.
E gli sviluppatori di framework (seri) sono i primi a prendere "laicamente" questo discorso, a non cercare di venderti la ricetta della pietra filosofale e ad avvertire che i framework non solo la soluzione per "tutto".
Ci sono parecchie circostanze nelle quali adattare un framework (ed essere vincolati alla sua impostazione) fa perdere molto più tempo che programmare da zero.

Per non parlare del rischio di finire su un binario morto nel momento in cui cessasse il supporto a una determinata versione di un determinato framework e tu ti trovassi di nuovo a dover riadattare daccapo la tua interfaccia alla nuova versione del framework non più retrocompatibile.

Io auspico che una eventuale futura versione di GdrCd (o corrispondente) integri da subito le caratteristiche che ci si attendono da un sito contemporaneo. E ben venga se un ipotetico gdrcd 6.x fosse basato su un framework che non rischia di essere dismesso dopo 2 anni.

Ma se le esigenze di chi apre o già gestisce un gioco vanno ben oltre il "pacchetto base" continuerò ad essere un sostenitore del "fatto in casa" e del sapere esattamente cosa c'è "sotto il cofano" del CMS (perchè comunque una land PbC questo è) che hai costruito.

Meglio spendere 120 ore di apprendimento serio e diventare in grado di produrre in proprio, che spenderne solo 40 di apprendimento di un framework per poi perderne 500 in emicranie per forzare il framework a fare quello che non è progettato per fare.

L'ordinaria amministrazione della programmazione e del mantenimento quotidiano di un codice vanno un bel po' oltre gli slogan da corso base di Udemy sul "non reinventare la ruota". Ma sono sicuro di non doverlo spiegare a voi. Lo dico unicamente a beneficio di chi, in cerca di scorciatoie comode, poi potrebbe trovarsi in un vicolo cieco.

---

quota

05/07/2021 20:20:53

Il discorso DevianArt è un po' particolare rispetto alle situazioni attuali perché per quanto ci fosse dibattito interno, la carenza di visitatori mensili (non di iscritti) è calata anche per altri motivi legati più alla scelta del quando e dei mezzi extra che negli anni si sono evoluti.
Sono passati da 65 milioni a 45 milioni di visitatori e non sono più saliti da li; nell'effettivo anche aver perso quegli utenti ma aver mantenuto stabile per tanti anni con altri mezzi come, uno tra tutti, Instagram (che ha fatto un boom proprio in quegli anni fino ai giorni nostri) è un analisi leggermente poco correlata a quanto si sta parlando.

---

quota

05/07/2021 20:28:42

Sì ma la picchiata verticale c'è stata esattamente nel momento in cui la nuove interfaccia ("eclipse") é diventata obbligatoria. Cosa che nella community di deviantart riconoscono tanto i fautori e i sostenitori della nuova interfaccia quanto (ovviamente) quelli che l'hanno presa male ma sono comunque rimasti.

La relazione con quello di cui stiamo parlando c'è: si tratta di ricordare sempre che quando si ristruttura un sito, le sue funzionalità e particolarità non sono una variabile ignorabile o secondaria.

---

quota

05/07/2021 21:45:09 e modificato da soizora il 05/07/2021 21:47:29

si, però ghennadi, alla fine è difficile penso che un pbc richieda interfacce grafiche così astruse che integrare bootstrap anche per usare un paio di plug-in sia tanto deleterio.
Magari sono d'accordo che la griglia non serve in un pbc, ma (e cito bootstrap solo perchè stiamo prendendo lui come esempio) ci sono molte altre funzionalità facilmente integrabili senza sconvolgere un progetto, e francamente i cms/framework se non hai pretese strane ti riducono d molto le ore di lavoro, permettendoti di dedicarti solo alle effettive implementazioni(prendi ad esempio il sistema di routing o gestione dipendenze che hanno i vari framework modrni...se uno dovesse fare quella roba da zero, che ripeto è solo roba che serve a far girare il codice base, senza alcuna implementazione di vera produzione, non dico che rifarla da zero sia impossibile, ma senza dubbio raddoppia la durata del lavoro).

Github, i vari npm e composer hanno fatto la propria fortuna su questo, sul concetto che qualcuno crea un utility qualsiasi, e questa viene condivisa con un click con milioni di sviluppatori in tutto il mondo, permettendoti di non dover programmare da zero ogni singolo aspetto del codice.

quota

06/07/2021 18:28:24

Eh appunto, la questione è proprio quella Soizora. "Se non hai pretese strane". Io metterei buona parte delle funzionalità che solitamente appaiono anche nel più scrauso dei gdr PbC sotto il cappello delle "pretese strane".

Forse, dico forse, ti salvi solo se costruisci un ipotetico gdr-cd 6.x (anzi, facciamo direttamente 7, saltando una generazione per marcare il balzo in avanti), solo con le funzioni base, utilizzando quanto c'è di utilizzabile e riutilizzabile. Operazione che dovrebbe avere in cima alla lista requisiti di stabilità, lungo supporto e facilità di personalizzazione.

Il fatto che abbiamo visto aprire in questi anni dozzine e dozzine di land fotocopia ci dice tutto quello che c'è da sapere su quello che chiede il gestore medio che decide di aprire un gioco usando un prodotto da personalizzare ma già pronto nelle sue funzionalità base.
Si potrebbe partire da lì e sono d'accordissimo che sarebbe già un grande passo in avanti (anche per quelli che a domanda "perchè non lo fai tu, il tuo gdr dei sogni?" puntualmente rispondono che non hanno tempo, non hanno i programmatori, ecc).

Ma detto questo: sappiamo anche benissimo che fine ha fatto pressochè la totalità delle land aperte con "gdrcd non modificato" o modificato solo per cambiare qualche css, sbattere su qualche immagine e un'ambientazione scritta di fretta. Le land che riescono, nonostante tutto, a sopravvivere sono quelle che offrono qualcosa di originale. E in termini di ambientazione, e in termini di meccanica di gioco e in termini di funzionalità. Oppure che riescono a mantenere interessata per anni di fila un'utenza molto fidelizzata al tipo di gioco che si fa in quella land.

Ne conosco una di land che è riuscita a stirare gdrcd fino ai suoi limiti estremi e che è ancora aperta ed attiva per raccontarlo. E manco gdrcd 5.x, parliamo dell'extreme. Una. Sto parlando di Stargate Command, ovviamente, che non a caso NON è un gdrcd "standard": oltre alla personalizzazione tecnica del cms e agli elementi tecnici originali che hanno realizzato, si regge su un'ambientazione coi fiocchi e su un impegno ammirevole del suo staff.
Mi verrebbe persino da dire che "forse" il problema del cimitero di land chiuse non sembra essere la mancata standardizzazione o la mancanza di un CMS con cui costruire una land in un giorno, ma questo discorso ci porterebbe fuori strada.

Mi rendo conto che siamo in pochi ad aver cercato di spremere il massimo da quello che un'interfaccia web può dare, andando oltre le funzionalità base che fanno da comune denominatore a tutti i giochi. E che magari quindi quello che dico può sembrare un "beh ma tu sei un caso a parte". No, non sono un caso a parte. O sarò un caso a parte, ma siamo in buona compagnia di land che durano da parecchi anni e che forse qualcosa lo devono proprio al non essersi fermati al "pbc modello base". Al non essersi "standardizzati".

E che fanno dell'offerta di funzionalità "particolari" una grossa parte della loro offerta di gioco, non sacrificabile sull'altare di alcun framework che ti costringerebbe, nella migliore delle ipotesi a riscrivere e riadattare il 75% del codice proprietario della land. E se alcune land di successo (almeno nel soddisfare il loro target di utenza) non avessero chiuso semplicemente perchè i rispettivi gestori non potevano più sobbarcarsi l'impegno saremmo anche di più.

E qui veniamo al punto dolente. Che non riguarda la miriade di giochi PbC 2.0 che in un radioso futuro ci inonderà e svecchierà finalmente il famigerato panorama stantio del PbC, ma le land attualmente attive e le difficoltà o le resistenze che hanno (abbiamo) a mettere mano pesantemente alla struttura dei nostri giochi.

Non è pigrizia. Non è attaccamento al passato. Non è incapacità di fare i conti con le "nuove (?) tecnologie" (seriously?). Non è che siamo boomer che tornerebbero volensieri all'MS-DOS. Certe baggianate e luoghi comuni strapperanno anche qualche sorriso, ma teniamole fuori dai discorsi seri e con pretesa di essere costruttivi.

E' semplicemente che rivedere l'impianto di un gioco che non si limita a offrire le funzionalità base, fin dalle fondamenta, non è uno scherzo. E' una cosa che richiede tempo, risorse e, quasi certamente, la chiusura a tempo indeterminato dei giochi attualmente attivi, visto che non sono solo i giocatori a contare sulle dita di una mano le ore che hanno a disposizione per il gioco. E se sei impegnato nel riscrivere il 75% del tuo codice per adattare un framework, o per rifare tutto daccapo su premesse tecnicamente più contemporanee te lo puoi anche scordare di fare contemporaneamente il gestore e star dietro al gioco e alla conduzione ordinaria e quotidiana di una land.

Vorrei un euro per ogni volta che ho chiesto "perchè invece di criticare non vi mettete a lavorare su un progetto" e mi sono sentito rispondere "eh, ma costruire un gdr è una cosa pesante. eh, ma non abbiamo il programmatore. eh ma mica si tratta solo di mettere su un'installazione di gdrcd".

Bene cosa vi fa credere che ricostruire dalle fondamenta un gioco già aperto e già funzionante, di fatto chiudendolo a tempo indeterminato per la "gioia" di chi ci gioca e ci si diverte, richieda meno energie?
O che i gestori abbiano più energie, più ore a disposizione nell'arco della giornata, rispetto a un qualsiasi appartenente alla specie Homo Sapiens e rispetto a un qualsiasi giocatore che si lamenta dell'offerta attuale ma non muove un dito per costruire qualcosa di nuovo, perchè ovviamente richiederebbe fatica, impegno, tempo e risorse?

Sarò onesto, farò tanti complimenti il giorno che dovesse uscire un gdrcd 6.x (o 7.x) basato su uno o più framework affidabili, con speranze di supporto a lungo termine e, soprattutto, di facile apprendimento per chi inizia e non ha tempo di approfondire tutto quello che dovrebbe per costruire un gioco in proprio.
Ma non ho realisticamente speranze che gdr già aperti, a meno che non abbiano solo le funzionalità base, possano facilmente ricostruire dalle fondamenta i loro giochi. O che sia sensato per loro farlo.

---

quota

Under 18 nei Gdr?

E' vero che gli under 18 non giocano più ai giochi di ruolo online testuali? Vediamo un pò di dati!

Eternal Dream

Intervista al gestore di Eternal Dream Hunter X Hunter Story play by chat manga!

Avventura

Gaming, quando l'avventura conquista tutti!

Alziora

Fantagiochi presenta Il Regno di Alziora, tra Elfi e Fate nel medioevo..