posts - 644, comments - 2003, trackbacks - 137

My Links

News

Raffaele Rialdi website

Su questo sito si trovano i miei articoli, esempi, snippet, tools, etc.

Archives

Post Categories

Image Galleries

Blogs

Links

Windows 8: la user experience

Per dirlo in due parole il responso è … troppo presto perché un utente possa giudicare Windows 8.

La //build/ conference da cui sono appena tornato è una developer conference che ha assorbito PDC (Professional Developer Conference) e WinHEC (Windows Hardware Engineering Conference). Le sessioni in agenda vanno infatti dai temi riguardanti il Framework.NET e il nuovo WinRT a quelli inerenti lo sviluppo di driver in user e kernel mode.

La user experience di Windows 8 doveva essere mostrata insieme a tutte le principali novità e infatti abbiamo visto la nuova shell basata sullo stile Metro ma questa è pur sempre una developer preview e quindi è ancora troppo presto per tirare le somme sull'experience degli utenti finali.

Le novità per gli utilizzatori di Windows erano in parte già state annunciate sul blog da Sinofsky dall'annuncio della doppia shell a tutti gli altri dettagli sull'aumentata usabilità della shell.

Come è stato annunciato nella prima keynote il Marketplace è ancora in costruzione e questo significa che un utente, in questo momento, dello stile Metro non se ne fa nulla. Le applicazioni in stile Metro sono solo quelle preinstallate, alcune delle quali (vedi twitorama) ancora incomplete anche se molto attrattive.

La scelta di avere la doppia shell è più che apprezzabile e va nella direzione di offrire agli utenti una nuova generazione di applicazioni senza per questo dover rinunciare ad una collaudata e funzionale operatività con Windows.

Il vecchio desktop rimane per ovvi e ottimi motivi e in più aggiunge nuove funzionalità in modo da migliorare la sua usabilità. La nuova shell Metro ha una serie di indubbi vantaggi per gli utenti:

  • Le applicazioni sono reperibili sul marketplace. L'idea nata in casa Apple è indubbiamente un modo semplice e conveniente per reperire nuove applicazioni. Il markeplace provvede a sistemi di controllo che limitano al minimo i potenziali danni che un'applicazione può arrecare.
  • Le applicazioni sono contenute in un singolo package (apex) che contiene tutto ciò che l'applicazione necessita. Sono autoconsistenti e la loro installazione/disinstallazione è solo una questione di aggiungere/rimuovere il package e nulla di più.
  • Il package contiene, tra le altre cose, il manifest che informa Windows sulla categoria di API che l'applicazione intende utilizzare (accesso alla rete, webcam, storage locale, etc.)
  • Le applicazioni hanno la possibilità di utilizzare le API di base (le nuove WinRT) oppure dei servizi locali che vengono visti sotto forma di "Contracts". In questo modo ogni applicazione ha la possibilità di utilizzare le funzionalità di Search di sistema, condividere una risorsa su un social network etc. etc. Il tutto è naturalmente vincolato dalle permission che l'applicazione richiede e che l'utente è disposto a concedere.
  • La vita delle applicazioni è più simile ad un device come cellulare o tablet. Il sistema operativo ora può ridurre a "sospeso" un processo in modo che non consumi risorse.
  • Le applicazioni possono solo utilizzare funzionalità compatibili con la modalità Metro.
  • Le applicazioni Metro devono essere fluide. Per questo motivo Microsoft ha deciso che le applicazioni Metro non avrebbero mai dovuto poter chiamare funzioni di libreria che blocchino il thread corrente per più di 50ms.
    Questo sembra un punto poco rilevante invece è gigantesco, sia per l'impatto che ha sull'usabilità, sia per tutto quello che comporta a livello di librerie, linguaggi e tools che discuterò in altri post.

A mio avviso Microsoft ha fornito una risposta molto convincente dal punto di vista tecnologico, guidato dai due fattori più importanti: l'hardware disponibile sul mercato e le necessità degli utenti.

  • L'hardware ha guidato verso la ricerca spinta di performance ed infatti WinRT, le novità del CLR 4.5 e l'uso di C++ sono in ottica performance.
  • Gli utenti hanno chiesto usabilità, sicurezza e disponibilità di device e come conseguenza è nato il Metro-style, i packages, i Contracts, Windows per CPU ARM e la gestione asincrona.

Per concludere gli utenti hanno una piattaforma che potenzialmente è molto potente ma che in assenza del marketplace e di applicazioni non è giudicabile. Sarebbe totalmente errato giudicare Windows 8 utilizzando da un tablet che deve necessariamente utilizzare il vecchio desktop di Explorer. La piattaforma tecnologica verrà giudicata non solo dagli addetti ai lavori ma anche dalle applicazioni che saranno sul market. Se la grande maggioranza delle applicazioni dovessero offrire in futuro scarse funzionalità o problemi ricorrenti, significherebbe che Microsoft non ha fornito gli strumenti sufficienti a costruire buone applicazioni. Personalmente sono convinto del contrario perché tecnologicamente mi convince molto.

Nei prossimi post analizzerò nel dettaglio questi ed altri punti sotto il punto di vista dell'architettura del sistema operativo.

Print | posted on lunedì 19 settembre 2011 11:57 |

Feedback

Gravatar

# re: Windows 8: la user experience

Avremmo probabilmente visto la caccia alla ISO sui vari peer to peer, che è pure peggio.
Sono il primo ad essere scontento delle beta pubbliche ma in questo caso l'attesa derivata dal precedente silenzio era troppo alta.
19/09/2011 15:07 | Raffaele Rialdi
Gravatar

# re: Windows 8: la user experience

@Nick hai centrato :) Sto lavorando al resto del materiale e pian piano sfornerò i vari post :)

@Andrea. Capisco il tuo punto di vista ed è proprio per mettere in guardia sulle aspettative che ho scritto questo post. Si chiama "developer preview" e non "ctp" nè "beta" :)
19/09/2011 19:59 | Raffaele Rialdi
Gravatar

# re: Windows 8: la user experience

Roberto, ero lì ed ho parlato con diversi amici che lavorano nel team del CLR. La notizia perciò non è di seconda mano. Sono stati categorici nel ribadire che il ruolo del CLR è invariato.
Posso anche dire che non era neppure necessario precisarlo perché:
1. il CLR è un runtime indispensabile al funzionamento dei linguaggi managed. Quindi C#, VB, F# e gli altri compilatori di terze parti non possono girare senza CLR.
2. Tutte le tecnologie 'lato server' (ma non solo) come WCF, WF, EF, WIF, etc. etc. fanno uso di questi linguaggi e si avvalgono pesantemente sul CLR
22/09/2011 19:30 | Raffaele Rialdi
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET