sabato 28 gennaio 2012
#
Metro è un Design Language, (potremmo definirlo anche un “pattern di User Experience”) introdotto da Microsoft, prima con Encarta 95, poi Windows Media Center e Zune (fonte). La sua introduzione è abbastanza datata, ma è da poco più di un anno che con Windows Phone 7 gli sviluppatori e i designer hanno iniziato a lavorarci.
Spesso ridotto alla leggenda che lo vuole “ispirato dalle stazioni delle metropolitane”, in realtà Metro ha una storia molto più interessante.
Metro è basato sui principi stilistici dell’International Typographic Style, sviluppatosi negli anni ‘50 in Svizzera; lo stile è infatti anche chiamato Swiss Style. Lo stile svizzero si basa su tre punti cardinali: chiarezza, leggibilità e obiettività. (Fonte) E’ uno stile freddo, impersonale e per questo poco utilizzato in pubblicità ma che ha trovato largo impego nell’architettura moderna e per la sua leggibilità nei cartelli informativi.
In realtà Metro si ispira più direttamente agli stessi principi a cui si riconosce lo stile svizzero degli anni ‘50, attingendo direttamente alle idee nate nel cosiddetto Movimento Moderno, un movimento multidisciplinare che intorno agli anni venti e trenta del XX secolo ha cercato di migliorare l’architettura, l’urbanistica, la pittura e il design concentrandosi sulla funzionalità e introducendo nuovi concetti estetici.
Al Movimento Moderno, appartiene in particolare una rivista fondata in Olanda nel 1917 chiamata De Stijl. Lo stile.
Il contributo dato alla rivista De Stijl da Theo van Doesburg e Piet Mondrian ha il suo apice con la definzione di un termine che in segna un punto fermo nell’arte astratta: in neo-plasticismo. Il critico d’arte Giulio Carlo Argan, intellettuale e sindaco di Roma, nel 1976 scrive :
“Nella poetica neo-plastica è estetico il puro atto costruttivo: combinare una verticale ed una orizzontale oppure due colori elementari è già costruzione.”
In pratica è una grafica “pura” che combina linee e colori esclusivamente con un obiettivo estetico . Il De Stijl introduce uno stile interdiscipliare che si basa su alcuni principi che ritroviamo in Metro.
- Astrazione
- Essenzialità
- Geometria
Negli elementi che compongono l’interfaccia utente, dobbiamo tenere conto di questi principi; per esempio, se dobbiamo disegnare un pulsante esso dovrà essere un rettangolo oppure un cerchio, non una forma complessa che ricorda un pulsante fisico, come il classico rettangolo con angoli arrotondati che troviamo tra i controlli di Windows. La nostra interfaccia utente dovrà essere essenziale, ma non minimale: dovrà contenere tutto ciò che serve e soltanto ciò che serve, senza però mettere in difficoltà l’utente con elementi troppo piccoli.
Seguendo questi semplici principi e le linee guida ufficiali, riuscirete a realizzare applicazioni funzionali e belle da usare.
Buon Metro!
mercoledì 30 novembre 2011
#
L’occasione è quella dell’uscita della 4 prewiev di Internet Explorer 10 (link) ma è da un po’ che mi chiedo se HTML5 diventerà concretamente una tecnologia per lo sviluppo di applicazioni “client”. Diamo per scontato che HTML5 sarà il futuro del web ma oggi, tolti i grossi ‘player’, vedo ancora tanti, forse troppi, contenuti con tecnologie a plug-in ma soprattutto strumenti di sviluppo ancora allo stato primordiale.
La strada di Html5 verso la conquista del desktop è parallela, non conseguente, a quella del web, con scenari molto differenti.
Oggi sviluppare un’applicazione Metro in Html5 è vincente quando si verificano almeno una di queste condizioni:
- l’applicazione condivide parte del front end con un sito web;
- il team è fortemente skillato su HTML CSS e JavaScript.
Alcuni potrebbero suggerire una terza opzione se tra i requisiti ci fosse il supporto multipiattaforma, ma che io sappia le funzionalità Html5 per desktop di Apple sono limitate ai widget, senza un accesso diretto alle funzionalità del sistema operativo.
Per contro sviluppare applicazioni Metro in Html5 è perdente quando tra i requisiti ci sono:
- supporto a Windows 7 o precedenti;
- mancanza di conoscenze specifiche nel team di sviluppo.
Sviluppare in XAML oggi è vincente se il team ha
- conoscenze dei linguaggi del Framework .NET: C# o VB.Net;
- conoscenza di C++;
- esperienza di sviluppo di applicazioni Silverlight, WPF o Windows Phone.
La mancanza del supporto a Windows 7 o precedenti di WinRT ne preclude anche il supporto di applicazioni Metro basate su XAML; probabilmente però sarà più semplice fare il porting verso Silverlight di un’applicazione XAML che non di una scritta con HMTL5, specie se si sono adottati pattern di separazione del presentation layer come il noto MVVM. Tra l’altro possiamo dire che oggi Silverlight rimanga ancora una buona soluzione per sviluppare soluzioni verso Mac OS.
Lo scenario di un unico linguaggio cross-platform per realizzare applicazioni che possano girare ovunque è dunque ancora lontano e penso che Html5 potrà essere una base concreta per svilupparlo. Microsoft in futuro supporterà le tecnologie che verranno più utilizzate, ,ma non penso esisti una roadmap definita in tal senso: troppe sono le incognite, in particolare quelle che dipendono dalla concorrenza.
Per concludere questa breve riflessione, XAML è la tecnologia che ci offre maggiore retro compatibilità e migliori strumenti di sviluppo: Html5 oggi ha ancora troppe incognite per rappresentare una soluzione equivalente.
mercoledì 16 novembre 2011
#
Come molti sapranno il 22, 23 e 24 novembre al Centro Congressi Milanofiori di Assago si terrà l’annuale appuntamento organizzato da OverNet incentrato sulle tecnologie e prodotti Microsoft: la WPC.
Ho partecipato a diverse edizioni di questo convegno, sin dalla prima edizione 17 anni fa nel 2004, anche come MVP all’Ask The Expert, ma questa - la 18° edizione - mi vedrà per la prima volta sul palco per presentare una mia vecchia conoscenza: SketchFlow, ma questa volta in salsa Windows Phone.
SketchFlow è un fantastico strumento per la realizzazione di prototipi applicativi: l’unico, tra il panorama degli strumenti presenti sul mercato, a consentire la realizzazione di prototipi Dinamici: una vera e propria applicazione Silverlight che consente di giocare interattivamente con il prototipo, permettendo di annotare modifiche e suggerimenti direttamente sul prototipo.
Nella sessione vedremo appunto come poter usare questo strumento per realizzare prototipi di applicazioni Windows Phone, attraverso un template open source.
Di seguito i dettagli della sessione:
[D3003] Windows Phone: Prototipizzazione Dinamica di Applicazioni XAML
Track: Windows Phone
Speaker: Alessandro Scardova
Level: Avanzato
Agenda: 23/11, 09.00 - 10.15
Sala: Rossa
Vi aspetto!
mercoledì 31 agosto 2011
#
Da quando ho la beta di Mango, navigare da Windows Phone con un browser HTML5 è uno spettacolo, però quest’estate navigando sui siti dei ristoranti spesso mi sono trovato in difficoltà nel consultare le mappe interne al sito. Da utente mi sono chiesto: ho un’app Mappe fantastica, che mi permette di ottenere le indicazioni, impostare i percorsi perché i siti non mi permettono con un semplice click di accedere alla mappa?.
Ieri ho dedicato un po’ di tempo libero a questa problematica e ho dedotto che ogni OS mobile affronta la questione in modo diverso: vediamo come.
iPhone.
Apple taglia la testa al toro, facendo un regalone alla rivale Google. In pratica non occorrono particolare doti, basta fare un link a maps.google.com o ditu.google.com (Asia) e Safari aprirà il collegamento direttamente in Map. La documentazione è chiara: “The domain must be google.com and the subdomain must be maps or ditu.”
Android.
Google merita un plauso: è la sola, nella mia indagine, che considera l’unica RFC relativa a questa problematica, la RFC 5870 , implementando lo schema URI geo:. Nella lista di intenti vengono indicate le varie modalità di costruzione dell’URI.
Windows Phone 7
Per quanto riguarda Microsoft non ho ancora trovato una documentazione ufficiale (non è facile cercare su internet la keyword Map) ma studiando l’applicazione Facebook per Windows Phone 7 ho notato che viene utilizzato lo schema URI maps:. Questo schema probabilmente deriva da una vecchia implementazione Apple, mai documentata, soppiantata con l’avvento di iOS.
In attesa di trovare una documentazione, posso dirvi che ho sperimentato con successo l’uso di maps: nella ricerca indirizzo con questa sintassi:
<a href=”maps:my+address+city”>Map</a>
Conclusioni
L’idea non è quella di sostituire la mappa sul sito, ma di offrire all’utente anche la possibilità di sfruttare le potenzialità del proprio terminale, consentendogli di passare dal sito all’applicazione nativa.
Se volete un esempio ho sviluppato un piccola pagina di test che attraverso uno script basato sull’user-agent, imposta dinamicamente il link “Open Map” per i sistemi iPhone/iPad, Android e Windows Phone 7. Non sono un esperto di javascript: se avete suggerimenti sono bene accetti.
venerdì 19 agosto 2011
#
Avete presente le catene dei supermercati? Quasi tutte offrono prodotti con il “brand” del supermercato stesso. Questo tipo di vendita di fatto non comporta che il supermercato diventi “produttore” ma semplicemente commissiona l’opera ad un produttore terzo, solitamente individuabile in piccolo sull’etichetta che confeziona il prodotto con le specifiche imposte dalla catena.
I vantaggi sono un po’ per tutti.
Il produttore si concentra sul suo lavoro, non deve occuparsi di marketing, distribuzione, customer-care e robe simili.
Il consumatore se ha una buona percezione del brand del supermercato rifletterà la sua percezione sul prodotto, convincendosi (come è nella maggior parte dei casi) di portare a casa un ottimo rapporto qualità prezzo.
Il supermercato ottiene il famigerato lock-in. “Se ti piace il mio prodotto a marchio devi venire nel mio punto vendita anche per il resto della spesa”.
A volte la qualità non è sufficiente per essere associata al brand principale, quindi il prodotto viene offerto con un brand secondario, che ne evidenzia l’economicità.
Nel mondo IT, Apple è il classico esempio del prodotto a marchio. Sappiamo benissimo che i PC, gli smartphone e i tablet vengono prodotti in Cina (è pure scritto) ma abbiamo una fiducia nel Brand tale che siamo convinti che il prodotto debba superare diversi test per essere “approvato”.
E’ una tecnica da GDO. E così è anche Apple, con i suoi punti vendita, la vendita diretta e sostanzialmente fuori dal “vecchio” canale fatto di produttore, importatore, distributore e dettagliante che probabilmente ha fatto il suo tempo. Una tecnica che per Apple è più importante dei prodotti stessi: la linea server “enterprise” ha infatti lasciato il passo a mini-server per lo small office.
Così deve pensarla anche HP che oggi ha deciso di creare una spin-off dei prodotti destinati al pubblico consumer. Una spin-off che gli permetta di abbandonare il canale di vendita dei server e delle stampanti e di approcciarsi a modalità diverse.
E’ la stessa cosa che ha pensato anche Google quando ha deciso di comprare Motorola? Personalmente non credo ma molti analisti sostengono il contrario.
Una rete di vendita diretta non si inventa dall’oggi al domani, ma oggi il canale consumer è il nuovo eldorado dell’IT. Ormai le aziende hanno già un PC per ogni dipendente e a parte il naturale ricambio non possiamo parlare di un mercato in espansione, specie in un periodo in cui la crisi globale sta riducendo i posti di lavoro, inoltre il cloud ridurrà sempre più l’esigenza di risorse IT locali.
E’ quindi sul consumatore casalingo che produttori Hardware e Software stanno ponendo la concentrazione. Ma il consumatore vuole il prodotto a marchio: è quello sul quale viene percepito il migliore rapporto qualità / prezzo.
Chi ad oggi ha saputo valorizzare il proprio brand potrà spenderlo; chi ha commesso in passato passi falsi dovrà forse inventarsi un nuovo brand o tentare la fortuna, con la consapevolezza che un ulteriore errore potrebbe essere fatale.
Sono convinto che i prossimi 12-18 mesi ci riserveranno novità importanti, novità che probabilmente ci porteranno ad approcciarci all’IT in modo completamente diverso rispetto ad ora.
lunedì 8 agosto 2011
#
Uno dei motivi che hanno portato ai crollo dell’Impero Romano è che i costi necessari per mantenere l’apparato militare man mano che l’Impero allargava i propri confini erano superiori alle maggiori entrate dovute alle nuove conquiste. (fonte Wikipedia)
Secondo Trefis il pacchetto azionario di Google è legato per oltre 75% ai ricavi degli annunci pubblicitari (inclusi quelli su YouTube), mentre altri settori, a noi sviluppatori tanto cari, non rappresentato che le briciole.
E’ chiaro, che anche se non hanno un peso nel pacchetto azionario, servizi come Gmail, Google Plus o prodotti come Android, sono strategici da un lato per raccogliere informazioni sull’utente per posizionare meglio gli annunci pubblicitari, dall’altro per mantenere gli utenti legati sempre di più al proprio Brand.
Per fare un esempio, mentre per Apple iPhone è un business “diretto”, per Google Android è un business “indiretto”.
Il meccanismo messo in piedi da Google funziona finché i costi recatavi alle aree di intervento “indiretti” vengono coperti dai ricavi provenienti dal core business dell’azienda. Gli investimenti di oggi di Google in questa direzione sono massici: anche con la chiusura di Labs (fonte: googleblog) le attività volte a rosicchiare terreno dalla concorrenza sono sempre più onerose e numerose.
Riuscirà Google a mantenere vivo il proprio Impero nonostante i numerosi teatri di scontro in cui è impegnata? Vedremo.
lunedì 18 luglio 2011
#
Oggi ho trovato 3 commenti di spam sul blog, non che la cosa mi infastidisca ma avendo la replica di questo blog sulla mia pagina di Facebook ho pensato che fosse meglio raggruppare i commenti in un unico posto, non tanto per me, ma per consentire a tutti di leggere tutti i commenti in entrambi i siti.
Per commentare questo post segui il link.
UPDATE:
Tommaso mi ha fatto correttamente notare che nella sua azienda Facebook è bloccato: centralizzare là i commenti non permetterebbe a chi è in quelle condizioni di replicare ai miei post. Faccio ammenda e riapro i commenti anche sul blog. In attesa di provare Disqus..
martedì 12 luglio 2011
#
In questi giorni di vacanza ho avuto la fortuna, grazie ad un invito dell’amico Lorenzo Squarza, di provare il social network di Google, lanciato dai media un po’ come lo sfidante di Facebook. Mi rendo conto che il prodotto è in fase embrionale, mancano le connessioni con il resto del mondo, Twitter, Facebook, ma non sarebbe un problema: quello che manca si può sempre aggiungere.
La cosa che non fa per me è l’impostazione che caratterizza proprio il social di Google: il meccanismo dei circles, o nella traduzione che hanno dato, delle cerchie.
Le cerchie sono un gruppo di persone. Un post viene pubblicato in modo che possa essere visto da tutti o solo dalle persone all’interno di una cerchia. Il meccanismo è lo stesso di wave, sostanzialmente si scrivono cose in un gruppo chiuso di utenti.
Come ho già scritto su Google Plus, questa cosa di dover catalogare le persone mi impaccia al limite del fastidio. Mi spiego: se uno scrive cose interessanti lo seguo su Twitter, se uno è interessante come persona, magari lo connetto in Facebook, o in LinkedIn se l’interesse è più lavorativo che personale. Le cose le scrivo un po’ nel blog, su su Twitter , su Facebook, o nel mio profilo o nella mia pagina Alex Bream e più o meno viene “splittato” un po’ ovunque, poi uno è libero connettersi e di leggere o meno quello che vuole.
La scelta da parte mia in questo caso è “cosa interessa a me”, molto diversa da dover decidere “cosa interessa a loro”.
Alcuni, me compreso, usano Google Plus come se fosse Facebook o Twitter, ma che senso ha? Ci sono molti meno utenti e probabilmente sono sottoinsieme di quelli che abbiamo connesso altrove. Altri invece trovano questo meccanismo delle “cerchie” interessante e lo stanno usando correttamente.
Se un domani Google dovesse aprire ai feed o a Twitter la possibilità di inserire contenuti sicuramente potrebbe diventare un contenitore interessante anche se “usato male”, per ora sospendo la mia esperienza su quel social e dedicherò il tempo ad altro.
Nel frattempo continuate ad aggiungermi nelle vostre cerchie, nulla è deciso per sempre!
sabato 4 giugno 2011
#
L’annuncio del supporto a HTML5 di Windows 8 ha suscitato commenti nella comunità di sviluppatori che vanno dall’entusiastico al disperato. Ancora una volta qualcuno ha profetizzato la morte di Silverlight. Di nuovo. Faccio questo mestiere da più 20 anni, sono passato da Clipper a WPF e in tanti anni ho imparato a leggere soprattutto i fatti, più che le parole non dette.
Vediamo i fatti.
- HTML 5 non è uno standard completo, e probabilmente non lo sarà entro la fine dell’anno in corso;
- Silverlight oggi gira su sistemi X86 e ARM, con la versione per Windows Phone 7;
- Il mercato dei PC oggi non è solo fatto di desktop ma anche (in una percentuale piccola ma in crescita) di tablet, un mercato che sta offrendo dispositivi basati su processori x86 ma anche su processori ARM; Leader di questo nuovo mercato (anche se loro dicono che non sono PC) è Apple con iPad seguito da dispositivi basati su Android;
- Probabilmente Microsoft ha oggi il sistema operativo migliore per la piattaforma x86 e x64 ma non ha una soluzione per i dispositivi ARM, se ovviamente escludiamo Windows Phone 7;
Ora ecco le mie supposizioni personali:
Sul mercato desktop Windows ha un dominio consolidato, i competitor di Microsoft stanno perciò spingendo su due fronti: il cloud e il mobile. Sul cloud abbiamo visto come Microsoft ha saputo rispondere egregiamente con Azure, sul mobile la risposta è stata data, con un certo ritardo, con Windows Phone 7. Con Windows Phone 7 Microsoft ha dato un taglio con Windows Mobile investendo su Silverlight e su un nuovo modello di UI, che abbiamo visto paro paro sull’anteprima della UI di Windows 8.
Probabilmente, se io pensassi davvero di fare morire Silverlight, non l’avrei adottato come piattaforma di sviluppo per le applicazioni mobili, scatenando la prevedibile ira degli sviluppatori Windows Mobile 6.5 e regalando una buona fetta di quel mercato alla concorrenza. Probabilmente avrei fatto prima a sviluppare un Windows Mobile 7, magari con un browser decente, lasciando la tecnlogia “winform”. Ma così non è stato: Silverlight è oggi la piattaforma Microsoft di riferimento per lo sviluppo su Mobile (escludendo XNA per i giochi).
Sul mobile la sfida ha un campo di battaglia preciso: il tablet. Una sfida che corre sul filo del cross-platform, terreno minato sul quale è difficile capire l’approccio giusto. Le soluzioni oggi sul mercato sono di due tipi: una basata su runtime, la seconda di tipo “multi-compile”. Soluzioni interessanti ma entrambe con dei limiti importanti.
Le soluzioni basate su runtime, come JAVA, Silverlight, AIR/Flash funzionano un runtime per ogni “platform” che si vuole “crossare”. Questa soluzione si è dimostrata fallimentare con la comparsa piattaforme, come quella iPhone OS /iOS, dove per scelta del produttore i runtime sono stati banditi. La stessa Apple, forse per giustificare il mancato supporto a Flash, ha insistito sulla necessità di migrare il web verso HTML5 il più velocemente possibile.
L’altra soluzione, quella che ho chiamato multi-compile, si basa su tools che, una volta sviluppata la soluzione, sono in grado di generare codice eseguibile su più piattaforme. Io personalmente non credo molto a questi “generatori multi purpose”, sia perché difficilmente riescono a cogliere le specificità delle varie piattaforme, sia perché non tutti i tools oggi supportano tutte le piattaforme e soprattutto non è detto che lo facciano in futuro.
Microsoft ha evidenziato il supporto a HTML5 non perché vuole abbandonare Silverlight, ma perché si rende correttamente conto che il cross-platform non può essere risolto da un tool, ma deve essere supportato da uno standard. Uno standard che dovrà essere rispettato sia dagli sviluppatori che dai produttori di PC. Che non si limiti al web ma che possa anche essere usato per applicazioni, giochi e quant’altro.
Definirsi “sviluppatori Silverlight delusi” è da imbecilli. Delusi da cosa? Gli sviluppatori Microsoft potranno continuare a sviluppare con Silverlight per le piattaforme in cui Silverlight è supportato (e continuerà ad esserlo): Windows e Mac OS. Volevate forse essere gli unici a sviluppare per Windows?
Con il supporto a HTML 5 Microsoft non chiude la porta agli sviluppatori Silverlight/WPF ma semplicemente ne apre un’altra ai tanti sviluppatori, soprattutto giovani, che oggi fanno applicazioni per altre piattaforme.
giovedì 2 giugno 2011
#
Oggi tutti guardano a HTML 5, inteso come HTML 5 + CSS3 + JS, come la piattaforma futura per sviluppare non solo siti, ma vere e proprie applicazioni, che possano essere eseguite indipendentemente dal dispositivo sul quale sono installate.
Da quello che si è potuto capire, dalla recente intervista di Steven Sinofsky al D9 e dalle dichiarazioni ufficiali di Microsoft il nuovo Windows 8 sarà in grado di eseguire queste applicazioni non solo nel browser, ma come oggetti autonomi, esattamente come succede ora con le applicazioni Silverlight out of browser.
HTML 5 quindi si affiancherà alle altre tecnologie di presentazione oggi consolidate come Silverlight/WPF, con il vantaggio della portabilità su altre piattaforme, come Android o iOS.
Se oltre ad affiancarlo HTML 5 saprà sopraffare Silverlight/WPF solo il tempo saprà dirlo. La portabilità verso molte piattaforme sarà sicuramente strategica per molte aziende che oggi producono software, ma per altri mercati probabilmente la produttività di WPF sarà imbattibile su applicazioni progettate per Windows che, ricordiamo, ha ancora oltre il 90% del mercato dei desktop.
HTML 5 diventa in ogni caso una preziosa risorsa per il nostro business, che non possiamo ignorare. La mia sessione di giovedì prossimo allo SMAU Business di Bologna cercherà appunto di fare chiarezza sulle novità che HTML 5 ci propone, quanto lo standard è maturo ma soprattutto come usarlo, e anche, perché no, non usarlo.
Vi aspetto!