pokemoncentral / wiki-project

Coordinamento dello sviluppo tecnico di Pokémon Central Wiki
https://wiki.pokemoncentral.it
1 stars 0 forks source link

Raggruppare forme alternative uguali negli elenchi #39

Closed flavio-a closed 6 years ago

flavio-a commented 6 years ago

Descrizione

Negli elenchi, spesso vengono ripetute più volte entry uguali solo perché corrispondono a forme alternative diverse. Per esempio, nell'elenco Pokémon per statistiche base compaiono tutte le forme di Pikachu cosplay nonostante abbiano le stesse statistiche della forma base. La proposta è di raggruppare tutte queste forme in un'unica entry, aggiungendo una didascalia adatta a far capire che è un raggruppamento.

A questo punto si presentano due opzioni:

Preferenze tra le due? Altre proposte? Non volete assolutamente questi raggruppamenti?

Preferenze raccolte

Io preferisco la seconda perché secondo me piuttosto che leggersi l'elenco delle forme sotto è più comodo scorrersi le varie righe e vedere con il MS la forma che si vuole. Se l'unica possibile scritta è invece "tutte le forme" anche senza leggerla so che quella riga contiene le informazioni che sto cercando, mi basta vedere che c'è la scritta.

@lucas992, @davla e @cruifer invece preferiscono la prima.

flavio-a commented 6 years ago

Ora vi convinco tutti che ho ragione io: screenshot_02-08_18 12

Lasciate perdere Pikachu che ancora non funziona, Rotom ha evidentemente un problema. Come soluzione stavo pensando di mettere l'elenco delle forme in tt, ma temo risulti scomodo.

davla commented 6 years ago

Più che altro, poi, si scatenano guerre civili per il mini-sprite. Mi hai convinto.

Però non buttare via il codice che hai scritto per fare quello, sono sicuro che tornerà utile.

flavio-a commented 6 years ago

@davla Non c'è rischio, è già committato. Solo in locale, per ora, ma provvederò a pushare.

Tornando IT: soluzioni per l'elenco lunghissimo/il MS? O qualcuno passa all'altra sponda?

flavio-a commented 6 years ago

Io ho pronte entrambe le soluzioni, ditemi quale caricare.

lucas992x commented 6 years ago

Se l'hai aggiustata, confermo che preferisco la prima.

flavio-a commented 6 years ago

Se preferisci la prima devi presentare delle soluzioni ai due problemi/motivare perché non sono problemi.

lucas992x commented 6 years ago

Per le etichette problematiche, vorrei vedere un esempio pratico delle forme messe in tt per capire effettivamente come rende. Per i MS effettivamente i casi come questo sono un problema, provo a pensarci su, se nessuno trova idee per me va bene anche la seconda.

flavio-a commented 6 years ago

https://wiki.pokemoncentral.it/Utente:Ff300/sandbox#Prove_statlist La versione con il link è inusabile perché il nome della pagina e l'icona del mouse finiscono sopra il tt è non si riesce più a leggerne metà, e non metterci il link secondo me è un peccato. Inoltre così

  1. non si può fare ctrl + f sul nome della forma (non è fondamentale)
  2. mentre scorri non hai idea di quali forme siano, devi fermarti e andarci sopra con il mouse/toccare con il dito

L'ultimo punto è quello che mi dà più fastidio e per cui vorrei evitare questa soluzione.

Cruifer commented 6 years ago

@flavio-a il secondo problema non è un vero problema, nel senso che per leggere i dati che ti interessano devi comunque fermarti, a premere l'asterisco sono giusto due secondi in più. Il vero problema mi sembra su mobile, ovvero per aprire il tooltip si preme sul link quindi si apre la pagina delle differenze di forma, cosa sgradevole se uno vuole leggere la pagina in santa pace. Sinceramente, la seconda opzione continua a non convincermi tantissimo ma in questo momento non ho neanche modo di sperimentare delle alternative per conto mio, quindi mi affido a voi. Per sapere, quante righe verrebbero nascoste comunque con la seconda opzione?

flavio-a commented 6 years ago

