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:

L’utente medio cerca informazioni complete e aggiornate in una grafica accattivante.
Il nostro scopo (di web designer) è soddisfare questi bisogni e renderci conto che essi evolvono nel tempo e questa evoluzione è determinata da tecnologia e moda.

In questo articolo spiego come le tecniche di Web Design Progressivo e Web Design Adattivo possono essere utilizzate come compromesso vincente per la realizzazione di progetti web attuali e retro compatibili.

HTML4, xHTML Transitional, xHTML Strict, HTML5, CSS2, CSS3, Javascript, jQuery (e altri frameworks) sono le infrastrutture che abbiamo a disposizione per realizzare una pagina web. Come capita in moltissimi ambiti lavorativi dobbiamo avere le competenze necessarie per scegliere lo strumento giusto per il lavoro da realizzare.

Un esempio pratico di questa affermazione è HTML5: è una novità sulla bocca di tutti ed introduce nuove ed interessanti funzionalità alle pagine web (io utilizzo già HTML5 per molti miei lavori!).
Eppure se dobbiamo realizzare un progetto web per una Pubblica Amministrazione italiana non possiamo farne uso! Siamo obbligati dalla Legge Stanca ad utilizzare xHTML.

Vecchie abitudini dure a morire!

In principio era Explorer (e Netscape!) e poi pian piano abbiamo assistito (noi utenti del Web) alla nascita degli altri browsers. Da sempre agenzie e clienti chiedono (pretendono) che le loro pagine web si vedano identiche su qualunque computer, browser e OS.

Questo fenomeno deriva dal fatto che l’utente medio ha assistito alla nascita del web ed il web è stato venduto per anni come il volantino digitale dell’azienda: una semplice digitalizzazione di una brochure.

La caratteristica principale del volantino è che tutte le copie sono identiche tra loro e questa abitudine è stata erroneamente trasferita al web. Questa abitudine è dura a morire!

La (pessima) soluzione grafica

In principio era FrontPage e Dreamweaver e poi pian piano abbiamo assistito  (noi sviluppatori) alla crescita di una coscienza collettiva orientata alla qualità del codice ed alla sua semantica con lo scopo di valorizzare un contenuto di qualità.

Gli strumenti visuali (WYSIWYG) utilizzavano (e lo fanno tutt’ora!!!) tabelle e slices per comporre il risultato grafico di una pagina.
Quasi tutta la grafica risultante è basata su di un mosaico di immagini composte in una una struttura a tabelle annidiate.

Questa soluzione permette di ottenere un elevato grado di “uguaglianza” tra i vari supporti ma è legata a tecnologie vecchie e deprecate (le tabelle di layout) ed è destinata a morire perchè colossi dell’informazione come Google basano i risultati delle proprie ricerche anche sulla qualità intrinseca delle pagine indicizzate: la qualità del codice sorgente!

Moda e Tecnologia

Il web è fatto di contenuti impaginati ed erogati principalmente attraverso lo schermo di un computer o di un dispositivo mobile. In sintesi una pagina web può essere sia letta sia osservata come immagine.

L’immagine di una pagina web può essere percepita come bella o brutta in base al background culturale del singolo individuo ma anche in base alla moda del momento. Anzi, sempre più spesso sono le mode collettive ad influenzare il singolo background culturale anche nella fruizione di una semplice pagina web.

Le tecnologie messe a disposizione di noi sviluppatori web evolvono assieme alla moda e spesso rispondono ad esigenze stilistiche con maggior priorità rispetto alle esigenze funzionali. Un esempio eclatante è la direttiva border-radius introdotta con i CSS3.

Quasi sempre l’ultima tecnologia disponibile nasce per semplificare un certo compito (si pensi sempre ai bordi arrotondati) mentre quasi mai gli strumenti esistenti si adeguano alle nuove tecnologie (si pensi a Internet Explorer).

Il risultato è che lo sviluppatore si trova a dover scegliere tra:

• utilizzare l’ultima tecnologia disponibile a rinunciando alla compatibilità con sistemi obsoleti
• rinunciare all’aggiornamento tecnologico per favorire una compatibilità globale del proprio lavoro
• studiare soluzioni complesse per rendere retro-compatibili alcune (ma non tutte) le nuove tecnologie (si pensi a sIFR o Cufon)

Il Compromesso Vincente

Esiste tuttavia un approccio pragmatico che tiene in massima considerazione il contenuto che una pagina deve erogare (su questo non c’è compromesso!) e tenta di studiare soluzioni grafiche che possano sfruttare al massimo le nuove tecnologie ma risultare comunque accettabili in assenza delle stesse.

Questo compromesso prende il nome di “Design Progressivo” e “Design Adattivo” (in inglese “progressive enhancement web design” e “adaptive web design”).

Utilizzo il termine compromesso perchè entrambe queste tecniche di desing hanno risultati grafici differenti su browsers o supporti differenti.

Utilizzare queste tecniche significa comprendere che il web è uno strumento elastico e contestualizzato allo strumento che lo visualizza. Significa comprendere che il web non è la carta stampata!

Colori, layouts, effetti grafici e movimenti possono essere un’utile arricchimento della pagina quanto viene visualizzata su di un iMac 27″ e contemporaneamente risultare un pesante impedimento per chi tenta di accedere alla stessa pagina con un cellulare.

Web Design Progressivo

Il termine Design Progressivo identifica delle tecniche di sviluppo per cui un layout tecnologicamente semplice viene arricchito di funzionalità extra solo per i browsers che le supportano.

Il design di partenza si basa su tecnologie solide e ampiamente diffuse assicurando che un determinato layout è correttamente visualizzato sulla (quasi) totalità dei browsers/dispositivi in circolazione. Successivamente si applicano gruppi di regole avanzate le quali vengono lette solamente dai browsers che le supportano. Tali regole verranno ignorate da vecchi dinosauri quali IE6, IE7, IE8!

In passato si utilizzavano i commenti condizionali per IE, successivamente hanno preso il sopravvento i CSS Hacks (safe e non) mentre oggi possiamo contare su strumenti evoluti quali modernizr che ci permettono di scrivere fogli di stile simili a questo:

<style type="text/css">
/* Basic Layout Rules */
.box { margin:10px; padding:10px; background: #ddd; color: black; }

/* Advanced CSS3 Rules */
.boxshadow .box { box-shadow: 2px 2px 4px #666; }
</style>

Leggi l’approfondimento su Wikipedia (inglese) »

Web Design Adattivo

Il termine Design Adattivo identifica delle tecniche di sviluppo per cui un layout subisce delle trasformazioni in base alle caratteristiche del dispositivo che lo visualizza.

Questa pratica si basa sul concetto che chi visualizza una data pagina con un cellulare o un iPhone non ha interesse nel visualizzare una enorme, seppur magnifica, testata grafica del sito.

Il Web Design Adattivo è una materia molto complessa perchè ha a che fare con molti livelli di erogazione di una pagina web.

A livello CSS possiamo decidere di caricare o meno la testata del sito grazie ad una media query oppure possiamo utilizzare un set di icone ad alta risoluzione per lo schermo di un iPhone4.

A livello Javascript possiamo valutare di inserire i tasti avanti/indietro in uno slide-show per chi utilizza il mouse mentre per chi utilizza un iPad (touch screen) possiamo prevedere un comportamento a trascinamento (qui ci aiuta modernizr).

A livello Server possiamo valutare di ridimensionare le immagini a 800px per chi ha una connessione veloce e ridurle a 300px per chi ha una connessione lenta o un cellulare basandoci sugli header della richiesta e su dei pingback ajax (qui si va sul difficile).

L’ultima Sfida!

Considero abbastanza semplice da comprendere quanto esposto in questo articolo: la grafica su web ha caratteristiche diverse dalla grafica su carta.

Nel lavoro quotidiano mi trovo spesso a discutere di questi argomenti con colleghi designers e grafici e molto spesso mi accorgo che quando un creativo si mette davanti a Photoshop raramente tiene in considerazione le problematiche di implementazione e lo strumento (il web) cui è destinato il suo lavoro.

Per fortuna l’impatto che il SEO ha su di un progetto web è sempre più forte e Google sta facendo enormi sforzi per premiare la qualità costruttiva di una pagina web.

Sono sicuro che in un futuro abbastanza vicino le considerazioni qui esposte diverranno argomento comune tra tutti i miei colleghi!
E tu cosa ne pensi?

Segnala presso:

Un software (Photoshop, Fireworks) si occupa di convertire il tutto in una pagina html piena di tabelle annidiate le quali contengono pezzi di immagini (le slices), testi e celle vuote con immagini di sfondo elastiche (vi ricordate le “transparent.gif”?).

La modifica ai contenuti di questo tipo di pagine è realizzabile solamente attraverso il software WYSIWYG perchè il codice risulta quasi completamente illeggibile. Oltretutto capita molto spesso che la quantità di codice superi abbondantemente la quantità di contenuto e questo è un grosso danno per il ranking del sito web!

Vantaggi:

Il vantaggio di questa soluzione è insito nello sfruttamento massivo delle immagini: tutto ciò che è immagine rimane sicuramente uguale su qualsiasi browser o dispositivo. Al massimo può cambiare la dimensione!

Svantaggi:

• dimensioni: la pagina è molto pesante, ha difficoltà di caricamento su connessioni lente ed un pessimo impatto sulla banda hosting consumata e sul ranking nei motori di ricerca
• manutenzione: le richieste di modifica sono difficili e molto costose da applicare sia per quanto riguarda i contenuti e, peggio ancora, per quanto riguarda la struttura
• standard: questa tecnica è quanto di più distante ci sia dal concetto di pagina web semantica attorno cui ruotano tutti gli standard web attuali nonchè le direttive di usabilità ed accessibilità

Alternative:

L’alternativa più valida e sicura è la realizzazione di pagine web scrivendo il codice sorgente (e magari comprendendo ciò che si sta facendo!).
Solamente in questo modo il Web Master può evolvere ed avvicinarsi alla figura del Web Engineer.

Ho citato questi due termini “lavorativi” di proposito perchè non esiste organismo al mondo che possa darne una definizione reale ed assoluta dunque voglio esprimere anche la mia opinione:

Web Master: è una figura professionale risalente agli ultimi anni del secolo scorso. Dispone delle competenze tecniche sufficienti a pubblicare contenuti on-line.

Web Engineer: è una figura professionale sviluppatasi dal 2007 in poi. Dispone delle competenze del Web Master ma comprende le implicazioni semantiche durante la definizione di una pagina web.

Inoltre conosce e comprende il processo di costruzione di un’interfaccia grafica funzionale alla comunicazione, ha nozioni di SEO e SEM ed è in grado di predisporre semplici campagne di visibilità o di coordinare un team di specialisti esterno, ha nozioni di problem solving e di analisi.

Il Web Engineer ha la capacità di formulare una stima di lavoro su tempi e risorse necessarie alla risoluzione di una richiesta/problema. E’ capace di coordinare un gruppo di lavoro e formulare dei report verso il cliente. In linea di massima il Web Engineer ha una presenza professionale e deve essere percepito dal cliente come persona competente e su cui far affidamento: l’impressione personale del cliente è fondamentale!!!

Il Web Engineer ha una naturale tendenza all’aggiornamento e innovazione, legge articoli da diverse fonti on-line, frequenta community di colleghi e scrive egli stesso articoli su blog personali e non.

NOTA PERSONALE: nel momento in cui scrivo queste cose mi definisco un Web Developer che sta lavorando duro per diventare a tutti gli effetti Web Engineer!

Segnala presso:

1. Compatibilità cross-library
2. Configurazione globale del plugin
3. Separazione delle API dal codice funzionale del plugin stesso

1. Definizione di uno Scope anonimo:

/**
 * jQuery Bacheca
 * Plugin Dimostrativo
 */

;(function($){
  // Plugin's code goes here
})( jQuery );

2. Configurazione Globale del Plugin 

$.bacheca = {

  // Versione ed altre info eventuali.
  version: '1.0,
  author: 'Marco Pegoraro',
  doc: 'http://www.documentazionedelplugin.com',

  // Configurazione globale del plugin.
  defaults: {},

};

Questa istruzione estende jQuery e aggiunge una nuova proprietà chiamata con il nome del plugin stesso.

NOTA: I dati qui collezionati saranno pubblici ed accessibili da qualunque porzione di codice abbia accesso al namespace jQuery. Questo è un fatto importante perchè chi utilizza il nostro plugin potrà scrivere istruzioni simili alla seguente per configurare a livello globale il comportamento del plugin stesso.

$.bacheca.defaults.var1 = "foo";

Qualunque istanza del plugin bacheca riceverà questa variabile nella configurazione locale (a meno che non venga sovrascritta dalla configurazione dell’istanza stessa!)

Può essere molto utile poter controllare, a livello di pagina, se un determinato plugin è caricato o meno con un’istruzione simile a questa:

if ( $.bacheca ) { /* plugin exists */ } else { /* plugin missing */ }

3. Il Plugin

Il plugin vero e proprio è semplicemente una funzione che estende la collection di jQuery aggiungendo nuove funzionalità.

$.fn.bacheca = function() { /* plugin logic */ }

Molti sviluppatori implementano le funzionalità direttamente nel codice logico del plugin ma io trovo sia più corretto organizzare il plugin come un metodo pubblico di accesso ad API  private.

Questo significa che tutta la logica del plugin è inaccessibile da codice globale e la possiamo utilizzare solamente attraverso il plugin stesso mediante istruzioni simili a:

$('#bacheca').bacheca({ bgcolor: "#eee" });
$('#bacheca').bacheca( "write", "Nuova frase in bacheca" );
$('#bacheca').bacheca( "clear" );

Come si può vedere da questo esempio stiamo utilizzando sempre il plugin “bacheca” il quale avrà comportamenti differenti in base alla tipologia del primo parametro. nel caso il primo parametro venga riconosciuto come nome di una API essa verrà invocata ricevendo tutti i parametri aggiuntivi.

Il codice da utilizzare per implementare quanto esposto è:

// Collezione di metodi di interfaccia (API)
apis = {};

// Definizione del plugin
$.fn.bacheca = function( method ) {

  // Cerco il metodo richiesto tra le API esposte.
  if ( apis[method] ) {
    return apis[ method ].apply( this, Array.prototype.slice.call( arguments, 1 ));

  // Lancio il metodo di inizializzazione in presenza di un oggetto di configurazione.
  } else if ( typeof method === 'object' || ! method ) {
    return apis.init.apply( this, arguments );

  // Lancio un'eccezione jQuery in caso il metodo API non sia trovato.
  } else {
    $.error( 'Method "' +  method + '" does not exist on jQuery.bacheca' );

  }
}

Come anticipato il plugin non contiene logica funzionale ma è solo un “passa carte” verso metodi elencati in un array chiamato “apis”.

L’oggetto “apis” viene definito all’interno dello scope del plugin e risulta quindi essere un oggetto “privato” il cui utilizzo è riservato al codice del plugin stesso.
In questo modo possiamo esporre funzionalità all’esterno garantendo che esse non siano modificabili da altro software (altri plugins, etc).

4. API Collection

Il plugin definito nel paragrafo precedente non fa altro che cercare metodi all’interno della collezione delle API.

Il nostro lavoro di sviluppo del plugin consiste proprio nell’estendere queste API a partire dal metodo “init()”, che riceverà la configurazione del plugin stesso, proseguendo poi per i metodi di azione.

5. Bacheca::init()

apis.init = function( cfg ) {

  // Estendo la configurazione di default con la configurazione locale
  var cfg = $.extend( {}, $.bacheca.defaults, cfg );

  // Ciclo gli elementi identificati dal selettore
  return $(this).each(function(){
    $bacheca = $(this);
    $bacheca.html( cfg.content );
    if ( cfg.bgcolor != null ) $bacheca.css( 'background', cfg.bgcolor );
  });
}

Questo metodo riceve la configurazione locale applicata all’istanza del plugin. Ogni istanza del plugin (ogni suo utilizzo) può essere configurato a piacere ed è importante che queste configurazioni siano mantenute isolate le une dalle altre.

In questo primo e semplice plugin la configurazione è utilizzata semplicemente per definire il contenuto iniziale della bacheca ed il suo colore di sfondo. Gli altri metodi API non fanno uso di questa configurazione dunque non ci siamo occupati di gestirla al meglio (lasciamo l’argomento ad un articolo dedicato).

6. Bacheca::write(), Bacheca::clear()

apis.write = function( word ) {
  return $(this).append('<p>'+word+'</p>');
}

apis.clear = function() {
  return $(this).html("");
}

Questi due metodi API esposti dal plugin sono estremamente semplici e consentono di manipolare il contenuto della bacheca.

7. Utilizzo del plugin:

<!-- Codice HTML -->
<div id="bacheca"></div>

// Codice Javascript globale:
$(document).ready(function(){
  $('#bacheca')
    .bacheca({ bgcolor:"green", content:"Test Contenuto" })
    .bacheca('clear')
    .bacheca('write','Il mio nome è Marco')
  ;
});

Segnala presso:

Utilizza i due menu a tendina per modificare lo stato di avanzamento e la priorità assegnata al Task.

Una volta salvate le informazioni il Task viene spostato nella posizione corretta sia che ci si trovi in vista priorità che in vista progetti.

La sincronizzazione tra le varie finestre attive assicura una probabilità minima di sovrascrivere il lavoro altrui!

Come sviluppo futuro stiamo già pensando di sostituire i menu a tendina con delle icone rappresentative in modo da rendere il più immediata possibile l’interfaccia grafica della modifica del task!

Come sempre cerchiamo collaboratori e designer che vogliano partecipare al progetto!!!

Segnala presso:

In breve si tratta di un ToDo Manager cui sto applicando varie viste e funzionalità. Lo scopo è fornire lo strumento più semplice ed immediato possibile che però possa essere utilizzato anche in modo avanzato.

Vista “Progetto”

E’ il punto di ingresso in Task4 e ti chiede di organizzare le tue liste di ToDO per progetto e stato di avanzamento.
Ogni lista può essere riordinata tramite drag’n drop ed i task possono essere spostati da uno stato all’altro (o da un progetto all’altro) sempre tramite drag’n drop.

Lo scopo di questa vista è capire immediatamente cosa c’è da fare in ogni progetto e lavorare per spostare i task nello stato “Done”.

La vista Progetto organizza i ToDo per progetto e stato di avanzamento

Vista “Engagement”

Questa vista è attualmente in piena fase sperimentale. Stiamo cercando soluzioni grafiche migliori!

Lo scopo di Engagement è dare un colpo d’occhio dell’impegno temporale richiesto per completare i task.
I task hanno una dimensione che dipende dal tempo necessario al loro completamento.

In questo modo, se ho a disposizione solo 10 minuti di tempo, posso cercare qualcosa da fare tra i task più piccoli ignorando tranquillamente quelli grandi!

Così risparmio tempo nella decisione del “cosa faccio adesso?”

Permette di avere un "colpo d'occhio" sulla quantità di tempo richiesta per completare i vari Task

Vista Priorità

Questa vista è la più complessa da utilizzare in quanto richiede di assegnare una priorità ai ToDo sulla base di 4 possibilità (basta trascinare il ToDo nel quadrante corretto):

1. Urgente e Importante: cose da fare immediatamente perchè portano guadagno
2. Urgente e Non Importante: problemi da risolvere che fanno perdere tempo
3. Non Urgente e Importante: progetti remunerativi a lunga scadenza
4. Non Urgente e Non Importante: cose che fanno solo perdere tempo

Una corretta gestione del tempo vuole che si lavori per “svuotare” i vari quadranti nell’ordine qui sopra espresso. Solo in questo modo si otterrà un’ottimale gestione del proprio tempo ed il massimo rendimento personale.

Io personalmente trovo estremamente difficile gestire questa vista in quanto solitamente i compiti “Non Urgenti e Importanti” sono quelli che preferisco svolgere… tipo sviluppare questo software quando ho altre 1000 cose in lista!

Qui entra in scena il concetto di disciplina personale! Però per questo non ci sono soluzioni software adatte!

Organizza i ToDo in base alla loro priorità

Alcune funzionalità interessanti:

Al momento sto lavorando molto sul corretto funzionamento delle funzionalità di base e sulla ricerca di soluzioni grafiche che rendano più gradevole e profittevole l’utilizzo del tool… ad ogni modo:

Sincronizzazione Automatica:
quando una o più persone aprono lo stesso “foglio” i task vengono automaticamente sincronizzati ogni 5 secondi. In questo modo si riduce la possibilità di conflitto tra i vari utilizzatori favorendo il lavoro di gruppo.

Backup Veloce:
il software è in BETA e chissà problemi che possono spuntare… in alto a destra c’è un link che permette di scaricare il proprio db dei task. Esso contiene tutte le informazioni utilizzate dal tool e sì, è un semplicissimo JSON utilizzabile o integrabile in  qualunque altro software! (PS: non è detto che la cosa rimanga così!)

Multilinuga:
Task4 è localizzato in tutta la sua interfaccia, attualmente è disponibile in inglese ed italiano ma presto molte altre lingue verranno pubblicate!
http://www.consulenza-web.com/2011/06/pimp-disponibile-il-multilingua/

[we still be in "work in progress" status!]

Segnala presso:

In questa prima lezione viene illustrata la struttura di files e cartelle di base utile per la costruzione di un tema. E’ inoltre disponibile il download dell’esempio completo utilizzabile come base pronta per qualunque nuovo tema!

Vai alla lezione »

Indice delle lezioni:

• 01. struttura dei files di un tema
• 02. informazioni del tema
• 03. costruiamo il primo layout!

Segnala presso: