Archivi tag: pownce

Leah Culver (Pownce) – Web app do’s and don’ts

Pubblicato il da

Pownce è una applicazione sociale, sviluppata in 4 mesi, con solo invito, lanciata a giugno. Leah ha presentato, schematicamente, i passi che sono stati seguiti nello sviluppare questa applicazione, con risorse limitate. Le riporto così come sono: nulla che non si sappia già, ma fa bene averle in una lista.

Hanno usato Django, un framework in phyton, perché:

  • è un web framework
  • è molto documentato e leggibile
  • genera automaticamente la parte di amministrazione per ognuna delle tabelle

Poi hanno usato S3, l’Amazon Simple Storage Server, perché

  • meno manutenzione necessaria
  • costa meno

Hanno usato AIR di Adobe:

  • lavora sia su Pc sia su Mac
  • molto facile da sviluppare
  • ingoraggia lo sviluppo di interfacce utente efficaci

Fare molto con poco

  • Pownce ha un team piccolo
  • solo uno sviluppatore web
  • è self-funded
  • lavorano con scadenze a breve tempo

Team piccolo, indossano scarpe diverse

  • ogni persona ricopre diversi ruoli
  • si aggiornano frequentemente
  • lavorano molto, per questo cercano soddisfazioni in quello che fanno

Open Source Tools

  • perché qualcuno ha già risolto il problema
  • e probabilmente meglio di come lo potresti fare tu

Tratta bene il tuo database

  • il database di Pownce è anche il suo collo di bottiglia
  • un solo database Mysql
  • velocizzare le query lente ha dato ottimi risultati all’odiermo Pownce
  • seguono suggerimenti

Caching

  • usare memchache
  • cusare il caching a livello di pagina e di oggetto
  • già dal lancio del sito

Usare le code

  • deciedere cossi può fare con le code
  • come spedire messaggi e note
  • un sistema che devono ancoa migliorare

Paginazione

  • ovunque sia possibile
  • è anche una buona pratica per l’interfaccia utente

Evitare la complessità

  • se le query sono troppo comples, evitarle
  • e chiedersi se servono davvero
  • in questa fase evitano visualizzazioni di dati complessi

Tenere i backup

  • usare la gestione delle versioni
  • dotarsi di un sistema per tornare a versioni precedenti del progetto
  • tenere traccia delle dipendenze e dei diversi aggiornamenti

Salvare quanto più dati possibili

  • Per capire cosa succede
  • Per applicare criteri quantitativi nell’analisi
  • Cercare di realizzare grafici sintetici dai dati ottenuti

Community

  • let user know what you’re working on
  • respond to indivisual bug reporters
  • inform users of bug fixes and new features

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

Aggiornamento (15 Ottobre 2007): si parla di questo intervento anche su highscalability.com.

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