Nel mio articolo parlavo di come secondo me l’evoluzione dei motori di ricerca modificherà il ruolo del SEO, ma avevo tralasciato completamente i colleghi di lavoro del summenzionato SEO, ma dimenticavo che “l’altra faccia della medaglia” ci insegna che è sempre un errore tralasciare le altre prospettive.

Nel leggere le descrizioni del team di sviluppo nell’articolo di Andrea (posso darti del tu vero?) ho ritrovato proprio quello che mi aspetto che un buon team faccia e sappia fare, quindi vi rimando al suo post “Il SEO è inutile. Forse. O forse cambierà soltanto…” sapendo bene che le mie aspettative nei confronti di chi fa il mio stesso lavoro (ed anche verso me stesso) sono alte, ma del resto secondo me non esiste codice biologico, ma solo errori di management e la voglia di migliorarsi.

In this article I’m talking about The Ugly Prototyper a concept idea for a prototyping functionality.

When I start a web project sometimes I need to think about the size of the element on a page.
You are saying “never heard about photoshop/fireworks/flair builder/other prototyping software?” yes, I’ve done my homework, tryed lot of them and discovered that none give me the possibility to input a percent of the father element and get a new object of the proper size.

Practically we have to rely only on us eyes to decide if the logo (or content area) is big enough.
We put elements on page, size them and only then mathematically calculate their encumbrance (when this happens).
It’s a trials and errors method.
I don’t like at all.

If you are designing with a content-driven method you have to decide the right priority of the page elements, I think that a good starting point is to say:”the content area cannot be less than the 33% of the page, the header must be no bigger than 25%, ads will be 25%”, visually see it, modify and then (only then) start with the real prototyping and design.

So I developed my tool.
I made it in few nightly hours, sorry, it lacks of functionality and usability.
You have to reload a page if you change the working area size after creating some child and a lots of others problem.
In my excuse: this is not a release!
The Ugly Prototyper is on line just to be showed to my friends and to gather opinions

Italiano:
In questo articolo parlo di The Ugly Prototyper, un concept per uno strumento di prototipizzazione.

Ho provato diversi software per la prototipizzazione delle pagine web (e più genericamente delle interfacce) e non ho trovato nessuno che mi fornisse la possibilità di inserire una percentuale ed ottenere in cambio un oggetto della dimensione giusta.
Lo trovo strano, perchè in questo modo per il posizionamento contiamo solo sul nostro occhio che potrebbe non essere abbastanza allenato.
Penso che in fase di progettazione, specie se usiamo un approccio content-driven, sarebbe un buon punto di partenza poter decidere che l’header non debba essere più grande del 25%, i contenuti non più piccoli del 33% visualizzandone gli ingombri per poi partire con la prototipizzazione ed il design reali.

Nessuno me lo faceva e così ho creato il mio tool.
è stato sviluppato in poche ore notturne, quindi ha parecchi problemi, tra cui che non ha un sacco di funzionalità comode e necessarie, che bisogna ricaricare la pagina se si cambiano le dimensioni dell’area di lavoro dopo aver già creato almeno un oggetto ed un sacco di altre cose.

A mia discolpa posso dire che questa non è una release (e forse non ci sarà mai una release).
The Ugly Prototyper è messa on line per farsi vedere dagli interessati e raccogliere qualche opinione.

• Una faccia della medaglia
• L’altra faccia della medaglia

è diventata un’estensione per wordpress.
La pagina che la descrive e permette lo scaricamento si chiama: bSEM – Un grassetto per domarli tutti.

L’idea è esaurientemente spiegata nei due post e nella pagina dedicata, quindi non la riassumerò nuovamente.

Vorrei però ribadire qualche punto saliente e l’importanza dell’estensione.
Il nostro modo di vivere il testo scritto è cambiato profondamente.
Mentre la pagina stampata era un media fisso, immutabile nel tempo fruire i contenuti scritti sul web (e sui computer in generale) ci permette di cambiare l’aspetto del testo al cambiare delle nostre esigenze.

Le nostre necessità cambiano tra il momento in cui apriamo la pagina ed il momento in cui effettivamente incameriamo le informazioni
Quindi è giusto che anche la pagina, per aiutarci, cambi con noi.
L’estensione si occupa di rendere coerente l’uso del grassetto con il tipo di lettura che stiamo facendo.

Ho scritto anche troppo.
L’estensione è attiva su questo blog.
L’estensione è scaricabile a questo indirizzo: bsem.lghinelli.it
L’estensione è per wordpress, ma è integrabile con qualsiasi pagina, basta includere il js, i css e seguire le regole.

Per il momento in attesa che wordpress accetti di ospitare l’estensione nella directory dei plugin per segnalare i bug e proporre modifiche avete a disposizione:

• i commenti di questo post
• email: info@lghinelli.it
• wave: lghinelli@googlewave.com

Posso sognare di implementare una feature?
In un mondo bello, bello in modo assurdo (cit.) l’estensione assegnerebbe i bSEM alle parole/frasi più significative in base alla provenienza dell’utente offrendo non solo una lettura più facile, ma anche personalizzata.
Ok, ho esagerato, ma io nel web semantico ci spero molto.

Il tema mi è caro perchè ritengo che sia uno dei campi in cui ancora c’è molta innovazione da vedere e che vada affrontato in fretta e di petto liberandoci da alcune vecchie ragnatele di pensiero che ci portiamo dietro.

Ho già affrontato un aspetto della questione nei post “una faccia della medaglia” e “l’altra faccia della medaglia” in cui introduco il tempo come variabile da tenere in considerazione per aiutare la lettura di una pagina.

Un altro parametro (di cui ho imparato solo recentemente il nome) è il mantenimento degli indici spaziali.
Uno dei problemi più importanti quando leggiamo su monitor è lo scroll.
Ogni volta che usiamo la rotella del mouse scorriamo la pagina di un numero arbitrario di righe (su windows e linux il default è 3, ma è impostabile, io uso 2) e questo ci costringe ogni volta a percorrere il testo per ritrovare il punto in cui rileggere.

Da qualche anno ormai cerco di costruire un sito che abbia esclusivamente uno scorrimento orizzontale.
Perchè?
Perchè io a casa non ho una collezione di papiri, ma di libri e i libri hanno uno sviluppo orizzontale piuttosto che verticale.
L’intuizione (non originale, tutte le metafore informatiche sono nate così) è stata di copiare l’analogico che abbiamo intorno.
Approfondendo l’intuizione per trasformarla in idea e poi in pratica i punti che ho reputato minimi ed indispensabili sono diventati questi:

1. Mantenere le righe di testo ad una lunghezza accettabile (75 caratteri più o meno)
2. Occupare tutto lo spazio verticale possibile
3. Eliminare in ogni caso lo scroll verticale
4. Fare in modo che lo scroll orizzontale non fosse fluido, ma a scatti, di blocco di testo in blocco di testo

Il punto forte è il n°4, infatti quello che ci consente una lettura più fluida non è la direzione di scorrimento, ma facilitare il lavoro dell’occhio, spostandoci di un blocco di testo l’occhio va automaticamente alla prima lettera della prima riga del nuovo blocco, nessuna confusione, nessun ritardo, vita più facile.

Altro punto fondamentale è il n°3, esistendo una molteplicità di device e risoluzioni non possiamo decidere arbitrariamente di limitare l’altezza di un blocco di testo a nostro piacimento, farlo provocherebbe frustrazione in chi ha un monitor più alto e costringerebbe i monitor minori (cellulari in primis) ad avere uno scroll in due direzioni, cosa che i nostri device di puntamento non ci consentono facilmente.

Un esempio di “orizzontalizzazione” dei contenuti è the horizontal way e come si può vedere nel tentativo di rispettare il punto n°2 rende fissa l’altezza (da bravo sito web rispetta una risoluzione minima di 1024×768) e non prende in cosiderazione il punto n°4 portando i difetti dello scroll verticale nel “mondo orizzontale”.
Sia chiaro che prendo “The Horizontal Way” come esempio in quanto uno dei siti che a suo tempo analizzai con più cura e non certo per criticare l’ottimo lavoro Marco Rosella.

Recentemente ho rivisto l’idea e ho scoperto che l’orizzontale non è necessario, il punto fondamentale è il n°4 e può essere usato in qualunque direzione, l’importante è spostarsi seguendo dei blocchi di testo, meglio se i blocchi hanno anche un significato semantico.

La mia idea risale ad ormai anni fa e periodicamente la riprendo in mano, nell’ultima (recente) rianalisi della questione ho eliminato dai requisiti il punto n°2, il monitor non è una pagina, abbiamo spazio in tutte le direzioni, usiamolo. ma questa è un’altra storia ed un altro post.

In occidente ogni giorno
decine di lemuri
vengono maltrattati senza ragione
questo post è dedicato alla difesa
di questi sciacalli.

Si, c’è un errore. Un problema banale di coerenza nel testo: un’anafora che non funziona come dovrebbe. Talmente banale che non vi sorprenderà sapere che non vincerete un premio per averlo scoperto. Quello che dovrebbe sorprendervi è invece la facilità e la precisione con la quale appena letta la parola “sciacalli” siete tornati a leggere la parola “lemuri”. Se tutto è andato come dovrebbe, non avete riletto il testo per ricercare la parola sbagliata, ma siete direttamente saltati alla sua posizione.

Nella frase che segue invece tutto è coerente dal punto di vista semantico:

In occidente ogni giorno
decine di lemuri italiani
vengono maltrattati senza ragione.
La stessa sorte spetta agli
sciacalli francesi.
Un’altra categoria a rischio sono i falchi turchi.

Nessun problema semantico in questo caso, eppure anche qui c’è qualcosa che non va. Questa volta si tratta di coerenza grafica: nelle prime due frasi i nomi di animali (lemuri e sciacalli) sono in grassetto e la loro provenienza (italiani, francesi) è in corsivo. Nella terza questo codice è ribaltato.

Dietro a questi due esempi sta buona parte della progettazione dell’estensione che avete incontrato in un post precedente: «Una faccia della medaglia» e che serve a tenere insieme in una pagina web i grassetti che servono ad aiutare la lettura (scelti dal redattore) e i grassetti che servono ad ancorare il lettore alle parole chiave di un testo (scelti dal SEM) distinguendoli da un punto di vista grafico e temporale. I grassetti di lettura servono a comprendere meglio il testo, i grassetti SEM servono invece a individuare le parole chiave del testo durante una prima lettura rapida, per capire se il contenuto ci interessa o no.
C’è una descrizione più precisa nel post originale a cui vi rimando.

Quello che faremo è invece condividere alcune delle riflessioni sulla User Experience che hanno animato la fase di design dell’estensione e che potrebbero servire a dare qualche indicazione sul design di applicazioni web più in generale. Cosa c’entrino lemuri, sciacalli e falchi lo capirete a breve.

Se avete letto il post precedente capirete di cosa parliamo. Se non l’avete fatto siete ancora in tempo per farlo.

Fatto? Bene.

La versione che vedete ora (anche in questo post) è solo l’ultima di una serie di prove, in gergo iterazioni che abbiamo testato per decidere quale fosse la maniera migliore di distinguere graficamente (come) e temporalmente (quanto) ha richiesto lo scambio di un buon numero di mail.
Se vi capitasse di sviluppare qualcosa di simile sappiate che un modo sbagliato di ragionare è quello di considerare ogni elemento separatamente:

1. Decidiamo quale sia lo stile migliore da attribuire al grassetto SEM « acceso » per renderlo rapidamente reperibile a una prima lettura;
2. Poi quale sia lo stile migliore da attribuire al grassetto SEM « spento » per renderlo leggibile a una seconda lettura;
3. Infine decidere dopo quanto tempo il grassetto SEM deve spegnersi;

É quello che abbiamo fatto in un primo momento, rendendoci poi conto che le nostre soluzioni non potevano funzionare. Ripercorriamo le fasi del design.

Fase 1: grassetti evidenziati, e testo normale

In un primo momento i grassetti SEM accesi erano evidenziati in rosso: così e quando si disattivavano apparivano come testo normale: cosi.
Soluzione che soddisfaceva pienamente il nostro desiderio di fornire il miglior layout alle due fasi della lettura:
massima leggibilità nella prima, minima distrazione nella seconda.

Il problema è però che per quanto riguarda l’Esperienza dell’Utente queste due fasi di lettura non sono affatto indipendenti: l’utente coglie informazioni di un certo tipo nella prima lettura che poi utilizzerà nella seconda, ma non vive una pausa tra le due. Inoltre, come i due esempi di lemuri sciacalli e falchi ci hanno dimostrato, quando leggiamo un testo non ci interessiamo solo al suo contenuto semantico, ma ci serviamo anche della sua posizione e del suo aspetto di superficie: usiamo degli indici spaziali e grafici per identificare un contenuto con l’aspetto che questo ha all’interno della pagina, in modo da poterlo ritrovare quando diventerà per noi interessante. Il primo esempio ci ha dimostrato quanto possa essere preciso questo meccanismo, e spiega ad esempio perchè fatichiamo cosi tanto a leggere dei pdf a monitor: ogni volta che facciamo uno scroll perdiamo quegli indici spaziali la cui stabilità costituisce la struttura di superficie del testo che è fondamentale alla sua comprensione.

Da questo punto di vista la nostra soluzione poneva due problemi:

1. Il primo problema riguarda l’evidenziazione dei grassetti SEM, che catturavano troppo la nostra attenzione: Lo sfondo rendeva molto “grafici” i grassetti e portava a dare poca attenzione al testo. Proprio perchè diamo molta importanza alla struttura di superficie del testo in questo caso gli occhi rimbalzavano sui blocchi rossi senza fermarsi sul loro contenuto. Per capire quale sia la struttura di superficie del vostro testo e quali elementi attirino maggiormente l’attenzione potete testare la vostra interfaccia con delle tecniche di eye tracking.
   Un modo low cost per averne comunque un’idea approssimativa è quello di sfocare (con Photoshop) un’immagine della vostra pagina e vedere quali sono le strutture che restano salienti. Molto probabilmente l’occhio seguirà queste strutture.
2. Il secondo problema che avevamo riguardava il passaggio dal grassetto evidenziato al testo normale. Anche in questo caso il problema era dato dal fatto che la struttura con cui l’utente diventava familiare durante la prima lettura scompariva nella seconda. E questo perchè avevamo considerato la prima e la seconda lettura come due eventi indipendenti, mentre in realtà sono strettamente collegati: giustamente l’evidenziazione creava una struttura visiva di superficie (delle etichette rosse) che doveva servire a scorrere il testo a una prima lettura. Ma avevamo dimenticato che aiutare la prima lettura significa fornire le basi per la seconda!
   Nel nostro caso la differenza grafica tra grassetti SEM attivi e non attivi era troppo grande, e l’utente non aveva alcun modo di servirsi nella seconda lettura di quegli indici grafici che aveva incontrato nella prima.

La prima soluzione è stata quella di sostituire le evidenziazioni con dei dei grassetti normali. Non abbiamo scelto di adottare un’evidenziazione meno forte perchè l’evidenziazione rappresenta un problema in sè: crea degli spigoli. E siccome i nostri occhi sono attirati dalle strutture salienti e discontinue come gli spigoli, c’erano molte meno probabilità che gli occhi cadessero anche sulle parole che si trovano prima o dopo il grassetto. E questo era un male perchè il grassetto dovrebbe si attirare lo sguardo sulla parola importante, ma all’interno di una frase che dovrebbe comunque essere percepita per intero, anche se rapidamente.

Come seconda soluzione cosa abbiamo deciso di trasformare i grassetti disattivi in grassetti più “magri”, graficamente vicini al testo normale, ma ancora distinguibili. Questo per evitare il problema di coerenza visto nel secondo esempio di lemuri, sciacalli e falchi: leggo dei grassetti molto marcati, imparo a distinguerli semanticamente dal testo normale finchè ad un tratto la distinzione scompare e le caratteristiche grafiche che avevo imparato a distinguere si fondono con il testo normale. Rendendoli meno intensi, ma ancora distinguibili dal testo standard, introduciamo non una forte variazione grafica, ma una modulazione che permette all’utente di passare alla seconda lettura mantenendo però gli indici grafici e spaziali che aveva appreso nella prima.

Fase 2: Gestione del tempo
In una seconda fase ci siamo invece occupati del tempo. Per quanto tempo i grassetti SEM devono restare attivi ? In un primo momento avevamo deciso di far sparire l’evidenziazione dopo un numero di secondi pari a quello delle parole evidenziate presenti nella pagina. Ad esempio: 20 parole, 20 secondi. Un ottimo criterio quantitativo, ma che si basa su un’interpretazione sbagliata delle azioni e delle intenzioni dell’utente. Questo criterio funziona solo se l’utente durante la prima lettura arriva direttamente in fondo alla pagina subito dopo averla aperta. Ci eravamo dimenticati una possibilità: quella che la pagina fosse aperta, ma letta solo dopo un certo tempo. Una possibilità resa molto probabile dall’uso dei TAB.

Quante volte vi capita di aprire un nuovo tab e poi leggere la pagina molto tempo più tardi?. Nel tempo che passa tra l’apertura del tab e l’effettiva lettura della pagina le nostre evidenziazioni sarebbero sparite, e ci saremmo ritrovati con un gran numero di utenti che non le avrebbe mai viste.
La soluzione adottata in questo caso è stata quella di far cominciare il conto alla rovescia solo dopo un periodo di attività del mouse sulla pagine, il che ci garantisce che l’utente stia scorrendo la pagina quando inizia il conteggio.

Queste modifiche ci lasciano con l’estensione WordPress che verrà ufficialmente rilasciata nei prossimi giorni (siamo ancora in trattativa per l’esclusiva con Wired). Ci lasciano anche qualche saggio insegnamento sul webdesign: volete costruire una buona User Experience? Prendetevi cura della coerenza e della continuità:

1. Gestite in maniera coerente gli indici grafici e spaziali che servono all’utente per orientarsi nella semantica del testo. Fate attenzione alla struttura di superficie della vostra pagina.
2. Prendete in considerazione che l’utente vive anche al di fuori della vostra pagina. Chiedetevi sempre da dove venga, cosa voglia fare quando agisce in un certo modo, dove vorrebbe andare poi;
3. Rendeveti conto che non esiste una sola categoria di utenti, ma che il nostro design deve cercare di soddisfarne il più possibile. Non ci sono solo diverse versioni di browser, ma diverse pratiche d’uso del browser: ad esempio c’è chi legge tutto subito e chi apre tab che leggerà solo in seguito. Pensateci, se progettate un’applicazione che evolve nel tempo.

Alcuni di voi si staranno ancora chiedendo il senso degli esempi su lemuri, sciacalli e falchi in apertura di post. Ci sono tre risposte:

la prima è che se avessimo voluto inserirli solo per spiegare l’importanza di indici non semantici e della coerenza superficiale saremmo stati costretti a introdurli con « ora leggete questa frase ». Voi avreste capito che c’era qualcosa sotto e l’esempio non avrebbe funzionato cosi bene (mica bello farsi fregare cosi in un post in cui si scrive di User Experience).

La seconda ragione è che certe volte la curiosità di capire dove il post andrà a parare può motivare la lettura più di un buon riassunto.

La terza è che è molto divertente iniziare un post scrivendo di lemuri, sciacalli e falchi.

Claudio è stato completo e chiaro (ma del resto ne ero sicuro), spero che la lettura sia stata per voi interessante tanto quanto lo è stato per noi il processo che ci ha portato qua.
Mi limito solo a ringraziare di nuovo anche le altre persone che hanno collaborato all’idea:

dplastino che mi ha spiegato tutto quello che dovevo sapere sul dove e come posizionare correttamente i grassetti per entrambi i tipi di lettura.

Diego (formaldeide) Ricci che per primo ha notato che per gli spider <span class=”qualcosa”> non ha lo stesso peso di <strong>è

I SEM dicono che i grassetti devono aiutare a catturare l’utente e quindi devono formare un “sommario” del testo che fermi il lettore sulla pagina, la mia analogica professoressa di italiano, a suo tempo, mi diceva che il grassetto deve fornire un appiglio visivo a quelle parti del testo che sono anche semanticamente rilevanti.
Le due cose anche se si assomigliano non sono affatto equivalenti, chi scrive di mestiere distingue immediatamente un testo ottimizzato per “fermare” il lettore da uno scritto per la lettura approfondita, il lettore passivo invece probabilmente non riesce a razionalizzare la differenza, ma la sente come un retrogusto.

Al momento siamo costretti ad una scelta, un testo deve essere ottimizzato in un modo o nell’altro, abbiamo solo un tag <strong> e dobbiamo conviverci.

Siccome entrambi i tipi di lettura sono utili al nostro scopo di divulgazione/marketing dover scegliere quale adottare oltre ad essere insulso (perchè rinunciamo ad una cosa in cambio di un’altra di pari valore) ci porta anche ad effettuare una scelta “artigianale” di quale tipo di lettura sia la più adatta per il nostro testo.
Definisco questa scelta artigianale perchè si basa su variabili non conoscibili tramite strumenti tecnici, ma solo sulla percezione che supponiamo il lettore avrà del testo, ponendo quindi l’effettiva efficacia dell’articolo al di  fuori del nostro controllo.

Le soluzioni sono due, continuare ad usare la sensibilità del nostro editor per decidere che stile usare oppure non accettare nessun compromesso e distinguere nettamente le due cose.
Un’aspetto per gli analogici grassetti del professore d’italiano ed un’altro per il digitalissimo sommario del SEM.

Il problema è che in questo modo molta parte del testo risulterà evidenziata, come può dirvi chiunque “tutto importante = niente importante” e questo non ci piace per niente.
Ci viene però in aiuto il fatto che i due tipi di lettura sono temporalmente non contemporanei, il grassetto SEM compie il grosso del suo scopo nei primi secondi, nel tempo di scorrere la pagina da cima a fondo per decidere se vale la pena leggere tutto, poi passa in secondo piano.
Questo ci suggerisce che il primo tipo di grassetto non è necessariamente permanente sul testo, ma che può scomparire dopo un tempo congruo alla valutazione del testo stesso.

Quindi con due intonacate di javascript e qualche pennellata di css potremmo ottenere un nuovo strumento che funzioni all’incirca così:

• evidenziazione di tutti i tag “SEM” della pagina
• calcolo della durata dell’evidenziazione (in sperimentazione 1 secondo per ogni tag)
• scomparsa dell’evidenziazione “SEM” dopo un periodo di inattività del mouse pari alla durata dell’evidenziazione

A riprova che il web non è più il “one man show” di qualche anno fa vi informo che anche questa semplice idea è estremamente interdisciplinare, infatti la mia idea iniziale non avrebbe raggiunto un livello soddisfacenze senza:

dplastino che mi ha spiegato tutto quello che dovevo sapere sul dove e come posizionare correttamente i grassetti per entrambi i tipi di lettura.

Claudio Vandi che ha rivisto l’intera idea in un’ottica di usabilità ed UX oltre ad aver fornito una tonnellata di altri spunti e nuove idee.

Diego (formaldeide) Ricci che per primo ha notato che per gli spider <span class=”qualcosa”> non ha lo stesso peso di <strong>

Se notate qualche “movimento” strano sulla pagina è perchè sto già sperimentando l’estensione cercando il giusto equilibrio tra i vari parametri da tenere in considerazione in vista della prima release.

Il Seo però è una stregoneria che funziona, infatti i siti nelle mani di persone capaci salgono di reputazione e valore all’interno di un elenco di link ordinato e pertanto è una figura essenziale nella progettazione e nel rinnovamento dei siti web.
Un motore di ricerca considera un sito “meritevole” sulla base di parecchi parametri, i link entranti, i link uscenti, l’indicizzabilità dei testi etc etc etc etc etc (ad libitum), per i più comuni parametri esistono delle linee guida rilasciate dai motori di ricerca stessi, per il resto esiste un sottobosco di trucchetti che il seo conserva più o meno gelosamente e che si coltiva con l’esperienza.

Il trucchetto nascosto in piena vista naturalmente è che il sito sia sul serio di qualità , ovvero ricco di contenuti aggiornati spesso e che interessino davvero gli utenti.
Ed ecco quindi il motivo per cui il SEO è un mestiere solo temporaneo:
finchè i risultati dei motori di ricerca saranno un elenco di link la valigia dei trucchetti (aka l’esperienza) farà la differenza a parità di contenuti, ma nel momento in cui i motori di ricerca daranno dei risultati in base alla semantica della richiesta e delle possibili risposte sarà la qualità dei contenuti a comandare senza opposizione.
In quel momento la figura professionale più richiesta per “migliorare il ritorno del mio investimento su internet” sarà un semplice, banale, vecchio tizio che sceglie la notizia più interessante tra quelle che gli hanno girato i collaboratori oppure se la scrive da solo, in una sola parola: il redattore.

In conclusione il seo è una figura assolutamente essenziale in questo periodo storico del web, ma che è fortemente vincolato alla struttura odierna dei motori di ricerca, che però è ormai decisamente pronta per un balzo in avanti (tutte le interfacce sono pronte per un balzo in avanti, si vedano gli schermi sempre più touch ed il fermento attorno al -semantico e il cloud computing).
Sicuramente la professione SEO si evolverà di pari passo con i motori, ma io scommetto diventerà così simile ad un redattore da non vederne la differenza.