Mi trovo dal cliente con l’art director per illustrare la tavole grafiche del progetto. Ha apportato le ultime modifiche ieri sera e non siamo riusciti a rivederle insieme. Apre il portatile e fa doppio clic su figo.psd.
Il collega che si occupa del frontend manda un’email con le ennesime correzioni richieste dall’azienda che si occuperà dell’integrazione. Una volta decompresso il file, nel desktop compare la cartella che_palle.
Sono due esempi, ma potrei tranquillamente continuare per ore e ore senza mai ripetermi. Ok_bis_def.zip, altra_prova.psd, oggi_non_ho_idee.png: ho a disposizione un’intera letteratura di nomi insignificanti e imbarazzanti.
Stufo di passare le giornate a rinominare i file e inviarli ai diversi attori (ammesso che fossi ancora in tempo) ho messo a punto un semplice sistema di nomenclatura che cerco di applicare e fare applicare.
Il consiglio è quello di partire già dalla stesura dei wireframe, per proseguire nel corso della progettazione grafica fino ad arrivare allo sviluppo delle pagine HTML. Ogni wireframe va correttamente nominato prima di consegnarlo all’art director, che solitamente è ben felice di conservare la creatività per altri compiti.
Ho provato in questi anni diversi tipi di nomenclature, ma quella che si è rilevata più efficace nasce da un compromesso tra nome dal contenuto altamente informativo e semplicità di applicazione della regola.
Un tipico esempio di nomenclatura potrebbe essere il seguente:
- HP010
- PR010
- PA010
I primi due caratteri indicano la sezione del sito a cui la pagina fa riferimento (in questo caso HP sta per homepage, PR per scheda prodotto e PA per processo d’acquisto), mentre il numero indica il progressivo della pagina all’interno della sezione (HP010 potrebbe essere l’homepage generale, HP020 la declinazione per il periodo natalizio, ecc.). Utilizzo le decine e non le unità per rappresentare i progressivi perché, se ci accorgiamo di aver dimenticato un template che “logicamente” va inserito tra altri due, lo possiamo includere (ad esempio HP015).
Come è facile vedere la regola è banale, ma proprio per questo altrettanto semplice da applicare. A me ha risparmiato molto tempo, ma soprattutto ha permesso di verificare a colpo d’occhio se i template realizzati erano, in ogni fase, tutti quelli previsti.
P.S.: se, come me, avete il pallino delle nomenclature, vi rimando a un articolo che ho scritto quasi 10 anni fa (il tempo passa) e che affronta tra le altre cose il tema dei nomi da dare e non dare alle regole CSS: Chi ha paura di Xhtml 8?
Ciao Antonio, il problema in effetti esiste ed è anzi ricorrente. Anche io ho il pallino dei nomi (e dei subject delle mail, per rintracciarle velocemente in futuro), ma ti faccio una domanda: come mai hai scelto una sigla di 2 lettere?
Io preferisco utilizzare una nomenclatura estesa, auto-esplicativa e gerarchica tramite “camel case” se necessario, tipo ordine_anagrafica_errore.png (processo d’ordine – step inserimento dati anagrafici – gestione degli errori), cosi’ che sia chiara per eventuali collaboratori futuri ma anche, e soprattutto, per il cliente.
Chiaramente in questo caso diventa indispensabile la radice del nome, affinché tutto rimanga ordinato. Ottimo consiglio quello delle decine, invece dei classici “_v2”, “_2” o “b” :-)
Uso una sigla di due lettere per evitare la proliferazione di nomi di lunghezza infinita. Non potendo avere sempre in prima persona il controllo sulla nomenclatura di tutte le pagine, ma dovendone delegare la creazione, preferisco porre fin da subito questo limite.
E’ un atteggiamento che ho imparato quando, anni fa, mi trovavo a sorridere guardando i nomi delle tabelle di alcuni gestionali di vecchia generazione, che limitavano la lunghezza a 8 caratteri. “Che obsoleti” – ho pensato come prima cosa – “oggi non c’è limite al numero di caratteri nel nome di una tabella o di un campo”. Poi col tempo ho capito che il limite permetteva a tutti quelli con un minimo di esperienza di capire esattamente di cosa si trattasse.
Riguardo alle decine, non mi riferivo in realtà al numero di versione, ma a template diversi della stessa sezione del sito. Per le versioni, la strategia che per me funziona meglio è quella di avere cartelle diverse, mantenendo lo stesso nome del file.
Trovo l’articolo interessante in se e condivisibile, ma per chi come è nato programmatore sa bene quanto è importante il nome dei file almeno quanto il nome delle variabili all’interno di un progetto.
Però oggi l’idea di di un sistema di nomi a due cifre è quanto meno arcaico e fuorviante, preferisco come per la programmazione usare nomi convenzionali ma associati non ad una sigla o un numero ma qualcosa che definisca l’oggetto.
Ad esempio tre o più lettere che identifichino il progetto: fcnw_ per fucinaweb e poi dopo l’underscore, una descrizione dell’immagine fcnw_homepage_header_logo.gif che sia coerente con il progetto.
Anche per gogle non ci sono grossi problemi dato che anche il nome dell’immagine è meno criptico di un HP0001 che verrebbe mal indicizzato dal motore di ricerca e non mi deve far perdere del tempo a creare un nome significativo.
M.
Ciao Marco. Non parlavo in realtà degli asset del sito come immagini, fogli di stile e altro tipo di risorse, ma di una nomenclatura per definire wireframe, template (PSD) e HTML statici. Di questi nomi nel progetto finale non rimane nulla, quindi non ci sono ripercussioni lato SEO.
Per evitare sigle del tipo homepage_box_rivisto_rosso.psd preferisco dare delle regole forse rigide, ma facili da seguire.