In questo caso l’indicizzazione della pagina può risultare compromessa, penalizzando il sito.

Esempio pratico:

Se usiamo WordPress, modificando la data di pubblicazione di un articolo viene modificato anche il suo indirizzo url.

Ad esempio, in questo indirizzo

http://www.consulenza-web.com/2012/01/gratis-costa-troppo/

si nota chiaramente che la data dell’articolo è parte fondamentale dell’indirizzo: se cambiassimo la data cambierebbe di conseguenza anche l’url dell’articolo.

Perchè è importante farci attenzione?

I motori di ricerca (come Google) navigano il web alla ricerca di nuovi contenuti seguendo i link che trovano in pagine già conosciute.

Quando una nuova pagina viene scoperta il motore salva il suo indirizzo ed elabora delle parole chiave che associa alla pagina stessa: questa è l’indicizzazione.

Successivamente il motore torna a rilegge la nostra pagina ad intervalli di tempo regolari alla ricerca di aggiornamenti, nuovi commenti, nuovi link da seguire. Per farlo utilizza l’indirizzo precedentemente salvato.

Se questo indirizzo non esiste più il motore ottiene l’informazione: “il sito ha eliminato una pagina”. Se molte pagine di un sito non vengono trovate però l’informazione peggiora in “il sito è in stato di abbandono“.

Ogni pagina rimossa provoca un piccolo danno alla considerazione che il motore di ricerca ha del nostro sito web.

Per evitare questo effetto basta prendere un semplice accorgimento:

Risolvere il Problema:

Il server web Apache ci mette a disposizione un semplice strumento per risolvere il problema: il redirect 301 eseguito via HTACCESS:

Redirect 301 /vecchio_indirizzo/ /nuovo_indirizzo/

NOTA: nella root del sito web crea un file con il nome “.htaccess” quindi modificalo con un editor di solo testo quale Coda o Eclipse inserendo le istruzioni che ti servono.

In questo modo il motore di ricerca, tentando di leggere il vecchio indirizzo, viene istruito circa l’avvenuto spostamento, aggiorna il suo database e le pagine dei risultati di ricerca contenenti i riferimenti al nostro sito mantenendo la visibilità raggiunta dall’articolo.

@ThePeg

Segnala presso:

L’autrice sostiene alcune tesi che condivido e sulle quali vorrei esporre il mio punto di vista:

1. il sito web è essenziale per iniziare una qualsivoglia forma di comunicazione on-line
2. il sito web è (solo) uno strumento, è il contenuto del sito che ottiene il successo
3. si può iniziare gratis con WordPress aprendo un blog su wordpress.com

Sui primi due concetti sono totalmente d’accordo, sul terzo lo sono un po’ meno e in questo articolo vorrei esplorare alcuni concetti di base su cui ogni persona – potenziale cliente di una web agency – dovrebbe soffermarsi e riflettere prima di iniziare una qualsiasi attività di comunicazione on-line.

In estrema sintesi la mia teoria è questa:

il Tempo costa più del Denaro!

(immagine dahttp://www.productiveflourishing.com)

Vi spiego subito il perchè.

Back to the basics: il sito Web è Essenziale

Comunicare è l’atto del trasmettere un messaggio ad un destinatario. Per farlo è necessario un canale di trasmissione:

• La lettera ha bisogno delle Poste
• Il telefono ha bisogno di una Telecom
• Internet ha bisogno di un sito web.

Distribuire il proprio indirizzo web è come dare il proprio numero di cellulare: chi lo riceve lo utilizzerà per raggiungervi e dialogare con voi!
(e il sito, a differenza del telefono, permette a più persone contemporaneamente di farlo)

Servizi Gratuiti in Rete:

Internet offre molti servizi gratuiti (e non) che permettono di pubblicare contenuti:

• Facebook rende possibile gestire il proprio profilo e rete di contatti
• Twitter permette di pubblicare messaggi di 140 caratteri
• WordPress consente di pubblicare articoli liberamente organizzati per data e archivi

ATTENZIONE: La pagina Facebook, l’account Twitter o il blog WordPress.com (versione gratuita) possono essere chiusi in qualsiasi momento, senza spiegazioni o risarcimenti.
(questa condizione è solitamente espressa nei “termini e condizioni d’utilizzo” scritti in piccolo che nessuno legge mai!)

È come aver distribuito a tutti i clienti il numero di un vostro amico che vi ha prestato il telefono: e se il vostro amico si riprende il telefono?

Ciò che distingue il sito web da un tutti questi servizi è la proprietà del sito e la possibilità di decidere liberamente l’utilizzo che se ne vuol fare.

Il Sito Web è uno Strumento, non un fine!

Essendo quindi il sito web  uno strumento, esattamente come il telefonino, o la busta e francobollo, ciò che conta è cosa si scrive!

La prima domanda da porsi è: che tipo di comunicazione voglio fare? Il vostro obiettivo potrebbe essere la promozione di un’attività, oppure scrivere di ricette, o ancora vendere i vostri quadri via internet.
Sapere cosa e come volete comunicare vi permette di capire di che strumento avete bisogno.

Facciamo qualche esempio:

BLOG:

Cosa: Caratteristica fondamentale del blog è la pubblicazione periodica di articoli più o meno complessi riguardanti un argomento coerente (come avviene in questo!)

Come: Una delle piattaforme più diffuse per realizzare un blog è WordPress, ma ci sono altre soluzioni come Posterous, Tumblr, etc…

NEGOZIO ON-LINE:

Cosa: Le pagine contengono informazioni tecniche sui prodotti in vendita ed è possibile effettuare un acquisto mediante carta di credito e/o affini (e-commerce).

Come: Esistono moltissimi software di e-commerce, gratuiti e non. Valutare che soluzione scegliere è compito da effettuare con la consulenza di un esperto.

SITO WEB:

Cosa: Il sito web è un archivio di pagine web organizzate in una una piattaforma di comunicazione multifunzionale  con lo scopo di dare informazioni esaustive e coerenti su di un argomento, un prodotto, servizio o iniziativa.

Il sito web può contenere al suo interno molte sezioni: dal blog all’e-commerce, può essere collegato ai vari servizi quali Facebook e Twitter, può ospitare commenti degli utenti tramite Disqus (o simili). È insomma un punto di partenza potente e versatile da cui poi diramare la propria strategia di comunicazione.

Ma veniamo al punto che ci interessa…

Opzione 1: Si può fare un Sito Gratuito?

Sì, tecnicamente si può fare, ma bisogna accettarne le conseguenze:

Per realizzare un sito web bisogna utilizzare vari linguaggi di programmazione i quali possono richiedere svariati anni di studio. Per questo motivo esistono software (CMS = Content Management System) che facilitano la creazione di pagine web.

I CMS vanno quindi installati su un server web, il quale deve essere scelto e configurato in base al software che si intende utilizzare. Anche in questo caso sono coinvolte un certo numero di competenze necessarie per svolgere il lavoro: FTP, MySQL, cPanel, etc…

Scaricare un CMS gratuito e metterlo in funzione senza spendere un soldo è possibile ma richiede molto spesso una GRANDE QUANTITA’ DI TEMPO, che non giustifica la scelta del “FAI-DA-TE”.

Opzione 2: Pacchetti economici “chiavi in mano”

Esistono servizi web che offrono CMS pre-installati e perfettamente funzionanti gratuitamente o per poche decine di euro l’anno.
Questi servizi fanno “i soldi” sull’elevato numero di clienti attratti dal falso risparmio.

All’inizio va tutto bene: avete speso poco, create le vostre pagine in 5 minuti, siete contento. Ma appena vi accorgete di volere qualcosa in più vi scontrate contro il “non è previsto nel servizio”.

Oltre ai limiti tecnici bisogna considerare anche la totale assenza di un consulente esperto. Non c’è nessuno a cui rivolgersi per ottenere un consiglio, una “dritta” su come creare al meglio una pagina.

Uno strumento troppo semplice spesso comporta un risultato altrettanto limitato!

“GRATIS” è quindi una parola molto costosa su web:

• può costare tempo
• può costringere a rifare da zero un progetto perdendo mesi di lavoro
• nel peggiore dei casi, può nascondere una truffa (condizioni di servizio poco chiare, zero garanzie, etc)

Ogni mestiere richiede professionalità ed esperienza. Improvvisarsi programmatori o esperti di comunicazione web porta ad uno sviluppo non ottimale del progetto, nel peggiore dei casi al completo fallimento.

Opzione 3: Consulenza professionale
(e come valutare il COSTO/RISULTATO)

Per valutare la consulenza professionale per la realizzazione di un progetto di comunicazione on-line e capire se è necessaria, se è conveniente, se proposta ad un prezzo corretto dovete fare attenzione al rapporto COSTO/RISULTATO.

COSTO

Il concetto di COSTO va considerato in termini di “spesa economica + tempo impegnato“.

Nel progetto di realizzazione di un sito web possiamo suddividere il COSTO in più categorie:

1. servizio di hosting
2. configurazione CMS / realizzazione delle pagine
3. ideazione veste grafica / realizzazione del tema grafico
4. organizzazione dei contenuti / produzione della flow-chart del sito web
5. redazione dei contenuti
6. produzione / ricerca / acquisto dei materiali collaterali (immagini, video, etc)
7. attività di promozione SEO / SEM
8. attività di promozione su social network
9. comunicazione diretta ai clienti / servizio di newsletter
10. comunicazione offline (inserire l’indirizzo del sito su carta intestata, biglietti da visita, materiale informativo e divulgativo)

L’elenco, già lungo così, non è nemmeno completo.
Ogni singolo punto ha un costo parziale e fornisce un risultato parziale. Alcuni punti hanno costi molto alti e risultati misurabili solamente nel lungo termine (SEO e promozione su social network).

Gli unici due punti che possono essere trovati “gratis” come risorse on-line sono solo i primi due: Hosting + CMS.

RISULTATO

Il RISULTATO è l’impatto che il sito web “finito” ha sulla propria attività, ossia il vostro OBIETTIVO.

Questo non è un concetto solo di estetica o completezza delle pagine, ma comprende posizionamento, aumento dei contatti ricevuti  e quindi aumento delle visibilità/vendite/profitti.

Tenendo in mente questo è possibile valutare il rapporto COSTO/RISULTATO sia in fase di preventivazione che a progetto ultimato, e potrete misurare il successo o l’insuccesso dell’intero progetto.

Conclusioni:

Se quindi un sito internet è lo strumento che vi serve, rifletterei su questi punti:

• E’ veramente conveniente risparmiare poche centinaia di euro di consulenza server e hosting ed affrontare da soli tutti gli aspetti tecnici della configurazione di base di un sito web?
• Siete disposti ad affrontare il costo di svariate ore (o serate) di studio e prove per ottenere un sito web dall’aspetto poco professionale e magari anche soggetto a problematiche di sicurezza, barriere di indicizzazione, blocchi di usabilità?

Se viaggi spesso per lavoro compri un’auto o ne costruisci una da zero?

Perchè un sito web dovrebbe essere differente?

@ThePeg

Segnala presso:

La soluzione proposta consiste nel definire due o più gruppi di colonne assegnando varie classi (Es: essential, optional, etc..) quindi utilizzare delle media-query CSS per visualizzare e nascondere gruppi di colonne in base alle dimensioni del display.

Si tratta dunque di un esempio di design responsivo.

Trovando la soluzione molto interessante ho costruito un plugin jQuery che rende estremamente semplice realizzare sulle proprie pagine web quanto spiegato nell’articolo.

>>> Vai alla demo! <<<

MediaTable in Azione:

In questo primo screenshoot vediamo una tabella di cui sono visualizzate solamente le colonne veramente importanti. Siamo su di uno schermo di piccole dimensioni!

Cliccando sul menu “columns” (il cui nome è configurabile) si apre un menu contenente l’elenco completo delle colonne disponibili nella tabella. Possiamo variare a piacere il numero di colonne visualizzate mettendo in relazione informazioni differenti.

Questo menu è generato automaticamente! Il sorgente di questo esempio, come spiegato successivamente, è una semplice tabella dati HTML!

>>> Vai alla demo! <<<

Come si usa MediaTable?

MediaTable richiede la definizione di una tabella HTML definita correttamente ovvero con THEAD e TBODY. Le colonne di intestazione vanno raggruppate per classe in base alla priorità di visualizzazione.

Via CSS si imposteranno dei breakpoint su cui definire quali gruppi di colonne visualizzare.
Il plugin costruisce inoltre un menu delle colonne disponibili per consentire una selezione manuale esplicita delle colonne da visualizzare.

Il nostro esempio utilizza 3 gruppi di colonne:

• essential – visibili su qualunque schermo
• optional – visibili dai 768px (iPad portrait)
• n/a – visibili dai 1024px (iPad landscape)

Un’ulteriore classe “persist” è utilizzata per identificare colonne che non sono gestite dal menu. Impostando una colonna con le classi essential e persist essa non potrà mai essere nascosta!

<table class="mediaTable">
<thead>
<tr>
<th class="essential persist">Employee</th>
<th class="essential">xHTML</th>
<th class="optional">HTML5</th>
<th class="essential">CSS</th>
<th class="essential">JS</th>
<th class="optional">jQuery</th>
<th class="optional">jQueryUI</th>
<th>jQuery Mobile</th>
<th>Sencha Touch</th>
<th class="essential">PHP</th>
<th>PHP (OO)</th>
<th class="optional">CakePHP</th>
</tr>
</thead>
<tbody>
<tr>
<td>Marco Pegoraro</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
</tr>
<tr>
....
</tr>
</tbody>
</table>

Il codice javascript per l’inizializzazione del plugin è estremamente semplice:

0

$('.mediaTable').mediaTable();

Tutte le tabelle aventi classe “mediaTable” verranno attivate per consentire la selezione dei campi ed il comportamento responsivo rispetto alle dimensioni dello schermo.

>>> Vai alla demo! <<<

Compatibilità:

Ho testato il plugin sui seguenti sistemi:

• Mac OsX, Firefox 9.0.1
• Mac OsX, Firefox 4.0
• Mac OsX, Chrome 16
• Mac OsX, Safari 5.1.2
• Windows7, IE9
• Windows7, IE8, IE7, IE6 (with respond.js for media-query)
• Windows7, Firefox 7.0.9

Fork on GitHub:

Il plugin è di libera distribuzione!

Link al progetto pubblico su GitHub!

Segnala presso:

Qualunque tipo di funzione/effetto e/o trasformazione del DOM di una pagina web può essere incorporata in un plugin jQuery con lo scopo di migliorare l’organizzazione del proprio codice Javascript.
Invece di un’accozzaglia di istruzioni generiche avremo il riferimento ad un set ordinato di plugins.

http://jsbin.com/apojah/14/edit/

Wrapper jQuery:

Il primo accorgimento utile è incorporare il codice del plugin in un oggetto wrapper il cui scopo è duplice:

1. isolare il codice del plugin dallo spazio degli script della pagina
2. utilizzare $ come riferimento interno a jQuery in modo sicuro

0
1
2

;(function($){
... qui va il codice del plugin ...
})(jQuery);

Tutte le variabili dichiarate mediante la sintassi “var” saranno locali al plugin mentre rimane possibile accedere a variabili globali dichiarate esternamente.

Passare la variabile “jQuery” al wrapper rende possibile l’utilizzo della funzione $ tipica di jQuery all’interno del codice del nostro plugin anche in presenza di altri framework esterni (es MooTools).

Struttura base del plugin:

Un plugin è un’estensione di jQuery che agisce su di un contesto formato da un elenco di nodi DOM identificati da una query xPath.

$('p').hide();

La precedente istruzione identifica un elenco di nodi DOM composto da tutti i paragrafi (p) presenti nel documento HTML e passa tale contesto alla funzione hide() di jQuery. Tale funzione restituisce il contesto stesso rendendo possibile la concatenazione di più plugins:

$('p').hide().fadeIn();

Per questo motivo il codice base del nostro plugin sarà:

0
1
2
3
4
5
6
7
8

$.fn.customPlugin = function() {
 
  $(this).each(function(){
    ... azioni sul singolo elemento DOM ...
  });  
 
  return this;
 
};

Viene eseguito un ciclo applicando una funzione ad ogni elemento del contesto. Successivamente il plugin restituisce il contesto stesso per consentire la concatenazione dei plugins come accennato sopra.

Ottimizziamo il ciclo sul contesto:

E’ importante capire che in Javascript ogni function() è trattata come un oggetto.
Il codice di questo esempio, seppur molto diffuso, crea un nuovo oggetto per ogni elemento di contesto quindi incide significativamente sulla memoria e sulla prestazioni del plugin stesso.

Possiamo ottimizzare il tutto spostando la logica applicata al singolo elemento in una funzione esterna locale al wrapper del plugin:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

;(function($){
 
  /**
   * Metodo locale utilizzato dal plugin jQuery sugli elementi DOM
   *
   */
  var __loop = function() {
 
    $(this).fadeOut().fadeIn();
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Applico la logica agli elementi del contesto (DOM)
    $(this).each(__loop);
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);

In riga #19 applichiamo la funzione __fn() che è definita esterna al plugin ma localmente al wrapper creato. In questo modo Javascript utilizzerà sempre il medesimo oggetto passando di volta in volta dati differenti.

Questo concetto è estremamente importante in quanto con jQuery è utilizzo comune passare nuove funzioni come parametri di metodi applicati ad elementi DOM. Aver cura di definire tali funzioni (solitamente callback) in modo esplicito nel wrapper del plugin è fondamentale per migliorare le prestazioni del nostro codice.

Configurazione del Plugin:

Praticamente il 100% dei plugins jQuery utilizzano il primo parametro passato come oggetto di configurazione interna.

0
1
2
3

$('p').customPlugin({
speed:'fast',
color:'red'
});

Una configurazione classica consiste in un oggetto le cui proprietà sono utilizzate dalla logica interna al plugin stesso per personalizzare le funzionalità erogate secondo diverse esigenze.

L’utilizzo di un oggetto di configurazione fa nascere alcune problematiche di organizzazione del codice quali:

• necessità di applicare dei valori di default per opzioni non rese esplicite
• necessità di passare l’oggetto di configurazione alla funzione __loop()

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$.fn.customPlugin = function() {
 
  // Proprietà di configurazione interna.
  var cfg = false;
 
  // Estendo la proprietà di configurazione con l'oggetto di
  // configurazione contenuto nel primo parametro del plugin.
  if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
    cfg = $.extend({},{
      color: 'black'
    },arguments[0]);
 
  }
 
  // Applico la logica agli elementi del contesto (DOM)
  $(this).each(function(){ __loop.call( this, cfg ); });
 
  // Mantengo la possibilità di concatenare plugins.
  return this;
 
};

Come prima cosa si noti l’aggiunta di una proprietà locale al plugin cfg la quale è instanziata a false e successivamente estesa da un oggetto contenente la configurazione di default del plugin stesso. (riga #3 -> #13)

La configurazione è contenuta nel primo parametro tra quelli passati al plugin, inoltre il valore di cfg viene modificato solamente se tale parametro è un oggetto. Questo condizionale è la base di una semplice tecnica per utilizzare il medesimo plugin con tipi di input differenti come avviene in quasi tutti i widget di jQuery UI.

$('#foo').dialog({ .. config .. }).dialog('open');

Utilizziamo le Closures:

Anche la riga #16 è cambiata: abbiamo dovuto aggiungere una closure per consentire il passaggio della configurazione alla funzione locale __loop().

L’utilizzo della closure è un compromesso di ottimizzazione.

Cerchiamo di isolare tutta la logica possibile in una funzione esterna che verrà invocata con parametri diversi dal codice interno alla closure. La closure verrà invece creata per ogni elemento DOM del contesto causando un leggero spreco di memoria.

Mantenere essenziale il codice delle closure demandando tutta la logica a funzioni esterne è importantissimo per garantire buone performance al nostro codice!

Rispondere a diversi tipi di input:

Abbiamo accennato a jQueryUI ed a come metta a disposizione una serie di widget la cui caratteristica comune è erogare comportamenti diversi in base a tipi di chiamate diverse:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

(function($){
 
  /**
   * Logic methods
   */
 
  var __loop = function( cfg ) {
 
    $(this).data( 'customPlugin', cfg );
 
  };
 
  var __colorize = function() {
 
    var cfg = $(this).data('customPlugin');
 
    $(this).css( 'background-color', cfg.color );
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Proprietà di configurazione interna.
    var cfg = false;
 
    // Estendo la proprietà di configurazione con l'oggetto di
    // configurazione contenuto nel primo parametro del plugin.
    if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
      cfg = $.extend({},{
        color: 'black'
      },arguments[0]);
 
    }
 
    // Inizializzazione Plugin:
    // Applico la logica agli elementi del contesto (DOM)
    if ( cfg !== false ) {
      $(this).each(function(){ __loop.call( this, cfg ); });
 
    // Azioni su plugin intanziato:
    } else if ( arguments.length ) {
 
      switch ( arguments[0] ) {
 
        case 'colorize':
          $(this).each(function(){ __colorize.call( this ); });
          break;
 
      }
 
    }
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);
 
/**
 * Codice eseguito al caricamento della pagina
 */
$(document).ready(function(){
 
  // Inizializzazione del plugin
  $('p').customPlugin({
    color:'red'
  });
 
  // Esempio di utilizzo delle azioni del plugin
  $('input').click(function(){
 
    $('p').customPlugin('colorize');
 
  });
 
});

In questo esempio applichiamo il nostro plugin a tutti paragrafi (p) del documento (riga #69). Questa operazione andrà ad attivare il metodo locale __loop() la cui logica è salvare la configurazione del plugin all’interno del DOM del nodo interessato.

Successivamente sfruttiamo il click su di un bottone per invocare il metodo “colorize” del plugin stesso. In questo caso entra in scena il metodo local __colorize(). Questo è reso possibile dal controllo sul tipo di dato effettuato sul primo parametro passato al plugin. Rispettivamente in riga #30 e poi in riga #46.

Seguendo la struttura esposta nell’articolo il codice del plugin è diviso in due macro sezioni: un “router” di azioni ed un certo numero di metodi interni.

Il router è gestito nella funzione che estende jQuery. Controlla il tipo di input e si occupa di stabile che tipo di azione è richiesta.

I metodi interni si occupano di dar seguito alla decisione del router e devono “fare la magia”. Solitamente i metodi interni sono invocati per ogni elemento DOM identificato dal contesto del plugin come nei precedenti esempi.

Il passo successivo è massimizzare l’ottimizzazione dei metodi interni!

Ottimizzare con le Variabili Cache:

Ogni metodo locale di logica riceve come contesto il riferimento ad un preciso nodo DOM facente parte dell’xPath su cui è stato lanciato il plugin. Nel nostro esempio significa che il codice $(this) all’interno dei metodi __loop() o __colorize() è il riferimento ad un singolo paragrafo.

Sempre all’interno di questi metodi potremo aver bisogno di effettuare nuove ricerche su nodi:

$(this).find('strong')

a cui applicare vari metodi jQuery oppure altri plugin a cascata.

Ogni volta che si utilizza jQuery per effettuare una ricerca viene impegnata memoria e CPU. Noi possiamo agire e salvare i risultati di una query in una variabile locale così da alleggerire il carico del computer client. Vediamo il codice di __colorize():

0
1
2
3
4
5
6
7
8

var __colorize = function() {
 
  var $this = $(this);
 
  var cfg = $this.data('customPlugin');
 
  $this.css( 'background-color', cfg.color );
 
};

In riga #2 viene creata la variabile locale $this con riferimento al nodo DOM.
Nelle righe #4 e #6 riutilizziamo questa variabile per applicare metodi jQuery.

Questo è ovviamente un esempio banale ma possiamo immaginare l’impatto positivo di questo accorgimento quando la logica comincia a complicarsi un po’!

Conclusioni:

In questo articolo abbiamo raccolto le basi per la costruzione di un plugin jQuery versatile e prestazionale.

Grazie a questa struttura diventa semplice realizzare strumenti complessi che contengano configurazione e azioni.

Nel prossimo articolo studiamo in dettaglio alcune linee guida utili alla realizzazione di un “widget” ovvero un plugin complesso che mette a disposizione un controllo di interfaccia facilmente riutilizzabile in progetti differenti.

Al momento in cui scrivo il progetto di “widget collection” jQuery più affermato è sicuramente jQueryUI il quale mette a disposizione controlli di interfaccia evoluti quali dialog window, date picker, sortable list, etc.

Noi impareremo a creare componenti “custom” il cui utilizzo sia però ispirato alle linee guida di jQueryUI, fino ad arrivare alla creazione di nuovi widget completamente compatibili con jQueryUI e le sue linee guida.

Segnala presso:

$('#target').imagesLoaded(function(){
  alert("All images in #target were loaded!");
});

E’ anche possibile gestire una configurazione più dettagliata impostando callback di successo e di errore, quest’ultima lanciata nel caso una o più immagini non siano correttamente caricate nel tempo di timeout impostato:

$('#target').imagesLoaded({
  success: function(){ alert('Ok!'); },
  error: function() { alert('Ko!')); },
  timeout: 1000,
});

Nel precedente codice di esempio è impostato il timeout ovvero il tempo massimo di durata del controllo e le callback personalizzate in caso di successo o di fallimento del controllo. Le funzioni di callback ricevono come contesto il riferimento a $(‘#target’);

Fork on GitHub!

https://github.com/thepeg/ImagesLoaded

Segnala presso:

L’argomento:

Queste versioni di Internet Explorer non supportano le Media Query (nè HTML5… anzi, non supportano nulla!) ma fortunatamente esistono delle librerie che – via javascript – risolvono il problema.

• css3-mediaqueries-js - supporto esteso alle media query CSS3
• respond.js – supporto ottimizzato alle media query CSS3 per il “mobile first” responsive design

Io utilizzo respond.js perchè mi interessa solamente intercettare le dimensioni dello schermo ed agire di conseguenza sulla presentazione della pagina web ed è proprio su questa libreria che si concentra l’errore segnalato in questo post.

L’errore:

Questa libreria va in errore quando il foglio di stile contiene delle regole vuote:

body {}

La soluzione:

La semplicissima soluzione consiste nell’inserire almeno uno spazio all’interno delle parentesi graffe:

body { }

Conclusioni:

Molti di voi sostengono – a ragione – che questo tipo di istruzioni non dovrebbero esistere in un foglio di stile in quanto sono un semplice spreco di spazio e di tempo di caricamento. Sono pienamente d’accordo!

Tuttavia in piena fase di sviluppo molti sviluppatori usano scrivere il set completo di “css handler” per definire le regole interne in un secondo momento. In questo caso – in progettazione – questo bug può far perdere tempo prezioso e la soluzione proposta in questo articolo diventa utilissima!

Segnala presso:

Source code on GitHub!
https://github.com/thepeg/AutoFancybox

Di seguito un esempio di codice Javascript di inizializzazione (1 riga!) ed un esempio di HTML che permette di lanciare un IFRAME in lightbox.

// Document onReady()
$('.auto-fancybox').autoFancybox();

<!-- Inside your document -->
<a href="http://goo.gl/VgLDo" title="Lavora con me!"
  class="auto-fancybox"
  data-type="iframe"
  data-width="90%"
  data-height="90%"
>Lavora con me!</a>

Opzioni Supportate

Il plugin supporta quasi tutte le opzioni ufficiali di FancyBOX. Trattandosi di attributi HTML5 i nomi sono scritti completamente in minuscolo quindi l’opzione di configurazione “showTitle” diventa l’attributo “data-showtitle”.

• padding
• margin
• opacity
• modal
• cyclic
• scrolling
• width
• height
• autoscale
• autodimensions
• centeronscroll
• ajax
• swf
• hideonoverlayclick
• hideoncontentclick
• overlayshow
• overlayopacity
• overlaycolor
• titleshow
• titleposition
• titleformat
• transitionin
• transitionout
• speedin
• speedout
• changespeed
• changefade
• easingin
• easingout
• showclosebutton
• shownavarrows
• enableescapebutton
• type
• href
• title
• content
• index

Segnala presso:

Clicca questo link con il tuo iPhone, iPad, Android o Blackberry Touch:
(puoi visualizzare l’applicazione sul tuo computer utilizzando Safari o Google Chrome!)
http://ivapp.movableapp.com

Presentazione completa:
http://movableapp.com/ivapp

Brevi Info:

L’applicazione è scritta in HTML5 + Javascript utilizzando il framework Sencha Touch.

Durante il prossimo weekend proverò a creare un pacchetto per l’AppStore utilizzando PhoneGap… vediamo se me la pubblicano!

Il resto lo puoi leggere su:
http://movableapp.com/ivapp

Segnala presso:

Inizialmente ho letto parecchie discussioni sull’argomento in oggetto: “native VS webapp” e in questo articolo vorrei sintetizzare alcune mie valutazioni.

Potendo dedicare allo studio delle applicazioni mobile solamente poche ore la sera ho subito approciato il mondo delle WebApp perchè mi consentono di sfruttare competenze preesistenti: HTML5, Javascript, CSS.

WebApp

Per il primissimo approccio ho utilizzato jQuery Mobile con il quale ho realizzato una semplicissima photogallery la cui interfaccia responsiva si adatta al dispositivo che la richiede: se usi un computer vedrai una pagina web con effetto lightbox mentre se usi un iPhone, Android, iPad vedrai un’interfaccia simile a quelle native.
Inoltre il passaggio tra le immagini è gestito dal touch e non dal click. [vedi esempio].

Successivamente mi sono dedicato a SenchaTouch, un prodotto veramente incredibile e completo ma dotato di scarsa documentazione libera: l’azienda che lo produce campa vendendo formazione!
Attualmente mi sto dedicando allo studio di questo prodotto e ho aperto un piccolo blog dedicato dove pubblico i miei “appunti di viaggio” su piccole e grandi cose che scopro sull’argomento.

Principali vantaggi di un’applicazione web based:

• sviluppo su tecnologie open: html, javascript, css
• sviluppo su browser web: safari, chrome
• deploy dell’applicazione su server FTP
• installazione semplice: basta collegarsi all’indirizzo dell’app
• possibilità di funzionamento off-line (in assenza di connettività)
• compatibilità semplificata con Android, Blackberry

Applicazione Nativa

Lo studio di applicazioni native l’ho approciato qualche tempo fa scontrandomi subito con la pessima sintassi del linguaggio ObjectiveC.

Sostanzialmente i framework (volutamente al plurale) di sviluppo su cui si basano le applicazioni native sono incredibili collezioni di oggetti e componenti pronti da utilizzare e configurare.

L’applicazione risulta così una composizione creativa di oggetti mentre la realizzazione di componenti ex-novo è tutt’altra cosa.

In linea di massima ritengo che per chi proviene dal mondo web la curva di apprendimento sia piuttosto lunga rispetto all’applicazione web based a parità di obiettivo.

Principali vantaggio di un’applicazione nativa:

• AppStore: visibilità, diffusione, guadagno
• prestazioni decisamente superiori
• accesso all’hardware: fotocamera, file system, accelerometro, etc
• funzionamento off-line nativo

Applicazione Ibrida con PhoneGap!

Una possibilità di congiungere le due diverse soluzioni in un compromesso che possa sfruttare i relativi vantaggi è l’applicazione ibrida web/nativa. Questa soluzione si può ottenere con PhoneGap.

L’applicazione ibrida è un wrapper che consente il funzionamento dell’applicazione web. Una sorta di piccolo browser preconfezionato.

Solo questo punto rende possibile distribuire l’applicazione su AppStore consentendo dunque il funzionamento off-line nativo!

Cataloghi, manuali, reference, schede tecniche sono esempi di applicazioni che trovano in questa soluzione la miglior soluzione possibile: velocità di sviluppo abbinata a capacità di distribuzione su AppStore!

PhoneGap mette anche a disposizione delle API Javascript per poter accedere a funzionalità avanzate del dispositivo quali:

• file system
• fotocamera
• libreria media
• accelerometro
• bussola
• contatti
• geolocalizzazione
• connettività
• notifiche
• storage db

Con questo sistema sono riuscito, nell’arco di una giornata, a realizzare il prototipo di un’applicazione che mantiene sincronizzati sul device (in questo caso un’iPad) una serie di files (pdf) pubblicati su di un server FTP remoto. Una sorta di client Dropbox ma mooolto più semplice.

In conclusione presumo che proseguirò sulla strada dell’applicazione ibrida perchè rappresenta un punto di giunzione tra le due diverse filosofie di sviluppo. Inoltre offre un sistema piuttosto semplice per realizzare applicazioni compatibili con più dispositivi!

Segnala presso:

Scarico, installo, avvio e… scopro con immensa delusione che l’applicazione non è altro che una lunga e pesante serie di immagini inserite in un carosello! Niente più di un pdf o di un eBook… semmai con notevoli funzioni in meno perchè non è possibile inserire segnalibri o condividere i contenuti!

Che valore aggiunto da questa App?

Le schede contenute nell’App sono delle semplici immagini: scansioni di una brochure o di un libretto!
Ovviamente i contenuti ci sono, ma sono di difficile lettura.

Le schermate accorpano una o più scansioni di pagine del catalogo cartaceo ed è necessario applicare lo zoom anche per leggere i titoli!
Sono sicuro che sull’iPad il problema è leggermente meno pesante grazie alle maggiori dimensioni dello schermo ma ciò non giustifica un prodotto simile!

Linee guida di pubblicazione sull’AppStore:

L’AppStore è l’ambiente di distribuzione delle applicazioni per iPod, iPhone e iPad.
Le applicazioni qui presenti dovrebbero essere soggette a stretti controlli di qualità tra i quali cito:

https://developer.apple.com/appstore/resources/approval/guidelines.html

L’applicazione Trentino Holiday 2011 è chiaramente frutto di una semplice scansione di una versione cartacea dei medesimi contenuti e come tale dovrebbe essere distribuita come eBook e non come App!

Quali accorgimenti adottare per migliorare il risultato?

Il passaggio da rivista cartacea ad applicazione (nativa/web/sito/eBook) deve inevitabilmente passare attraverso una fase di discussione e riorganizzazione dei contenuti.

Lo strumento “carta” consente di sfogliare mentre lo strumento “computer” consente di navigare.
Sono sistemi di accesso alle informazioni estremamente diversi ed è importante che l’utente riceva ciò che si aspetta di ottenere!

Utilizzo della rivista cartacea:

La rivista cartacea ha un accesso principale di tipo sequenziale: parto da pagina 1 e arrivo a pagina x. La maggior parte delle riviste mette a disposizione un indice per un accesso diretto alle informazioni. L’indice analitico dei contenuti è un metodo di accesso secondario nella rivista cartacea!

Utilizzo della rivista digitale:

Il computer ci ha abituati al “point and click” ovvero alla selezione di oggetti di interesse. Quando ci troviamo davanti al desktop siamo abituati a cliccare direttamente su di un’icona piuttosto che scorrere l’elenco delle icone disponibili fino a trovare l’opzione desiderata.
Nel computer l’accesso diretto ai contenuti è primario.

Dovrebbe quindi essere chiaro come gli articoli (anche le sezioni degli articoli) di una rivista dovrebbero essere riorganizzati in “schede”: piccoli nuclei di contenuto messi in relazione con altri nuclei tramite i collegamenti.

L’applicazione deve dunque mettere a disposizione un sistema di navigazione predeterminata per il raggiungimento di una determinata scheda.
Intendo la definizione di menu e sottomenu che permettano all’utente di operare una semplice ricerca tramite la selezione progressiva di opzioni semplici.

Il concetto di “opzione semplice” è vitale al successo dell’applicazione mobile (iPhone/iPad). Su questo tipo di dispositivi l’utente non vuole utilizzare la tastiera per effettuare una ricerca a parole chiave bensì utilizzare le dita per navigare attraverso un sistema di filtro progressivo il quale aiuta ad identificare un numero sempre più circoscritto di “schede” tra cui scegliere la propria lettura.

Contenuti Aumentati:

Un’altro accorgimento utile nella realizzazione di un’App per riviste o cataloghi è l’inserimento di azioni utente sulle schede di contenuti.

L’ida di base è che l’utente non si limita a leggere i contenuti sull’iPhone ma li vuole condividere, segnalare, commentare, esportare etc.

Operazioni quali “invia ad un amico”, “condividi su facebook”, “aggiungi a preferiti” o simili diventano armi importanti per coinvolgere l’utente nell’utilizzo dell’App ed ottenerne così il consenso.

Ovviamente questo richiede l’esistenza di una struttura web (un sito) parallelo nel quale pubblicare parte dei contenuti delle schede fornendo così i link che possono essere condivisi tra i vari social network.

Conclusioni

Lo strumento mobile App è sicuramente potente ed allettante per moltissime realtà editoriali ma bisogna fare molta attenzione a non cadere nel banale pubblicando soluzioni frettolose ed abbozzate come l’App oggetto di questo articolo.

Segnala presso: