Scegliere di utilizzare un framework è di norma una scelta abbastanza difficile e scegliere quale usare  fra i tanti lo è ancora di più.

Se siete abituati a lavorare “a mano” una scelta standarizzata non può che suscitare qualche dubbio, è come dire ad un falegname di utilizzare i mobili dell’Ikea per i suoi lavori. La soluzione “standard” è infatti funzionale nel 99% dei casi mentre nel restante 1% rappresenta un problema in più da risolvere.

Sicuramente prima di prendere una scelta occorre fare le dovute valutazioni e porsi qualche domanda.

1) Obiettivo: Cosa posso fare con questo framework?

Il primo dubbio che devi risolvere è quale obbiettivo certo puoi raggiungere, non farti affascinare da addon, plugin, opzioni avanzate ed analizza il potenziale del framework senza aggiunte, è ciò che stavi cercando?

2) Compatibilità: funziona in tutti i contesti di utilizzo?

Pensa all’utilizzo finale, i vari contesti di utilizzo (browser, sistemi operativi, server) possono presentare problemi, verifica sempre se e come vengono risolti nelle specifiche casistiche.

3) Qualità: E’ conforme agli standard?

Nessuno parte con l’intenzione di fare un lavoro scadente, una sintassi poco elegante, prestazioni non ottimizzate e poca attenzione agli standard possono essere buoni motivi per provare altro.

4) Specifiche tecniche: Su che versione si basa questo rilascio?

Un prodotto aggiornato si basa su tecnologie aggiornate ma retrocompatibili, iniziare a lavorare con un framework obsoleto compromette seriamente le possibilità di utilizzo nell’immediato futuro.

5) Personalizzazione: Posso aggiungere parti modulari per personalizzare questo framework?

E’ corretto che esistano dei limit di utilizzo, altrimenti non servirebbe più l’essere umano per valutare e compiere scelte :) ma deve esistere la possibilità di superare questi limiti con un minimo di personalizzazione.

6) Utilizzo: Che licenza è stata associata a questo progetto?

Hai trovato il framework perfetto per te, ora vuoi usarlo ma puoi? Verifica la licenza e controlla se è rivendibile, modificabile ed utilizzabile e a quali condizioni. Non sempre le cose migliori sono a pagamento ma può anche essere vero il contrario, informarsi aiuta a farsi un’idea su che quali sono le offerte al momento, non è detto che domani la licenza cambi o che tu abbia un budget da investire in un valido prodotto.

7) Supporto: Esiste una documentazione per utilizzare questo framework?

Per utilizzare un framework occorre conoscerlo e bisogna avere la possibilità di avere almeno una documentazione di riferimento, se il progetto è abbastanza maturo di norma esisteranno già dei tutorial e siti specializzati nell’offrire le informazioni necessarie per iniziare. Qualche ricerca preliminare può aiutare a trovare risorse per capire la qualità e la quantità di documentazione di supporto.

8) Comunità: Esiste una comunità di utenti che utilizzano questo framework?

Una comunità di utenti è una dei maggiori vantaggi , oltra al supporto, documentazione ed esempi che si creano si è certi di non essere soli e che la nostra scelta è comune a molti altri sviluppatori che avranno valutato prima di noi questo framework.

9) Testimonianze: Chi ha usato questo framework me lo consiglierebbe?

Avere un feedback sulla qualità è sempre una buona cosa, dal numero e dal giudizio espresso dagli utenti si capisce al volo se il progetto merita o meno la nostra attenzione, cercare in rete o sul sito una recensione può farci risparmiare molto tempo e ci da più elementi per una scelta ponderata.

10) Limitazioni: L’utilizzo di questo framework limita in qualche modo l’utilizzo di altre tecnologie?

E’ possibile che un framework non sia compatibile con altri o limiti l’utilizzo di determinate tecnlogie, prima di usarlo sarebbe opportuno conoscere eventuali controindicazioni di norma segnalate nella documentazione.

11) Affidabilità: Chi porta avanti questo progetto?

