Ciao, è da poco che utilizzo drupal.
Ho sempre lavorato in modo piuttosto statico (non scendo nei particolari).
Quindi bene o male lavoravo su contenuti che avevo già in mano (tranne in pochi casi, ma al massimo si trattava di db particolari: immobiliari / auto usate, dove vi erano delle "schede" uniche, un solo tipo di contenuto)
Invece ora ho a che fare con una nuova dimensione.
Quindi mi è già capitato più di una volta (e in poco tempo) di lavorare con persone che richiedono determinati contenuti, per poi rendersi conto, al momento dell'inserimento dei vari testi & co., che vorrebbero altro.
Cercando di capire come lavorano altri, sono venuta a sapere ad esempio che una persona lavora chiedendo PRIMA al cliente di inserire un po' di contenuti (lasciano il garland come tema), POI lavorano di tema & co.
E voi? come fate?
Be, prima di iniziare un lavoro, passo un po di tempo per studiare la pianificazione del progetto e segno tutti gli intrecci su carta. In genere cerco di avere tutte le informazioni sin dall'inizio, ma organizzato ed ordinato comunque in modo tale che sia tranquillamente modificabile senza troppi problemi anke successivamente.
Dipende dal lavoro,ma in linea di massima procedo così:
-Tassonomia
-Tipi di contenuto collegati alla prima
-Estrapolazione dei dati con il views
In tal modo creo una prima struttura su cui lavorare. Il tema non è una necessità urgente, tuttavia la scelta delle regioni da avere a disposizione è necessario pianificarla subito.
Tutorial, guide e moduli per drupal su www.cmswiki.net
mi sono trovato non molto tempo fa a pormi lo stesso tipo di domande.
Da bravo noob, mi son messo in ricerca di guide/informazioni; alla fine ho preso questo articolo come modello.
C'è tutto, in particolare trovo importante la razionalizzazione delle attività.
Dimensionato al caso specifico funziona ottimamente come base di partenza per impostare un nuovo progetto.
Secondo me, ovviamente. ;)
Certified to Rock
Ottimissimo articolo postato da Bhoz! ... direi che la modalità mostrata nel Case Study su Drupal.org è quella che in qualche modo si fa un po' ovunque solo che probilmente ognuno personalizza le proprie fasi .... per farti un esempio posso diti come ho operato io in alcuni casi.
Spesso il compito più complicato è quando si ha a che fare con clienti "poco pratici" che magari non conoscono la nostra modalità di lavoro o semplicewmente non hanno mai avuto a che fare con lavori di sviluppo web e quindi ci vengono a chiedere nel bel mezzo del progetto modifiche prima non avevano neanche lontanamente accennato, quindi il mio consiglio è farti una bella tabella di cose che per te sono essenziali sapere in anticipo e che non possono essere cambiate nel bel mezzo del progetto e fargli capire che alcune cose le deve decidere lo stesso Cliente all'inizio... in questo modulo eviti di farti CESTINARE per una stupida modifica settimane di lavoro e allo stesso tempo cliente sà chiaramente quello che può chiedere e quello che non può chiedere.
- Altra cosa che posso consigliarti è lasciare la Grafica alla fine, prima cerca di far funzionare il sito....
- Una fase di transizione è essenziale: far testare il sito al cliente quando ancora non è finito, fargli testare diverse soluzioni, osservare come il cliente usa il tuo sito e modificare o adattarlo alle sue esigenze ... sono tutte cose che a mio avviso sono nevessarie se si vuol soddisfare il cliente.
- Perosnalmente utilizzo quasi indiscriminatamente Wordpress e Drupal o cose statiche per progetti che mi vengono chiesti, tutto dipende da cosa mi chiede il cliente, una cosa che senza dubbio non dimentico mai è "tenere bene a mente" la morfologia del CMS che sto utilizzando: in altre parole quando presento soluzioni, propongo e o cerco di mettere sul piatto soluzioni che il cliente dovrà accettare o meno... cerco di non dimenticare mai come funziona il CMS su cui stiamo lavorando. In questo modo Assecondo in qualche modo la logica di funzionamento per esempio di Drupal e in qualche modo non andiamo a sfociare in modifiche da far rizzare i capelli ....
Una cosa che ho imparato che senza dubbio è la più importante è mostrare chiaramente al CLIENTE solo cose di cui siamo realmente in grado di riealizzare e/o far realizzare a qualcuno tramite nostre conoscenze... mai mostrare o proporre soluzioni che poi in realtà non saremo in grado di riproporre nella realtà.
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
Domanda interessante, e risposte altrettanto.
Penso che fondamentalmente si tratta di comunicazione. Se si tratta di un sito con modello ben conosciuto da entrambi le parte, la strada è abbastanza chiara (ma non necessariamente liscia). Diamolo il colore bianco. Dall'altra parte il modello potrebbe essere innovativo, e/o poco conosciuto, o peggio con due modelli diverse (quello del cliente, e quello del drupalista). Questo è nero. Poi abbiamo tanti sfumature dl grigio in mezzo.
Ho letto l'articolo suggerito da bohz con interessa perchè
scritto in inglesemetteva molto in evidenza le tappe 'comunicativa', senza entrare troppo in dettagli tecnici. Altrettanto quel modello lascia molti spazi per le modifiche - che sono inevitabile IMHO.Qui sono in disaccordo con matteofro, perchè credo che sia praticamente impossible avere "tutte le informazioni sin dall'inizio", il massimo che posso pretendere è di capire le esigenze principale, e dargli un livello di grigio. Più scuro il grigio, più sarà necessario la comunicazione.
Anche nel programmazione si tentava, con grande accumulo di spese, e carta, di creare 'le specifiche' su quale i programmatori dovevano fare riferimento quasi religiosa. Poi passava mesi, forse anni, ed arrivava il sistema completato - ma che nel fratempo era stato reso ridondate dai cambiamenti di mercato. Ora si parla di agile programming, anche fin troppo, ma la logica IMHO è ragionevole.
Cioè se tutto intorno a noi cambia, il mercato, le comunicazioni, le tecnologie, il tempo, anche molto rapidamente, allora invece di 'strangolare' il cambiamento, dobbiamo abbracciarlo, renderlo facile. Questo si fa con piccoli iterazioni di pezzi del insieme (comunicando col cliente). Il risultato è quasi sempre diverso a quanto pensato dal inizio, ma anche quasi sempre corrisponde alle esigenze del cliente oggi, che sono diverse a quei esigenze iniziali, magari un, tre, o sei mesi fa.
Ho anche trovato interessante (in quel articolo) il discorso di staging (loro li chiamava alpha), di wireframe, e l'interfaccia programmatore/grafico. Io uso tutte e tre. Un graduale cambio del 'look' del sito da wireframe/grigio al rivestimento professionale del sito finale è anche un ottimo modo di dare 'tangibilità' al lavoro del programmatore/grafico che altrimenti rimane difficile da comprendere al cliente.
Il problema che io trovo più difficile è fare capire al cliente che il C in CMS lo deve fornire lui in qualche modo...
Comunque morale della favola: comunicazione, comunicazione e comunicazione.
Più imparo, più dubito.
concordo con tutto quello che dice jhl.verona... diciamo che ognuno ha le sue abitudini nel presentare il proprio lavoro al cliene ma grossomodo accompagnare l'intero progetto con bozze e wireframe sia in termini grafici che di funzionalità del sito ... può solo agevolare il rapporto tra il cliente e noi in generale.
Noi riusciamo ad offrire un prodotto più conforme alle richieste del cliente, e quest'ultimo riuscirà sia a capire il nostro percorso e allo stesso tempo viene messo in condizione di poter dare gli input corretti, perchè spesso secondo me il cliente non sà davvero cosa e come chiederlo anche se ha ben in mente quello che vorrebbe!
Solitamente ciò che è complicato al cliente a noi è di facile risoluzione e vicevera... :D
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits