Perché parliamo di Produzioni video cenematografiche

Si potrebbe pensare che la gestione video sia limitata ad applicazioni come iMovie o Vimeo e a una nicchia di esperti video. Invece può essere esteso ad una gamma più ampia di applicazioni, non è essenzialmente limitato a editing video. In questo articolo forniremo una panoramica del Framework AV Foundation applicato su un esempio pratico.

Nel nostro caso particolare, la sfida era quella di creare un’applicazione che, partendo da una serie di clip video esistenti, fosse stata in grado di costruire una storia fatta collegando un sottoinsieme di queste clip sulla base di decisioni prese dall’utente durante l’interazione con l’applicazione.
Il gioco finale è un insieme di scene, girato in luoghi diversi, che compongono una storia. Ogni scena è composto da un prologo, una conclusione (epilogo) e una serie di piccole clip che verranno eseguite dall’applicazione sulla base di alcune scelte fatte dagli spettatori – utenti- giocatori.  Se le scelte sono corrette, lo spettatore sarà in grado di riprodurre tutta la scena fino al suo lieto fine, ma in caso di errore dovrà tornare sulla scena prologo iniziale o in una certa scena intermedia. Lo schema seguente mostra un possibile schema di una tipica scena: un prologo, un flusso vincente (verde) alcuni rami (giallo sono intermedie, il rosso stanno perdendo filiali) e di un lieto fine. Così gli spettatori da qualche parte nel TRACK1 saranno chiamati a prendere una decisione, se lui / lei è in quel momento in gioco continuerà con TRACK2, se non entrerà nel giallo Track4, e così via

Quello che abbiamo tra le mani è la serie completa di tracce, ogni traccia rappresenta una sottosezione specifica di una scena, e uno storyboard che ci fornisce le regole da seguire per costruire la storia finale. Così lo storyboard è fatto dalle scene, dalle tracce del compongono ogni scena e dalle norme che stabiliscono il flusso attraverso queste tracce.
La sfida principale per lo sviluppatore è quello di mettere insieme queste clip e riprodurre un video in base allo stato attuale dello storyboard, quindi passare alla successiva, selezionare un nuovo clip di nuovo e così via: tutto deve trascorrere fluidamente senza interruzioni.
Lo spettatore deve prendere le decisioni, interagendo con l’applicazione-gioco e questo può essere fatto sovrapponendo al film con alcuni controlli personalizzati.

AV Foundation Framework

Sarebbe impossible raggiungere gli obiettivi spiegati nel paragrafo precedente utilizziando lo standard Media Framework view controllers, MPMoviePlayerController e MPMoviePlayerViewController. Questi conrollers sono buoni per riprodurre un filmato e fornire i controlli di sistema, a schermo intero e la rotazione del dispositivo di sostegno, ma assolutamente non adatti per i controlli avanzati.
Dopo il rilascio di iPhone 3GS dell’utility per la fotocomara avevamo la possibilità di fare un po ‘di tagli e l’esportazione, ma queste capacità non sono state date agli sviluppatori attraverso le funzioni pubbliche del SDK. Con l’introduzione di iOS 4, l’attività svolta da Apple con lo sviluppo delle app iMovie ha dato agli sviluppatori un ricco insieme di classi che consentono la manipolazione completa dei video . Tutte queste classi sono state raccolte ed esportate in un unico framework pubblico, denominato AV Foundation. Questo framework esiste da iOS 2.2, a quel tempo era dedicato alla gestione audio con la ben nota classe AVAudioPlayer, poi è stato esteso in iOS 3 con il AVAudioRecorder e le classi AVAudioSession ma il set completo di funzionalità che consentono capacità video avanzate ha avuto luogo solo a partire dal iOS 4 e sono stati pienamente presentati al WWDC 2010.

La posizione della AV Foundation nello iOS Frameworks stack si trova  sotto UIKit, dietro l’application layer, e immediatamente sopra i basic Core Services frameworks, in particolare Core Media che viene utilizzato da AV Foundation per importare strutture di temporizzazione e le funzioni necessarie per la gestione dei media . In ogni caso si può notare la diversa posizione nello stack rispetto Media Player di alto livello. Ciò significa che questo tipo di struttura non è in grado di offrire una classe plug-and-play  per la riproduzione di semplici video , ma si potranno apprezzare i moderni concetti di alto livello che sono alla base di questo framework, di sicuro non siamo allo stesso livello dei vecchi framework come core Audio.

(image source: from Apple iOS Developer Library)

Building blocks

L’organizzazione dele classi di AV Fondation è abbastanza intuitiva. Il punto di partenza e il building block principale è data da AVAsset. AVAsset rappresenta un oggetto statico multimediale ed è essenzialmente un aggregato di tracce che sono rappresentazioni temporizzate  di una parte de media. Tutti i brani sono di tipo uniforme, in modo che possiamo avere tracce audio, tracce video, tracce sottotitoli, e un complesso di attività può essere fatto di più tracce dello stesso tipo, ad esempio siamo in grado di avere più tracce audio. Nella maggior parte dei casi un asset è fatto di un audio e una traccia video. Si noti che AVAsset è una classe astratta per cui è indipendente dalla rappresentazione fisica dei media che rappresenta, inoltre la creazione di un’istanza AVAsset non significa che noi abbiamo tutti i media pronti per essere riprodotti, si tratta di un puro oggetto astratto.

Ci sono due classi di attività disponibili: AVURLAsset, per rappresentare un supporto in un file locale o in rete, e AVComposition (insieme con la sua variante mutevole AVMutableComposition ) per un’attività composta da più supporti. Per creare una risorsa da un file abbiamo bisogno di fornire l’URL del file:

NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:AVURLAssetPreferPreciseDurationAndTimingKey];
AVURLAsset *myAsset = [AVURLAsset URLAssetWithURL:assetURL options:optionsDictionary];

L’ options dictionary poò risultare nullo ma per i nostri scopi – per fare una composizione film – abbiamo bisogno di calcolare la durata esatta e fornire l’accesso casuale ai media. Questa opzione extra, che è l’impostazione su YES della chiave AVURLAssetPreferPreciseDurationAndTimingKey, potrebbe richiedere più tempo durante l’inizializzazione delle attività, e questo dipende dal formato di film. Se questo film è in QuickTime o MPEG-4, il file contiene informazioni aggiuntive che in sintesi annulla il tempo in più, ma ci sono in altri formati, come MP3, in cui queste informazioni possono essere estratte solo dopo la decodifica del media file, in tal caso l’inizializzazione del tempo non è trascurabile. Si tratta di una prima raccomandazione che diamo agli sviluppatori: si prega di utilizzare il formato del file a seconda dell’applicazione.
Nella nostra applicazione dobbiamo già conoscere le caratteristiche dei film che stiamo usando, ma in un diverso tipo di applicazione, in cui è necessario fare un po ‘di editing dei filmati, si può essere interessati a ispezionare le proprietà delle risorse. In tal caso si deve ricordare la regola di base che l’inizializzazione di un asset non significa aver caricato e decodificato in memoria: questo significa che ogni proprietà del file multimediale può essere ispezionata, ma questo potrebbe richiedere un poco di tempo in più. Per completezza abbiamo semplicemente introdotto il modo asset inspection che può essere fatto lasciando l’utente interessato alla documentazione di riferimento (vedere l’elenco proposto letture alla fine di questo post). Fondamentalmente ogni proprietà dell’attività può essere verificata utilizzando un protocollo asincrono chiamato AVAsynchronousKeyValueLoadingwhich che definisce due metodi:

- (AVKeyValueStatus)statusOfValueForKey:(NSString *)key error:(NSError **)outError
– (void)loadValuesAsynchronouslyForKeys:(NSArray *)keys completionHandler:(void (^)(void))handler

Il primo metodo è sincrono e restituisce immediatamente lo stato di conoscenza del valore specificato. Ad esempio si può chiedere lo status di “durata” e il metodo restituisce uno di questi stati possibili: carico, carico, fallito, sconosciuto, annullato. Nel primo caso il valore di chiave è noto e quindi il valore può essere immediatamente recuperato. Nel caso in cui il valore è ignoto è opportuno richiamare le loadValuesAsynchronouslyForKeys:completionHandler: metodo che alla fine dell’operazione chiamerà il callback dato nel completionHandlerblock, che a sua volta interroga lo stato di nuovo per l’azione appropriata.

Video composition

Come abbiam detto all’inizio, il nostro storyboard è composto da una serie di scene e ogni scena è composta da diverse clip il cui ordine di riproduzione non è nota a priori. Ogni scena si comporta indipendentemente dalle altre in modo da creare una composizione per ogni scena. Quando abbiamo un insieme di attività, o tracce, e da loro si costruisce una composizione nel complesso stiamo creando un altro asset. Questo è il motivo per cui le classi AVComposition e AVMutableComposition sono sottoclassi della classe  AVAsset base.
È possibile aggiungere contenuti multimediali all’interno di una composizione mutevole, semplicemente selezionando un segmento di un bene, e l’aggiunta di una gamma specifica di nuova composizione:

- (BOOL)insertTimeRange:(CMTimeRange)timeRange ofAsset:(AVAsset *)asset atTime:(CMTime)startTime error:(NSError **)outError

Nel nostro esempio abbiamo una serie di tracce che si desidera aggiungere una dopo l’altra per generare un insieme continuo di clip. Così il codice può essere semplicemente scritto in questo modo:

AVMutableComposition = [AVMutableComposition composition];
CMTime current = kCMTimeZero;
NSError *compositionError = nil;
for(AVAsset *asset in listOfMovies) {
BOOL result = [composition insertTimeRange:CMTimeRangeMake(kCMTimeZero, [asset duration])
ofAsset:asset
atTime:current
error:&compositionError];
if(!result) {
if(compositionError) {
// manage the composition error case
}
} else {
current = CMTimeAdd(current, [asset duration]);
}
}

Prima di tutto abbiamo introdotto il concetto di tempo. Si noti che tutti i media hanno un concetto di tempo diverso dal solito. Prima di tutto il tempo può muoversi avanti e indietro, oltre il lasso di tempo può essere superiore o inferiore a 1x se si sta visionndo il filmato al rallentatore o in avanzamento rapido. Inoltre si ritiene più conveniente  rappresentare il tempo non come virgola mobile o un numero intero, ma come numeri razionali. Per tale ragioneil framework  Core Media  fornisce la CMTimestructure e un insieme di funzioni e macro che semplificano la manipolazione di queste strutture. Quindi, al fine di costruire una specifica istanza time instance:

CMTime myTime = CMTimeMake(value,timescale);

che infatti specifica un numero di secondi proposto dal value/timescale. La ragione principale di questa scelta è che i film sono fatti di frames e i fotogrammi sono dati ad una razione fissa al secondo. Così, per esempio, se abbiamo una clip che è stata ripresa a 25 fps, allora sarebbe conveniente per rappresentare l’intervallo singolo fotogramma come un insieme variabile CMTime con valore = 1 e tempi = 25, corrispondente a 1/25th di secondo. 1 secondo  è dato da un CMTime con valore = 25 e timescale = 25, e così via (ovviamente si può ancora lavorare con i secondi, se volete, è sufficiente utilizzare i CMTimeMakeWithSeconds (seconds) function). Quindi, il codice di cui sopra inizialmente imposta l’ora corrente a 0 secondi (kCMTimeZero) quindi avvia l’iterazione su tutti i nostri film che sono assets in. Poi si aggiunge ciascuna di questi asset nella posizione corrente della nostra composizione con la loro gamma completa ([asset duration]). Per ogni asset spostiamo la composition head (current) per la lunghezza (in CMTime) dell’asset. A questo punto la composizione è fatta di un set completo di brani aggiunti in sequenza. Ora possiamo giocare.

