Archivio tag: intervista

Il ruolo delle agenzie nei progetti e-Commerce

Pubblicato il da
2

È uscito in questi giorni per i tipi di Hoepli “e-Commerce, Progettare e realizzare un negozio online di successo“, un manuale scritto da Daniele Vietri e Giovanni Cappellotto.

Il libro contiene anche alcune interviste, tra cui una al sottoscritto, che riporto qui sotto.

Quali caratteristiche deve avere un’agenzia per realizzare al meglio un sito di e-Commerce?

È importante individuare un partner che sia in grado di accompagnare l’azienda non solo nella fase di avvio e di primo rilascio del progetto, ma anche durante i successivi miglioramenti e integrazioni del prodotto che inevitabilmente verranno richiesti. L’agenzia, dopo i primi feedback forniti dalle analisi su utenti e vendite, dovrebbe essere in grado di recepire queste indicazioni e suggerire dei piani di intervento sia nel breve, sia nel medio termine, per esempio con sessioni di test multi-variabile. Molto importante è anche verificare l’esperienza che l’agenzia ha nella progettazione di siti di e-Commerce del proprio settore.

Cosa possono fare i clienti che chiedono un sito e-Commerce per agevolare il lavoro dell’agenzia?

Una delle difficoltà più grandi per il cliente è quella di saper illustrare le proprie esigenze. Alla domanda “qual è l’obiettivo del sito?” può succedere che il cliente risponda passando in rassegna un insieme sparso di componenti che ha notato navigando altri siti, soprattutto quelli dei competitor. Ci si trova allora in riunioni in cui viene chiesto di realizzare la scheda prodotto prendendola da un sito, il carrello da un altro, il risultato ricerca da un altro ancora. In questo contesto è fondamentale il ruolo dell’agenzia nell’aiutare il cliente a individuare in modo corretto e completo i veri requisiti del progetto, così da poter circoscrivere le funzionalità che verranno realizzare per la prima uscita del prodotto e quelle per i rilasci successivi, senza paura di sottolineare le difficoltà e le proprie opinioni in merito. Si fa presto, per esempio, a dire che un sito deve essere accessibile in più lingue, più difficile è gestire le spedizione di prodotto all’estero e risolvere le diverse problematiche di fatturazione o addirittura culturali dei diversi paesi.

Quali sono gli aspetti di un e-Commerce che i clienti trascurano con maggior frequenza?

Spesso gli aspetti più trascurati non riguardano il sito in sé. È certamente importante che il sito sia usabile, veloce, attraente, ma altrettanto importante e forse ancor più importante, è il servizio reso al cliente finale. Come si prevede di gestire la politica di reso? II cliente finale viene guidato in questa procedura o è lasciato in balia di se stesso? Quale potrà essere il tempo medio per la spedizione di un ordine? Esiste un numero verde o un indirizzo mail e quali sono i tempi medi di risposta da parte dell’operatore? Chi si occupa delle foto prodotto e quale è la qualità attesa? Sono domande spesso trascurate, ma che determinano il successo o il fallimento dell’esperienza utente complessiva, di cui quella web è solo una parte.

Quali sono le criticità che sorgono durante la realizzazione tecnica di un e-Commerce?

Le problematiche in ambito tecnico nascono quasi sempre da errori di valutazione in fase di analisi. E i punti dell’analisi che sono più soggetti a errori di valutazione riguardano l’integrazione e la comunicazione con servizi di terze parti e i dettagli della procedura di acquisto, dal momento in cui il cliente finale ha aggiunto un prodotto al carrello fino alla conferma dell’ordine. Se i tempi sono stretti e l’analisi deve essere realizzata in tempi brevi, concentratevi almeno su questi punti.

Nell’ottica di massimizzare le vendite, consiglieresti una piattaforma già pronta o una sviluppata su misura?

La scelta va fatta caso per caso in base ai requisiti del progetto. Se, a fronte dell’analisi dei requisiti e della vendor selection, le modifiche alla piattaforma risultano comunque significative, allora molto probabilmente la direzione corretta è quella della soluzione su misura. Le piattaforme disponibili oggi, sia commerciali sia open source, permettono un livello di personalizzazione tale che possono essere impiegate nella maggioranza dei casi.

Quanto è importante il rapporto con l’agenzia anche dopo la pubblicazione del sito?

È fondamentale, poiché se ogni sito web è una realtà in continua evoluzione, questo vale ancora di più per un sito di e-Commerce, dove è immediata la verifica del successo o del fallimento rispetto ai risultati attesi. Una soluzione di rapporto con l’agenzia potrebbe prevedere la stipula di un contratto di manutenzione annuale che copra la normale assistenza e un certo numero di micro interventi (stimabili per esempio in un monte ore a scalare), lasciando invece sviluppi più corposi a contratti separati.

Il project manager in un mondo agile

Pubblicato il da
Risposta

Tra gli interventi proposti quest’anno a Better Software ce ne sono alcuni che possono essere considerati un ideale completamento al mio “Guerrilla Web Project Management“. “Il project manager e lo sviluppo agile: separati in casa?“, di Jacopo Romei e Stefano Leli, è sicuramente uno di questi. Ecco alcune domande che ho rivolto a Jacopo Romei sul rapporto tra project management e agile.

Il titolo di uno dei workshop che terrai a Better Software è “Il project manager e lo sviluppo agile: separati in casa?”. Perché un project manager potrebbe temere l’introduzione di un approccio agile?

Perché in generale le persone amano lo status quo e un cambiamento utile all’azienda potrebbe essere visto come un pericolo per i propri obiettivi personali. Perché potrebbe non aver chiaro che un approccio anarchico non è l’unica alternativa ad un approccio “command & control”. Perché la funzione del management nello sviluppo agile è diversa da quello che decenni di ingegneria taylorista hanno saputo insegnarci, con successi enormi, ma anche disfunzionalità intrinseche che nel settore software diventano estremamente dannosi.

E quali potrebbero essere, invece, le ripercussioni positive sul suo lavoro?

L’adesione ad un modello di leadership più produttivo e solo in secondo luogo più… bello. Abilitando le persone che introducono il maggior valore nella filiera (sviluppatori, ma anche interaction designer, grafici, sistemisti…) a prendere decisioni tattiche in modo indipendente, il project manager può, per esempio, concentrarsi sulla strategia di portfolio e, solo un secondo esempio, sullo sviluppo di asset preziosi per una azienda software: i cervelli. Molte funzioni ritenute indispensabili del project manager tradizionale sono effettivamente disfunzionali da un punto di vista più sistemico. Il manager, concentrandosi sul flusso di valore e sulla rimozione degli impedimenti, può invece creare le condizioni per cui il team può produrre a livelli altrimenti impossibili e partecipare a questo successo.

Quali sono le principali difficoltà che incontra un project manager che decide ad avvicinarsi all’agile e come può essere aiutato a superarle?

La prima difficoltà è proprio a monte: molti project manager fraintendono la cultura agile. “Agile” non significa né “facile”, né “gratuito”, né “incasinato” né necessariamente “veloce”. Chi si avvicina allo sviluppo agile convinto che ci sarà meno lavoro da fare è completamente fuori strada. Chi invece entra nel mondo agile pronto a installare progressivamente un processo che faccia da cornice ad un miglioramento continuo, scoprirà che a parità di lavoro potrà ottenere molto di più. Per aiutare un project manager ad installare quel processo e a ritagliarlo sul proprio peculiare contesto io cerco sempre di partire attaccando il cosiddetto “wishful thinking“, il pensiero arbitrario. Cercare di basare le proprie analisi e decisioni sui fatti più che sulle percezioni è uno sforzo primario. Non tutto è misurabile numericamente, certo, ma quasi tutto può essere reso empiricamente evidente. Il mio sforzo principale all’inizio è quello di installare dei “manometri” di progetto e nel frattempo educare tutto il team a 2-3 concetti utilissimi, ma largamente ignorati, dell’ingegneria gestionale, tanto per ricordarci che non stiamo parlando di aria fritta: sapete quanti ingegneri hanno studiato la teoria delle code e non la usano mai più?

Jacopo è un coach agile oltre che sviluppatore, scrittore e cantante. È coautore, insieme a Francesco Trucchia, di Pro PHP Refactoring, pubblicato da Apress. E’ anche speaker a diverse conferenze italiane che parlano di agile e lean software development, oltre che uno degli organizzatori di Italian Agile Day, la principale conferenza italiana dedicata all’agile.

Il mondo dei web project manager

Pubblicato il da
Risposta

Sam Barnes, web project manager di Windsor, ha avuto la bella idea di organizzare una serie di interviste ad altri web project manager.

C’è anche quella dedicata al sottoscritto. Nelle 30 domande ho modo di affrontare diversi temi di web project management, più o meno seri, dagli strumenti che aiutano nel nostro lavoro al motivo per cui i siti funzionano bene in tutti i browser fuorché quello del cliente.

Ambient Findability – Intervista a Peter Morville

Pubblicato il da
Risposta

Ho avuto modo qualche mese fa di leggere “Ambient Findability” di Peter Morville, famoso per chi si occupa di Information Architecture in quanto co-autore di “Information Architecture for the World Wide Web” (ho avuto anche modo di intervistare a questo proposito entrambi gli autori).

Leggendo Ambient Findability (che ho recensito per Mytech) mi sono sorte alcune domande che ho condiviso con Morville, che ha gentilmente accettato di rispondere.

Ambient Findability seems in part the answer to the preface written by Jakob Nielsen to the second edition of Information Architecture for the World Wide Web. In it Nielsen talks about the need to teach information architecture at school…Do you agree? How will our children’s lives change in this sense?

In the polar bear book, we focused on enterprise information architecture because large institutions tend to have interesting challenges and the resources required to address them. But I agree with Jakob that from individual and societal perspectives, personal information architecture is perhaps more important.

The lemur book provided an opportunity to explore how the convergence of the Internet and ubiquitous computing will raise the stakes, making information literacy a prerequisite for success in the 21st century. Our children will need to be intelligent consumers and producers of information in an increasingly complex mediascape, and hopefully our schools will help them to keep up.

What is the difference between an information architect and a findability engineer?

The required skills and professional responsibilities of an information architect are fairly well defined. In a wide variety of environments, information architects collaborate with designers, developers, and authors to produce web sites, applications, and experiences.

The number of practicing information architects is significant and growing, and I see that as a real success for the field. In contrast, very few findability engineers exist today, and I’m not sure that should or will change tomorrow. I would prefer that architects, authors, designers, and developers recognize the vital importance and cross-disciplinary nature of findability.

That said, in some organizations, an entrepreneurial findability engineer can make a real positive impact by focusing attention on findability and serving as a bridge between disciplines.

Isn’t Ambient Findability too broad of a term? It spans from finding people to finding internet resources…it seems to me similar to the definition of web 2.0.

Ambient Findability describes a world, at the crossroads of ubiquitous computing and the Internet, in which we can find anyone or anything from anywhere at anytime. In this new reality, the lines between wayfinding and retrieval begin to blur as we use similar interfaces and algorithms for finding information, objects, people, and places. So, while ambient findability is certainly a big picture vision, it’s not difficult to define or imagine.

Some parts of the book seems based on 1984 by Orwell. What if I really don’t want to be found?

GPS, RFID, and other location-sensing technologies raise serious questions about privacy. However, they also promise a wealth of useful services that may save time, money, and lives. My guess is that we will sacrifice some privacy in the coming years, and those who would prefer to stay hidden may find themselves without much choice.

You say that folksonomies and taxonomies are like leaves and trees, but also that they are not mutually exclusive. How can a company use both to build a better product? Are folksonomies useful only in the short period? And are they useful on situations where you are working with a shoestring budget?

From a navigation perspective, it’s quite easy to imagine taxonomies (trees) and tags (leaves) complementing one another. Publisher-defined taxonomies can provide a useful foundation and starting point while user-defined tags can enable the emergence of novel discovery paths and rich cross-linking.

The hard part is creating a context that manages image and incentive. Most large companies are afraid of letting users tag their products. They fear that tags like “thisproductsucks” may harm their image. And it’s unclear how many companies could enlist a critical mass of user participation. So far, Amazon’s foray into tagging has returned disappointing results.

How is the lemur book related to the polar bear book? Are they complementary or not? Do you suggest a specific order in which they have to be read?

The polar bear book provides a practical, in-depth introduction to information architecture. It’s appropriate for aspiring information architects and anyone involved in web development and user experience design. The lemur book offers a conceptual overview of the future of the Internet and ubiquitous computing through the lens of findability. They’re very different books. I suggest reading the last one first. It’s shorter.

In a recent interview you said that the Google search isn’t without bias, even if it’s difficult to see it. Why?

Google is a great company that has made a wonderful contribution to society by making the world’s information more findable. However, like any other company, Google is largely motivated by profit. So, in cases where the needs of users and advertisers differ, it’s likely that Google will favor the paying advertiser. Along these lines, I believe that Google’s moves into personalization are more about targeted advertising than improving relevance.

Potete trovare altre interviste a Morville a proposito di Ambient Findability su Boxes and Arrows ,Aiga e Business Week.

Intervista a Eric Meyer

Pubblicato il da
Risposta

Quando abbiamo deciso di rivolgere qualche domanda ad Eric Meyer, il sito della casa editrice New Riders già ospitava un’intervista, che vi consigliamo di leggere senza indugi.

Per questo motivo abbiamo pensato di rivolgere all’autore qualche domanda un po’ più provocatoria, soprattutto perché ci aiuti a capire quali sono i veri vantaggi dei Css e fino a dove possiamo spingerci nel loro utilizzo.

  1. Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio? [Risposta 1]
  2. Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x? [Risposta 2]
  3. Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”? [Risposta 3]
  4. Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? [Risposta 4]
  5. A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione? [Risposta 5]
  6. Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi? [Risposta 6]
  7. Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica? [Risposta 7]

Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio?

Eric Meyer on Css è quasi interamente pratico in natura. È composto da 13 progetti, ognuno dei quali inizia con un semplice documento al quale vengono applicati stili sempre più complessi. Il testo è stato scritto in modo da consentire agli utenti di seguire il libro e vedere i progetti che evolvono man mano.

I file di base dei progetti, così come tutti quelli che sono stati utilizzati per realizzare le schermate del libro, sono disponibili sul sito dedicato.

Ho creato tutti i progetti partendo da zero, scegliendo ognuno con un occhio rivolto ad un aspetto ben preciso dei Css. Due progetti, ad esempio, trattano quasi esclusivamente del posizionamento, uno si concentra sugli stili per la stampa, un altro si preoccupa dei form e il primo esamina la conversione di un design realizzato con tabelle e font in uno che usa i Css.

Il sito web contiene i dettagli su tutti e 13 i progetti, oltre a del materiale aggiuntivo, ad esempio alcune appendici che sono state eliminate dal libro per preservare spazio.

Top

Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x?

Non penso sia arrivata la fine per le tabelle di layout, e il libro non ha questa pretesa. Se usate delle semplici tabelle per le aree principali della pagina e poi impiegate i Css per i contenuti di queste tabelle, otterrete una pagina decente in Netscape 4.x e la pagina voluta nei browser più recenti.

Ammetto che il libro non prende molto in considerazione Netscape 4.x, ma diciamolo: è un browser vecchio di 5 anni, più di metà dell’era del “web popolare”, quello che è cominciato con il rilascio di Mosaic 1.0. Era un browser contemporaneo di Internet Explorer 3, e di quest’ultimo nessuno ormai si preoccupa più.

Detto questo, se un webmaster si occupa di un sito con un buon numero di utenti che usano Netscape 4.x, allora dovrà fare un po’ di più per andare incontro a questo browser, ovviamente.

La vera domanda è: la pagina deve apparire identica in Netscape 4.x e in Internet Explorer 6?

Per me no. Fintantoché la pagina è comprensibile nei vecchi browser, può apparire leggermente diversa. Un esempio in questo senso è il sito di Fox Searchlight.

Questo sito non è preciso al pixel in Netscape 4.x rispetto ai browser recenti, ma la resa è molto buona. Se non paragonate Netscape 4.x e Mozilla fianco a fianco, probabilmente non vi accorgereste neppure che sono diversi.

Top

Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”?

Non troppo complessa. L’ostacolo principale è che dovete lasciar perdere tutto quello che avete imparato con il layout basato su tabelle. Quando abbracciate il layout basato sui Css, ci sono sicuramente dei cambiamenti. Se però mantenete delle tabelle di base e usate i Css per il contenuto, allora la curva di apprendimento è praticamente lineare. Ogni autore che ho incontrato e che è passato dalle tabelle ai Css mi ha detto che non può credere di aver pasticciato con tabelle annidate in tabelle e spacer gif quando i Css avrebbero reso le cose molto più facili.

Top

Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? Ecco alcune possibili cause che vorremmo esplorare con te:

perché sono pochi gli sviluppatori che usano i Css per il layout e così i produttori di browser non sentono la necessità di migliorarli

Questo poteva essere vero nel 1998, ma non oggi. Praticamente ogni sito usa i Css in qualche modo. Sono d’accordo che molti li usano senza sfruttarne le potenzialità, ma la maggioranza li usa almeno ad un livello che potremmo definire moderato. È comunque vero che alcuni siti mischiano i Css con i tag font, il che è una sciocchezza. Gli autori dovrebbero usare uno o l’altro, ma non entrambi nei loro design.

perché le specifiche Css sono scritte in inglese, e ogni lingua è per definizione ambigua (molti non sono bug, ma diverse interpretazioni delle specifiche)

Questa è una parte del problema. Ci sono stati casi in cui le specifiche Css 2 erano contraddittorie, come ci si può aspettare da un documento di grosse dimensioni. Il Css Working Group sta cercando di risolvere questi limiti con le specifiche Css 2.1, che sono quasi complete. Comunque ogni documento scritto in un linguaggio per umani è aperto alle interpretazioni.

perchè i Css sono complessi e così è complessa la loro implementazione

Questo è esattamente il nocciolo della questione. I Css sembrano molto semplici quando gli date un’occhiata, ma in realtà sono così complicati che la maggior parte dei comportamenti inaspettati sono in realtà casi particolari. Alla fine degli anni 90 i produttori di browser non hanno prestato la giusta attenzione alle sottigliezze dei Css, o hanno scelto deliberatamente di ignorarle. Solo in tempi recenti hanno cominciato a correggere gli errori fatti.

perché il layout basato su Css è una materia nuova

Penso che il layout basato sui fogli di stile sembri nuovo perché solo recentemente i browser li gestiscono più o meno correttamente, così da farci prendere in considerazione la loro adozione.

Top

A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione?

Uso @import per nascondere i Css a Netscape 4.x, quindi penso che questi stratagemmi possano benissimo essere utilizzati: ho impiegato alcuni di questi trucchi almeno in uno dei progetti per il libro. Penso comunque che sia facile eccedere nel loro utilizzo. Se il vostro foglio di stile è composto per metà da trucchi e regole che si appoggiano ai bug dei browser, state probabilmente sbagliando l’approccio. A me è capitato di scartare alcune progettazioni perché troppo avanzare per i browser di oggi senza impiegare un gran numero di trucchi. Questo accade per tutti i media e non è una sorpresa che si verifichi anche nel web.

Personalmente non mi piace l’uso di codice lato server per riconoscere il browser, perchè è un procedimento che introduce un carico extra al server ed è utile in pochissime situazioni. L’unico caso in cui questo sforzo è necessario si verifica quando il contenuto deve variare a seconda dei browser. Se invece volete inviare Css diversi a browser diversi, probabilmente state scegliendo una soluzione inutilmente complessa: un solo foglio di stile dovrebbe essere sufficiente.

Top

Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi?

A dire il vero, quando Wired è stato convertito ad un layout basato sui Css, i loro problemi con il codice valido riguardavano esclusivamente la codifica degli Url, non il markup. Ci sono pagine vecchie di 3 anni che non sono valide, ma possono essere sistemate gradualmente. Comunque la pagina principale del sito è valida, o almeno lo era quando la ho scritta io.

Se usate i Css per il layout, è più semplice ottenere pagine valide perché il codice è più semplice e più logico. Invece di districarvi tra tabelle annidate e tag td avete la possibilità di concentrarvi sui paragrafi e sui div. Quando ho abbandonato le tabelle dal mio sito personale a Gennaio 2002 è stato molto più semplice convalidare le pagine e correggere gli errori di validità.

Top

Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica?

Lo standard Css non sarà mai realmente completo. La sua evoluzione potrebbe cessare un bel giorno, ma ci sarà sempre qualcuno che si lamenta perché non fa quello che lui vuole.

Così com’è oggi, lo standard non dispone di un modo per legare un elemento ad un altro in termini di layout: non potete dire “rendi questo elemento alto come quest’altro”. Sarebbe una caratteristica che aiuterebbe il posizionamento degli elementi, e forse sarà aggiunta in un prossimo futuro, ma dovremmo poi gestire qualcosa di complesso.

Penso che nessun linguaggio di presentazione, non importa quanto ricco e potente, potrà mai soddisfare tutte le richieste degli autori.

Il fatto che una caratteristica mancante sia importante oppure no dipende dalla persona a cui si pone la domanda. Quella che per me è una lacuna cruciale, potrebbe essere di importanza minima per qualcun altro, e viceversa.

Un esempio è dato dalle “variabili”, la possibilità di definire una parola chiave e assegnarle un significato, per poi utilizzarla da qualunque parte all’interno del foglio di stile. Conosco alcuni autori che pensano si tratti di un’enorme lacuna dello standard, ma personalmente la cosa non mi ha mai preoccupato.

Top

Eric Meyer è uno “Standards Evangelist” per Netscape Communications, il che vuol dire che cerca di spargere la voce sul perché gli standard sono una “cosa buona”. Realizza soluzioni basate sugli standard ed è anche l’autore di 3 libri, nonché di un gran numero di articoli. Il suo principale ambito lavorativo è rappresentato dai Cascading Style Sheets, in parte perché è stato uno dei primi ad adottarli, ma soprattutto perché li trova infinitamente affascinanti e utili.