Il mio primo articolo

http://www.uxmagazine.it/interface-interaction-design/il-ruolo-dei-moduli-nellinterazione-tra-utente-interfaccia-web/#more-865

Yahoo’s interactive menu, un bell’esempio di design e usabilità

segnalo questo articolo molto interessante

On my previous job, when I was working for a big web portal, we got used to look up to Yahoo’s interaction design as one of the most insightful example of dealing with users’ experience on a large scale audience.

via Yahoo’s interactive menu | Web & Patterns: patterns for a better web..

Search Engine Optimization Is Part of Good Web Design – Webmonkey

Leggo questo articolo sull’argomento design vs SEO e mi rendo conto che spesso non si centra bene l’argomento. L’ottimizzazione delle pagine per le attività S.E.O. sono spesso attività a latere rispetto alla pubblicazione del sito.

Questo è un problema che solo in parte riguarda il webdesigner, poichè se la struttra dell’html e la gestione del css son corretti il rendering prodotto è gia SEOReady.
Se utilizziamo correttamente i marcatori html rendiamo più facile la vista agli spider dei motori di ricerca.
Se la produzione di contenuto informativo è correttamente veicolato dai fogli di stile non ci saranno grandi problemi di utilizzo e poi di share su altri siti.

Insomma dopo tutti questi se credo sia chiara la distinzione dei ruoli, e cioè chi pensa alla progettazione dell’interfaccia per la sua ottimizzaizone grafica e la sua capacità di utilizzo, e chi invece deve ottimizzare i contenuti gestire delle tecniche di marketing e trip and tips vari per far salire di posizione l’url nella pagina di google.

Insomma chi si occupa di SEO faccia bene il suo lavoro che noi designer abbiamo altro a cui pensare;)

Italia.it – non c’è verso2

Macchè, non c’è verso, il portale nazionale del turismo è nato sotto una cattiva stella, non è cosa!
Gli esordi furono raccapriccianti, col Rutellone che parlava davvero come Alberto Sordi col suo peggior inglese, ma quello che è stato inaugurato oggi dalla rossa Brambilla è un punto peggio.

La grafica è del tutto anonima, nulla a che vedere con lo stile e la qualità del “fatto in Italia”, nemmeno lontanamente apprezzabile come un tramonto sulle colline toscane o le gradazioni di blu del mare salentino.
Si sono impegnati nel realizzare una patacca di quelle epocali!

L’abito non fa il monaco direte voi, e invece questa volta lo fa eccome, anzi l’abito fa lo straccione, perchè da una prima analisi è di questo che si tratta, uno straccio di sito.
Si fa bella mostra della dichiarazione di accessibilità e si precisa anche che per colpa di qualche filmato flash alcuni contenuti non saranno fruibili ai diversamente abili.
Ma fosse solo qualche filmato flash il problema, navigando velocemente il pataccone si rileva immediatamente che:
1. nessuna attenzione al corretto uso delle intestazioni (fig. 02)
2. già dall’home page vengono fuori errori di codice html (fig. 03)
3. mancano quasi del tutto gli attributi alt sulle immagini presenti (compresa quella del presidente ommioddio uggesù) (fig. 04)
4. assenti nella maggior parte dei casi i title sui link e sui bottoni
5. sui link che puntano a siti esterni non c’è il minimo avviso di cambiamento del focus

e queste son solo le cose minime, che saltano subito agli occhi…ma presto spulcerò meglio!

10 domande a cui un sito deve rispondere – wip

10 domande per un sito web

partendo dall’analisi del portale dell’automobilista è venuta fuori questa valutazione…

Premesso che abbiamo individuato come elementi principali di una pagina web:

1.    la testata
2.    il menù di primo livello
3.    il box di ricerca
4.    il menù di secondo livello
5.    il contenitore di contenuti
6.    eventuale colonna destra o sinistra con contenuti aggiuntivi (es. lista di link, box news)
7.    footer o piede di pagina

1. la prima pagina del sito è facilmente riconoscibile e rintracciabile?
2. è facile individuare gli elementi principali della pagina?
3. selezionando le voci del menù di primo livello è facile capire se esiste un menù di secondo livello o se quella determinata voce porta ad una pagina precisa
4. il contenuto testuale della pagina è fruibile?
5. il contenuto media (immagini, audio, video) sono fruibili senza plug-in aggiuntivi
6. il sito presente strumenti per riconoscere l’utente che lo ha già visitato?
7. eventuali form di ricerca o inserimento sono gestiti in maniera logica?
8. ad ogni form è associata una pagina di report per comunicare all’utente le operazioni che sta compiendo?
9. nell’ipotesi della presenza di file da scaricare, sono adeguatamente segnalati (tipo e peso)?
10. esistono strumenti per facilitare la navigazione in casi particolari (es. ancore di navigazione, strumenti di ricerca avanzati etc)

Mi faccio una domanda e mi do una risposta

tastiera

partendo dall’articolo di jacob nielsen mi sono posto le domande da lui suggerite:

se leggo solo il titolo, capisco se l’articolo mi interessa o meno?
l’abstract è sufficientemente complementare al titolo tanto da fornire un minimo di informazione?
la foto se c’ è è chiara o richiede uno sforzo?
ho scritto qualcosa di veramente interessante tanto da spingere l’utente a scrivere un commento?

Width su fieldset

avere a che fare con questo oggetto è una continua scoperta:
ho un fieldset con all’interno i soliti controlli (select, radio, check), con ie 5, 6, 7 tutto ok ossia all’ingrandimento caratteri rimane tutto leggibile.
Con firefox 2.0 invece al terzo ingrandimento sparisce tutto!
Scapoccia di qua scapoccia di là alla fine capisco che il fieldset vuole un width, che io ho impostato in questo caso al 100%, solo in questo modo il contenuto riesce ad adattarsi agli zoom del browser.

ecco il css:

fieldset {margin-top: 30px;padding: 0 0 0.5em 0;width:100%!important}

zoom al 100% (solo testo)

zoom +2 solo testo

soluzione con width

Si, ma poi vallo a spiegare!

mi occupo di accessibilità di siti e applicativi web (cioè che funzionano attraverso un browser), quando si rilascia un progetto, questo va in verifica di accessibilità.La verifica comprende l’analisi dei 22 punti della legge Stanca con  una discreta aggiunta di verifica della compatibilità tra quello che si legge nella pagina e quello che effetivamente deve essere compreso (chiamiamola per comodità e anche per pigrizia usabilità).

Ad essere onesti i problemi principali non riguardano nello specifico il rispetto dei 22 punti di controllo (certo è uno smazzo quando si ereditano grafiche sviluppate in tempi remoti, tipo con tabelle e stili in linea), ma per quello che mi riguarda è la difficoltà nell’illustrare le funzionalità se nza scrivere righe e righe che tanto l’utente non leggerà mai!

Sarà che oggi ho finalmente passato la verifica di un mega progetto e mi son reso conto che sarà pure accessibile secondo la legge stanca ma indubbiamente ci sono dei passaggi nei form di dubbia comprensibilità.

Per cui il mio dubbio è nettamente questo, a chi giova avere un sito pulito con un codice perfetto, se quando c’è un form che ti chiede millemila cose non c’è una chiara comprensione dell’obiettivo del form stesso?

termini che forse è meglio specificare:

1. accessibilità termine con cui si individuano delle linee guida attraverso le quali permettere a chiunque di navigare pagine web (persone che hanno difficoltà fisiche o cognitive nell’utilizzare il mezzo internet)
2. sito genericamente inteso come raccolta di pagine collegate tramite link
3. applicativo sfrutta l’architettura del sito ma ha dietro un compelsso motore di elaborazione dati attraverso il quale si compiono delle operazioni (es. compilazione di un questionario o iscrizione ad un servizio erogato tramite web)
4. legge stanca prende il nome dal suo promotore Lucio Stanca che nel 2004 (numero 4 del 9 gennaio 2004) ne promosse l’abrogazione a legge per i siti delle pubbliche amministrazioni
5. form in linguaggio html il tag form serve per presentare controlli e operatori (esempio radio button, select etc) è presentato all’interno del tag Fieldset
6. codice perfetto ossia in linea con gli standard utilizzati dal consorzio w3c

