Archivi tag: digg

Kevin Rose – Lesson learned from launching web apps: the story behind Pownce and digg

Pubblicato il da

Un altro intervento che si è svolto ieri, proprio in coda alla giornata, si è rivelato interessante.

Kevin Rose è uno dei fondatori di digg e si è soffermato a illustrare quelle che nella sua esperienza sono le strategie più efficienti nel creare un nuovo servizio web. Se non altro Rose si è dimostrato meno abbottonato dei propri colleghi, riuscendo a proporre qualche tema di discussione.

Per prima cosa Rose ha sottolineato come sia rischioso, e tutto sommato non necessario, abbandonare il proprio lavoro per buttarsi a capofitto in progetti del genere. Meglio cominciare dedicando le sere e i week-end, soprattutto per valutare se l’idea sia poi così buona.

Come conservare i soldi (per usarli successivamente):

  • Affidarsi a programmatori freelance, perché questo è il modo più economico per partire. Fare molta attenzione però a quello che viene prodotto, per evitare di trovarsi con un prodotto scadente in mano, per esempio con irrisolvibili problemi di prestazioni all’aumentare del traffico
  • Non compare i server, ma affittarli. Affittare un hosting che possa essere controllato remotamente, con accesso alla “shell”
  • Impiegare, ovunque sia possibile, prodotti opensource

Come fare i soldi. Per quella che è la sua esperienza:

  • Con l’advertising (es. Adsense)
  • Prevedendo degli account professionali a pagamento

Per far crescere un progetto così che nel tempo la base di utenti soddisfatti aumenti sensibilmente, è necessario introdurre periodicamente nuove funzionalità. Quelle che si sono rivelate vincenti in digg sono:

  • importare la rubrica contatti
  • avere la possibilità di aggiungere amici
  • spedire le storie via email (anche con un client di posta)

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA

Il futuro del web e le connessioni del medioevo

Pubblicato il da

Si sta per concludere la prima giornata al Future of Web Apps, qui a Londra.

Gli interventi che ho seguito oggi rientrano nella categoria “discreti”. Presentazioni che faticano a decollare, complici speaker non eccellenti sul palco (e con portatili da rottamare, mi consolo). Ho comunque seguito con interesse le parole di Daniel Burka a proposito degli approcci da seguire per aggiungere nuove funzionalità alle applicazioni web.

Un po’ di delusione per la presentazione di Matt Mullenweg di WordPress, da cui mi sarei aspettato molto di più, piuttosto che uno striminzito elenco dell’hardware usato da wordpress.com.

Altra nota dolente è la connettività presente in sala, che funziona a singhiozzo. Forse pensavano che solo 10 persone su 400 portassero con sé il portatile, quando invece siamo più vicini alle 390 su 400. Benedico la funzione di auto-save di wordpress, senza la quale nessun intervento sarebbe andato online visti i continui timeout. Non raggiungiamo i livelli dell’anno scorso al Le Web 3, ma è uno scontro testa-a-testa.

Domani si replica. Dubito che qualcuno passi la notte a fare un upgrade di banda, quindi la speranza è di “sentirci” prima del rientro in Italia.

Da Londra passo e chiudo.

Daniel Burka (Digg/Pownce) – Designing for web apps vs designing for the web

Pubblicato il da

Daniel ha per prima cosa presentato le differenze tra due degli ultimi progetti che ha seguito, Digg e Pownce. Il primo ha 3 anni e 2 milioni di utenti, il secondo è una realtà più giovane ma in cui i gruppi sono molto affiatati.

Le persone si aspettano che Digg aumenti le funzionalità e rispetti le aspettative degli utenti, anche in termini di performance.

Ma come comportarsi al momento di introdurre delle modifiche che, potenzialmente, potrebbero essere accolte con critiche? Come, in particolare, il feedback degli utenti influenza lo sviluppo dei prodotti web?

Daniel presenta l’esempio del nuovo sistema di commenti di Digg. L’obiettivo è che potesse gestire dei thread di conversazione più complessi di quello attuale, che fosse più veloce, e che permettesse discussioni legate all’argomento di cui si parla.

Come introdurre modifiche al sistema:

  • tenere sotto controllo i precenti feedback sul sistema
  • conoscere la comunità per cui si sta lavorando
  • cercare di anticipare le aree di frizione
  • impiegare focus group e studi di usabilità
  • decidere quali parametri adottare per stabilire che la modifica ha generato successo nella direzione voluta

Come comportarsi quando gli utenti dicono che andava meglio prima? Gli utenti andrebbero preparati per tempo. Va tenuto conto che lamentarsi di cambiamenti è in ogni caso una reazione normale.

Anche il feedback da parti degli “esperti”è importante, soprattutto se volontariamente dedicano del tempo a motivare i problemi che hanno riscontrato.

Esiste poi del feedback implicito: osservare il comportamento degli utenti, usando delle metriche. Molti utenti sono infatti “muti”, non condividono le loro esperienze.

Come comportarsi in seguito al feedback degli utenti

  • passo 1: non reagire subito, prendere fiato, a parte correggere gli eventuali bug
  • passo 2: identificare temi di critica e idee da seguire
  • passo 3: coinvolgere la comunità
  • passo 4: iterare nuovamente dal primo passo

Ricordatevi anche che è impossibile accontentare tutti: non provateci neppure.

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA