pokemoncentral / wiki-project

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

Gestione colori nelle grafiche #41

Open CiaobyDany opened 6 years ago

CiaobyDany commented 6 years ago

Descrizione

Da quando abbiamo introdotto i gradienti lo stile di PCW è notevolmente migliorato e circa tutto il mondo è d'accordo nel dire che siamo molto più belli di Bulba (ad eccezione di qualche pirla che trova seriamente gradevole il layout di Serebii, ma che direi non sia da prendere in considerazione). Tuttavia il cambiamento è stato un enorme trial & error che non ha mai avuto delle linee guida precise da seguire, da cui la necessità di creare un punto di riferimento. Sappiamo tutti che in linea di massima i gradienti si fanno light to normal con box bianchi al loro interno, ma non sempre questo è applicabile e ci sono in particolare alcuni casi degni di nota da considerare.

Pagine affette

Pressoché tre quarti di wiki

Risoluzione del problema

I problemi sono diversi, qui metto i tre più lampanti.

Partiamo dai box di vario genere dei personaggi: nel 90% dei casi continuiamo ad incollare da Bulba i colori con risultati a volte impressionanti (NB: non è in senso positivo). Perché se un personaggio è vestito di arancione ma ha un cappello verde chiaro, fare gli infobox arancioni con bordo verde ha un certo effetto visivo, fare un gradiente da arancione a verde ne ha un altro (circa simile ad un pugno in un occhio). Cosa fare in questi casi? La soluzione è più banale di quanto si possa credere: mettiamo un colore solo. Si prende il colore più rappresentativo del personaggio (arancione, ad esempio) e si fa tutto così.

Seconda questione: @mexicat tempo fa aveva proposto di cambiare i gradienti per far diventare lo standard monocolor light to normal to light per riequilibrare le pagine. Attualmente è possibile implementarlo facilmente nel modulo css se viene usata la sintassi con type. Direi di iniziare a farlo così da poter poi identificare facilmente chi ha mantenuto la vecchia sintassi e aggiornare anche quelli. Se la transizione sarà lunga non credo sia un grosso problema: abbiamo impiegato anni per passare quasi definitivamente dai solid color ai gradienti, la disuniformità che si creerà sarà molto più trascurabile.

Terza questione: cosa fare con box dentro a contenitori a gradiente. Cercherei di non mettere gradienti a contatto con altri gradienti se possibile, soprattutto se sono di contenuto. I template degli allenatori hanno dimostrato che può essere molto carino mettere gradienti radiali dentro box bianchi dentro a gradienti. Quel layout lo vorrei vedere applicato nei catch (con calma, abbiamo altre priorità), ma non mi dispiacerebbe vedere delle prove anche negli evobox. Una valida alternativa può essere il layout usato nei template degli allenatori con tanti box bianchi che hanno dei finti bordi in gradiente (finti bordi perché de facto sono div parent in gradiente).

Screenshot

immagine Originale su Bulba immagine Importazione "as is" da noi immagine Dopo la cura

immagine Se qualcuno avesse altri dubbi sul perché non vanno bene i gradienti dentro ad altri gradienti.

P.S. ho assegnato Flavio e Maze solo perché devono sistemare nel modulo css i gradienti, non sto lasciando a loro la decisione anche se un loro parere sarebbe molto ben accetto.

flavio-a commented 6 years ago

Quando hai aperto quest'issue avevo da poco visualizzato questa anteprima, e mi stavo proprio chiedendo cosa farci screenshot_08-08_16 33-1 quindi bravo che mi hai ninjato.

Poi le mie opinioni:

PS: modificare il modulo css per avere la doppia sfumatura con la sintassi del type dovrebbe essere facile, quindi da quel punto di vista qualsiasi soluzione è approvata.

lucas992x commented 6 years ago

@flavio-a Non dimenticate che certi colori light sono troppo chiari, secondo me è meglio normale - light - normale

CiaobyDany commented 6 years ago

Se ci sono due tipi si lascia as is. Il problema è lo sbilanciamento della pagina, soprattutto da mobile in cui attualmente "pende" verso destra, se fai un gradiente pesato al centro perdi questo effetto.

@lucas992 in realtà volevo anche usare questa issue come feedback per i colori problematici/da cambiare, ma non sapevo quanto fossi in-topic. Generalmente i colori light sono "giusti", l'unico problema evidente ce l'abbiamo con il colore attacco direi, quindi non darei la priorità su normale-light-normale. Qualcuno ha fatto una prova su una pagina per confrontare le opzioni?

lucas992x commented 6 years ago

@CiaobyDany Anche un colore del GCC ha questo problema, e in generale ricontrollerei tutti quelli "vicini" al giallo

CiaobyDany commented 6 years ago

@lucas992 Quelli del gcc sono stati importati da Bulba e mai modificati, potrei risolverlo (forse). Il giallo è un immenso problema però, sì, potesse essere abolito saremmo tutti più felici.

lucas992x commented 6 years ago

Comunque a prescindere dal colore chiaro problematico o meno, i box di due tipi vanno da un colore normale a un colore normale, quindi trovo più coerente che anche quelli monotipo abbiano normale ai bordi.

CiaobyDany commented 6 years ago

@lucas992 Questa è una buona argomentazione in effetti....

lucas992x commented 5 years ago

Anche questa discussione si è un po' persa :D allora vogliamo passare da light -> normale a normale -> light -> normale?

davla commented 5 years ago

Ricordo vagamente di una discussione con Denelio che servirebbero delle prove. Perché lo gradiente triplo, a mio avviso, non si vede sulle cose non sufficientemente larghe.

lucas992x commented 5 years ago

In alcuni casi è vero che non si nota troppo la presenza del gradiente. Ma è un problema ciò?

lucas992x commented 5 years ago

Ne approfitto anche per far notare che per certi colori la versione light è perfettamente identica alla normale. È voluta questa cosa? (https://wiki.pokemoncentral.it/Utente:Lucas992/Elenco_colori guardate per esempio i gruppi Uova)

flavio-a commented 5 years ago

@lucas992 dovrebbe succedere solo per i gruppi uova, alcuni colori _text, FFF e 000. Gli ultimi due per ovvi motivi, i colori _text perché credo che dovrebbe funzionare lo stesso su tutte e tre le shades del colore e i primi perché Dany non aveva (giustamente) voglia di inventarli visto che non c'erano su Bulba e non vengono usati tipo da nessuna parte. Non so di nessun altro caso di uguaglianza

flavio-a commented 5 years ago

Come ha osservato Crusca decidiamo se vogliamo o meno i cerchietti intorno ai MiniSprite. screenshot_07-03_15 02 Secondo me sono un po' abbondanti (specie in elenchi molto più colorati di questo tipo il movelist (esempio) quindi se devo decidere tra sempre e mai dico mai. Se invece vogliamo metterli solo negli elenchi molto bianchi (tipo quello nell'immagine) mi va bene.

lucas992x commented 5 years ago

Come detto, per me va bene toglierlo da questo elenco. Comunque in quell'esempio che hai fatto i tipi sono già indicati, quindi è proprio inutile il radialgrad lì.

Cruifer commented 5 years ago

a parte il caso specifico di questi due elenchi, il vero problema è che non abbiamo delle linee guida per stabilire quando usarlo oppure non usarlo. Visto che tutte le indicazioni all'inizio le aveva date @CiaobyDany, lo invoco per illuminarci sulla situazione. Anche con calma, penso che nessuno abbia furia.

CiaobyDany commented 5 years ago

@Cruifer È un periodo in cui sono un po' tanto preso. Quindi fatemi capire subito che priorità ha la cosa, o probabilmente ci guardo tra un mese.

Cruifer commented 5 years ago

@CiaobyDany Direi molto bassa; come ho detto, nessuno ha fretta spero

flavio-a commented 5 years ago

Up

CiaobyDany commented 4 years ago

Riuppo la questione. Innanzitutto per il normale>light>normale sui monotype su cui continuo ad essere favorevole. (per quanto riguarda i boxtipo sinceramente inizierei a considerare di cambiarli con le immagini dei tipi di SpSc che mi paiono sufficientemente grandi da non risultare pixelate e che non credo pesino troppo più di un box in gradiente, ma forse è meglio una issue a parte su questo) In secondo luogo per la questione radialgrad intorno ai Pokémon non saprei. Fare assoluti da applicare in casi che poi finiscono per essere drasticamente differenti non mi sembra particolarmente saggio. Nello screenshot che ha messo Flavio ci stanno bene. Nei movelist, che sono drasticamente differenti, va bene non metterli soprattutto considerando che ci sono specificati i tipi accanto. Ma, ad esempio, in template tipo il catch che non è particolarmente bianco secondo me sono ugualmente necessari perché chi guarda la pagina potrebbe voler decidere quali Pokémon catturare anche in base al tipo, e non è detto che tutti sappiano a memoria i tipi di ogni Pokémon.

flavio-a commented 4 years ago

Se volete il normale -> light -> normale io posso modificare il modulo css, però andrebbe ad impattare tutte le pagine in cui si usa la sintassi con il type. Che di base è un vantaggio perché con una sola modifica si aggiornano tantissime pagine, però meglio sapere cosa stiamo facendo. Le immagini dei tipi probabilmente pesano meno di un box in gradiente una volta caricate, e tanto sono solo 18 immagini che vengono pure cachate dai browser, quindi approvo. La domanda è: abbiamo quelle di SpSc o dobbiamo usarne di più vecchie? Per i radialgrad intorno ai MS se dobbiamo decidere caso per caso non c'è molto da discutere, li metto nel VexEntry (quello dell'immagine) e poi ogni caso si discute a sé (anche su Telegram).

CiaobyDany commented 4 years ago

Sinceramente direi di aspettare periodi più calmi (che non so quando saranno) perché sì, è un cambiamento importante quindi va pesato bene. Le immagini dei tipi le abbiamo circa di SpSc, non ho ancora avuto tempo di sistemarle (erano in uno zip di abcboy ma erano solo le maschere con i colori da applicare a parte non so bene perché, forse ha a che vedere con il fatto che durante il Dygamax cambiano colore). Faccio presente che abbiamo sia i simboli che i loghi con nome esteso.

Also: ricordo a tutti, soprattutto @orionumeri che qui non è presente, ma a cui incollerò la issue sotto il naso, che avevamo optato per single color sui personaggi ove possibile per evitare gradienti da pugno in un occhio.

Cruifer commented 4 years ago

Girovagavo per la wiki in cerca di distrazioni, e ho notato che in questa pagina il gradiente non si nota per nulla, quindi i colori per zona_neve sono troppo simili. Vale la pena di vedere se ci sono altri casi simili?

CiaobyDany commented 4 years ago

@Cruifer Possibilmente sì, grazie, così ci lavoro insieme agli altri.