fieldset

Tutte le pagine che presentano controlli (con o senza il tag form) devono presentare un fieldset che raggruppi questi elementi (INPUT, BUTTON, SELECT, etc).

il tag legend deve sempre riportare in poche parole a cosa serve compilare o agire su quella serie di controlli.

Importante all’interno del tag fieldset rispettare alcune regole per la presentazione dei controlli:

radio button devono presentare l’etichetta nella parte sinistra del controllo con presenza di label (per questo controllo si può usare la tecnica di label nascosta)

check box devono presentare l’etichetta nella parte sinistra del controllo con presenza di label (per questo controllo si può usare la tecnica di label nascosta)

select tutti i controlli di questo tipo devono avere un’etichetta ben visibile in modalità scrittura e un’etichetta nascosta in fase di lettura (ad esempio nella fase di report del form) per dare indicazioni precise all’utente.

button il nome deve essere nella lingua delle pagine dove si presenta e deve avere la presenza dell’attributo title per permettere di essere localizzato e individuato come controllo che fa quella specifica operazione (ad esempio invio dati)

esempio di codice:

<FIELDSET>
<LEGEND>Generalità</LEGEND>
<label for=”nome”>nome</label>
<INPUT type=”text” id=”nome”>Nome</input>
<label for=”cognome”>cognome</label>
<INPUT type=”text” id=”cognome”>Cognome</input>
</fieldset>

infine è buona regola verificare sempre che i campi di testo possano contenere solo testo e i campi numerici solo numeri!

tre domande sull’accessibilità

cosa significa sito accessibile?

Produrre siti applicativi e interfacce per supporti video significa produrre qualcosa che risulti il più possibile compatibile con la maggior parte dei supporti in circolazione.
Ogni singola pagina deve essere redatta conformemente alle regole segnalate dal w3c e a quelle formalmente previste nella legge “Stanca“; l’optimum sarebbe un ragionato mix di entrambe per ottenere applicativi validi e graficamente accettabili.

perchè si realizzano applicazioni accessibili?

Creare un pagina accessibile significa anzitutto far sì che le informazioni in essa contenute siano comprensibili per la maggior parte degli utenti normodotati e implica la massima cura nel rendere agevole e pienamente comprensibile la navigazione a utenti con disabilità motorie o cognitive.
In sostanza, sviluppare codici seguendo gli standard significa garantire lunga vita al nostro prodotto e avere la sicurezza che il suo contenuto informativo possa raggiungere la piena capacità cognitiva verso gli utenti.
Non avere barriere di accesso ai contenuti informativi consente la piena realizzazione degli scopi e obiettivi dell’applicazione stessa.

chi e come valuta se un sito è accessibile?

La valutazione di un sito applicativo o supporto multimediale è delegata a processi di validazione che possono essere sia di natura squisitamente automatica (es. validatore di html del w3c) o umana (un esperto che con il manuale di sitle alla mano verifica secondo punti di controllo le pagine) o mista (un esperto supportato da strumenti di validazione monitora le pagine ed effettua report specifici per i signoli punti).

Gli strumenti utili a questo scopo sono:

• 1. avere a disposizione le ultime versioni di Mozzilla Firefox, Microsoft Internet Explorer, Opera, Safari
• 2. utilizzare un tool di simulazione per le vecchie versioni di Explorer (es.Multi IeExplorer)
• 3. utilizzare strumenti di debugging per analizzare il codice renderizzato nel browser (es. Explorer Developer Toolbar)
• 4. utilizzare gli strumenti di analisi contenuti all’interno della barra dell’accesibilità
• 5. documentarsi in rete se e come sono state risolte le criticità che man mano si incontrano (es. tabelle dati complesse, form, fieldset, dichiarazioni di charset etc.)