[Archivio] - [Documenti] - [Home]
Queste note su alcuni passi del libro di Sofia Postai sono più degli spunti di riflessione che un tentativo di disamina critica. Non mancano tuttavia delle aggiunte laddove la necessità di un'approfondimento è particolarmente evidente.
Anche se in questi ultimi anni i browser sono stati concepiti in modo da attenuare le differenze tra i vari sistemi e la conseguente visualizzazione delle pagine, questo sintetico elenco basterà a capire che la strada da percorrere non è quella di "bloccare" le pagine (secondo il "pregiudizio della carta") ma piuttosto quello della progettazione fluida.
- pag, 4
(Segue l'elenco degli elementi di variabilità, suddivisi in variabilità hardware e software)
1. Dal 2003, anno in cui Sofia ha scritto il libro, i cambiamenti nel mondo del Web sono stati notevoli. A livello di browser, tuttavia, le cose sono rimaste sostanzialmente le stesse, se consideriamo solo l'aspetto della rivalità tra browser come Internet Explorer (IE), Firefox ed Opera. Questa rivalità ha sostanzialmente accentuato le differenze piuttosto che attenuarle: IE ha scelto la strada delle tecnologie proprietarie, non riuscendo di fatto a risolvere problemi come hasLayout, mentre Firefox ed Opera si sono impegnati sul fronte del supporto agli standard del W3C, anche se a volte in modo confuso. Se infatti da un lato abbiamo un browser pieno di bug che costringe spesso gli autori a creare fogli di stile ad hoc, dall'altro abbiamo dei browser sostanzialmente standard compliant, ma con un supporto di proprietà non ancora ufficiali e riconosciute o addirittura estensioni proprietarie (si vedano le estensioni con prefisso -o e -moz, oppure proprietà come 'opacity' e 'box-sizing'), che sicuramente contribuiscono a generare confusione tra gli autori. La rivalità sopracitata riduce la possibilità di migliorare l'interoperabilità con il conseguente rallentamento nello sviluppo del Web.
A proposito del "pregiudizio della carta" di cui parla Michele Diodati occorre fare una precisazione: non sempre è un errore in cui precipitano gli autori, quanto piuttosto un radicato convincimento da parte dei committenti. Chi per esempio proviene dal mondo dell'editoria, spesso non coglie la differenza tra il Web (media dinamico) e la stampa (media statico), non tanto per ignoranza, quanto piuttosto per una "priorità ontologica" della carta sul Web. In altre parole, il Web e il mondo della carta stampata hanno in comune solo i contenuti, non il modo in cui essi vengono presentati.
Per quanto riguarda le versioni dei browser, e soprattutto di IE, invece, le differenze sono abissali. Explorer per PC ed Explorer per Mac sono browser nettamente differenti. Explorer 5 per Mac, al momento del lancio, era un browser ricco di prestazioni innovative (come la posssibilità di ingrandire il testo fino al 300%) che nemmeno IE 6 per PC attualmente ha. Inoltre, per esempio, il baco nel rendering del box model CSS, che Explorer per PC ha corretto solo nella versione 6, su Explorer per Mac non c'è mai stato.
- pag, 7
2. In realtà la situazione è più complessa. IE5 per Mac presentava una vasta collezione di bug, ottimamente sintetizzata su http://www.l-c-n.com/IE5tests/. Nell'articolo Internet Explorer 5 Mac: oddities troviamo alcuni filtri (o hack) per IE5 Mac. Per ulteriori approfondimenti, si consultino i test di Bruno Fassino.
La fruizione del Web è strettamente individuale e segue percorsi di "interesse" relativi ai contenuti.
- pag. 14
3. Quando uscì CSS Zengarden si sentì un ohh di meraviglia. Credo che alcuni pensassero davvero che con i CSS si potessero creare quegli effetti strabilianti. In realtà, la proprietà più usata in Zengarden è 'background'. Tutto il resto lo fa l'uso artistico di Photoshop. In Zengarden non c'è traccia di contenuto generato o di proprietà sperimentali come 'opacity'. Da un punto di vista del design fu sicuramente un gigantesco passo in avanti, ma sotto l'aspetto dello sviluppo dello standard dei fogli di stile costituisce tutt'oggi un pericoloso esempio di prevaricazione della presentazione sul contenuto. Da allora le strade degli autori e degli sviluppatori di standard si sono pericolosamente divise: gli autori hanno cominciato ad usare ossessivamente solo alcune proprietà CSS, ricadendo di fatto nello stesso errore di chi abusava delle tabelle. Sviluppatori come David Baron hanno invano cercato di avvertire gli autori della pericolosità di quella ubriacatura estetica, che fossilizzava gli standard in un insieme ridotto di caratteristiche. In fondo, se le proprietà più usate servono solo per piazzare immagini grandiose come sfondo degli elementi, che senso hanno, ad esempio, le proprietà relative al contenuto generato o quelle dei fogli di stile acustici? Se è vero che in fondo l'ossatura del Web si basa sui contenuti, perchè non cercare un punto di equilibrio tra presentazione e contenuto? Purtroppo in questo binomio si inseriscono le richieste del committente/cliente, troppo spesso figlio di quella cultura televisiva che piazza le telecamere sotto le gonne delle ballerine e zittisce lo scrittore perchè non fa audience.
La cosa più importante di qualsiasi sito web è il suo contenuto. Può trattarsi di testi, immagini, filmati, musica, interattività. Può essere informazione, utilità, servizio, ricerca, interrelazione personale. C'è sempre, comunque, un motivo per cui le persone arrivano a un sito. L'apparente casualità della navigazione non è mai così casuale come potrebbe sembrare.
- pag. 24
4. Il Web è agnostico sul contenuto. Venendo da un tipo di navigazione basata esclusivamente sulla ricerca di contenuti testuali (al limite qualche immagine per il desktop) in siti prevalentemente universitari o comunque ruotanti intorno all'àmbito della cultura, faccio molta fatica ad accettare questa eterogeneità di fondo. Ma, come si è detto in precedenza, il Web è un'esperienza sostanzialmente individuale, e quindi, paradossalmente, la singola esperienza non può descrivere la totalità delle esperienze di navigazione. Tuttavia, se queste esperienze si assommano e si amalgamano, si giunge al successo di un sito. La matematica, in questo caso la statistica, ha sempre l'ultima parola.
Un testo può (anzi deve) essere lungo quanto serve per spiegare l'argomento. Le frasi e i periodi devono però essere brevi. Dobbiamo spezzettare il testo in atomi di lettura non più lunghi di metà della finestra a disposizione.
- pag. 31
5. Il Web deve formare o informare, far pensare o divertire? Come ogni sistema logico complesso, il Web non riesce a dimostrare la propria coerenza. Da qui il bisogno di un contenuto flessibile, agnostico, finalizzato ad un determinato target. Quanto deve essere lungo un testo che descrive la propria vita? Quanto basta a spiegare l'argomento. Si può spiegare una poesia in mezza videata? In una videata? Due? Come autori web lo sappiamo, come esseri umani no.
Ciascuna frase deve contenere un concetto. Il testo deve essere chiaro e concreto. Dobbiamo evitare qualunque retorica autocelebrativa. Le retoriche del Web sono altre: più easy, veloci, orientate all'utente. Evitate le frasi che suonano bene e non dicono niente. Sono controproducenti anche nella comunicazione tradizionale, ma sul Web diventano letali.
- pp. 33-34
6. Questo deve ovviamente essere riferito al contesto particolare del sito e al pubblico di destinazione. In un sito letterario, ad esempio, ci si aspetta che il livello dei contenuti sia in sintonia con il pubblico al quale ci si rivolge. Certo, è sempre possibile che un frequentatore abituale di siti pornografici legga con interesse un articolo sulle rivendicazioni femministe dei primi anni del '900, ma, consentitemi, è poco probabile. Easy e veloce mal si adatta ad un sito che invita invece alla riflessione sull'uomo e sulla società.Tuttavia, adottare una mentalità incentrata sull'utente è sempre consigliabile. La domanda è: quale tipo di utente?
7. Come autori e sviluppatori di siti Web, dobbiamo anche noi, come Machiavelli, indossare una veste diversa allorchè ci dedichiamo ad un sito. Dobbiamo essere, in altre parole, altre persone. Dobbiamo comprendere l'altro, il diverso, quello che di solito non rientra nei nostri schemi. Se abbiamo deciso di lavorare sul Web, dobbiamo assumerne la forma mentis, ossia il totale agnosticismo. Il Web è agnostico sull'utente, poichè si parla di accesso universale alla Rete. Il Web, nella sua globalità, si rivolge a tutti. Un sito, invece, nel suo essere microcosmo nel macrocosmo della Rete, ha una sua tipologia di utenti. Spesso questa tipologia non rientra nei nostri schemi. Abbiamo quindi due possibilità: rinunciare al lavoro o accettare di confrontarci con qualcosa che non conosciamo. Per esempio, io mi occupo prevalentemente di siti a carattere culturale, quindi la mia tipologia di utenti è diversa da quella di un autore che sviluppa siti per lo scambio di MP3 o di immagini. Se mai dovessi decidere di intraprendere un'altra strada, dovrei necessariamente acquisire nuove competenze, rimettermi in gioco. E ricominciare. - pp. 74-75
La più importante: le parole sottolineate sono link, le parole non sottolineate non sono link.
- pag. 110
8. Qui viene posto implicitamente anche un problema di conflitto presentazionale. Nell'
HTML esiste infatti l'elemento
INS, che marca un inserimento di testo aggiuntivo. Per impostazione predefinita, e secondo il
foglio di stile per l'HTML 4, tale elemento
viene rappresentato come sottolineato. Questo crea un conflitto presentazionale con i collegamenti
ipertestuali, che di norma sono sempre sottolineati dal browser. Personalmente, ritengo che un'altra
caratteristica fondamentale di un collegamento ipertestuale sia la comparsa di un puntatore diverso nell'interfaccia
del browser (la classica "manina"). Molto spesso ci si accorge dell'ipertestualità di un elemento
proprio da questa sua peculiare caratteristica. Non penso che la sottolineatura debba essere imposta
de facto, in quanto essa, come già detto, non è la sola caratteristica di un collegamento
ipertestuale a livello visivo. Certo, è più semplice identificare un collegamento ipertestuale
a prima vista, ma che dire di un documento in cui l'autore ha anche inserito un elemento INS senza modificarne
l'aspetto predefinito? Più che di regole non scritte, io parlerei di pratiche consigliate ma mai, comunque,
imposte come standard.
9. Sul conflitto (presunto) tra fogli di stile ed usabilità, credo che occorra fare
una precisazione. A mio avviso tale conflitto non esiste. Portare come esempio la "pericolosità"
(anche Sofia usa giustamente le virgolette) delle modifiche apportate, poniamo, ad un modulo (form), semplicemente
non ha consistenza tecnica. Infatti, il foglio di stile per l'HTML 4, già citato, non definisce l'aspetto
predefinito dei moduli. Si limita semplicemente a dichiarare 'display: inline-block' ad esempio per l'elemento
INPUT, senza fare alcun riferimento alla sua resa a video. Quello che vediamo nei browser
è semplicemente una convenzione accettata de facto (non uno standard). Per esempio Firefox, nel suo
foglio di stile predefinito, assegna un bordo rientrato pari a 2 pixel all'elemento INPUT, dandogli
poi un colore di sistema. Internet Explorer ha un comportamento vagamente simile, mentre Opera applica invece
la sua skin ai bottoni per l'invio dati. Gli autori sono liberi di cambiare l'aspetto dei moduli, perchè
esso non è definito in nessuno standard.
Un modulo per l'invio dati in genere è costituito
da un campo di testo e da un bottone per l'invio effettivo. Ora, se anche il colore e la forma di questi elementi
venissero cambiati con i fogli di stile, vi sono altri elementi testuali che spiegano all'utente che quel "coso" serve ad una determinata funzione. Se io infatti uso l'elemento LABEL e vi scrivo
"Inserisci i dati", e poi come valore dell'attributo value per
l'elemento INPUT specifico "Invia", non
credo che ci dovrebbero essere dei problemi per l'utente. C'è di più: a livello di accessibilità,
credo che i riferimenti testuali siano più importanti di quelli semplicemente presentazionali, in quanto un
non-vedente, per esempio, non sa cosa farsene dell'aspetto di un modulo, ma certamente trae beneficio dalla corretta
semantica usata nella scrittura del codice. Il problema a mio avviso risiede più nella corretta etichettatura
di un modulo e nella sua posizione nel contesto della pagina, piuttosto che in un abuso dei fogli di stile.
- pag. 202