Wikipedia:Bar/Discussioni/Snobismo grafico

Snobismo grafico		NAVIGAZIONE

Indice

Settimana

Giorno

Mi spiace usare una pagina del bar, ma la questione riguarderebbe diversi aspetti della grafica e non sarebbe opportuno sceglierne uno dimenticando gli altri... Credo peraltro che l'argomento debba essere di interesse ed attenzione generale.

In questi giorni sto di nuovo controllando le pagine che contengono il tpl {{TOCleft}} per vedere se l'uso ne sia davvero sempre giustificato, e le modifiche apportate hanno provocato qualche stupore. Dato che qualcuno comincia pure a rollbaccare, prima che ci avvitiamo in edit war grafiche mi sa che è tempo che finalmente affrontiamo l'argomento tutti insieme. Vi chiedo un momento di pazienza, ché la cosa può essere rognosa.

Problema

le nostre pagine sono sempre meno visualizzabili con risoluzioni video basse, ad esempio 640x480, in qualche caso risultano proprio illeggibili o di composizione quantomeno irrazionale.

Cause

1. nessuno pensa che le pagine potrebbero esser viste differentemente da come le vede lui/lei nel momento in cui ritiene di renderle graficamente più avvincenti
2. non è molto noto che mettere a sinistra un'immagine o il quadrotto dei titoli di sezione (il TOC) sposta il testo a destra, ed a destra non sempre c'è spazio sufficiente. Con basse risoluzioni, lo spazio non c'è quasi mai.
3. editando con risoluzioni "moderne" non si nota la dimensione eccessiva che hanno i box e le tabelle, ad esempio i tassobox, o quelli dei comuni. Spostando l'immagine a sinistra, al testo rimane solo da insinuarsi in una strisciolina verticale di poca larghezza
4. alternando immagini e/o tabelle a sinistra e a destra, il testo trova la sua strada spezzettandosi o, se manca lo spazio, sovrapponendosi a quello nelle tabelle.
5. per i motivi ora detti, sempre più spesso il testo delle voci risulta sbrindellato perché per desiderio di far più bella la voce vengono inseriti:

• template tocleft e tocright senza particolari ragioni tecniche
• immagini allineate a sinistra senza necessità
• immagini di dimensioni eccessive
• box, tabelle e template con allineamenti predefiniti incompatibili col testo o con altri elementi della pagina

Test effettuati

Ho navigato per WP con una macchina vecchia, in 640x480, e ne ho ricavato qualche screenshot dal momento che mi è stato fatto notare come in alcuni sistemi addirittura non sia proprio più possibile usare una risoluzione 640x480 e che quindi tutto questo potrebbe apparire mera teoria.

Spero perciò che le immagini riescano visivamente a chiarire bene il tipo di problema che personalmente ritengo da risolvere con una certa urgente attenzione.

La risoluzione di questo test non sembri estrema: due terzi dei problemi sotto indicati si verificano anche in 800x600, che è una risoluzione ancora usatissima

Le voci sono state prese a caso, nessun eventuale riferimento agli autori o ad altri significati è intenzionale.

---- *'''voce [[Ariccia]]''' <gallery> Immagine:G-CAP2.jpg|pagina vista in 1024x768 Immagine:G-CAP2_2.jpg|pagina vista in 640x480 Immagine:G-CAP1.jpg|proporzione della visualizzazione in 640x480 rispetto alla 1024x768: la seconda immagine (640) vista nel browser a 1024 </gallery> <gallery> Immagine:G-CAP3_2.jpg|Come appare scombinato nella versione attuale della pagina il testo in 640: non solo l'immagine entra dentro il box, ma i TOC, i titoli di sezione, si sovrappongono al testo della tabella Immagine:G-CAP1_2.jpg|Seguito della precedente visualizzazione: il testo prosegue incolonnato stretto, con poche parole per riga, a causa della larghezza del box comuni. Si noti in basso che il browser richiede lo scrolling orizzontale (barra di scorrimento orizzontale, in basso) perché alcune parti della pagina si espandono a destra, altre parti, come questa, no </gallery> ---- *'''voce [[Brigata Meccanizzata Granatieri di Sardegna]]''' <gallery> Immagine:G-CAP3.jpg|pagina vista in 1024x768, il tocleft dà tutto sommato poco fastidio Immagine:G-CAP20.jpg|pagina vista in 640x480, il tocleft "spinge giù" lo stemma, il testo si spezza, il link "modifica" della sezione finisce in mezzo al testo, che inizia da una parte e poi, senza gran ragione, prosegue da un'altra </gallery> ---- *'''voce [[Storia dell'urbanistica e dell'architettura di Reggio Calabria]]''' <gallery> Immagine:G-CAP14.jpg|Incipit in 640: il tocleft stringe il testo fra sé e la tabella, il testo si dispone in una parola per riga, come si vede sovrapponendosi alla tabella Immagine:G-CAP15.jpg|Seguito della videata precedente in 640 Immagine:G-CAP16.jpg|Il box a destra, troppo largo, in 640 interrompe il testo che resta sospeso, troncato a mezzo. Riprenderà dopo il box. Immagine:G-CAP10.jpg|Lo stesso brano visto in 1024: effettivamente nulla farebbe pensare a problemi del genere, se ci limitassimo a pensare a questa risoluzione. Ma ci sono risoluzioni più basse, però </gallery> <gallery> Immagine:G-CAP18.jpg|Altro genere di spezzatura del testo in 640, stavolta per l'incrociarsi di immagini allineate a destra e a sinistra Immagine:G-CAP11.jpg|Lo stesso brano in 1024 (ma non è entusiasmante nemmeno così..) </gallery> ---- *'''voce [[Camogli]]''' <gallery> Immagine:G-CAP4.jpg|In 1024 l'effetto potrebbe effettivamente essere gradevole, anche se in basso si intuisce che la sezione "geografia" è ristretta dal tocleft Immagine:G-CAP5_2.jpg|In 640 la poesia svanisce, e l'immagine troppo grande nasconde completamente il testo in tabella, sporgendo addirittura a destra Immagine:G-CAP6_2.jpg|Seguito della videata precedente, il tocleft manda il testo sul box, una parola per riga, col link modifica addirittura prima del titolo di sezione Immagine:G-CAP7_2.jpg|Seguito della videata precedente, il testo diviene comprensibile solo quando è finito il box. Se ci fossero delle immagini ordinariamente allineate a destra, chissà quando riprenderebbe </gallery> ---- *'''altre voci''' <gallery> Immagine:G-CAP10_2.jpg|incipit di [[Musica rinascimentale]] in 640: tocleft e template stringono il testo, che sfugge come può Immagine:G-CAP13.jpg|incipit di [[Carcere Mamertino]] in 640: appare evidente il nonsense di far procedere il testo in questo modo solo per aggiungere un tocleft </gallery> ---- ;Intervallo: {{lowres}} <small>Questo template si chiama <nowiki>{{lowres}}</nowiki> ed esiste dal luglio del 2006</small>

Principi

• WP è destinata non già a chi è privilegiato, ma a chi dobbiamo aiutare a raggiungere concetti senza spesa. Non trattandosi sempre di privilegiati, i nostri lettori potrebbero disporre di sistemi non all'avanguardia. Potrebbero dover usare vecchie macchine in uso nelle scuole o ricevute da qualcuno che stava per rottamarle. Possono dunque avere a disposizione SOLO macchine a bassa resa, poco veloci, a bassa risoluzione. Non è magari per loro volontà, ma potrebbero riuscire a vederci solo così
• Teniamo ben presente per chi facciamo tutto questo.
• Qui facciamo voci, raccogliamo concetti; a volte un concetto è necessariamente visivo, ma il più delle volte no. L'immagine è un "di più", un mero accessorio, non costituisce l'elemento più importante di una voce, è il testo che deve avere prevalenza sulle immagini e non viceversa
• Per i punti ora detti, le nostre pagine DEBBONO poter essere consultabili anche da chi abbia scarsità di risorse, quindi per favore, che nessuno se n'esca con argomenti del genere "ma ormai hanno tutti schermi grandi, ma chi è che oggi non ha... " etc.
• La pagina DEVE essere visibile in tutta la sua larghezza SENZA che il lettore debba scorrerla orizzontalmente (scrolling orizzontale), ma solo verticalmente; il contenuto della pagina non può quindi debordare lateralmente
• Per fissare una misura di compatibilità minima, ritengo opportuno tarare la compatibilità almeno con il 640x480. Cioè, con una larghezza di 640 pixel, che considerando i circa 160 pixel delle fascette a sinistra si riducono a circa 480 pixel "leggibili".

Proposte pratiche

1. eliminazione a vista di tutti i template TOCleft e TOCright che non abbiano davvero una fondata ragione di essere apposti
2. limitazione della larghezza delle immagini ad un massimo di 200px, cosicché, detratta la larghezza della barra dei link di sinistra, resti sufficiente spazio per il testo (tenendo presente che la cornice dei thumb sottrae altro spazio)
3. in mero subordine, laddove eccezionalmente vi siano particolari ragioni per avere maggiore larghezza, e laddove non vi siano interferenze con tabelle o box, si metta obbligatoriamente l'immagine centrata, il che consente al testo di riprendere dopo l'immagine senza sfilacciarsi e disperdersi in pagina; in ogni caso non devono superarsi i 450px per poter lasciare leggibile la pagina
4. spostamento a destra delle immagini: il tag "thumb|right|" consente infatti che esse si incolonnino compatte a lato l'una sopra l'altra, evitando tutti i problemi di incolonnamento testo e smarrimento dei link "modifica" delle sezioni. A parte l'armonia generale, e l'ordine nella pagina, sarà più facile tenere a mente come fare e spiegarlo ai nuovi
5. riduzione della larghezza dei box, a partire da quello dei comuni, eventualmente uso di caratteri small dentro questi template.
6. Iniziare la voce con la prima frase di testo, inserendo le immagini solo dopo il primo paragrafo ed allineate a destra, in modo che sia il testo a governare ciò che viene dopo e non il contrario
7. Tutto ciò che vorrete proporre per ristabilire una certa logica della nostra grafica...

Credo che tutti siamo qui per fare voci a favore di chi è meno privilegiato di noi; e credo che non siamo qui per fare i webmaster. Non ci spetta quindi fare pagine "creative", ma pagine che possano esser lette. Grazie anticipatamente della vostra collaborazione nel proporre ed attuare possibili miglioramenti del nostro lavoro :-) --g 08:11, 12 mar 2007 (CET)

Sono abbastanza d'accordo su tutta la linea (ricordo di averci sbattuto il nasone quando ho disegnato la pagina del Progetto:Omosessualità, la cui prima versione a basse risoluzioni diventava un disastro) e anche sulle proposte pratiche che indichi.

Potremmo prevedere in pagina di discussione della voce un avviso che segnali le pagine più stravolte a 800x600 e 640x480, in modo da poterle categorizzare e risistemare (nooo... un altro template di servizio noooo!!!' ;o) )

Una maggiore disciplina nell'uso delle immagini la caldeggio anch'io. Ci sono pagine di comuni che rischiano di diventare album fotografici e non più voci di enciclopedia. --Paginazero - Ø 08:29, 12 mar 2007 (CET)

Aggiungerei che non è solo un problema di hardware più o meno datato: gli utenti disabili, specialmente gli ipovedenti, ma non solo, usano basse risoluzioni per poter usufruire del web in generale e di WP in particolare. Vado subito a controllare le pagine che ho in watchlist :) (p.s. complimenti Gianfranco per il bel lavoro, così ben documentato) --Francesco (Discussione) 08:57, 12 mar 2007 (CET)

Sono abbastanza d'accordo anch'io su tutta la linea con Gianfranco, anche se - devo dire - ho la sensazione che i test effettuati con il browser Opera abbiano un valore relativo. Mi spiego meglio: ho la sensazione che Opera non sia fra i browser che meglio si adattano, nella resa grafica, all'impaginazione - per molti versi obbligata - delle pagine di Wikipedia. Comparo la pagina relativa a Camogli (non ricordo se da me impaginata): con FF la vedo benissimo; con Opera - in tutte le risoluzioni - crea dei problemi (con Opera quasi tutte le pagine in cui siano presenti box danno problemi). Da notare: FF - sulla medesima voce - sembra sopportare risoluzioni più basse. Adesso, io non voglio fare della propaganda a Firefox, però va detto che molti utenti (forse la quasi totalità) adoperano questo tipo di browser e su esso basano le impostazioni - favorite e invogliate dal wikisoftware - di impaginazione grafica delle pagine cui mettono mano. In definitiva: raccogliamo l'invito di Gianfranco a essere meno prodighi di quanto si sia stati finora in termini di orpelli grafici (i succitati tocleft e tocright, immagini in quantità, box e riquadri - che pure a mio avviso dovrebbero essere maggiormente utilizzati proprio in funzione di una maggiore scorrevolezza di consultazione - ecc. ecc.); però riprendiamo un po' a discutere sulla Wikipedia:Accessibilità del contenuto. Faccio notare che due soli portali su Wikipedia - il Portale:Bergamo e, sia pure in misura leggermente minore, il Portale:Genova - sono concepiti con un formato testo superiore alla media di quelli attualmente esistenti, appunto per favorire la consultazione da parte di chi possa avere problemi di vista. Si era parlato di estendere l'indicazione agli altri portali, poi non se ne è fatto più nulla. --Twice25·(disc.) 09:17, 12 mar 2007 (CET)

una precisazione: per brevità ho usato due macchine, ed ho usato Opera (ultimo update) per il 640 su una macchina con un 400mhz in W98 prima ed., data l'estrema pesantezza di FF su processori lenti, nei quali gli verrebbe comunque preferito IE o, per l'appunto, Opera che è più sciolto di IE. Forse avrei dovuto usare Opera anche sull'altra macchina, ma il rendering fra i due browser non è così diverso per gli argomenti di cui abbiamo trattato e ho fatto alla svelta. Ciascuno può cmq vedere se ci sono differenze passando ora ad Opera e confrontando la sua buona risoluzione in Opera con quella a 640 in Opera. I "bug" di Opera (ma magari sono i nostri) sono noti e riguardano altre cose, ad esempio i font nel prettytable o altre cose che non mutano di granché ciò che si intendeva evidenziare. Per inciso, sono problemi che sperimento personalmente su FF quando, ad es. in patrolling, lo tengo a finestra parziale sugli 850 pixel per vedere anche il VF o altri programmi. Su Camogli sinceramente sono curioso di capire come fai a vedere bene un'immagine da 450 con FF, o con qualunque browser, essendo questione di numeri: 450 + 160 = 610, cioè 30 pixel per il box salvi spazi fra elementi --g 09:55, 12 mar 2007 (CET)

Sono d'accordo con quanto afferma Gianfranco, anzi mi scuso per aver abusato di tale template per i comuni della Liguria da me seguiti. Finalmente è arrivata l'ora di darci delle regole sulle immagini, anche perché eravamo arrivati (parlo per i comuni liguri) a delle singole scelte di impaginazione. Penso che limitare le immagini a dx e 200px massimi sia la cosa migliore e più facile da spiegare agli eventuali utenti che mettono foto qua e la. Non sono tanto d'accordo con quanto afferma Paginazero, ossia che alcuni comuni stiano diventando album fotografici. Credo che dotare la voce di immagini sia importante per la comprensione immediata del testo e per arricchirlo ulteriormente. Fa piacere, secondo me, anche all'eventuale lettore ogni tanto staccare lo sguardo dal testo e rilassarsi con delle foto, specie se poi la voce è lunga. --Dapa19 ^(Scrivimi) 09:52, 12 mar 2007 (CET)

Non sono per niente d'accordo con quanto afferma Gianfranco (fatte salve le buone intenzioni). Il modo di ottenere la fruibilità a basse risoluzione non è peggiorare la grafica ad alte risoluzioni (come accade eliminando il tocleft per pagine in cui il toc è più lungo di quattro o cinque righe), ma - ad esempio - utilizzare appropriati css condizionali nel monobook (che ad esempio spengano il tocleft), o altre tecniche analoghe ben note nel campo della pubblicazione web. In dettaglio, praticamente tutti i problemi di usabilità/fruibilità - citati da Giancarlo hanno una soluzione tecnica appropriata che non è quella da lui proposta (cioè scrivere le pagine esplicitamente per una situazione tecnologica pre-1997, nel qual caso ci dovremmo anche preoccupare di Spyglass Mosaic e Cello) e il cui dominio infatti ricade nell'area di competenza dei web developer e non dei contributori all'enciclopedia.

In ogni caso, prima di iniziare campagne di modifica di massa, ancorchè benintenzionate,mi sembrerebbe il caso - per risparmiare il tempo di tutti, - di discuterne nei luoghi a ciò deputati. Anche perchè:

1. si tratta - al contrario dell'apparenza - di temi piuttosto specialistici
2. la cui soluzione, in termini di politiche, non credo possa essere presa dalla sola it.wiki nè da una sua frazione.

--alf · scrivimi 11:16, 12 mar 2007 (CET) (P.S.: Faccio notare, a margine, che le opinioni di Gianfranco sulla destinazione di WP sono in quanto tali POV, e quindi non automaticamente azionabili.)

Tanto per fare un po' l'integralista:

1. se non si vede bene con Opera, è la pagina che è scritta male, non Opera buggata.
2. Opera va benissimo per navigare su 'pedia (lo faccio da anni e ancora sono qui..)
3. viceversa Wikipedia non è FireFox-dipendente (dobbiamo veramente riaffrontare questo discorso?)
4. sul POV di Gianfranco sugli scopi di 'pedia.. consiglio di studiarsi un po' di storia di 'pedia ;-)
5. quali sono i luoghi deputati per discuterne?
6. se non implicano modifiche del software, le policy sono locali by def, non globali..

Frieda (dillo a Ubi) 00:41, 13 mar 2007 (CET)

Frieda,

fra locale e globale c'è anche il ... glocale ... ;-) - btw, il primo luogo deputato a cui si pensa in questi casi (è già stato scritto da qualche parte) è wikipedia:accessibilità del contenuto: dovrò aggiornare il mio Opera perché, oltre che lentissimo e ingabbiato nei reload di pagina, mi pare abbia un rendering (si dice così?) davvero poco wikisoddisfacente ... :)) --Twice25·(disc.) 01:36, 13 mar 2007 (CET)

Sostengo in toto Gianfranco. Credo che la possibilità di avere "belle" pagine ad alta risoluzione non deve inficiare la leggibilità a bassa risoluzione. Faccio inoltre presente ad alf che, nei casi in cui non sia strettamente necessario, la toc non dovrebbe essere forzata: chi lo desideri può tranquillamente modificare il proprio css, ma non vi è ragione di forzare tutti gli utenti ad avere una toca a sinistra.-- QWERTY  01:54, 13 mar 2007 (CET)

@Frieda:

1. Poichè si parla di schermi 640x480, tra i target browser dovrebbero quasi obligatoriamente esserci IE4 e Netscape 4.xx, e forse sarebbe saggio mettere in conto anche le vesioni precedenti (diciamo fino all'epoca di IE3, poco dopo la scoperta dell'America). Siccome neanche i web designer si tengono più installati i succitati polmoni, esiste ormai una grande quantità di codice scritto apposta per far sì che i server facciano un rendering appropriato al tipo di browser usato dal cliente, riducendo appropriatamente di molto la responsabilità di chi compila la pagina. E 15 anni di programmazione web dimostrano che - se si vuole e si hanno le competenze tecniche per farlo - si possono avere pagine belle ad alta risoluzione e accessibili a bassa risoluzione senza costringere gli autori a funambolismi tipo decidere tra tabelle e div a posizionamento assoluto (per non dire che questi ultimi, consigliati come strumenti di layout nella citata pagina sull'accessibilità al posto delle tabelle, non sono supportati dai browser di generazione precedenti alla quinta e anche in quelli assai male, a ulteriore dimostrazione che il tema è più complicatino di quello che generalmente si pensa).
2. Certo che va benissimo ma, ammettiamolo, la demografia di Opera non è travolgente.
3. Nulla da dire su firefox.
4. Accetto il rilievo storico (però...)
5. Anche il bar - ma magari farlo prima di intraprendere campagne di modifica di massa (sarebbe carino, no?). Anche perchè se tocleft non va più bene ci vuole un nanosecondo a toglierlo da tutte le pagine dove sta, senza farlo a mano (con i rollback che questo implica se poi si cambia idea, come a questo mondo capita). In questo caso penso poi che sarebbe meglio coinvolgere la parte tecnica del progetto, come spiegato più sotto).
6. Spero di aver convinto qualcuno che le implicano. E che se sono richieste politiche, queste sono da applicare quasi totalmente alla gestione dei template, che dovrebbe essere equiparata, non dico al codice del server, ma tenuta ad una stretta osservanza delle (erigende, mi pare di capire) regole di scrittura dei template. Così domani il tanto temuto tocleft potrà essere,con universale soddisfazione. scritto come:

if(hires) {
  floatTOC();
} else { //lowres
  TOC();
}

(NB: si può già fare oggi. Ma per motivi noti ai softwaristi, 'sta roba è meglio che venga coordinata, e non fatta a pene di levriero dal primo a cui salta l'uzzolo).

@Panairjdde: Spero di aver dimostrato che la possibilità di avere "belle" pagine ad alta risoluzione non deve inficiare la leggibilità a bassa risoluzione ma che entrambe si attuano senza costringere nessuno a cambiarsi il CSS (cosa che forse un utente di internet su 10 000 sa fare). Voglio anche fare notare che le pagine belle (aggettivo che non so bene perchè viene da alcuni virgolettato), sono perciò stesso spesso anche più leggibili (non necessariamente, è chiaro), e non vedo perchè (ma ipotizzo: senso di colpa?) si debba pregiudizialmente impedire a chi potrebbe una migliore fruizione. --alf · scrivimi 11:05, 13 mar 2007 (CET)

Proposte alternative

Condivido l'attenzione all'ergonomia, ma le proposte di soluzione non mi convincono e credo richiederebbero un gran lavoro per risultati modesti o per riscoprire progetti gia avviati come Wapedia.
Alcune proposte e considerazioni.

• Affiancare una versione per non vedenti

Affiancare alla wikipedia standard, una versione testuale ed a basso uso di template della wikipedia italiana, navigabile anche con browser testuali come lynx. E' un lavorone, ma se vogliamo fare una versione per non vedenti, e facilitare il lavoro dei software di lettura per ciechi, mi sembra la strada migliore. Non sarà l'adeguamento a 640x480 che migliorerà la situazione in questo caso.

• Suggerire in pagina principale agli utenti che usano una risoluzione di 640x480 di utilizzare la versione di WAPEDIA per palmari (http://pda.wapedia.mobi/it/)

Esiste, funziona piuttosto bene e risolve già automaticamente (lavora sul database aggiornato della wikipedia) molti problemi di visualizzazione per le risoluzioni inveriori.

• Rivedere il layout di mediawiki. Tornando alla wikipedia... Nell'analisi iniziale di questo thread si è dimenticato di includervi la colonna di navigazione. E non è affatto una questione da poco. La colonna a sinistra con i riquadri navigazione, comunità, strumenti, ruba spazio alle voci e non sempre è utile. Per esempio un lettore, una persona che non edita, non avrebbe alcun interesse ad usare la colonna strumenti, ben poco la comunità, e solo alcune voci del riquadro di navigazione. Ora io non so quanto è personalizzabile questa interfaccia. Se e' personalizzabile semplicemente agendo sui fogli di stile (e spero sia così) allora non sarebbe male pensare di aggiornarli (è intendo quelli generali) oppure di fornire una alternativa.

Attraverso le preferenze è possibile selezionare layout alternativi al monobook classico, alcuni di essi non hanno il menu di navigazione a fianco. --Paginazero - Ø 12:27, 12 mar 2007 (CET)

immaginavo una cosa del genere ed offre una soluzione, ma quanto praticabile?

• Si tratta di personalizzazioni raggiungibili solo andando a cercare nella pagina dei monobook e caricando un monobook alternativo.

• Tagliano fuori tutti gli utenti non registrati o non loggati.

Bisognerebbe agire rivedendo il monobook classico allora. Mi sembra la stessa questione venuta fuori per i colori delle pagine di modifica quando si discuteva dei template. La wikipedia francese usa dei colori pastelli blu e verdi dove noi usiamo un giallo-rosso per alcuni come me fastidioso agli occhi. Io ho aggiornato il monobook copiando il sistema francese, ma se non mi loggo ho di nuovo il giallo-rosso. Lo so che par una questione opinabile, ma in quell'altra wikipedia sta nel monobook generale e pure la wiki inglese è più lineare ed evita i colori accesi. Non credo che comunità di utenti più grandi per forza abbiano scelto soluzioni peggiori delle nostre. Le personalizzazioni poco ergonomiche dovrebbero essere riservati a chi le vuole. Qui nell'italiana abbiamo il contrario.

Tornando allo spazio per i contenuti: non sarebbe utile predisporre direttamente in homepage qualche variante creata con i fogli di stile? Non dico di diventare come CSSzengarden però offrire delle alternative tra cui qualcuna che ampi lo spazio dedicato ai contenuti non è male.

E precisando per lo spazio, i menu a me non danno neppure fastidio (uso 1280x1024, vedo bene le pagine), però non è neppure sbagliata ne l'idea di pensare alle altre risoluzioni, ne in fondo credo di dare più spazio ai contenuti visto che le pagine sono (giustamente perché anche una bella grafica migliora la leggibilità) sempre più elaborate.--Nanae 14:02, 12 mar 2007 (CET)

• Un layout dei menu di navigazione di wikipedia meno invasivo

Immaginiamo di avere come visualizzazione standard un riquadro di navigazione orizzontale di dimensioni ridotte posizionato al top della pagina e che mostri solo 5 opzioni: pagina principale, ricerca, vetrina, aiuto, menu esteso (per passare ad esempio all'interfaccia usuale) con l'ultima voce del riquadro di navigazione che permette di visualizzare il colonnone classico a sinistra.
Quanto spazio si guadagnerebbe, da dedicare ai contenuti delle voci sia che siano testo che immagini, eliminando la colonna di navigazione verticale? Circa 200 pixel. E' molto.

• Sull'utilizzo di hardware obsoleto

consideriamo che qualunque scheda video con 1mb di ram che era lo standard per i personal computer del 1994 visualizzava 1024x768x256 pixel e 800x600a65.000 colori. E' probabile che un hardware di 12 anni fa sia corredato di un monitor 14 pollici che dava il meglio di se con 800x600. Siamo sicuri che avremo anche nei paesi in via di sviluppo molte persone con hardware obsoleto e reciclato di questa età? Ok se le abbiamo 800x600 vanno bene.

Non è sbagliato il concetto di pensare all'utilizzo di prodotti obsoleti, ma qui si potrebbe aprire un parentesone, e penso a Lee Felsenstein e il suo sistema di alimentazione a pedali con pc-cube incastonato nel plexiglass (su cui gira linux) e che nonostante gli insuccessi iniziali, porta avanti in India; sull'inadeguatezza dell'hardware obsoleto in molti ambienti, ma sto divagando su questioni che non ci interessano...

• Le risoluzioni per la wikipedia

Mi azzardo a ipotizzare che 800x600 copra a mio avviso la stragrande maggioranza dell'hardware obsoleto effettivamente utilizzato oggi anche in una scuola di un villaggio in un paese in via di sviluppo.

Ma se vogliamo guardare a dispositivi come il prototipo da 100 dollari di Negroponte con schermo a 7,5 pollici (http://laptop.org/laptop/hardware/specs.shtml ) o come il cubo di Felsenstein sopra citato (che schermo ha? 10 pollici?), e vogliamo offrirgli non solo il testo,ma anche le immagini, il design o va riprogettato o li indirizziamo verso alternative come Wapedia

• Ottimizzazione a 800x600 della wiki attuale

Sono d'accordo per l'ottimizzazione a risoluzioni più basse (ma molti problemi imho sono dati sopratutto da un uso irrazionale di template più che dalla risoluzione) ma a mio avviso lo standard a cui riferisi può essere 800x600.
Per le ragioni sopradette, la risoluzione di 640x480 mi sembra invece veramente troppo bassa. Un adeguamento a questa risoluzione di una versione corredata di immagini e menu di navigazione non ha senso a mio avviso oltre che risultare complicato (molti pc recenti non hanno schede che scendono sotto 800x600 di risoluzione.). Sopratutto se poi come negli screenshot sopra si naviga pure con i browser attuali senza mandarli in full screen (F11).
Meglio dedicare a questa risoluzione direttamente una versione solo testuale e con caratteri grandi oppure offrire l'alternativa di un browser con un'interfaccia specializzata per navigare in wiki oppure ancora sponsorizzare la versione di wikipedia per i palmari.

• Per una interfaccia più ergonomica

Per calarmi nello spirito della discussione (e farmi del male :P) ho scritto queste note a 800x600 con Firefox in visualizzazione normale. Quanto è ridotta la finestrella di editing? Molto. Effettivamente questo thread ha centrato un problema (quello dell'ergonomia) e ringrazio g (anche se non condivido buona parte delle sue soluzioni) nell'averlo aperto perchè fa notare come l'intera impaginazione di wikipedia potrebbe essere molto migliorata in questo senso.

Dovremmo puntare a massimizzare l'area di editing e l'area di visualizzazione anche se già esistono alternative per dispositivi a bassa risoluzione. Il layout dovrebbe imho essere funzionale a queste due azioni: leggere e modificare. E agire sui contenuti non mi sembra essere la strada ottimale. E per contenuti intendo anche le immagini (non sempre orpello, ma a volte oggetto principale della voce: p.e. le voci sui dipinti). Diverso discorso per i template (quelli imho vanno ben razionalizzatii).

Dobbiamo agire sugli strumenti
Ciò che è davvero essenziale (pochi comandi in croce, i link alle licenze e il disclaimer che sarebbero anche più visibili e potrebbero essere ridotti di dimensioni se ci fossero meno elementi sullo schermo) dovrebbe rappresentare l'interfaccia standard. Le sezioni opzionali dovrebbero essere a scomparsa o pinnabili in modo da fissarle solo se e quando ci servono (tipo la toolbar o l'intera colonna di navigazione a sinistra). Ulteriori aggiunte demandate ai singoli via monobook utente. Questo accontenterebbe tutti. Uno potrebbe comunque avere una interfaccia ipercompleta di strumenti, ma garantirebbe di base una interfaccia semplice, lineare, ergonomica.
Non è facile da fare, ma a collaborare ad un progetto dedicato, io dico subito che ci stò. --Nanae 11:58, 12 mar 2007 (CET)

Il progetto esiste già e si chiama Wikipedia:Accessibilità del contenuto. Peccato che sia poco frequentato e che molti degli iscritti non siano più fra noi (lo scrivente si è depennato da tempo). E a proposito di monobook.js e css - generalizzati e personalizzati - : considerato che sono stati citati: essi comportano a mio avviso un rischio: che ciascuno scriva e si veda solo la propria personale Wikipedia ... Di javascript so poco (come anche di html del resto: oggi qui deprecato), però ho la sensazione che siamo ancora sotto .... l'anno zero. --Twice25·(disc.) 12:59, 12 mar 2007 (CET)

Credo che l'unica via praticabile sia stata citata da Twice, nel senso che il progetto Wikipedia:Accessibilità del contenuto deve necessariamente farsi referente di queste problematiche e "emanare" direttive, il più condivise possibile nat, ma precise. Spesso nascono ottime indicazioni da questi progetti, il più delle volte inevase o uccise nella culla. Cito l'esperienza sull'uniformazione dei template di navigazione geografica che è partita ma non decollata, ma tanti sono gli esempi.--ILLY⁷⁸ · ^{「Scrivimi...」} 13:12, 12 mar 2007 (CET)

Dò la mia adesione a chi più sopra ha detto che la soluzione va cercata a livello di tool, non al livello di ulteriori policy più o meno brillantemente inventate (e foriere di chissà quali complicazioni future). Per chiarire (e magari mi perdo l'inclita per strada, ma questa è la natura della discussione). Già adesso le pagine sono scritte con un markup che è quasi integralmente server-side (tali sono il wiki code, e i template). Questo significa che il server può creare versioni di pagine indipendenti da browser e risoluzione sempre tranne nei casi dove si è usato esplicitamente e in forma libera l'HTML (cosa che va scoraggiata dopo avere chiarito cosa è forma libera e cosa no). Com'è che questo risolve il problema? Prendiamo il tocleft che tanto sconcilia gianfranco: in questo caso basta scrivere il template in modo che al disotto di una certa risoluzione, l'effetto di float left non venga più applicato. Questo non solo richiede forse 12 righe di codice, non solo è meno laborioso e più razionale che andare a togliere il tocleft da tutte le pagine dove si trova dopo aver valutato se è appropriato o no (dando nel frattempo la stura a migliaia di liti, blocchi, ban, e via discorrendo), mi dà anche il servizio addizionale di poter effettivamente spegnere il float per tutti i browser che non lo supportano (che include la stragrande maggioranza di quelli che ancora girano su macchine con hardware a 800x600). Le immagini possono essere servite a risoluzione diversa o perfino spente, sempre in maniera condizionale, sempre server side. (Fra l'altro anche solo con i CSS si possono fare molte di queste cose - forse qualcuno avrà notato che il link di stampa spegne i tocleft). Questi sono tutti problemi ben noti la cui soluzione (specie per un sito semplice come WP) è altrettanto nota e non implica lo sbudellamento del look a risoluzioni 1024 e superiori: richiede invece il coinvolgimento dei developer e la riscrittura in maniera compliant dei template in uso. Il che significa coinvolgere alcune decine di persone per fare quello che sanno fare meglio, invece che cercare di persuaderne svariate centinaia a fare (tramite policy) cose di cui sanno e capiscono poco e di cui soprattutto non gli potrebbe interessare meno. --alf · scrivimi 13:56, 12 mar 2007 (CET)

mi sembra la strada migliore quella che prospetti. Consiglio pero' anche di rivedere il monobook classico, dato che gli utenti non registrati non possono personalizzarlo purtroppo, con un occhio maggiore all'ergonomia come grafica e colori e ad aumentare lo spazio per le voci, magari permettendo di selezionare direttamente dalla pagina principale due o tre varianti di stile, tra cui anche una versione essenziale dell'interfaccia di navigazione.--Nanae 14:15, 12 mar 2007 (CET)

Condivido quanto scritto da Alf. Oltre al coinvolgimento dei developer cmq ci vorrebbe maggiore controllo e centralizzazione dei template. Io ne ho inseriti un po' e quando lo faccio sono sempre combattutto tra esigenze diverse. Bellezza grafica, usabilità e uniformità rispetto a quanto gia fatto da altri. I template invasivi sono spesso criticati eppure permettono una consultazione del materiale che non ha eguali. Sono molto utili anche per realizzare nuovi articoli e fanno risparmarie un sacco di tempo. Molte volte ti sbatti per fare un template cerchi di usare colori neutri e poco invasivi poi arriva qualcuno che modifica e passa ai colori vistosi. In certi casi la scelta non è ragionata e porta all'impossibilità di distinguere i wikilink dallo sfondo (e i developer non possono nulla contro chi non capisce che se metti del testo blu sopra a uno sfondo blu fai una cretinata). Riguardo a questo ci dovrebbero essere regole più ferree e indicazioni meno ambigue. Mi auguro che per salvaguardare il diritto di lettura dei 600x480 non venga buttato all'aria tutto il lavoro svolto dalle gente che si occupa dei template di navigazione (trovo inquietante discorsi del tipo cancellazione a vista). Certo la cosa piu' importante è l'articolo ma wiki è un'enciclopedia ipertestulae sarebbe stupido non approfittare della cosa. Imho sarebbe ora che i template non fossero più il territorio di frontiera che sono stati fino ad oggi in cui ognuno di noi fa un po' come gli pare. Per le immagini vale piu' o meno lo stesso discorso. Il problema e che spesso quando vai nei bar tematici per chiedere consigli circa i template non ottieni risposte, oppure le ottieni dopo settimane o mesi. Occuparsi di template su wiki è spesso frustrante non aumentiamo ulteriormente la cosa--Contezero 15:48, 12 mar 2007 (CET) P.S. Non sarebbe male a mio avviso proteggere tutti i template. In modo che se modifichi prima di farlo lo devi chiedere e visto che ci sei spieghi quello che vuoi fare e quali vantaggi porteranno le modifiche da te apportate--Contezero 15:56, 12 mar 2007 (CET)

Condivido le parole di Gianfranco sul fatto che dovremmo sempre ricordarci per chi stiamo scrivendo l'enciclopedia. Mi sento anche un po' in colpa per aver inserito negli ultimi giorni un centinaio di immagini, tutte rigorosamente allineate a sinistra e a 250px (es. Castrisch e Brando). L'allineamento a destra, per i comuni, è un problema, perché a destra c'è già la tabella. Se la voce è molto breve (tipico dei comuni, soprattutto non italiani), l'immagine a destra allunga la pagina che è in gran parte bianca, il che può non piacere a chi vuole stampare la pagina. Avere anche solo la possibilità di allineare l'immagine alla tabella (e non solo ai margini dx e sn o al centro) sarebbe un miglioramento. Per quanto riguarda la barra dei link laterale, sarebbe utile avere un tasto che permetta di modificare il monobook con uno in cui la barra stia sotto. Questo soprattutto per il lettore che non ha interesse a scrivere, ma a leggere bene. Cruccone (msg) 18:18, 12 mar 2007 (CET)

post scriptum

«WP è destinata non già a chi è privilegiato, ma a chi dobbiamo aiutare a raggiungere concetti senza spesa. Non trattandosi sempre di privilegiati, i nostri lettori potrebbero disporre di sistemi non all'avanguardia. Potrebbero dover usare vecchie macchine in uso nelle scuole o ricevute da qualcuno che stava per rottamarle. Possono dunque avere a disposizione SOLO macchine a bassa resa, poco veloci, a bassa risoluzione. Non è magari per loro volontà, ma potrebbero riuscire a vederci solo così»

(.)

era tutto molto interessante, e non sto facendo ironia o polemica o scherzando o altro, ma quando sono arrivata alla frase succitata ho smesso di capire qualcosa...sarà l'ora tarda, saranno le 12 ore di lavoro sulle spalle, chissà, ma anche le discussioni lunghe eoni o yottametri che dir si voglia sono un po' controverse, poco fruibili, poco leggibili, poco comprensibili, a un certo punto si perdono nel loro senso e vanno a finire nel solito OT. ripeto, non so nemmeno chi sia l'autore dell'intervento iniziale, che è tecnicamente molto utile e buono. adesso torno in alto, dopo aver salvato, e cerco di finire di leggere e ve lo dice una che avrebbe potuto dire solo "troppo lungo, tagliare" e invece ha già scritto 10 righe almeno... --jo 02:03, 13 mar 2007 (CET)