Vai ai contenuti

LAU



Home > progettare > usabilità: la progettazione utente-centrica > Palmari e verticalitā dei contenuti


Palmari e verticalità dei contenuti

Alcune trasformazioni strutturali utili per evitare la perdita indesiderata di informazioni nel corso della progettazione di siti web per palmari.

a cura di: Mario Picarelli | 7 luglio 2006



1. Introduzione

La scelta di progettare siti dedicati per palmare comporta il rischio di contravvenire a un principio cardine dell'accessibilità: l'indipendenza del contenuto dal dispositivo.

Gianluca Affinito [link esterno] sintetizza la questione in queste righe:

A causa dei limiti fisici di questi dispositivi, la soluzione più diffusa finora è stata quella di realizzare una versione "ottimizzata" per palmari, come nel caso del sito della RAI o delle Pagine gialle. Questa scelta nasce dalla considerazione che al cambiamento del mezzo di fruizione si modificano anche i requisiti di usabilità e debba quindi corrispondere una modifica dell'interfaccia in termini di quantità di informazione presentata; questo significa però realizzare un sito ad hoc per palmari e quindi un sito parallelo mentre un sito dovrebbere essere indipendente dal dispositivo di fruizione [.] Il "rischio" di questi siti è di presentare solo una parte dei contenuti e delle funzionalità disponibili nella versione "normale" per PC.

Il rischio, in sintesi, è che l'integrità dei contenuti venga compromessa a causa delle caratteristiche del dispositivo, laddove invece la quantità di informazione andrebbe preservata a prescindere da queste caratteristiche.

Ma se, da una parte, occorre ridurre la perdita indesiderata di informazione, aggirando eventualmente i limiti del device (approccio "accessibilista"), d'altra parte, però, non si può trascurare di conformare l'informazione alle modalità d'uso specifiche del device (approccio "usabilista").

Conciliare le due esigenze non è sempre facile, tant'è che il dibattito sulle pratiche di progettazione per palmari, piuttosto che vertere sulle possibilità di compromesso tra i due approcci, gravita spesso intorno all'aut-aut: siti dedicati o siti ricavati.

Le stesse Mobile Web Best Practices 1.0 [link esterno] proposte dal W3C, attualmente allo stato di Candidate Raccomandation, presentano una certa ambiguità su questo tema.
Nel paragrafo 3.1 [link esterno], si prescrive di

[...] rendere disponibili agli utenti, nei limiti del ragionevole, la stessa informazione e gli stessi servizi a prescindere dal dispositivo che utilizzano. [...]

ma poco oltre viene precisato che

[...] Questo comunque non vuol dire che la stessa identica informazione sarà rappresentata esattamente nella stessa maniera in tutti i dispositivi. [...]

Quindi, non "la stessa identica informazione".

Tuttavia, c'è una sottile differenza tra adeguare i contenuti ed essere costretti a sacrificarli: se si ritiene che una certa informazione è essenziale, bisogna provvedere, "per quanto ragionevole" affinchè non vada perduta nel corso della sua "traduzione" per i vari dispositivi.

A questo scopo, può essere utile ricorrere a modifiche strutturali (XSLT) oltre che presentazionali (CSS): nel presente articolo, illustrerò un paio di questi casi.

Il problema da cui prenderò le mosse è il seguente: le dimensioni ridotte dello schermo del palmare potrebbero comportare un uso eccessivo, scomodo e dispersivo dello scrolling.
Come evitarlo garantendo al contempo l'integrità dei contenuti?

torna su


2. Tabelle vs elenchi

La consultazione di tabelle su palmare spesso obbliga allo scorrimento orizzontale: assolutamente da evitare.

Le Mobile Web Best Practices 1.0 [link esterno] si esprimono così a proposito dell'uso delle tabelle:

5.4.4 Tables

[TABLES_SUPPORT] Do not use tables unless the device is known to support them.

[TABLES_NESTED] Do not use nested tables.

[TABLES_LAYOUT] Do not use tables for layout.

[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.

Traduzione:

5.4.4 Tabelle

[SUPPORTO TABELLE] Non usare tabelle a meno che non si sia sicuri che il dispositivo le supporti.

[TABELLE ANNIDATE] Non usare tabelle annidate.

[TABELLE PER IL LAYOUT] Non usare tabelle per il layout.

[ALTERNATIVE ALLE TABELLE] Dove possible, ricorrere ad un'alternativa alla presentazione tabulare.

Una valida alternativa alle tabelle possono essere gli elenchi, che tendono a dipanarsi verticalmente piuttosto che orizzontalmente, adeguandosi meglio alle dimensioni dei palmari.

Ma per compiere una simile "traduzione" strutturale va innanzitutto ripensato il rapporto tra record, campi e valori.
Per esemplificare, si prenda come punto di partenza un documento XML strutturato in questo modo:

<dati>
 <dato id=”record1”>
  <descrizione etichetta="campo1" 
valore="record1:campo1" />
  <descrizione etichetta="campo2" 
valore="record1:campo2" />
  <descrizione etichetta="campo3" 
valore="record1:campo3" />
 </dato>
 <dato id="record2">...</dato>
...
</dati>

Con un foglio di stile estensibile si può trasformare questo sorgente in una tabella XHTML.

<xsl:template match="/dati">
 <table>
  <tr>
   <th></th>
   <xsl:for-each select="dato[1]/descrizione/@etichetta">
   <th scope="col"><xsl:value-of select="." /></th>
   </xsl:for-each>
  </tr>
   <xsl:for-each select="dato">
  <tr>
   <th scope="row"><xsl:value-of select="@id" /></th>
   <xsl:for-each select="descrizione">
    <td><xsl:value-of select="@valore" /></td>
   </xsl:for-each>
  </tr>
   </xsl:for-each>
 </table>
</xsl:template>

Il template seleziona e manda in output i valori dell'attributo etichetta degli elementi descrizione del primo nodo dato , ricavando le celle di intestazione della prima riga di una tabella.
Il successivo ciclo di for manda in output per ciascun dato il valore dell'attributo id e per ciascuna descrizione del dato il valore dell'attributo valore, ricavando il corpo della tabella.
Il risultato è il seguente:

<table>
<tr>
<th scope="col"></th>
<th scope="col">Campo1</th>
<th scope="col">Campo2</th>
<th scope="col">Campo3</th>
</tr>
<tr>
<th scope="row">Record1</th>
<td>record1:campo1</td>
<td>record1:campo2</td>
<td>record1:campo3</td>
</tr>
<tr>
<th scope="row">Record2</th>
...
</tr>
...
</table>

Una simile formattazione è adatta per un PC browser, ma non per un dispositivo palmare: come si nota in figura, la tabella obbliga ad un fastidioso scrolling orizzontale.

Immagine raffigurante lo scrolling orizzontale causato dall'uso di una tabella in una pagina su palmareFig. 1
Visualizzazione su pIE della trasformazione in tabella.

La stessa struttura XML di base può essere formattata come un elenco: ciascun record può assumere la funzione di elemento lista, e ciascun elemento lista può snodarsi a sua volta nell'elenco delle coppie campo-valore che definiscono i record.

Si consideri la seguente trasformazione:

<xsl:template match="/">
<ul>
<xsl:for-each select="dato">
<li><xsl:value-of select="id" />
<ul>
<xsl:for-each select="descrizione">
<li>
<strong><xsl:value-of select="@etichetta" /></strong>: <xsl:value-of select="@valore" />
</li>
</xsl:for-each>
</ul>
</li>
</xsl:for-each>
</ul>
</xsl:template>

Il template manda in output come elementi lista il valore dell'attributo id di ciascun dato e, per ciascun dato, genera un sotto-elenco contenente il valore degli attributi delle descrizioni (etichetta e valore).

Il risultato è una sorta di "linearizzazione" della tabella precedente:

<ul>
 <li><strong>Record1</strong>
  <ul>
   <li><strong>Campo1</strong>: record1:campo1</li
   <li><strong>Campo2</strong>: record1:campo2</li>
   <li><strong>Campo3</strong>: record1:campo3</li>
 </ul>
 </li>
 <li><strong>Record2</strong>
...
 </li>
...
</ul>

Come si nota in figura 2, a differenza della tabella, l'elenco non necessita di scrolling orizzontale.

Immagine raffigurante la trasformazione in elenco da tabella in una pagina visualizzata da palmareFig. 2
Visualizzazione su pIE della trasformazione in elenco.
La barra di scorrimento orizzontale non è più necessaria

È facile notare che le due soluzioni, sebbene conservino entrambe l'informazione originaria, non si equivalgono del tutto.
Nell'elenco è stato necessario ripetere per ciascun record il nome dei campi per compensare la perdita dell'informazione circa il rapporto campo-valore esplicitato nella tabella mediante l'attributo scope delle celle di intestazione.
Ma, si sa, ogni "traduzione" implica inevitabilmente una seppur minima percentuale di "tradimento".

torna su


3. Variazioni dell'ordine di successione

È pratica diffusa nella progettazione di pagine Web collocare il menu prima della sezione dei contenuti.
Su palmare, una simile soluzione può rivelarsi scomoda e disorientante, costringendo l'utente (che si presume interessato principalmente ai contenuti, non alle opzioni di navigazione) a scorrere verticalmente il menu per pervenire all'informazione desiderata.
Un link "skip navigation" risolverebbe il problema, permettendo di "saltare" con un click il menu "atterrando" direttamente ai contenuti. Ma rimarrebbe pur sempre disattesa la ragionevolissima aspettativa dell'utente di ottenere subito, ad apertura pagina, l'informazione desiderata.
A questo proposito, le "Mobile Web Best Practices 1.0 [link esterno]" consigliano di porre in primo piano i contenuti e di limitarsi a barre di navigazione minimali ad inizio pagina (breadcrumbs, per esempio).

5.2.2 Navigation Bar

[NAVBAR] Provide only minimal navigation at the top of the page.

Traduzione:

5.2.2 Navigation Bar

[BARRA DI NAVIGAZIONE] Fornire soltanto una barra di navigazione minimale in alto nella pagina.

5.3.4 Navigation Bars etc.

[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.

Traduzione:

5.3.4 Barre di navigazione etc.

[SIGNIFICATO CENTRALE] Assicurarsi che il materiale che è centrale per il significato della pagina preceda il materiale che non lo è.

Progettando interfacce per palmari, in certi casi può tornare utile contravvenire alla consolidata pratica di anteporre il menu ai contenuti, semplicemente invertendo il loro ordine di successione.
Si consideri questa struttura XML

<pagina>
<intestazione>Titolo</intestazione>
<menu>
<voce>pagina 1</voce>
<voce>pagina 2</voce>
<voce>pagina 3</voce> ...
</menu>
<corpo>
<titolo>Sezione contenuti</titolo>
<contenuti>…</contenuti>
</corpo>
</pagina>

È sufficiente stabilire nel modello radice dell'XSLT l'ordine delle chiamate ai template:

<xsl:template match="/pagina">
<html>
 <body>
  <h1>
   <xsl:value-of select="intestazione" />
  </h1>   
  <xsl:call-template name="menu" />
  <xsl:call-template name="contenuto" />
 </body>
</html> </xsl:template>

Il template manda in output come h1 il valore dell' intestazione, e richiama questi due modelli:

<xsl:template name="menu">
<ul id="menu">
<xsl:for-each select="menu/voce">
<li> <a href="#"><xsl:value-of select="." /></a> </li> </xsl:for-each>
</ul>
</xsl:template>
<xsl:template name="contenuto">
 <div id="contenuto">
  <h2>
   <xsl:value-of select="corpo/titolo" />
  </h2>
  <p>
   <xsl:value-of select="corpo/contenuti" />
  </p>
 </div>
 <hr /> 
</xsl:template>

Il modello "menu" seleziona gli elementi voce dell'elemento menu, ricavandone una lista non ordinata; il modello "contenuto" trasforma l'elemento corpo in un div con titolo e paragrafo.
Risultato della trasformazione:

<h1>Titolo</h1>
<ul id="menu">
<li><a href="#">pagina 1</a></li> ...
<li><a href="#">pagina 6</a></li>
</ul>
<div id="contenuto">
<h2>Sezione contenuti</h2>
<p>...</p>
</div>

Immagine raffigurante un menu anteposto ai contenuti in una pagina visualizzata da palmareFig. 3
Visualizzazione su pIE della trasformazione. Menu anteposto ai contenuti.

Per ricavare dal medesimo sorgente XML una versione ottimizzata per palmare, con contenuto anteposto al menu, è sufficiente invertire l'ordine delle chiamate ai template.
Vediamo un esempio:

<xsl:template match="/pagina">
<html>
<body>
<h1> <xsl:value-of select="intestazione" /> </h1> <xsl:call-template name="contenuto" />
<xsl:call-template name="menu" />
</body>
</html>
</xsl:template>

Risultato:

<h1>Titolo</h1>
<div id="contenuto">
<h2>Sezione contenuti</h2>
<p>...</p>
</div>
<ul id="menu">
<li><a href="#">pagina 1</a></li> ...
<li><a href="#">pagina 6</a></li>
</ul>

In questo modo, ad apertura pagina, l'utente ha modo di prender subito visione di titolo e contenuti.

Immagine raffigurante contenuti anteposti al menu in una pagina visualizzata da palmareFig. 4
Visualizzazione su pIE della trasformazione. Contenuti anteposti al menu.

torna su


4. "Torna su"

Su palmare, lo scorrimento verticale può risultare parecchio dispersivo.
Si confrontino Figura 1 e Figura 2: con la trasformazione della tabella in elenco è stato abolito lo scrolling orizzontale, ma a prezzo di una maggiore verticalizzazione dei contenuti, che in certi casi può tradursi, per l'utente, in un maggior ricorso allo scrolling verticale.

Lo stesso inconveniente si presenta nel caso dell'adattamento automatico di un layout fluido allo schermo del dispositivo mobile: compresso sull'asse orizzontale, il contenuto tenderà inevitabilmente a distribuirsi verticalmente.

In questi casi, per agevolare la navigazione ed evitare l'uso eccessivo della barra di scorrimento, può essere utile disseminare nella pagina ancore interne che riportino l'utente all’inizio delle sezioni particolarmente "lunghe".

Si consideri questa struttura XML:

<doc>
<sezione>
<titolo>titolo1</titolo>
<contenuto>…</contenuto>
</sezione>
<sezione>
<titolo>titolo2</titolo>
<contenuto>…</contenuto>
</sezione>
</doc>

Con il seguente template XSLT è possibile aggiungere il link "torna su" al termine delle sezioni. Vediamo l'esempio:

<xsl:template match="/doc">
<xsl:for-each select="sezione">
<a href="#" id="{titolo}"></a>
<h1><xsl:value-of select="titolo" /></h1>
<p><xsl:value-of select="contenuto" /></p>
<a href="#{titolo}">torna su</a>
</xsl:for-each>
</xsl:template>

Dal valore dell'elemento titolo di ciascuna sezione viene ricavata un'ancora di riferimento e, sfruttando questo stesso valore, viene generato al fondo di ciascuna sezione un link "torna su" che punta all' id dell'ancora di riferimento.

Risultato:

<a href="#" id="dati1"></a>
...
<a href=”#dati1”>torna su</a>
<a href="#" id="dati2"></a> ...
<a href=”#dati2”>torna su</a> ...

Immagine raffigurante il link torna su al fondo delle sezioni in una pagina visualizzata da palmareFig. 5
Visualizzazione su pIE della trasformazione. Link "torna su" al fondo delle sezioni.

torna su


5. Webografia

Mobile Web Best Practices 1.0 [link esterno]
Raccomandazioni del W3C per la progettazione di siti Web per palmari (documento attualmente allo stato di Candidate Raccomandation).

Guida siti per dispositivi mobili [link esterno]
Come possono essere utilizzate le tecnologie web per pubblicare siti adatti al Mobile Web.

MWI: come migliorare interoperabilità e usabilità nel web mobile [link esterno]
L'accesso al web da dispositivi mobili è un passo essenziale nel raggiungimento dell'obiettivo "Web on Everything" o "One web".

Dall'accessibilità del web all'indipendenza dai dispositivi [link esterno]
Alcuni accorgimenti per migliorare la navigazione sui siti web con un palmare, a cura di Gianluca Affinito.

"One web"?
Un approfondimento sul rapporto tra accessibilità e usabilità nella progettazione per palmari, con particolare riferimento al documento W3C "Mobile Web Best Practices 1.0".

Fruibilità dei contenuti web da palmare
I prodotti e servizi web su palmare sono il frutto di una mirata strategia progettuale che tiene conto dei limiti e dei vantaggi del mezzo stesso.

torna su



[ Torna all’inizio della pagina ]



Sito realizzato dal Laboratorio di Accessibilità e Usabilità del CSI-Piemonte - Dichiarazione di accessibilità

[ Torna all’inizio della pagina ]