Dipende dall'elenco. Su quello per statistiche base l'unica differenza tra i due è Rotom, in cui uno non raggruppa le cinque forme elettrodomestico e l'altro sì, quindi parliamo di 4 righe di differenza. Ovviamente dipende molto da quando vogliamo unire le entry. Nell'ndex (in cui vorremo unire quelli con lo stesso tipo?) mi vengono in mente solo due esempi in cui sarebbero diversi (Charizard e Mewtwo, in cui uno raggruppa base e una megaevo mentre l'altro no), e da una rapida occhiata all'elenco delle forme alternative mi sembra che siano anche gli unici, quindi parliamo di 2 righe di differenza

Cruifer commented 6 years ago

Va bene dai, allora a meno che Luca non trovi una soluzione decente opterei anche io per la seconda. Comunque siamo sicuri che il problema che ho detto prima non si presenta anche così vero?

flavio-a commented 6 years ago

Quale problema? Se parli del link sul tt non c'è perché se scrivi Tutte le forme non c'è bisogno di nessun tt, quindi se uno preme è solo perché vuole effettivamente seguire il link. Se invece parli di qualcos'altro non ho capito.

Cruifer commented 6 years ago

Non si sa mai passasse l'idea di scrivere comunque le forme nel tt, ma comunque va bene così ahah.

lucas992x commented 6 years ago

Stando così le cose mi va bene la seconda opzione, visto che la prima ha troppe controindicazioni.

CiaobyDany commented 6 years ago

Ma io ero per la prima opzione :C Anyway, ottimo che sia uscito questo problema perché erano secoli che c'era bisogno venisse guardato. Per l'MS si usa quello della forma base se si raggruppano solo quando sono "tutte le forme". Leggermente off topic (ma nemmeno tanto): è fattibile ora fare in modo che le forme "base" non abbiano didascalie? Mi spiego meglio. Finora il default è stato che se ci si riferisce a tutte le forme non si specifica nulla mentre se ci si riferisce ad una forma singola si mette la specificazione. Questo andava bene quando le forme alternative avevano tutte un nome proprio tranne due o tre eccezioni. Ora però abbiamo tipo tutte le forme di Alola che nella "forma base" non hanno un nome differente dal Pokémon stesso (oltre a Castform, Pikachu, Rotom e sicuramente altri che al momento non mi vengono in mente). Grazie alle vostre competenze migliorate negli ultimi anni rimane tanto problematico gestire forme alternative senza nomi?

P.S. So che dovrei aprire una nuova issue, ma nel catch/entry7 Basculin Linearossa non fa apparire la didascalia usando l'entry 550. Es: https://wiki.pokemoncentral.it/Canyon_di_Poni

flavio-a commented 6 years ago

Ma io ero per la prima opzione :C

Non ho ancora aggiornato niente sul Wiki. Se proponi delle soluzioni ragionevoli per i due problemi sono dispostissimo a cambiare (naturalmente a seguito di una votazione democratica :P). Ti faccio però notare che nei due esempi considerati le differenze tra i due metodi sono rispettivamente 4 e 2 entry in meno, quindi non cambia poi così tanto.

Leggermente off topic (ma nemmeno tanto): è fattibile ora fare in modo che le forme "base" non abbiano didascalie?

Così su due piedi non saprei, devo guardaci meglio e parlarne con Maze.

P.S. So che dovrei aprire una nuova issue, ma nel catch/entry7 Basculin Linearossa non fa apparire la didascalia usando l'entry 550. Es: https://wiki.pokemoncentral.it/Canyon_di_Poni

Questo in teoria è un bug del template (o meglio, del modulo che ci sta sotto) che non mostra mai la didascalia della forma base (per dire, non mostra Forma alterata per Giratina) e che andrà corretto a prescindere dal resto.

davla commented 6 years ago

Leggermente off topic (ma nemmeno tanto): è fattibile ora fare in modo che le forme "base" non abbiano didascalie?

Così su due piedi non saprei, devo guardaci meglio e parlarne con Maze. A parte il fatto che vorrei spezzarti le gambine come quando mi hai chiesto di resizare i modeli a 150px, ma la nuova issue serve perché devi darci requirements più precisi. Eccola: #40