An alternative to the ugly default buttons

Build your own custom buttons easily just with CSS using the sliding doors technique!

demo page:

http://www.open-lab.com/mb.ideas/index.html#mbbuttons

download page:

http://www.open-lab.com/mb.ideas/demo/jquery.mbButtons/jquery.mbButtons.zip

Uno dei core business di Open Lab è focalizzato sulla realizzazione di applicazioni web based (teamwork ne è un esempio).

La parte di sviluppo delle interfacce GUI (Graphic User Interface) ha un ruolo fondamentale nel successo di qualsiasi applicazione, tantopiù se questa è fruibile attraverso un browser.
Occupandomi di graphic design, questo aspetto mi affascina e mi interessa in maniera particolare (Open Lab ha un sito dedicato: More than Icons).

Oggi è inpensabile scindere gli aspetti di interazione tra “chi utilizza” e “ciò che è utilizzato” (è anche questo un interessante tema di comunicazione); un designer non solo deve avere una cultura teorica sull’argomento (e già questo aspetto implica un attenzione ed una sensibilità rivolta al contemporaneo); ma deve conoscere gli strumenti che le tecnologie e le nuove tecnologie mettono a disposizione per la realizzazione di strumenti e metodi di fruizione delle interfacce.

One of the core businesses of Open Lab is building web based applications (teamwork is an example).
Development of web based GUI (Graphic User Interface) today plays a key role in the success of any application, especially if it is available through a browser.  Graphic design fascinates me, particularly when combined with usability (see our web site: More than Icons).
Today it is unthinkable to separate aspects of interaction between “those who use” and “what is used”  (this is also an interesting theme of communication), a designer must not only have technological background  (and this already implies a sensitivity and attention devoted to the contemporary), but must also know the tools that new technologies provide for the creation of usable interfaces.

Per le applicazioni realizzate in ambiente web (quello che ora viene chiamato Web 2.0), che sempre più stanno assumendo un ruolo centrale nello sviluppo informatico, stiamo assistendo a sanguinose battaglie per l’affermazione degli standard comportamentali dei browser di fruizione; anche l’indiscusso protagonista IE (che fino ad oggi ha imposto in maniera arrogante i suoi standard proprietari, costringendo chi come me si occupa di programmazione di interfacce web a frustrazioni e sforzi disumani per far sì che le interfacce siano coerenti su tutti  i browsers) si stà allineando agli standard del W3C e ECMA, rendendo tutti un po’ più felici.

Gli strumenti per realizzare interfacce in ambiente web, a prescindere dall’ambiente in cui l’applicazione è stata sviluppata server side, sono tendenzialmente 2: L’HTML o XHTML (HyperText Markup Language) per la gestione della strutura dei contenuti ed il CSS (Cascading Style Sheet) per la loro visualizzazone. A questi si aggiunge l’ECMAscript (javascript) per la manipolazione del DOM (struttura della pagina) e dei suoi contenuti.

Ci sono inoltre elementi realizzati con codice compilato che possono essere inglobati nelle pagine e per i quali sono richiesti plug in client side per la loro fruizione; tra questi, il linguaggio più utilizzato è senza dubbio l’actionScript in ambiente Flash o Flex di Adobe ®.
Inoltre, per la fruizione contestuale di oggetti multimediali quali filmati, audio, documenti pdf, oggetti 3D e quant’altro, ogni softwarehouse (Adobe®, Apple®, Microsoft®, etc.) ha implementato plug in proprietari per integrare la loro tecnologia all’interno del’ambiente web. Il maggior difetto di questi componenti è quello appunto di essere codice compilato e non interpretato per cui l’iterazione tra oggetti diversi su una stessa pagina non è esplicita e gli eveti non sono condivisi.

Il Web 2.0 differisce dalla precedente gestione delle pagine web fondamentalmente per due aspetti:

1. La manipolazione degli oggetti del DOM a seguito di eventi scatenati dall’utente (mouse click, mouse hover, mouse out,  change, time events,  etc.).
2. La possibilità di modificare il contesto dei contenuti a seguito di richieste specifiche server side, senza dover ricaricare interamente il contenuto della pagina, tramite la tecnologia Ajax (Asynchronous JavaScript and XML).

La tendenza generale è quindi quella di utilizzare quanto più possibile i linguaggi interpretati (javascript, HTML e CSS) per la realizzazione delle interfacce così da poter condividere gli eventi e modificarne i contenuti attraverso codice espresso direttamente sulla pagina o su files a questa collegati.

Tutto questo si scontra comunque con le diverse specificità dei browser utilizzati per fruire dei contenuti web (in realtà le specificità sono 2: IE da un lato, tutti gli altri dall’altro!!).
Come già detto, a differenza di browser come Firefox (basato su motore Mozilla), Safari e l’ultimissimo nato Chrome (basati su motore webkit), Opera ed altri che hanno sposato l’idea di seguire standard comuni per l’interpretazione del codice e degli eventi scaturiti; rimane IE (Internet Explorer) di Microsoft®, che da solo ricopre poco meno del 50% dell’utenza e quindi non può essere tenuto di poco conto (anche se se lo meriterebbe!) che cerca di dettare standard proprietari (sia per l’interpretazione degli eventi, sia per gli aspetti grafici) in netto conflitto con gli altri (http://maxb.net/blog/2008/06/17/blacknwhite/), facendo sì che il codice necessario alla realizzazione dell’interfaccia, sia visiva che comportamentale, debba essere sottoposto a costanti verifiche di funzionamento e sporcato per far sì che l’applicazione sia coerente su tutte le piattaforme di fruizione.

Per far fronte a questo inconveniente, almeno per l’aspetto comportamentale, sono nate delle API (Application Programming Interface) basate su javascript che permettono allo sviluppatore di scavalcare i problemi di compatibilità tra interpreti delegando ai propri metodi la verifica e la gestione delle differenze di codice necessario; hanno inoltre linearizzato i metodi di analisi del DOM e implementato metodi di gestione di eventi e metodi di gestione Ajax.

Questo ha facilitato talmente la programmazione da far sviluppare in poco tempo interfacce che fino a soli 2 o 3 anni fà sarebbero state irrealizzabili.

Le librerie più utilizzate oggi sono Prototype, Mootools, Dojo, jQuery; ognuna di queste ha dei buoni motivi per essere usata, comunque io ho sposato jQuery che ha, a mio parere, un approccio meno invasivo nella manipolazione del dom e degli eventi, una forte comunity che alimenta costantemente lo spettro di applicazioni, esempi e tutorials, ed è veramente write less get more.

Alcuni link utili di comparazione fra jQuery e le altre API:

• Prototype and jQuery: A code comparison
• Why jQuery’s Philosophy is Better
• jQuery: (Mis)leading the Pack
• Javascript Toolkit Comparison
• Zebra Table Showdown
• Event Selector Showdown

Per concludere, la ricerca nell’ambito dell’usablità applicativa è in continua evoluzione ed offre grandi spazi creativi; pubblicherò in seguito alcuni componenti che ho realizzato per le nostre applicazioni.

Intanto, se volete, potete andare a vedere mb.ideas.repository, un sito che ho realizzato per la pubblicazione dei miei compnenti javascript.

Per  informazioni sulla storia della Graphical User Interface dei sisemi operativi :

• http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface