live blogging

WhyMCA 2010 live blogging (appunti): design per iPad

0.00 avg. rating (0% score) - 0 votes

Design per iPad, Luca Mascaro La prima volta che hai in mano un iPad non capisci bene cosa ti ricorda come esperienza d’uso. Le regole di progettazione e di interfaccia dell’iPhone non funzionano sempre sull’iPad. Nel ciclo di vita giornaliero di un utente non c’e’ nulla che assomigli all’iPad. Approccio di scoperta. iPad viene utilizzato da un’utenza trasversale: sia vecchi che nuovi utenti. Non sono solo nativi digitali. Un computer e’ troppo complesso per leggere la posta e guardare due siti. L’iPad si utilizza in contesti relativamente nuovi: nessuno lo usa alla scrivania. Divano, bagno, in piedi, riunioni, etc. Chi fa ricerca con utenti ora dovra’ esplorare tutto… Per fare design delle interfacce bisogna pensare prima agli scenari che alla progettazione, ancora piu’ dell’iPhone. Sviluppare le interazioni sugli scenari: studi lo scenario e il contenuto e l’interfaccia viene da se’. Prototipare, prototipare, prototipare. Esempio reale: a livello di ipotesi/sketch/disegno un contenuto doveva essere navigato in verticale, quando si aggiungono le immagini vere nel mockup tutti gli utenti pensavano di doverle scorrere in orizzontale. iPad e iPhone sono due cose diverse, anche se le human interface guidelines di Apple dicono che si possono migrare facilmente, la percezione degli utenti non e’ la stessa (e non lo e’ nemmeno tecnicamente). Forse non si riusciranno a fare applicazioni perfettamente identiche sui due dispositivi. L’interfaccia delle schermate di iPad e’ un misto tra pattern classico della telefonia e un computer (iPhone e’ piu’ semplice da navigare e naturalmente sequenziale). Risoluzione dell’iPad: schermo iPad, iPhone e monitor sono cose diverse. Nell’emulatore le misure sono sbagliate e quindi per progettare su iPad bisogna avere un iPad. La rotazione dell’iPad viene usata poco dagli utenti a meno di motivi rilevanti come ad esempio la migliore navigazione. In verticale fruisci il contenuto, in orizzontale fai apparire altre informazioni/funzionalita’ a lato. SciencePlus: app editoriale per iPad che sfrutta l’interazione tra contenuti (su layer). Il contenuto definisce cosi’ l’interfaccia, rendendo invisibile l’interfaccia stessa (es. se il contenuto scorre da solo verso l’alto l’utente e’ portato a sfogliare in verticale). Su iPad hai dubbi su qual e’ la direzione di interazione, per sfogliare: slide o scroll? Tipografia densa e rendering dubbio: a certe dimensioni il carattere e’ illeggibile per via del sistema di antialias. Illustrator e Photoshop vengono usati per progettare/simulare, ma portando i contenuti su iPad non sempre la cosa funziona e rimane leggibile. Lo stesso problema si ha con l’emulatore di XCode. Sfondi, luminosita’ e colori: su iPad l’uso di colori pieni non funziona benissimo, ma funzionano meglio i colori con “rumore” perche’ rendono l’interazione piu’ naturale e aiutano la sensazione di scorrimento. La metafora e’ quella di spostare veramente un oggetto. Su iPad non si pensa piu’ in 2D, ma in tridimensionale: e’ un dispositivo esperienzialmente profondo verso la realta’. Un esempio di profondita’ e’ l’interfaccia dell’applicazione iBooks.

WhyMCA 2010 live blogging (appunti): HTML5 come strumento per lo sviluppo mobile

0.00 avg. rating (0% score) - 0 votes

HTML5 come strumento per lo sviluppo mobile, Sandro Paganotti e Marco Moscaritolo

I big dicono che l’HTML5 e’ uno strumento valido e puntano su quello. La timeline e’ un po’ lunga: 2022 per completare la definizione ufficiale degli standard (con una serie di step intermedi).

Il supporto per l’HTML5 e’ in gran parte gia’ presente su tutti i principali browser (Opera, Safari, Firefox, Chrome) ad eccezione di Explorer che ha un basso supporto al momento. Sul mobile il supporto all’HTML5 e’ anche maggiore.

Nuovi tag semantici in HTML5, nuove funzionalita’ per gli elementi di input (es. definendo l’attributo Type=”number” si abilita, su mobile, solo una tastiera virtuale con numeri), possibilita’ di definire alcuni tag/attributi secondo le proprie esigenze (meno formale dell’XHTML).

Web Cache: l’utente puo’ disporre dell’applicazione anche nel caso in cui non fosse connesso alla rete. Nel tag HTML si definisce l’attributo “manifest”. Il file con estensione .manifest definisce l’elenco degli asset (css, immagini, js, video, etc) che devono essere disponibili anche per la funzione offline e li scarica sul device dell’utente, in cache. Nuove API ApplicationCache che permettono di gestire e interagire nei casi on/offline con la cache manifest.

Web Storage: sempre per l’utilizzo offline, simile al concetto HTTP di cookie e sessione esistono sessionStorage e localStorage.

Web DataBase: esistono API che permettono di lavorare con logica e sintassi SQL, anche quando l’utente e’ offline. Ora tutti i mobile device utilizzano sqlite (anche se il W3C parla di SQL, quindi a tendere situazioni troppo specifiche per SQL potrebbero non funzionare piu’). La sincronizzazione tra DB offline e DB online deve essere manuale e a carico dello sviluppatore, non esistono API che la fanno.

Canvas: spazio da usare come elemento per rappresentare graficamente le informazioni (modificabile e gestibile con javascript). Vantaggi rispetto ad ora: carico sulla macchina molto basso in caso di operazione grafica.

Video: marcatore che permette di inserire un video nell’applicazione web senza plugin esterni (niente Flash, SilverLight, etc). Il supporto e’ nativo nel browser e quindi l’uso delle risorse e’ piu’ basso e meglio gestito. Si puo’ interagire con javascript, disegnare il player con CSS, etc. Due grossi contro: non esiste la modalita’ full-screen, problemi nella scelta del codec (h264 per Apple, Theora per Firefox, VP8 etc) e quindi costi di licenza.

API potenti per il mobile e le necessita’ mobile. Non ci sono framework (Sproutcore sta muovendo i primi passi rispetto HTML5) e tutto e’ in carico al developer.

Vantaggi HTML5 su applicativi mobile ad oggi:
– non serve alcuna approvazione per la nostra applicazione (vedi Apple Store)
– e’ cross-device, anche se bisogna personalizzare i presentation layer per i device e rispettare le singole guide lines
– e’ una tecnologia standard

Svantaggi HTML5 su applicativi mobile ad oggi:
– accesso limitato ad informazioni gia’ presenti sul device ed eventuali sensori particolari (es. giroscopio dell’iPhone)
– il layer di presentazione e’ difficile da rendere uguale alle applicazioni native
– alcune API cambieranno nel tempo quando ci sara’ il rilascio definitivo

Fattori limitanti di un ecosistema di applicazioni HTML5: non c’e’ uno store, quindi la scoperta delle app dev’essere manuale e sulla spinta del singolo, inoltre allo stesso modo non c’e’ un sistema di pagamento fluido e comodo come quelli degli store piu’ famosi e centralizzati. Difficolta’ nel rendere profittabili le nostre applicazioni. Anche se esiste un appstore di terze parti con una sezione web per HTML5, si chiama AppStoreHQ, e probabilmente cresceranno.

CSS3 nuove funzionalita’ per web designer: gradienti, ombreggiature, font diversi da quelli presenti sul client, sfondi, trasparenze, animazioni senza javascript, etc.

Nota: per la presentazione hanno usato prezi.com , bella modalita’ di transizione tra le singole slide.

WhyMCA 2010 live blogging (appunti): mobile security and privacy

0.00 avg. rating (0% score) - 0 votes

Mobile security and privacy, Fabio Pietrosanti

La sicurezza mobile non e’ identica alla sicurezza IT. Oggi assistiamo ad una crescita esponenziale di SmartPhone, potendo metterci su applicazioni e informazioni (tali info passano dal PC al telefono).

Quando esci di casa: macchina, chiavi di casa, portafoglio e… cellulare!

I dati che sono oggi sui cellulari sono estremamente personali e ricchi rispetto ad anni fa.

Eccesso di fiducia tra operatori, tra utenti e operatori, tra utente e telefono (non ha mai sperimentato in modo pratico un virus, un trojan, un phishing, etc in modalita’ mobile). Poca consapevolezza sui rischi del mobile.

Nuovi rischi sociali: gli utenti installano qualunque cosa e applicazioni. L’app che simula una scoreggia per Android ha realizzato 50.000 utenti. E se contenesse un trojan?

Le capacita’ necessarie per poter rilevare un attacco, un trojan o spyware su cellulare sono elevate, quindi e’ difficile scoprirlo.

La gestione delle vulnerabilita’ e del patching/aggiornamenti sono arretrate: ben fatte quelli di iPhone e Android, peggio quella di Nokia (anche per via degli operatori che personalizzano il firmware del telefono).

Ultimi anni: vulnerabilita’ nell’ambito mobile sono cresciute in maniera importante e ce ne sono molte di piu’ per iPhone (le eredita’ da OSX).

Se voglio una password sicura questa ridurra’ in modo drastico l’usabilita’ per via della tastiera virtuale (difficile mantenere alta la sicurezza e alta anche l’usabilita’).

L’utente finale fatica a comprendere i messaggi di alert sulla sicurezza anche per via del poco spazio a monitor per spiegare il problema (es “Certificato SSL non valido” su iPhone e’ riduttivo).

Se su PC siamo padri e padroni delle informazioni e del sistema operativo, su mobile questo non e’ vero: solo i produttori e gli operatori lo sono.

In Francia hanno vietato il BackBerry negli ambienti governativi perche’ RIM USA filtrava e controllava le mail in passaggio. Cosa che su PC sarebbe impossibile.

Modelli di sicurezza: Windows Mobile e BlackBerry sono i migliori dal punto di vista della sicurezza enterprise, anche se un po’ limitati a “tutto” o “niente” (dopo l’ok dell’utente l’applicazione puo’ fare quello che vuole). iPhone ha delle policy per chi pubblica applicazioni e delle API limitate per gli sviluppatori rispetto al resto del mercato.

Esiste una vulnerabilita’ di Safari su iPhone che con la semplice visita di un sito permette di accedere alla lettura completa di tutti gli SMS.

App di FaceBook per Android non usa SLL, ma semplice HTTP (e l’utente non viene avvisato), quindi e’ possibile rubare le password di FaceBook.

Fino al 2008 nelle conferenze di hacking e di sicurezza non si parlava di mobile, ora invece se ne parla moltissimo e l’interesse e’ in crescita. Aumento della consapevolezza: scoperta, preccupazione, l’industria reagisce e corregge.

GSM: esistono suite per il cracking delle conversazioni (2009). UMTS: si puo’ far passare su GSM. WiFi: problematiche classiche del senza fili. MMS: si possono far installare exe senza controlli (es. bug HTC di qualche anno fa). SMS: spoofing semplice e possibilita’ di mandare profili di collegamento ad internet con DNS personalizzati, quindi spiabili (es. bug iPhone che puo’ scaricare un trojan a seguito della ricezione di un messaggio). Bluetooh: crackato ufficialmente e facile da sniffare. NFC: scarica applicazioni direttamente senza chiedere e solo dopo chiede se installarle. WEB: proxy degli operatori che aggiungono header alle richieste http (es. Vodafone), quindi il sito web puo’ vedere addirittura il telefono dell’utente! SSL sul mobile non si vedono comodamente i dettagli di un certificato (almeno 4-5 clic) e le informazioni non sono sempre complete (es. iPhone non lo permette se non in seguito all’invio dei dati). Tramite la rete e’ sempre possibile conoscere con approssimazione dove si trova geograficamente l’utente.

Gli spyware su mobile costano, ma ce ne sono di completi, vedi FlexySpy. Virus e worm non ce ne sono.

Su mobile ogni forma di trasmissione costa qualcosa: tutte le frodi telefoniche in ambito mobile consistono nel fare in modo che l’utente faccia qualcosa di costoso che viene incassato totalmente o in parte dal malintenzionato.

Conclusioni: troppa eterogeneita’ tecnologica, modelli di sicureza non uniformati, operatori e produttori che non apprezzano la liberta dell’utente sul device e sulla rete.

WhyMCA 2010 live blogging (appunti): Nuovi scenari di sviluppo nel mondo degli eBook

0.00 avg. rating (0% score) - 0 votes

Nuovi scenari di sviluppo: il mondo degli eBook, Giacomo D’Angelo

ePub, standard indipendente, open. Produrre contenuti per la carta e poi convertirli per gli eBook e’ costoso e sconveniente.

Stealth, utile agli editori (l’unica funzionante in Italia), permette di caricare contenuti e distribuirli automaticamente attraverso API ai sistemi di vendita online e store (web, mobile, ondevice, etc).

Le persone leggeranno, a tendere, i contenuti su un numero di device diversi e sempre in crescita come numero.

Samsung E60, accede in modo libero ad internet (e 3G), non sfruttando piu’ gli store “chiusi”. Per questo motivo l’approccio allo sviluppo su queste piattaforme cambierà a breve.

I produttori di hardware si stanno orientando verso i monitor 6 pollici, con 8 livelli di grigio (scarsa esperienza per gli elementi a colori).

Le applicazioni sviluppate per eBook Reader devono essere legate al miglioramento dell’esperienza di lettura, perche’ si tratta di device che servono quasi solo per leggere.

iPad e’ fantasmagorico, ma e’ un altro strumento rispetto ad un eBook Reader, questi ultimi permettono di ottenere un’esperienza di lettura simile a quella di un libro cartaceo.

Lo schermo eInk ha un refresh/rendering piuttosto lento, quindi le interazioni uomo-macchina, in caso di sviluppo di applicazioni, devono essere limitate.

Nello sviluppo di app per eBook Reader ecco i vincoli legati al web: nessuna immagine dinamica (es. gif, video) o contenuto dinamico (es. ajax), layout fisso senza presenza ne’ utilizzo di scrollbar, pagine sotto 1 Mb, nessun radio button o checkbox.

Peso medio di un file ePub: solo testo 600K-1,5Mb (es. 400 pagine di romanzo), libri illustrati circa 5Mb (es. Touring Club, con diverse immagini per ogni pagina, ottimizzando molto le immagini). Circa il 90% del peso di un ePub risiede nelle immagini.

Lo store di Simplicissumus Book Farm e’ un sito web, ma compliant alle specifiche dei device.

Sviluppo di app stand-alone: lui ha fatto fatica a trovare persone con cui confrontarsi, ambiente pioneristico. L’app dev’essere uniforme all’esperienza d’uso del device: stesso look&feel, stessa interazione, stessa esperienza della libreria.

Amazon Kindle e Onyx Boox60 e Bebook Neo sono alcuni device che permettono di sviluppare applicazioni. Disponibili gli SDK.

Esempio: ambiente di sviluppo per Onyx e’ tipico C++, permette di usare le API e l’SDK relativo al dispositivo.

I libri costano meno del 50% del cartaceo. Tra qualche mese ipotizza che costeranno meno della meta’ della meta’ del cartaceo per via della crescita del volume delle vendite.

e-Commerce Forum 2010 live blogging (appunti): le decisioni del Garante in materia di privacy, prevenire è meglio che curare

0.00 avg. rating (0% score) - 0 votes

 

eCommerce Forum 2010 Milano: Studio legale CMB & Partner

trattamento dei dati in tutti quei casi diversi dal telefono: posta, fax, mms, sms, etc dove cioè non è necessario un operatore. fonti: 2002/58/ce e dlgs 196/2003. dove non c’è l’operatore è consentito trattamento solo con il consenso preventivo dell’interessato.

provvedimenti a livello nazionale: garante per la protezione dei dati personali del 29 maggio 2003. a livello comunitario parere 5/2004 (proposte e comunicazioni indesiderate ai fini di commercializzazione diretta).

inviare mail pubblicitarie senza il preventivo consenso dell’interessato è vietato, sanzioni 10k – 120k euro (erogata dal garante) ed è anche un illecito penale art. 167 codice privacy (erogata dal giudice penale). c’è un’altra sanzione erogata dal garante: il blocco dei dati, cioè l’impossibilità di utilizzarla per determinati fini a seguito di una decisione del garante (art. 11 comma 2 codice privacy, art. 154 lettera d codice privacy).

per gli interessati è più efficace rivolgersi al garante che al giudice per via delle sanzioni applicate e per il fatto di poter trattare tra le parti e chiudere in via amichevole (e pecuniaria) la controversia.

nel 2009 circa 340 segnalazioni di cui il 67% chiuso con sanzione per il merchant.

qualsiasi manifestazione di volontà preventiva con la quale la persona interessata accetta che i suoi dati vengano trattati a fini commerciali. quindi la volontà si esprime prima della ricezione del messaggio: anche l’invio di un solo messaggio non rispetta il requisito del consenso preventivo e non è in linea con il codice della privacy.

anche l’invio di fax aziendali a numeri presi dall’elenco telefonico non è permesso perché manca comunque il preventivo consenso (c’è già stata una sentenza in merito).

l’unica eccezione è mandare una mail pubblicitaria ad un cliente, preventivamente informato, con queste caratteristiche: il medesimo titolare tratta i dati, no società controllate nè controllanti; l’interessato deve essere già cliente del titolare (c’è già stato un rapporto contrattuale); deve trattarsi di prodotti o servizi del titolare del trattamento dei dati; le comunicazioni devono riguardare solo servizi o prodotti analoghi all’oggetto della vendita precedente (analogia: ragionevoli aspettative del ricevente  piuttosto che di quelle del mittente. es. se il merchant vende sia tende da campeggio che frigoriferi e il cliente ha comprato un frigorifero non gli si può proporre una tenda anche se dello stesso venditore); l’interessato deve sapere che si può opporre in qualsiasi momento al trattamento dei suoi dati e che può farli cancellare.

l’informativa carente o imprecisa incide sulla validità del consenso. l’informativa deve avare tutti i contenuti descritti dall’art. 13 del codice privacy. nel caso di trattamento per finalità di marketing bisogna dire anche che è un trattamento ulteriore non strettamente connesso al servizio o alla prestazione richiesti, inoltre deve sapere che il consenso è facoltativo, dev’essere spiegata la modalità del trattamento, indicato che i dati vengono ceduti a terzi, il fatto che l’interessato può opporsi per qualsiasi motivo e gli estremi identificativi del titolare del trattamento. non si può negare un servizio o una prestazione a chi non vuole fornire i propri dati per finalità di marketing.

bisogna fornire consensi differenziati per tutte le distinte finalità dell’informativa (es. pubblicità + profilazione clientela + cedere dati dei clienti a terzi), pena invalidità, illecito e sanzione amministrativa.

il trattamento dei dati non autorizza a mandare informazioni commerciali se non espressamente indicato e scelto dall’utente, proprio perché il consenso deve essere espresso in positivo.

non è possibile pre-flaggare il campo di accettazione.

acquisto banche dati per marketing online: occhio alle finalità del trattamento ed alla cessione dei dati a terzi. la responsabilità ricade sia su chi acquisisce che su chi vende i dati, quindi chi li acquista deve verificare la presenza delle informative e l’acquisizione del consenso (sui grossi numeri si può fare a campione e verbalizzare per testimoniare il processo attivo e diligente dell’acquirente dei dati). l’acquirente deve seguire accorgimenti per non cadere in incauto acquisto: assumere informazioni sulla banca dati, assumere informazioni sulle finalità per le quali la banca dati può essere utilizzata, qual è stata la formula del consenso, inviare la nuova informativa agli interessati per accedere ai propri dati e per opporsi eventualmente al trattamento, ottenere dal cedente una dichiarazione di garanzia sulla sussistenza dei requisiti previsti dalla legge ai fini delle comunicazioni commerciali da parte di terzi in relazione a tutti i nominativi presenti nel database.

1 2 3 8  Torna su