In this article I’m talking about The Ugly Prototyper a concept idea for a prototyping functionality.

When I start a web project sometimes I need to think about the size of the element on a page.
You are saying “never heard about photoshop/fireworks/flair builder/other prototyping software?” yes, I’ve done my homework, tryed lot of them and discovered that none give me the possibility to input a percent of the father element and get a new object of the proper size.

Practically we have to rely only on us eyes to decide if the logo (or content area) is big enough.
We put elements on page, size them and only then mathematically calculate their encumbrance (when this happens).
It’s a trials and errors method.
I don’t like at all.

If you are designing with a content-driven method you have to decide the right priority of the page elements, I think that a good starting point is to say:”the content area cannot be less than the 33% of the page, the header must be no bigger than 25%, ads will be 25%”, visually see it, modify and then (only then) start with the real prototyping and design.

So I developed my tool.
I made it in few nightly hours, sorry, it lacks of functionality and usability.
You have to reload a page if you change the working area size after creating some child and a lots of others problem.
In my excuse: this is not a release!
The Ugly Prototyper is on line just to be showed to my friends and to gather opinions

Italiano:
In questo articolo parlo di The Ugly Prototyper, un concept per uno strumento di prototipizzazione.

Ho provato diversi software per la prototipizzazione delle pagine web (e più genericamente delle interfacce) e non ho trovato nessuno che mi fornisse la possibilità di inserire una percentuale ed ottenere in cambio un oggetto della dimensione giusta.
Lo trovo strano, perchè in questo modo per il posizionamento contiamo solo sul nostro occhio che potrebbe non essere abbastanza allenato.
Penso che in fase di progettazione, specie se usiamo un approccio content-driven, sarebbe un buon punto di partenza poter decidere che l’header non debba essere più grande del 25%, i contenuti non più piccoli del 33% visualizzandone gli ingombri per poi partire con la prototipizzazione ed il design reali.

Nessuno me lo faceva e così ho creato il mio tool.
è stato sviluppato in poche ore notturne, quindi ha parecchi problemi, tra cui che non ha un sacco di funzionalità comode e necessarie, che bisogna ricaricare la pagina se si cambiano le dimensioni dell’area di lavoro dopo aver già creato almeno un oggetto ed un sacco di altre cose.

A mia discolpa posso dire che questa non è una release (e forse non ci sarà mai una release).
The Ugly Prototyper è messa on line per farsi vedere dagli interessati e raccogliere qualche opinione.

Nell’ultimo ufficio dove ho lavorato avevamo una lavagna.
Sulla lavagna c’erano scritte cose utili e cazzate (quasi solo partorite da me), ma soprattutto c’era segnato anche il nostro decalogo di internet.

E’ un decalogo composto da 3 regole, le prime due parlano di idraulici e per il momento le lasciamo perdere perchè non siete pronti per qualcosa di così strano, ma la terza invece recita:

3. Quanto costa il tuo barattolo di marmellata?

Esplica il concetto che tu puoi fare anche la marmellata più buona del mondo, ma se, al barattolo, costa troppo non la venderai mai, perciò in base a questa regola la qualità di un lavoro deve essere abbassata finchè il costo della produzione non consente un buon guadagno.

Naturalmente non può essere così perchè se un’azienda che fa siti web dovesse abbassare la qualità del prodotto fino ad incontrare l’aspettativa di prezzo dei clienti staremmo ancora facendo siti con il tag marquee (pessimo esempio, io adoro il tag marquee. Remember, real spartans use tag marquee).

Tra uno scherzo e l’altro sono stato “accusato” di produrre marmellata codice biologico (e quindi troppo costoso) ed io ci ho pensato seriamente su.

Esiste davvero del codice biologico?
Ho deciso di no.
La qualità di un progetto dipende essenzialmente da due fattori: la bontà del codice del programmatore meno abile e la data di scadenza.
è compito di chi progetta il software stabilire quanto tempo ci vuole per sviluppare le features richieste oppure decidere quali features possono essere incastrate nel tempo che viene concesso dall’alto.
Il codice biologico è un mostro della mente che viene fuori nel momento in cui si vogliono inserire troppe features nel tempo a disposizione.
Mi sembra quindi ovvio che il problema non è né nel codice né nello sviluppatore, ma in chi fissa i tempi.

Al momento mi sto dedicando a creare un nuovo ramo del mio sito, essendo esso un frutto delle mie personali fissazioni (cfr. “orizzontale è più leggibile”) i requisiti sono:

• la pagina non deve avere alcuno scroll verticale a nessuna risoluzione
• essere integrato con i vari social network
• avere la possibilità di commentare i post (no, non è un blog)
• ajax dappertutto perchè a me non piace ricaricare la pagina
• essere usabile

Questi paletti che ho posto al progetto complicano tutto, perchè se da un lato quello che deve fare la pagina è una banalità (lo vedrete) far interagire tra loro i 5 punti precedenti complica orrendamente la faccenda.

Siccome sono pigro e non voglio perdere un sacco di tempo a correggere bug e ad aggiungere funzionalità a “oggetti” non predisposti a riceverle questa volta ho deciso di non commettere l’errore di farmi trascinare nel programmare la funzione più interessante per poi aggiungervi “metastasi” che per funzionare richiedono trucchetti e difettano di solidità.

E’ qui che entra in scena il “progressive enhancement” di cui si legge tanto in giro e che sto applicando per step:

1. creazione della pagina statica (html/css)
2. dinamicizzazione della pagina lato server (php)
3. aggiunta di ajax (javascript/jquery)

1. creazione della pagina statica (html/css)

Tenendo in mente che la pagina non deve avere alcuno scroll verticale ho scelto di progettare il layout con tutte le dimensioni espresse in em utilizzando font-size:16px ed un’altezza della finestre di 649px in modo che nel punto 3 del progetto con il javascript dovrò cambiare solo il font-size del body per ridimensionare tutto.

E come ben sapete progettare un layout in em è un bagno di sangue (anche se ho trovato un buon sistema che avrà un post in seguito) ed un po’ di tempo è andato.

2. Dinamicizzazione della pagina lato server (php)

Lasciando (ovviamente) inalterato il layout il contenuto della pagina viene creato dinamicamente da funzioni php che restituiscono i dati in base ai parametri ricevuti in $_GET dai link, quindi nella pagina vengono inseriti tutti i necessari controlli di flusso

3. Aggiunta di ajax

A me l’ajax piace tanto, infatti oltre a far figo nel mio curriculum aggiunge una dimensione fluida alla navigazione che a mio avviso migliora la fruibilità (meglio una gif “loading” o la cesoia della pagina bianca con la clessidra che gira?).

Le funzioni richieste al js sono:

• cambiare il font-size del body in funzione della dimensione della finestre (in questo caso: $(window).heigth()/40 (jquery)
• intercettare i click dell’utente sui link e trasformali da “hey browser segui quel link” a “hey browser XMLHttpRequest con questi parametri“.
• segnalare all’utente che le sue azioni intercettate dal js non sono cadute nel niente, ma stanno eseguendosi

Se siamo tutti d’accordo nel dire che un progetto web sviluppato da un professionista richiede (almeno):

• una totale separazione tra layout, contenuto e codice, perchè così ognuno fa il suo mestiere senza disturbare gli altri (l’epoca del one man show sul web è finita assieme agli anni ’90)
• “graceful degradation“, perchè nel 2008 ancora qualcuno gira con javascript e flash disabilitati (paranoici!)
• mantenibilità nel tempo, perchè non vogliamo mettere noi stessi ed in nostri colleghi in difficoltà tra 3 mesi vero?

scopriamo che i 3 step elencati sopra ci consentono di ottenere quasi automaticamente queste 3 caratteristiche, infatti la graceful degradation è garantita dal fatto che ogni strato è stato programmato in maniera da funzionare autonomamente, la mantenibilità è garantita dalla progettazione che abbiamo dovuto per forza fare per separare gli strati mentre la totale separazione è garantita solo se abbiamo fatto i bravi nella costruzione delle funzioni php (se parliamo di me diciamo che ancora non sono un campione in questo).

Ecco descritto quindi il progressive enhancement in salsa lghinelli, nel mio progetto e nel mio tempo libero sta funzionando ed anche bene, ma quanto tempo ci vuole in più a sviluppare un progetto in questo modo?

Non ne ho idea, ma  sono quasi sicuro non ci voglia del tempo in più, a patto che tutte le persone coinvolte nel progetto siano concordi nell’applicare il metodo e perciò non cerchino scorciatoie facili.

Il problema è quindi squisitamente umano piuttosto che tecnico:

saranno disposti i membri del team di sviluppo a modificare le abitudini che si sono incrostate in una vita?

E sarà disposto l’uomo che sgancia i soldi ad investire nella formazione sapendo che sicuramente il primo progetto sviluppato in questo modo avrà degli intoppi?