la complessità di OOOGUI

2011-03-02

00:05:50

dopo il rilascio di OOOGUI qualche sito (sia italiano che estero) ne ha riportato l'annuncio, e tra i lettori è scattato un minimo di dibattito. le critiche mosse sono più o meno ciò che ci è stato detto dalle poche persone che hanno avuto modo di metterci le mani prima del rilascio: è troppo complesso (non si capisce un cazzo!)


il problema è che OOOGUI non vuole in nessun modo essere un competitor di Wordpress, Joomla, Drupal ecc.., così come non ci aspettiamo certo che possa essere utilizzato con un tablet dal divano di casa. non è questo lo scopo per cui è stato creato. quando i nostri clienti ci chiedono un modo semplice, veloce, intuitivo di fare un sito web, siamo noi i primi a consigliare l'utilizzo dei cms più in voga oggi, sappiamo bene che OOOGUI non è adatto all'utente che cerca queste qualità.

in proposito abbiamo pubblicato nel nostro sito una pagina che chiarisce quale sia il nostro target, ma è evidente che questo messaggio non è passato :-)


il nostro target è lo sviluppatore di backend custom, il programmatore che ha come pane quotidiano quello di modellare database, scrivere query, e creare pagine di amministrazione per il data model così definito. nella mia esperienza lavorativa sono sempre stato costretto a creare manualmente tutto il codice necessario a questo scopo, ed è così che pian piano, negli anni, è nato OOOGUI. il nostro utilizzatore ideale è un programmatore, uno che ha ben chiaro in mente cosa voglia dire creare un oggetto, sia dal punto di vista della sua persistenza (data model del db), sia dal punto di vista della sua amministrazione (pagine per creare/modificare record nelle varie tabelle del db), sia, infine, dal punto di vista della sua rappresentazione (le pagine pubbliche del sito, insomma la view del modello). e questo, purtroppo, né Joomla né Wordpress né Drupal lo fanno. ci sono cms che si sono mossi nella nostra direzione (come ezPublish), ma non sono certo considerati i più semplici sul mercato, oppure ci sono framework (come RubyOnRails) che aiutano il più possibile a ridurre il codice da scrivere, ma comunque sia, proprio perchè framework, non hanno alcuna interfaccia visuale: tocca comunque scrivere codice.


OOOGUI entra in gioco proprio qui: se il vostro cliente non si accontenta di gestire news, paginette, gallery, e in generale moduli predefiniti, ma vuole qualcosa di custom, oggi sono pochissimi i cms che supportano la completa amministrazione del data model, oltre ovviamente alla generazione del codice necessario per farlo. noi ci siamo mossi in quella direzione, e ve lo dico fuori dai denti, è stato tuttaltro che banale, e sicuramente il risultato ottenuto è tuttaltro che ineccepibile. rappresentare con un'interfaccia visuale una query, o un oggetto, o una relazione, può essere fatto in un milione di modi diversi, ma comunque presuppone che l'utilizzatore abbia chiari in mente i concetti di cui si sta parlando, altrimenti il problema non è proprio rappresentabile o intellegibile.


infine una precisazione riguardo l'utilizzo di flash: sempre in una pagina del nostro sito abbiamo spiegato anche questo punto, che riassumo qui: flash (flex, per la precisione) è stato scelto svariati anni fa, all'inizio dello sviluppo di OOOGUI, per il semplice fatto che non esistevano framework javascript (come extJS o la YUI library) per svolgere il compito che invece flex (alla sua prima versione) svolgeva egregiamente. da qui la scelta di partire con flash. se ricominciassimo oggi da zero con lo sviluppo di OOOGUI di sicuro adotteremmo una soluzione HTML5 + js. quello che posso garantire è che nel futuro più prossimo attiveremo una migrazione di tutto il backend da flash a questa tecnologia (anche perchè, fortunatamente, tutta il codice PHP del backend resterebbe valido, dovendo riscrivere solo la view)... ma dateci tempo, è già stata un'odissea arrivare a questa prima versione!

 

 

languages