Non è mai bello essere abbandonati, affidarsi ad un framework e scoprire un giorno che il progetto ha chiuso può essere davvero un grave problema, occorre appurare se questo progetto è attivo al momento e ha il potenziale per essere portato avanti. Sarebbe meglio affidarsi a progetti portati avanti da un team piuttosto che da un singolo per avere maggiori certezze sulla longevità del framework.

12) Apprendimento: Quanto tempo mi richiede imparare ad usare questo framework?

Il tempo è sempre una variabile da considerare, più è complesso ed ampio un framework più tempo richiederà per conoscerlo a fondo, se non avete molto tempo a disposizione conviene cercare qualche tutorial o una guida introduttiva per iniziare.

13) Vantaggio: Quali vantaggi presenta l’utilizzo di questo framework rispetto all’uso tradizionale della tecnologia?

Normalmente il grande vantaggio di un framework è quello di ridurre i tempi di sviluppo se dopo un periodo di prova non si riscontra nessun beneficio è meglio cercare altro.

14) Comodità: Questo framework è compatibile con il mio modo di lavorare?

Se una persona è abituata a fare siti con le tebelle difficilmente troverà comodo e intuitivo un framework css.

Bisogna sempre valutare la compatibilità della proposta con la propria metodologia di lavoro per utilizzarla senza sconvolgimenti.

15) Provare

Per quante informazioni puoi trovare l’unica soluzione per prendere una scelta è quella di provare, le domande precedenti servono a “scremare” i frameworks e a limitare la scelta a pochi se non ad uno.

Se è possibile scarica il framework ed utilizzalo per le operazioni più comuni, valutane la comodità e la semplicità di utilizzo, la compatibilità e se incontri problemi cerca delle soluzioni con il supporto nella documentazione, ti aiuterà a farti un’idea di come sia utilizzarlo nel lavoro, dedica un po’ di tempo a questa operazione soprattutto se hai già scartato altre alternative, se infine non ti trovi bene potresti provare altri frameworks oppure pensare di svilupparne uno tuo risolvendo i problemi che hai incontrato su quelli esistenti.

Una buona risorsa per iniziare a gestire queste problematiche è OSCON un buon esempio di contratto open source, è scaricabile, modificabile ed utilizzabile per i progetti di aziende e freelance.

Essendo un argomento delicato merita una lettura e qualche modifica prima dell’utilizzo per essere una soluzione personalizzata efficace ma rimane un ottimo punto di partenza per definire un contratto per progetti web.

Ho visto molti web designer lamentare questa situazione fin troppo comune e finire con il giustificare il tutto con un’errata percezione del settore.

Per coloro che pensano che le cose vadano male solo in Italia propongo questo articolo, di Sarah Parmenter, giovane web designer inglese che si trova a dover gestire un cliente che richiede un sito sul calibro di CBBC (il canale per bambini della bbc per intenderci) per la cifra di 500£ (563 euro in nostra valuta).

La cosa che mi ha piacevolmente sorpreso è come viene trattata professionalmente la questione, dinanzi ad una richiesta eccessiva e ad un budget irrisorio viene esposto chiaramente quale processo c’è alle spalle della creazione di un sito, di come non sia possibile “fare una cosa semplice” e poi trasformarla in un portale in un secondo tempo.

Questa spiegazione diciamo “di cortesia” ha sicuramente un grande valore, ma la parte che personalmente preferisco è dove indica con precisione quale sarebbe il compenso orario a persona per realizzare il sito: meno di 2 £ all’ora.

Di fronte a questo numero il cliente non si è più fatto vivo, per fortuna aggiungerei.

Il metodo utilizzato da questa web designer mi sembra un buon esempio di gestione del cliente che evita di iniziare progetti già in perdita.

Se analizziamo la lettera i passaggi sono semplici.

1) Cosa occorre fare per realizzare il progetto

2) Quanto ci vuole per realizzare il progetto

3) Differenza tra budget proposto e tempo necessario

Un errore nel calcolo dei tempi può sempre accadere, una modifica aggiunta a fine lavoro può anche essere tollerata ma nel caso proposto si vede quanto la differenza tra il budget effettivo ed il budget necessario sia enorme.

E’ possibile leggere l’articolo completo sul blog di Sarah Parmenter