Playing an asset

Il framework AVFoundation non offre alcuna player integrato, come siamo abituati a vedere con MPMovieViewController. Il motore che gestisce lo stato di riproduzione di un asset è fornito dalla classe AVPlayer. Questa classe si occupa di tutti gli aspetti relativi al play dell’asset ed essenzialmente è l’unica classe in AV Foundation che interagisce con i controller di visualizzazione dell’applicazione per mantenere in sincronia la logica dell’applicazione con lo stato di riproduzione: questo è rilevante per il tipo di applicazione che stiamo prendendo in considerazione in questo esempio, come lo stato di riproduzione può cambiare durante l’esecuzione del filmato base alle specifiche interazioni dell’utente  in momenti specifici all’interno del film. Tuttavia non abbiamo una relazione diretta tra AVAsset e AVPlayer, la loro connessione è mediata da un’altra classe denominata AVPlayerItem. Questa organizzazione delle classi ha lo scopo di separarel’asset, considerato come un’entità statica, dal player, puramente dinamico, fornendo un oggetto intermedio, che rappresenta uno stato specifico di presentazione di un asset. Ciò significa che per un determinat e unicoo asset  possiamo associare elementi di più players, tutti  rappresentano diversi stati dello stesso asset e eseguito da diversi players. Quindi, il flusso in questo caso è dato da un determinato asset che crea un elemento di player e poi lo assegna al pleyer finale.

AVPlayerItem *compositionPlayerItem = [AVPlayerItem playerItemWithAsset:composition];
AVPlayer *compositionPlayer = [AVPlayer playerWithPlayerItem:compositionPlayerItem];

Al fine di eseguire il rendering sullo schermo, dobbiamo fornire una view in grado di rendere lo stato attuale di player. Abbiamo già detto che iOS non offre on-the-shelf una vista per questo scopo, ma quello che offre è un livello speciale CoreAnimation chiamato AVPlayerLayer. Quindi è possibile inserire questo livello nella gerarchia a livello di Anteprima del player o, come nel seguente esempio, utilizziamo questo come livello di base per questa view. Quindi, l’approccio suggerito in tal caso è quello di creare un MovieViewer personalizzato e il  set AVPlayerLayeras base layer class:

// MovieViewer.h

#import <UIKit/UIKit.h>
#import <AVFoundation/AVFoundation.h>
@interface MovieViewer : UIView {
}
@property (nonatomic, retain) AVPlayer *player;
@end

// MovieViewer.m

@implementation MovieViewer
+ (Class)layerClass {
return [AVPlayerLayer class];
}
– (AVPlayer*)player {
return [(AVPlayerLayer *)[self layer] player];
}
– (void)setPlayer:(AVPlayer *)player {
[(AVPlayerLayer *)[self layer] setPlayer:player];
}
@end

// Intantiating MovieViewer in the scene view controller
// We suppose “viewer” has been loaded from a nib file
// MovieViewer *viewer
[viewer setPlayer:compositionPlayer];

A questo punto siamo in grado di riprodurre il filmato, che è abbastanza semplice:

[[view player] play];

Translated from Carlo’s post

Quando si decide di progettare un’App è sempre necessario seguire i principi di base della progettazione industriale.
Molte persone  pensano di commissionare un’app, ma quando si trovano a dover descrivere l’applicazione e quindi come la loro idea possa essere tradotta nell’esperienza dall’utente e nell’interfacia grafica (User Experience & User Interface),  si trovano impreparati e si nascondono molto spesso dietro frasi del tipo “non saprei questo è un lavoro per tecnici, pensateci voi tecnici!”.
Inutile aggiungere che quando poi i cosidetti “Tecnici” si mettono al lavoro queste persone, che non hanno vuluto delegare il concept, inizieranno a chiedere modifiche sostanziali dispensando consigli e ragguagli di ogni genere e quasi sempre solo dopo che l’app e’ arrivata alla fase finale del suo sviluppo.
E’ ben noto il concetto secondo il quale i “tecnici”, e gli ingegnieri, prima costruiscono il cuore dell’applicazione e poi ci adattano il design e fanno il contrario, loro malgrado, solo se il commitment e’ valido e convincente e, sopratutto, quando questo è deciso fin dall’inzio delle fasi di progettazione.
Di norma con l’approccio “fate voi che poi vediamo” , voluto dai professionisti distratti e poco preparati,  il risultato estetico finale può risultare quantomai scadente dato che ogni ingegniere sa bene che, prima di mettersi a scrivere codice, bisogna aver chiari i principi dell’interfaccia utente unitamente alla descrizione delle funzionalità legate all’esperienza dell’utente stesso.

Alcuni sofisti mi potranno criticare per l’uso della parola “utente”, che a volte risulta poco accattivante se si pensa che alla fine gli utenti non sono altro che persone, ovvero individui utilizzatori. Questa differenza di significato delle parole mi è molto chiara, ma per semplicità comunicativa e sopratutto per necessità di traduzione preferisco usare la parola “utente” o “utilizzatore” al posto dell’ “individuo“.

10 principi per un buon design di un’app e di un prodotto

Inanzi tutto,  per citare Steve Jobs,  propongo  una delle definizioni di design che più mi ha convinto:
“Il design è l’anima che si trova al cuore di un oggetto creato dall’uomo e che gradualmente si estrinseca ai piani esteriori.”

Di certo lo stesso Jobs si ispirava ai principi di Dieter Rams, ex-designer della Braun, che ha enumerato i suoi 10 principi per un  buon design di un prodotto:

Dieter Rams e i suoi prodotti di design

• Un buon design deve essere innovativo.
• Un buon design deve rendere il prodotto utile.
• Un buon design deve essere dotato di estetica.
• Un buon design deve aiutare a capire il prodotto.
• Un buon design non deve essere invasivo, mancare di riservatezza.
• Un buon design deve essere onesto.
• Un buon design deve essere durevole.
• Un buon design è la conseguenza dell’ultimo dettaglio.
• Un buon design si deve preoccupare dell’ambiente.
• Un buon design deve contenere il minor design possibile.

Naturalmente è facile capire che questi principi si adattano sia al design dei prodotti industriali, ma anche per il design delle Applicazioni, sopratutto se queste verranno utilizzate sui prodotti che sono stati costruiti proprio secondo i buoni principi del design industriale, come lo sono tutti i prodotti Apple.

Progettare meglio, lavorare meno

Dieter Rams, creatore dei 10 principi, ha sempre espresso il suo approccio al design con la frase: “Weniger, aber besser” , ovvero “Meno, ma meglio” .
Il minimalismo , oltre ad essere molto elegante, è sicuramente il modo migliore per permettere a tutti gli utenti-utilizzatori di comprendere d’istinto il prodotto e le sue funzionalità e rende il prodotto stesso, o l’App,  amichevole all’uso (user friendly) e “puro”.

Di seguito riporto i commenti , tradotti dall’inglese, dello stesso Rams sui principi da lui stesso enunciati:

1.  Le possibilità d’innovazione non sono esaurite. Lo sviluppo tecnologico offre sempre nuove opportunità per il design innovativo. Ma il design innovativo si sviluppa sempre assieme alla tecnologia innovativa, e non può mai essere fine a se stesso.
   (The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself )
2. Un prodotto viene acquistato per essere utilizzato. Esso deve soddisfare determinati criteri, non solo funzionali, ma anche psicologici ed estetici. Un buon design sottolinea l’utilità di un prodotto, mentre trascura tuuto ciò che potrebbe sminuirla.
   (A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it. )
3. La qualità estetica di un prodotto è parte integrante della sua utilità, perché i prodotti che utilizziamo ogni giorno influiscono sulla nostra persona e il nostro benessere. Ma solo gli oggetti ben costruiti possono essere belli.
   (The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being. But only well-executed objects can be beautiful.)
4. Chiarifica la struttura del prodotto. Meglio ancora, si può far parlare il prodotto. Meglio se esso è auto-esplicativo.
   (It clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.)
5. I prodotti che soddisfano un fine sono come strumenti. Non sono né oggetti decorativi, né opere d’arte. Il loro Design dovrebbe quindi essere sia neutrale che sobrio, per lasciare spazio all’auto-espressione dell’utilizzatore.
   (Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.)
6. Non costruire il prodotto in modo da farlo apparire più innovativo, potente o importante di quanto sia realmente. E non tentare di manipolare il consumatore con promesse che non possono essere mantenute.
   (It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.)
7. Evita di seguire la moda ma non appare mai antiquato. A differenza del design “alla moda”, il prodotto deve durare per molti anni – anche nella società dell’usa e getta di oggi.
   (It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.)
8. Nulla deve essere arbitrario o lasciato al caso. La cura e la precisione, nel processo di progettazione, mostrano il rispetto nei confronti dei consumatori.
   (Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.)
9. Il Design offre un importante contributo alla salvaguardia dell’ambiente. Esso conserva le risorse e riduce al minimo l’inquinamento fisico e visivo durante tutto il ciclo di vita del prodotto.
   (Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.)
10. Meno, ma meglio – questo perchè ci si concentra sugli aspetti essenziali, e i prodotti non sono appesantiti da elementi non essenziali. Torna alla purezza, torna alla semplicità.
    (Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials.Back to purity, back to simplicity.)

Valutazione Euristica

A questo punto non mi resta che descrivere anche la cosidetta valutazione euristica.
La Valutazione Euristica è un metodo ispettivo che viene effettuato esclusivamente dagli esperti di usabilità  e consente di valutare se una serie di principi generali di progettazione sono stati applicati correttamente nell’interfaccia utente.
Le linee guida (“Ten Usability Heuristics”) su cui si basa questo tipo do valutazione sono state sviluppate negli anni 1990 da Jakob Nielsen e Rolf Molich e sono state pensate per i desktop software , ma anche in questo caso questi principi sono ancora validi per le applicazioni studiate per touchscreen, come le App iOS per iPhone e iPad ,  per le  app Android e Window Mobile.

Stimare i costi e definire il processo di un'app è come rivedere Tempi Moderni

Perché gli sviluppatori non riescono a stimare di stimare il tempo di produzione?

Questa, come altre domande, sono lo spunto per scrivere un articolo che mi è stato ispirato dopo la lettura di un post di  Ash Moran mentre navigavo per il Patch Space Blog.

Introduzione
In passato, mentre ero dirigente (settore di Sviluppo) di grandi gruppi italiani, ho cercato molte volte di comunicare al vertice aziendale che determinare su un documento (Plan) le esatte tempistche delle diverse fasi di lavoro dello sviluppo di un software è un attività abbastanza inutile e che, semmai, serve solo a far lievitare drammaticamente i costi.
Con questo non voglio affermare che le pianificazioni, e i diversi report che ci impongono le grandi aziende, sono  inutili; questi report servono a fornire date di scadenza e di rilasco delle componenti in relazione ad un budget definito.
Il problema nasce quando ti capita come capo la classica persona (top-manager?) che non avendo mai neppure sviluppato un “hello world!” si ostina a cercare di voler capire cosa esattamente farai con la tua squadra e ti imporrà dei lunghi meeting in cui sarai costretto a dire numerose baggianate perchè le domande che ti faranno saranno talmente idiote da non poter far altro che costringerti a dettagliare le varie fasi del processo che tanto non comprenderanno del tutto.

Cercare di spiegare e dettagliare in anticipo le fasi di uno sviluppo software, come definire i tempi di  tutte queste singole fasi (o task) a un “Manager” che si ostina a voler capire come poter fare/controllare/comprendere il tuo lavoro è come chiedere ad un compositore musicista di spiegargli come farà a comporre una canzone e quando e come arriverà alla prima , alla seconda o alla terza strofa…
Sappiamo con certezza che ad un compositore si puo’ affidare la scrittura di un’opera e l’artista al massimo potrà dirci quando ce la consegnerà ma di certo nessuno con la testa sulle spalle potrà pensare di chiedergli esattamente cosa farà , quando lo farà e di fornirgli una data esatta in cui sarà arrivato all’ ennesima nota sullo spartito.

A questo punto uno dei tanti miei ex colleghi, che casualmente leggerà questo articolo, si dirà: “bhe ma in azienda a noi non servono grandi artisti come Mozart, ma solo mediocri esecutori che devono fare esattamente quel che diciamo”.
La mediocrità è ovviamente una componente essenziale di molti cosidetti “managers” della grande o media azienda italiana, quella mediocrità che ha portato un paese di artisti e navigatori ai margini dell’impero economico e culturale.
E’ quindi abbastanza facile intuire che il mio pensierò ha basi culturali completamente diverse, poichè lo sviluppo è a mio parere sinonimo di creatività e solo la creatività applicata, unitamente alla genialità, può portare risultati duraturi e tenere alti quei fattori che fanno di un’azienda un motore economico-sociale che non si arresta neppure con le crisi.
Semmai, per parafrasare Einsten, è solo con la crisi che si sviluppa la genialità.

Stimare il tempo o il rilascio?

Non possiamo stimare il tempo per ogni singola attività nello sviluppo di software in quanto la natura del lavoro è la creazione di nuova conoscenza.

L’obiettivo di sviluppo del software è quello di automatizzare i processi. Una volta che un processo è automatizzato, esso può essere eseguito ripetutamente, e nella maggioranza dei casi, in un tempo prevedibile.

Il codice sorgente è come un progetto di produzione, il computer è come una vera e a se stante azienda, gli ingressi (dati) sono come materie prime, e le uscite (dati o programmi) sono come prodotti finiti. Quindi la chiave di volta sta nella progettazione del processo, che è un compito complesso e costoso. Una volta che il processo è stato definito e reso efficente non c’è più bisogno di riscoprire questo processo, basta acquisire il modello.

Non è in realtà sempre un problema il fatto che i tempi di sviluppo sono in parte  imprevedibili, perché il rovescio della medaglia è che così è il valore restituito sarà maggiore; un software di successo può creare o salvare molto più del suo costo. Tom DeMarco, sempre citato da Ash,  sostiene la necessità di concentrarsi sui progetti di alto valore proprio per questo motivo. Si noti che questo approccio ha valore come generazione di un nuova mentalità, che porterà a superare l’attuale  prevalente mentalità basata quasi esclusivamente sul controllo dei costi . Questa è una questione tutt’altro che banale.

Una delle migliori spiegazioni della variabilità, e come sfruttarla per creare valore, è  nei “Principi del flusso di prodotto per lo sviluppo” di Don Reinertsen.

Regola generale: prendere le stime di uno sviluppatore, raddoppiare e aggiungere un po’

Il doppio-and-add-a-bit è una regola interessante. Quando i manager fanno questo, spesso  le attività vengono completate in tempo.

Voglio precisare che la pratica di stimare ogni task, o building block (come lo chiamano alcuni consulenti) puo’ portare alla richiesta di budget di gran lunga piu’ elevati del necessario; a questo proposito voglio fare un’esempio su un fatto che mi è accaduto realmente:
Qualche anno fa un grandissimo gruppo industriale mi chiese di dirigere un progetto per un portale intranet, che sarebbe stato utile ai dipendenti. Dopo le prime stime sull’utilità di un nuovo portale intranet e sopratutto dopo l’analisi degli eventuali costi risparmiati dal Gruppo con l’introduzione del self-service per i dipendenti, si cerco’ di stimare tempi e costi dello sviluppo.
Consegnai un breve rapporto, basato sulla forte esperienza pratica sul campo, in cui stimavo a spanne un budget di X euro e il rilascio graduale dei servizi entro un anno. Mi chiesero allora di dettagliare uno per uno i task , fino al singola piccola applet, e di definirne per ognuno tempi di rilascio e costi per task . Facendo questo mi ero accorto, seguendo il loro modello di stima, che in ogni singola pagina web potevano essere presenti anche una trentina di building blocks (…). Evidentemnte ho cercato di fargli capire che questa era una pratica del tutto superflua e che bastava proiettare delle medie rispetto alle esperienze pregresse e sopratutto in base al materiale disponibile e alle caratteristiche professionali del team di sviluppo.
Sono stato costretto a lasciare l’incarico quando un gruppetto di giovani consulenti d’azienda , che mai nella loro vita avevano neppure lavorato su un sisterma di sviluppo, hanno presentato un piano ben dettagliato in un mastodontico file power point (ppt) con bella grafica e in cui si definivano tutti i piccoli building block, uno per uno e si proiettavano scadenze e costo per ognuno di essi: risultato un budget da 7X euro in tre anni. Decisi di lasciare l’incarico sopratutto dopo che il mio sguardo si era soffermato su una decina di slides dedicate al servizio “calcolatrice” il cui costo era di alcuni giorni di lavoro. Ogni sviluppatore degno di questo nome sa che un building block “calcolatrice” lo si ottiene gratis e neppure si deve mostrare in un piano del genere… e questo non era neppure il fatto piu’ eclatante.
Inutile proseguire , poiche’ evidentemente il mio approccio non era piaciuto e mi sarei dovuto adattare a quello dei consulenti che hanno lasciato l’azienda qualche anno dopo, in fallimento, e con nessun portale intranet funzionante… dopo 4 anni la stessa azienda ha dovuto riaccendere il sistema precedente , e questo dopo aver speso piu’ del previsto e senza risparmiare alcun costo.
Questo racconto è importante per far capire ai decision maker che un software , come un’app per iPhone o un sito web è frutto di esperienza sul campo e questa non potrà essere mai sostituita da stime dettagliate e del tutto astratte , che spesso costringono al rispetto stretto dei tempi intermedi non curando il senso del progetto stesso.
A mio parere è proprio l’insistenza  ,da parte dei top manager, ad adottare modelli di stima basati sul modello finanziario e fondato sul controllo del prodotto che hanno portato l’industria informatica italiana ad una crisi cosi’ profonda che oramai parlare di industria informatica italiana non ha neppure piu’ senso…

Non sono solo agli sviluppatori a far male le stime.

Tutti prima o poi inprovviseranno perché gli sarà affidato un compito che non hanno mai fatto prima e non saranno in grado di effettuare con successo una vera stima fino a quando non hanno acquisito esperienza.
Se non sappiamo, non sappiamo, e dobbiamo dirlo. I clienti o i capi che vedono i progressi compiuti e sono stati messi al corrente  del rischio dei task (e hanno scelto di investire ) hanno molto di più fiducia nel proprio team ripetto ai clienti o ai capi che basano il loro controllo su stime.

La stima è una abilità molto importante e dovrebbe essere insegnata sopratutto a figure “junior”

Ciò che dobbiamo fare è insegnare a tutti gli sviluppatori junior il significato della parola “fatto” o “terminato”. Se un cliente o un capo viene a scoprire nel futuro, a un certo punto imprecisato,  che qualcosa è stato consegnato incompiuto (possibilmente in fretta per venire incontro alla stima) cio’ non solo rende la stima controproducente, ma rende inaffidabile tutto il calendario di lavoro con l’attuale processo. Questo problema è molto comune, e può causare una significativa perdita della capacità di un team di sviluppo.

Agile Developing

Nessuna grande e consolidata azienda ha avuto risultati straordinari come quelli avuti dalle società create da adolescenti o giovani imprenditori che non avevano, fortunatamente, alcuna idea dei modelli di lavoro , e di pensiero, che erano imposti dall’establishment e dall’economia finanziaria. Pensiamo a Mark Zuckerberg | Facebook, a Larry Page e Sergey Brin | Google, Sean Parker | Napster, Plaxo, Causes e Facebook.. pensiamo a Jeff Bezos, Bill Gates o a Steve Jobs e tanti altri.
Tutti questi personaggi hanno creato il nostro futuro e,  con tutta probabilità, non si sono mai adattati (per fortuna!) ai modelli aziendali e alla moda.

Negli ultimi anni , probabilmente a causa degli enormi Flop,  tutte le grandi aziende  hanno tentato di cavalcare l’onda della new economy e ora si ritrovano a terra, parlano molto di “Agile Developing“.
Il nome “Agile” ci arriva dall’ingegneria del software che differenzia i metodi e i modelli di sviluppo in:  Metodologie pesanti per i vecchi metodi basati sul Modello a cascata,  Metodologie iterative per i metodi basati sul Modello a spirale e  Metodologie agili per i metodi basati sui principi definiti nell’Agile Manifesto.
Leggendo Wikipedia si scopre che il termine “Metodologie Agili” fu coniato nel 2001 proprio quando il Manifesto Agile è stato formulato e che:
” La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, progetto, implementazione, test e documentazione.
Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto”.

Se si utilizza l’approccio agile si dovrà comunicare sempre in tempo reale, preferibilmente faccia a faccia, puttosto che fare report o documenti. Componenti di un team agile sono solo le persone necessarie per portare a termine il progetto.

Mi aspetto che qualcuno mi dirà: bella scoperta , quella dell’acqua calda…

Molto probabilmente parleremo nei prossimi articoli di questo metodo che molte aziende stanno implementando , anche perche’ importato da molte società di consulenza.

Cari Editori,

finalmente abbiamo realizzato un sistema che permette di pubblicare riviste, libri, giornali o qualsivoglia pubblicazione senza alcun costo per ogni nuovo numero o per ogni nuovo lettore.

Ci rivolgiamo al piccolo editore come alla grande casa editrice; dopo aver collaudato i nostri prototipi, e dopo piu’ di un anno di sviluppo, i3Factory è lieta di presentare un sistema software che permette di pubblicare le proprie edizioni sull’App Store senza investimenti onerosi.

Attraverso l’App Store di Apple , l’Android Market e Amazon App store, il vostro mercato cartaceo diventerà il mercato online mondiale, con la possibilità quindi di raggiungere nuovi lettori in tutto il mondo.

I costi di stampa in carta sono sempre piu’ elevati e non permettono all’editore di pianificare tirature elevate e quindi di raggiungere un pubblico geograficamente piu’ vasto.

Con il nostro sistema editoriale per iPad , i costi di tiratura si annullano; i  lettori sfoglieranno la vostra pubblicazione sul tablet, iPad, iPhone o Smartphone e il costo per le nuove pubblicazioni sara’ sempre nullo con costo marginale tendente allo zero.

Notiamo che l’esperienza di lettura di un magazine su iPad e di gran lunga piu’ soddisfacente dell’esperienza di leggere la stessa pubblicazione su carta.
Oltre ad essere semplice da sfogliare, basta un gesto con la mano, la rivista diventa piu’ fruibile; basterà pensare alla possibilita’ di poter ingrandire i caratteri con un gesto e fare lo zoom anche su immagini e altri dettagli oltre alla possibilità di fruire di video o di seguire links e ipertesti, html5…

Nessun costo aggiuntivo. Si utilizzano le infrastrutture esistenti del cliente e l’applicazione viene distribuita da Apple, Google e Amazon.

Illimitati lettori potenziali allo stesso costo,

nessun impatto ecologico.,

..sono solo alcuni dei vantaggi dell’utilizzo del  sistema editoriale i3Factory.

Alcune delle principali caratteristiche del  sistema editoriale “i3F Editorial” per iPad , iPhone e Android :

• Pubblicazione e distribuzione Applicazione personalizzata per l’editore  su App Store

• Illimitate Pubblicazioni

• Illimitati Lettori e Utenti

• Distribuzione pubblicazioni su App Store sia gratuitamente che a Pagamento (inApp)

• Investimento Una Tantum: nessun costo di manutenzione

• Nessun costo nascosto: paghi una sola volta e il sistema funziona per sempre

• Dal pdf ad iPad senza costi

• Links ipertestuali sul pdf

• Support per Video e Multimedia

• Supporto Youtube

• Social Network: Facebook, Twitter, etc..
• Supporto HTML5 Nativo
• Supporto Pdf
• Supporto social networks (Facebook , Twitter, etc…)

• Nessuna infrastruttura necessaria, colleghiamo il sistema al vostro sito web senza alcun costo aggiuntivo per hardware.

Alcune caratteristiche Tecniche del sistema editoriale:

• php per la processione dei dati

• sqlite per db
• Interfaccia DB editor

• una singola pagina html con interfaccia in ajax

Funzioni

• autenticazione  utente

• caricamento dei dati realtivi a pubblicazioni

• modifica dei dati con un sistema a versioni

• output dei dati in formato json

• caricamento selletivo immagini per copertine riviste

• resize automatico di dimensioni predefinite delle copertine caricate

• caricamento file zip e pdf

• abbinamento pagina della rivista con video

• backup automatico del db
• Inserimento contenuti extra e Html5

Costi/Prezzi:

Evidentemente i prezzi varieranno rispetto all’esigenza dell’editore, che di norma richiede alcune “personalizzazioni”.

Il prezzo di partenza per la nostra soluzione parte da  500 euro per Autori indipendenti e appena 1000 euro per Piccoli Editori, a partire da 2000 euro  per Medi e Grandi Editori.

Domanda:
Ma se i prezzi sono cosi’ bassi allora la soluzione non è professionale?

Risoposta:
La soluzione proposta è teconologicamente ai massimi livellli di avangiardia e professionalità; le grandi bolle speculative dovrebbero avervi fatto capire che quando si ha a che fare con internet e le App il prezzo e il costo non hanno nulla a che vedere con la professionalità;
ci sono sul mercato soluzioni editoriali di gran lunga inferiori a quella da noi proposta che possono costare anche 100 volte la nostra.

La Nostra filosofia è:
Il prezzo di vendita deve essere sempre onesto!

Maggiori Informazioni sui pacchetti editoriali potete trovarli su questo in questa pagina:

Sistema editoriale per iPad, iPhone & Android.

o direttamente sul  i3F Editorial web site :

i3editorial.com

(http://i3factory.com/editorial)

Un “Mock up” é un prototipo non funzionante di un prodotto in fase di sviluppo, serve a definirne il design e normalmente lo utilizziamo per far approvare  al cliente il prodotto prima di iniziare la fase di sviluppo.

MockApp è invece un software gratuito, per Mac Osx, scaricabile da questo sito dove è posibile ottenere una raccolta di file e immagini che vi permetterà di realizzare una presentazione in Powerpoint o Keynote ed esportare la presentazione direttamente in formato Pdf.

Di seguito alcuni video presenti su Youtube che ne mostrano l’utilizzo:

MockApp Trailer

MockApp Demo – Parte 1

MockApp Demo – Parte 2

Apple ha annunciato che il Mac App Store per Mac OS X Snow Leopard farà il suo debutto sia con le applicazioni gratuite che a pagamento il 6 gennaio 2011.

In un comunicato stampa, Apple ha riferito che il Mac App Store farà scoprire, installare e aggiornare applicazioni Mac nel nodo più facile che mai. La destinazione di download del software sarà disponibile in 90 paesi al momento del lancio, e sarà caratterizzato da applicazioni a  pagamento e gratuite divise in categorie quali l’istruzione, Giochi, Grafica & Design, Lifestyle, produttività e utilità.

“L’App Store ha rivoluzionato leapplicazioni mobili”, ha detto amministratore delegato di Apple Steve Jobs, “Speriamo di fare lo stesso per le applicazioni PC con il Mac App Store, facendo trovare e acquistare applicazioni per PC in un modo facile e divertente. Non possiamo aspettare e siamo pronti a iniziare il 6 gennaio”.

Il Mac App Store permetterà agli utenti di cercare nuove applicazioni e quelle  degne di nota, scoprire ciò che è “in caldo”, i preferiti, le categorie di ricerca e leggere i giudizi e recensioni. Come su iPhone, iPod touch e iPad, gli utenti possono acquistare, scaricare e installare applicazioni in un solo clic e iniziare a utilizzarle immediatamente.

L’ acquistato applicazioni può essere eseguito su tutti i Mac e gli aggiornamenti sono forniti direttamente tramite l’App Store per Mac, rendendo più semplice mantenere le applicazioni aggiornate. Il Mac App Store sarà disponibile per Mac OS X Snow Leopard agli utenti  attraverso Aggiornamento Software gratuito.

Gli sviluppatori Mac potranno  fissare il prezzo per le loro applicazioni, tenere il 70% dei proventi delle vendite, non pagano nulla per distribuire le applicazioni gratis e non devono pagare l’hosting, il marketing o commissioni di carta di credito. Per saperne di più sullo sviluppo basta visitare il Mac App Store.

Leggiamo il rapporto di ChangeWave Research e sfogliamo il sito InvestorPlace (http://www.investorplace.com/25527/explosion-in-corporate-tablet-demand) che ci relaziona sui risultati di un nuovo sondaggio condotto lo scorso mese in materia di utilizzo aziendale di dispositivi tablet, come iPad di Apple.

Con le offerte di nuovi tablet come l’ardesia HP 500 e il Dell Streak, la ricerca rileva che le imprese ancora preferiscono l’ iPad.

In termini di uso corrente, il 7% degli intervistati aziendali  dicono che la loro azienda fornisce agli impiegati dispositivi Tablet.

iPad di Apple (82%) resta di gran lunga il Tablet più popolare per fini commerciali. HP (Slate, 11%) e Dell (Streak, 7%) mostrano un interesse tra gli utenti aziendali – ma entrambi rimangono molto indietro la quota preponderante di Apple sul mercato.
L’uso del tablet in azienda dovrebbe aumentare a picco, si prevede un utiulizzo di tablet nel primo trimestre del 2011co una penetrazione del 14%, il doppio del numero attuale. Tali società prevedono di iniziare ad utilizzare tablet all’inizio del prossimo anno e hanno in programma di adottare per il 78% il dispositivo tablet iPad di Apple.

Prototipo interattivo creato con keynotopia

Vi segnalo un’interessante pacchetto che vi permetterà di creare Prototipi Interattivi per iPhone, iPad, Android e Web. Un vero e proprio prototipo puo’ essere creato in meno di 30 minuti, il tutto utilizzando  Apple Keynote unitamente ai templates Keynotopia per l’user interface.

I Pacchetti contengono  piu’ di  250 componenti per l’user interface (interfaccia utente), fatti a mano in  Apple Keynote. Con Keynote e Keynotopia potete facilmente creare dei files Pdf interattivi che poi istallati sul device vi permetteranno di fare presentazioni di funzionali direttamente dal device.

Clicca qui per visitare Keynotopia.

Nota:

Keynote e’ un un’applicazione Apple economica e facilmente utilizzabile cheap e che non richiede speciali esperienze o abilità per disegnare un’interfaccia utente e creare link interattivi.

Il Video tutorial:

Prototyping an interactive iPhone app in 10 minutes

DeTelegraaf for iPad

Finalmente l’iPad e’ sbarcato anche in Italia, e l’App Store si e’ subito popolato delle applicazioni delle maggiori testate giornalistiche italiane, oltre che di qualche rivista.
Provate a scaricarne qualcuna, scegliendo tra Repubblica, Il Corriere della Sera, La Gazzetta dello Sport, Il Foglio, L’Unione Sarda, Mac Magazine (ma ve ne sono altre, che non abbiamo scaricato e provato dato che ci son bastati gli snapshot per capire dove saremmo andati a parare): sono tutte esattamente uguali (con La Repubblica che si distingue leggermente dal gruppo).
Non c’e’ nulla di male a che le applicazioni siano uguali, se non fosse che esse sono ben lontane da quel che dovrebbe essere un’app per iPad.
Escludiamo per ora dal gruppo l’app di Repubblica, che merita una trattazione a parte (e una stelletta in piu’ nel rating Apple, cosi’ permettendo di elevarsi dal mediocre 2 stelle alla sufficienza). Le altre si mostrano al pubblico come dei visualizzatori di PDF o meglio di PNG. Optiamo per la seconda scelta, dato che sono app abbastanza veloci (unico vantaggio) ma che di fatto si comportano come dei visualizzatori di un’unica grande immagine sulla quale sono impressionate tutte le pagine del giornale. Quindi la meravigliosa esperienza sensoriale che avrete leggendo questi giornali online sara’ semplicemente lo scroll e lo zoom lungo questo enorme foglio elettronico.
Un po’ poco, soprattutto se si confrontano queste app con quella del New York Times Editor’s Choice, quest’ultima si’ che rende giustizia all’iPad.
Si distingue leggermente La Repubblica +, forse un po’ piu’ lenta nel caricamento, ma che almeno permette di aprire l’articolo nella sua interezza (ahime’ senza immagini, ahime’ senza i link nel caso di rimando alla prima pagina, ahime’ con la disposizione a due colonne e scroll verticale, quando invece la lettura sarebbe facilitata se impostata a libro, si vedano nuovamente NYT o l’app iBooks) e con qualche contenuto multimediale (una bella galleria fotografica, un video).
A nostro avviso queste app cosi’ fatte avranno vita difficile quando i contenuti diventeranno a pagamento, cosa necessaria affinche’ il business dell’editoria sull’iPad diventi profittevole per gli editori. Attualmente forse il business l’hanno fatto i produttori di questa app (trattasi di una start-up italo-californiana) ma di certo non hanno un reso un gran servizio ne’ all’iPad ne’ alle testate nostrane. Questi ultimi da biasimare certamente, poiche’ presi dalla fretta di uscire per primi e del tutto incapaci di capire le potenzialita’ dell’iPad.
Il nostro auspicio e’ che queste applicazioni vengano aggiornate (oserei dire: rivoluzionate) il piu’ presto possibile e ben vengano le fotocopie, ma che non si presentino ancora sullo schermo dell’iPad le fotocopie delle pagine del giornale.

Il Foglio su iPad

Secondo un report pubblicato da Gartner ( consultabile sul sito Gartner) , i cellulari venduti nel corso del 2009 sono stati 1.2 miliardi, con una leggera flessione rispetto a quello dell’intero 2008 (-0.9%).
I dati dell’ ultimo trimestre del 2009 (340 milioni di dispositivi venduti) invece segnano una crescita dell’ 8.3% rispetto allo stesso periodo dell’anno precedente.

I dati sui produttori di cellulari ci mostrano che a guidare il mercato rimane Nokia, con il 36.4% sul totale dei dispositivi venduti, seguita da Samsung al 19.5%

I dati sulle vendite di apparati non si distaccano dai numeri che prendono in considerazione i Sistemi Operativi , e infatti a guidare il mercato dei sistemi troviamo ancora Symbian (Divenuto Open Source) che e’ istallato sui telefoni Nokia. Al secondo posto abbiamo Blackberry (RIM) al 19.9% e al terzo iPhone OS con il 14,4%

E’ necessario notare che i dati sul sistema operativo prendono in considerazione il solo mercato dei telefoni cellulari, e non tiene conto del fatto che il sistema oprativo di Apple viene istallato anche sul’ipod touch.