I’d like to speak about liveness, it has been introduced in Xcode 6 and along with storyboard and interface preview is a great way to help you undestand how your application will look like without even launching on the simulator.
Watching the documentation I thought it was possible only by creating a subclass of UIView (or UIControl) programatically, while instead is possible to build our own UIView implementation and attach a xib file to it.
This is really helpful, for instance if you need to create a complex layout in a view building it with interface builder is a lot easier instead of coding each constraints.
How to do that?
1. Create a custom UIView subclass and a xib files, that we will name after our own class name: in our case MemeView. Inside the Meme View class remember to define it as designable, by adding the @IBDesignable attribute before the class declaration
2. Rember to set the File’s Owner in the xib with our custom UIView subclass in Indetity Inspector panel

Memeview custom class
3. In the xib file now we can build our interface, make constraints, create outlets, actions etc.

Meme view connection
4. We need to implement few methods to our custom class to open the xib once initialized

    weak var nibView: UIView!

    override convenience init(frame: CGRect) {
        let nibName = NSStringFromClass(self.dynamicType).componentsSeparatedByString(".").last!
        self.init(nibName: nibName)
    }

    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        let nibName = NSStringFromClass(self.dynamicType).componentsSeparatedByString(".").last!
        let nib = loadNib(nibName)
        nib.frame = bounds
        nib.translatesAutoresizingMaskIntoConstraints = false
        addSubview(nib)
        nibView = nib
        setUpConstraints()
    }

    init(nibName: String) {
        super.init(frame: CGRectZero)
        let nibName = NSStringFromClass(self.dynamicType).componentsSeparatedByString(".").last!
        let nib = loadNib(nibName)
        nib.frame = bounds
        nib.translatesAutoresizingMaskIntoConstraints = false
        addSubview(nib)
        nibView = nib
        setUpConstraints()
    }

    func setUpConstraints() {
        ["V","H"].forEach { (quote) -> () in
            let format = String(format:"\(quote):|[nibView]|")
            addConstraints(NSLayoutConstraint.constraintsWithVisualFormat(format, options: [], metrics: nil, views: ["nibView" : nibView]))
        }
    }

    func loadNib(name: String) -> UIView {
        let bundle = NSBundle(forClass: self.dynamicType)
        let nib = UINib(nibName: name, bundle: bundle)
        let view = nib.instantiateWithOwner(self, options: nil)[0] as! UIView

        return view
    }

5. In our custom class we can also define some inspectable properties to have full control over them from interface builder

 @IBInspectable var memeImage: UIImage = UIImage() {
        didSet {
            imageView.image = memeImage
        }
    }
    @IBInspectable var textColor: UIColor = UIColor.whiteColor() {
        didSet {
            label.textColor = textColor
        }
    }
    @IBInspectable var text: String = "" {
        didSet {
            label.text = text
        }
    }
    @IBInspectable var roundedCorners: Bool = false {
        didSet {
            if roundedCorners {
                layer.cornerRadius = 20.0
                clipsToBounds = true
            }
            else {
                layer.cornerRadius = 0.0
                clipsToBounds = false
            }
        }
    }

    @IBOutlet weak var label: UILabel!
    @IBOutlet weak var imageView: UIImageView!

In this case swift property observers are super helpful in detect property changes and apply them in real time to out interface.

As a note is worth to mention that not all the types of variable can be inspected (CGPoint, CGSize, CGRect, UIColor, NSRange, UIImage and numbers), for instance if you try to make a font property inspectable it will fail silently and it will not be displayed inside the attribute inspector.

To abstract a little more the xib loading process I created a class subclass of UIView that already takes care of loading “a same class name” xib.

Here are the results.

memeview grumphymeme view koala

If we need to fill with more information the view while it is displayed inside a storyboard or another xib, we can implement prepareForInterfaceBuilder(), this method will be executed only while opening the file in interface builder.

If you did everything I wrote but nothing is working, there is a way to debug a sigle view by adding breakpoints in its implementation.

debug view
You can download this little sample from dropbox.

Oggi nessun articolo di programmazione e niente inglese maccaronico.
Vorrei parlare in realtà di una funzionalità a mio avviso molto interessante presente in iOS8.
A volte può essere utile inserire nel vostro telefono informazioni che siano leggibili a tutti in caso di emergenza senza compromettere la privacy di altre, in pratica aprire una piccola finestra in cui far sbirciare piuttosto che aprire la porta di casa.

Read more!

One thing that I love about Obj-C and Cocoa is how seamlessly Apple is introducing funcionalities to take advantage of multicore devices.
One of the most common things that a dev does by hourly basis is enumerate a collection.
In Obj-C we can takle this with different approaches:
1 – old plain C for/while loops
2 – fast enumeration protocol (the for..in)
3 – Create an NSEnumerator object from the collection
4 – Use enumeration methods declared in the object interface

The 4th approach is present in almost each kind of collections and one of its methods is the

- (void)enumerateObjectsWithOptions:(NSEnumerationOptions)opts usingBlock:(void (^)(id obj, BOOL *stop))block

The opts parameter is a bit mask where we can pass this really interesting option:

NSEnumerationConcurrent

As the name states this makes the enumeration process a concurrent task and it’s a pleasure to see in instruments the 2 cores working all togheter. There is one caveat as stated by Apple engineers “the code of the block must be safe against concurrent invocation”.

One other stuff that I really love is the way we can help thread safety using blocks.
Recently for a social-instagram-like app I needed to use extensively the AFNetworking library.
To take trace of the networking operation created by each view controller I created a sort of register of the living connection.
The problem in this scenario is the async nature of the process related to the networking tasks. After adding an operation to the register, is impossible to know when it will be  finished (and consequently removed from the register) and this could happen while adding another one the register. We need to put things in order.

To help us we can use a thread locking mechanism,  I’ve found really uselfull the dispatch_barrier mechanism that has less overhead compared to an exclusive lock.

First we need to create our concurrent queue.
In the reading method we create a synch block that waits for the reading to end, if more cores are avalaible more reading request can occur, in the writing method we use a barrier to be sure that no other code has access until the writing finishes. Since GCD queue are executed in first in – first out order we can guarantee that the block would be executed in the same order we have requested.
As you can see from the picture (taken from the book Effective Obj-C 2.0) while the writing block is executing no reading (or writing) can happen.

Read-Write process

Read-Write process

In code is pretty much something like that.

First we create a our concurrent queue

syncQueue = dispatch_queue_create("it.shootshare.registeroperation", DISPATCH_QUEUE_CONCURRENT);

Then we override our properties:

- (NSString*) name {
  NSString * __block aName = nil;
  dispatch_sync(syncQueue, ^{
     aName = _name;
  });
  return aName;
}

- (void) setName:(NSString*)aName {
   dispatch_barrier_async(syncQueue, ^{
     _name = aName;
  });
}

Visto che l’argomento iBeacon sembra particolarmente interessante ho deciso di fare un video di 13 min con due piccole demo.

Spero possiate trovarlo interessante e perdonate le papere, ma andavo a braccio!!!!

Un altro articolo interessante sullo stesso argomento: iBeacon, behind the scene

 

La pirateria – e forse dico una cosa scontata – è un grosso problema anche per iOS.

Nel mondo del Jailbreak esistono AppStore fittizi dove è possibile scaricare gratuitamente copie di app che normalmente si trovano a pagamento.

Il tipo di utenza che usufruisce di questo servizio è divisibile in due macro-categorie:

a. persone che non compreranno mai la tua app

b. persone intenzionate all’acquisto, ma che desiderano provarla prima di investire i loro soldi nel tuo prodotto 

Riguardo al successivo pagamento da parte degli utenti tipo b. non bisogna farsi molte illusioni: sono davvero pochi coloro che regolarizzano la loro posizione andando sullo store virtuale di Apple.

Lo scenario è, dunque, tutt’altro che roseo. Un’ulteriore complicazione viene anche dalla natura stessa delle applicazioni. Questo genere di prodotti ha, infatti, una vita brevissima di utilizzo-medio, con il tangibile rischio che la ”prova” gratuita coincida perfettamente con il termine di utilizzo. Detto questo le app hanno anche costi rappresentativi del loro effettivo utilizzo. Apple, inoltre, non fornisce alcun periodo di trial sui prodotti distribuiti attraverso l’AppStore.

Come accade per altri settori, anche le tecniche per evitare la pirateria sulle app sono molto complesse, facilmente aggirabili e dall’elevata possibilità di creare un danno anche a chi l’applicazione l’ha regolarmente acquistata. Questo a causa di falsi positivi che possono essere causati anche per una semplice sostituzione del device. Non dimentichiamoci, poi, che Apple non vincola l’applicazione al dispositivo sul quale è stata scaricata, ma all’account dell’utente che l’ha acquistata.

Esistono soluzioni al problema? Una tecnica ottimale sarebbe quella di verificare se effettivamente l’utente ha effettuato l’acquisto, richiedendo una sorta di ricevuta digitale. Con iOS7 è stato introdotto un set di nuove API che consentono di ottenerla (anche se – a dire il vero – il sistema era comunque disponibile già con Lion). La classe è in oggetto SKReceiptRefreshRequest , interessante vero? Peccato che la verifica dello scontrino digitale sia ancora una procedura particolarmente complessa.

La ricevuta digitale sarebbe anche utilizzabile nel passaggio da applicazione a pagamento ad applicazione con modello freemium, in questo modo sarebbe possibile fornire a chi ha già pagato un set superiore di risorse.

La speranza è che venga rilasciata una qualche utility che renda l’analisi più snella (esiste già una lib su GitHub, che comunque richiede diverse conoscenze nell’ambito di certificati etc). O il danno economico diventerà sempre meno gestibile.

Il momento del rilascio di un’applicazione non segna la conclusione di un progetto, semmai del primo step, della prima parte del lavoro. Un’affermazione sempre più vera, dato che l’attuale situazione di AppStore è radicalmente diversa da quella che si poteva osservare solo qualche tempo fa. Niente come l’espressione “qualcosa è cambiato” è più adatta per descrivere ciò che è successo.

app-marketing-cloud_in_touchPrima – nei tempi eroici – era come trovarsi in un territorio di frontiera, con spazi sterminati e popolato da pochi coraggiosi pionieri. La sensazione che, invece, si prova oggi è assimilabile a quella di un cittadino medio di una moderna megalopoli, magari con la densità abitativa di Tokyo: sentirsi un singolo elemento statistico che al massimo può ambire, almeno una volta nella vita, ai famosi 15 minuti di celibrità.

Fuor di metafora, oggi è sempre più complesso sia ottenere visibilità nell’AppStore per aumentare i download sia aumentare i download per salire in visibilità nelle classifiche dell’AppStore. In un precedente post abbiamo mostrato come per entrare nella top ten app italiana serva ormai una media di 11.000 download ogni 48 ore (e il nostro non è nemmeno fra i mercati più sviluppati).

L’occasione della pubblicazione del nostro progetto Fresh & Local, il conseguente utilizzo delle principali leve di marketing a nostra disposizione per promuoverlo e i dubbi sulla correttezza delle scelte operate, mi hanno fatto tornare in mente un report pubblicato nello scorso mese di marzo dalla Forrester, società di marketing americana.

Dall’indagine condotta su un campione di 58.000 individui è emerso il basso impatto che campagne one-way push hanno sui consumatori. In particolare, in cima a questa speciale classifica delle comunicazioni meno degne di fiducia si trovano i messaggi di direct marketing provenienti dalle aziende. L’invio di notifiche, sms e messaggi email non richiesti sono considerati alla stregua di spam. Subito dopo, raccoglie poca fiducia tutto quanto viene postato dalle medesime sui propri profili social.

Il grado di fiducia, invece, aumenta quando si tratta di ciò che viene scritto nei siti web delle aziende, dei risultati dei motori di ricerca, delle opinioni di altri utenti su questo o quel prodotto o servizio e delle recensioni di professionisti del settore apparse sui media, cartacei e digitali (magazine, blog e siti).

Tuttavia, se si deve concedere fiducia a qualcuno allora il consumatore continua a preferire l’opinione di chi gli sta intorno, siano essi familiari, amici e conoscenti.

Una classifica che vede Stati Uniti ed Europa viaggiare sulla stessa lunghezza d’onda, seppur con alcune variazioni percentuali (gli americani confidano molto più nelle review di professionisti rispetto ai “sospettosi” europei, con un 55% contro un 33%).

Dunque l’obiettivo è conquistare familiari, amici e conoscenti in maniera che questi influenzino gli orientamenti di acquisto dei rispettivi… familiari amici e conoscenti! Ma come è possibile spezzare questo circolo vizioso?

Gli analisti della Forrester propongono una soluzione antica: l’aggiunta di contenuti ad hoc che diano valore al marchio o al prodotto pubblicizzato, in modo da renderlo agli occhi del consumatore / utente un qualcosa: a) di meritevole di fiducia b) degno di nota c) inconfondibile e d) essenziale.

Un contenuto brandizzato che dev’essere facilmente accessibile e in grado di tenere in considerazione il contesto, il momento e la modalità di fruizione (da un dispositivo mobile, da pc, dalla televisione etc.). Un contenuto che possa essere condiviso e che abbia in sé ragionevoli motivi di interesse.

I contenuti – dai consigli per le neo mamme targate Johnson&Johnson fino agli eventi spettacolari sponsorizzati Red Bull – hanno lo scopo di coinvolgere il consumatore / utente, di farlo sentire parte più o meno attiva di qualcosa e non solo il semplice terminale di un messaggio (quest’ultimo spesso non diverso dall’imperativo “compra!”). Insomma, uscire da una logica prodotto-centrica per entrare in una dove si concede qualcosa in più al potenziale acquirente / utilizzatore (nel segno di “ti do qualcosa in cambio della tua attenzione al mio marchio”).

Tutto ciò può servire anche nel momento della promozione di una App mobile? In linea generale, sì. Promuovere cercando di incuriosire, colpire, concedere e offrire qualcosa prima che il possessore di smartphone entri nel negozio virtuale Apple e clicchi “installa” è una strategia che può dare buoni frutti.

Resta, tuttavia, un grosso dubbio che ci riporta al “qualcosa è cambiato” dell’inizio, ovvero: tutto ciò è sufficiente? Non esito a rispondere dicendo che un tempo lo sarebbe senz’altro stato. Una applicazione pregevole, mediamente originale e ricca di contenuti se promossa con criterio e un minimo di pianificazione scalava le classifiche.

Oggi, con le classifiche dominate dalle grandi major che producono giochi o da start up lautamente finanziate, serve un budget consistente per la promozione a volte pari o superiore a quello allocato per lo sviluppo.

 

Essere inseriti nella “vetrina” dell’AppStore, fra le applicazioni consigliate. Ecco uno dei principali sogni per coloro che – società o singoli sviluppatori – pubblicano sul negozio virtuale di Apple. Un negozio che stando anche agli ultimi dati di Distimo – società americana di ricerche di mercato – vanta ricavi quasi doppi rispetto al rivale Google Play Store (65% contro 35%).

Il sogno ha, tuttavia, concrete basi nella realtà. Infatti, rientrare tra le migliori App scelte da Apple, generalmente garantisce un’impennata dei download e, conseguentemente, il posizionamento nelle parti alte delle classifiche di categoria e di quella generale. Un risultato più o meno arduo da ottenere a seconda del Paese in cui si pubblica. Negli Stati Uniti per arrivare fra le prime migliori 10 applicazioni bisogna almeno mantenere una media di  80.000 download ogni 72 ore. In altri mercati, invece, occorrono sforzi più contenuti; in Italia ne bastano 11.000, in Germania 15.000 e in Francia 13.000.

Ma quali meccanismi consentono a un’App recentemente pubblicata a), di farsi notare e b), scalare le classifiche? Innanzitutto lo consente un mix ben calibrato di elementi “ovvi” quali l’ottima fattura, l’idea originale, un tema non eccessivamente sfruttato e l’ambizione di interessare un pubblico ampio. Ma per il resto? Si possono applicare sistemi standard di indicizzazione in grado spingere la propria App più in alto?

Fino ad oggi il meccanismo che porta su e giù le App non è stato ancora completamente svelato. Tuttavia, risale alla fine dello scorso mese di agosto, la notizia di una revisione dell’algoritmo che regola ascesa e discesa nelle classifiche dell’AppStore. Almeno secondo quanto afferma Fiksu, una società di mobile marketing, che ha notato alcune variazioni nella composizione dei ranking.

Da luglio, infatti, i cambiamenti nelle posizioni in classifica sono originati da logiche leggermente diverse da quelle ritenute valide nei mesi precedenti. Quindi a un fattore premiante come è sempre stato l’alto numero di download raggiunto in un breve lasso di tempo, si è ora aggiunto anche quello del giudizio degli utenti. Ora le review e il numero delle stelle lasciate in calce alla App dall’utente smettono di avere una semplice funzione accessoria o indicativa, ma diventano parte attiva nel determinare la sorte del prodotto in questione.

fiksu report_cloud_in_touch

Ugualmente, si è notato come l’aggiornamento delle classifiche abbia subito un rallentamento, passando dai soliti 15 minuti a lassi di tempo più ampi (all’inizio si era parlato di 3 ore, ma nelle settimane successive questa misura è tornata a variare, segno che Apple sta ancora facendo test e valutazioni). Aumentare i tempi di aggiornamento significa per Cupertino poter meglio gestire e arginare la manipolazione delle classifiche da parte di terzi e le eventuali anomalie nell’andamento dei download.

 

Le centinaia di migliaia di applicazioni oggi esistenti hanno dunque bisogno di classifiche articolate e il più possibile precise. La questione della visibilità dei prodotti software lanciati sull’AppStore rimanda al tema delle migliaia di applicazioni anonime che non saranno mai nemmeno vicine all’ingresso in una qualsiasi classifica. La notizia è uscita all’inizio del 2013, ma ha ancora una sua validità.

Secondo un report presentato dalla tedesca Adeven, società specializzata nell’analisi dei dati sul mercato mobile, sarebbero oltre 400.000 le “applicazioni fantasma” (o “zombie”, chiamatele come preferite) presenti sullo store. Osservando l’andamento dei download, i ricercatori avrebbero scoperto che quasi la metà dei software presenti nel negozio virtuale di Apple non viene mai o quasi mai scaricato. Si tratterebbe di App regolarmente pubblicate, ma che nessuno avrebbe mai utilizzato sui propri device e che ora giacciono dimenticate perché mai pubblicizzate, mal presentate (con keywords sbagliate), inutili o prive di qualità. Non sappiamo se il numero è reale o esagerato. Fossero anche la metà di quelle dichiarate nello studio non cambierebbe la sostanza del problema.

Soprattutto ora che siamo di fronte a un sistema di vendita davvero imponente e ormai consolidato (a 5 anni dal lancio) a livello planetario, con fatturati sempre più importanti, con una frequentazione di utenti in costante crescita e con concorrenti agguerriti (sarebbe interessante condurre uno studio analogo su Google Play Store). Un problema che chiama in causa tanto Apple, ma soprattutto le società di sviluppo e i loro clienti.

 

La soluzione? Meno tecnologica di quanto uno s’immagini: un approccio di qualità che ripaga sempre dell’investimento. Ciò significa realizzare App “ragionate”, in grado di “poter dire qualcosa” e “di durata”. Applicazioni che gli utenti scaricano e tengono nel proprio dispositivo.

IOS7 è uscito, lo sappiamo e molti di noi lo hanno già installato. Il nuovo sistema operativo rappresenta un cambiamento radicale rispetto al 6, un cambiamento necessario per svecchiare un prodotto che rischiava di essere visto come “datato”, specie se confrontato con quelli proposti da concorrenti che, con il trascorrere degli anni, hanno saputo produrre sistemi operativi molto accattivanti.

Non parlerò delle funzioni di iOS7, delle quali è stato detto già abbastanza. Voglio guardare “il dietro le quinte” e ripercorrere le trasformazioni che iOS7 ha subito negli ultimi mesi, dalla developer preview 1 fino al rilascio ufficiale odierno. Un’altra maniera per capire il modus operandi di Apple, fra tentativi, certezze e modifiche dell’ultima ora.

Per noi sviluppatori iOS7 rappresenta “un problema” anzi, due problemi. Il primo è il missmatch creativo che si è creato tra sistema operativo e applicazioni “vecchie” che per lo più utilizzavano lo scheumorfismo.

Il secondo sono le API e il nuovo modo di “vedere” le applicazioni.

La questione ha due risvolti, entrambi da considerare.

Senza dubbio per innovare, è necessario guardare avanti e, nel caso, prendere decisioni unilaterali, di forza, in maniera che tutti vi si adeguino senza negoziare. Lasciando troppa libertà si corre il rischio che ognuno continui sulla sua vecchia strada, implementando API vecchie. Una nota personale: è da tempo che mi riprometto di imparare bene il linguaggio “Ruby”, ma ad ogni rilascio di sistema operativo mi vedo costretto a ricominciare a studiare tutto daccapo.

Apple è decisamente coerente con quello che dice e fa; alcuni elementi dell’interfaccia grafica standard sono stati macellati da diversi sviluppatori (me compreso) per accontentare le richieste di clienti a cui non piaceva il pop up bluetto perché non in linea con i colori aziendali. Da Cupertino, infatti, non si smetteva di sconsigliare modifiche a tali componenti, avvertendo che release future avrebbero potuto generare cambiamenti, con il rischio di dare vita a comportamenti inaspettati con l’applicazione di questi hack… Insomma tutti ne erano consapevoli tanto ieri come oggi.

 

Tuttavia, se la filosofia che sta dietro a determinate scelte è comprensibile, le vie che propone per renderla operativa sono talvolta meno limpide.

Parliamo del minimalismo dell’interfaccia grafica di iOS7. È chiaro che questa scelta non è fine a sé stessa come su altri sistemi (una pura questione estetica, di gusto), ma propedeutica al contenuto e al contesto presentato, animazioni incluse.

Meno chiaro, invece, la maniera attraverso la quale trasformare il concetto in qualcosa di reale, attraverso la programmazione. Infatti, benché iOS7 preveda che tutte le app compilate debbano utilizzare come area lo schermo intero, ad oggi sembra non esistere un modo semplice per cambiare questa azione e renderla simile ad iOS6. Una scelta che ha fatto letteralmente impazzire un certo numero di sviluppatori. Capita che le “vecchie” applicazioni ricompilate vengano visualizzate con un layout diverso e con i contenuti che “scivolano” sotto la status bar. Un problema non da poco per chi come me sta lavorando per implementare animazioni di transizione diverse da quelle standard tra una sezione e un’altra senza usare gli strumenti forniti da Apple.

Non c’è dunque da stupirsi se il forum ufficiale della Mela morsicata è animato da discussioni visitate da migliaia di persone. In pratica, con questa scelta, si obbliga lo sviluppatore da una parte a “ridisegnare” gran parte del layout e dall’altra a tenere sempre presente la bicompatibilità con il vecchio sistema.

Gli stessi ingegneri Apple si sono dimostrati non esattamente all’altezza: le loro risposte ancora latitano e quando arrivano, non sono del tutto esaustive, soffermandosi su un solo modo di programmare , talvolta utilizzato da una percentuale minima dei programmatori. Intanto anch’io mi sono cimentato, proponendo una soluzione che riduca l’impatto sulle ore di lavoro e mantenga la retrocompatibilità con il 6. La speranza è che funzioni.

 

Il confronto con i programmatori ha portato Apple ha fare alcuni importanti correttivi. Dai primi giorni di settembre è possibile scaricare anche le versioni vecchie per quelle app che hanno interrotto la compatibilità con i precedenti sistemi operativi.

Nel nostro caso stiamo sviluppando un update per un nostro prodotto, iEtiquette che sarà compatibile solo con iOS7. Mentre per chi non avesse o potesse aggiornare sarà comunque possibile scaricare la versione precedente. Questa è una scelta di importanza enorme perché favorisce sia sviluppatori che utenti.

Il cambiamento, come dicevo all’inizio di questo post è radicale. Sicuramente qualcuno si lamenterà. Negli ultimi giorni ho letto di diverse polemiche riguardo ad aggiornamenti  di applicazioni a pagamento che – con il pretesto del passaggio al sistema 7 – dovranno essere pagate di nuovo dagli utenti che le avevano a suo tempo scaricate. Un caso eclatante – notizia di oggi – riguarda il task manager CLEAR che nella nuova versione iOS7 compatibile richiede ben 3 euro.

L’effort per rendere una app compatibile con iOS7 è molto elevato e per applicazioni complicate (CLEAR non è tra queste) è abbastanza normale che gli sviluppatori richiedano un pagamento. Il problema è che non è possibile fissare un prezzo di update, o gratis o tutto. D’altra parte ritengo che sia normale che un’applicazione supporti gratuitamente un solo sistema operativo. È una situazione che nel mondo desktop viviamo tutti i giorni (è probabile che qualcuno se ne approfitti, avvelenando il mercato).

 

Altre sorprese passate in sordina sono la possibilità di scaricare app in 3G fino a 100MB (prima il limite era di 50MB) e che un’applicazione per iPhone su iPad userà le risorse per retina display e verrà visualizzata a quasi tutto schermo, con un miglioramento sull’usabilità davvero notevole.

 

Proximity Marketing: grande potenzialità da maneggiare con cura. La notizia è ormai di qualche settimana fa: niente più cestini per l’immondizia “spioni” per le strade di Londra. Almeno per il momento. L’amministrazione comunale ha imposto a Renew, società di marketing e pubblicità, di interrompere la raccolta di dati dei passanti che si trovavano nelle vicinanze dei suoi speciali gettacarte: i cestini high-tech, dotati di schermi LCD sui quali vengono proiettate informazioni e advertising.

Ma facciamo un passo indietro. Nel mese di giugno, Renew aveva installato dei particolari device all’interno di 12 cassonetti nella City di Londra, in una zona ad altissima densità di professionisti muniti di smartphone.

Grazie alla connessione wi-fi e individuando mac-address proprio di ogni telefono cellulare, il dispositivo è stato in grado di registrare movimento, modello, direzione, velocità dei singoli smartphone tracciati e… dunque di coloro che li trasportano! Renew ha subito assicurato che si tratta di dati totalmente anonimi, non riconducibili a singole persone, ne più ne meno simili a quelli che si possono raccogliere attraverso indagini quantitative condotte con metodi più tradizionali. L’amministrazione comunale, invece, preoccupata per la privacy dei cittadini si è cautelata, imponendo di interrompere la sperimentazione.

Non preoccupatevi! L’obiettivo di questo post non è disquisire se e quanto le nostre vite sono “sotto controllo”  e se la nostra privacy è a rischio (e qui le citazioni si sprecano: da Orwell con il suo “Grande Fratello” fino a Philip Dick e il suo futuristico “Minority Report”).

Questa storia è interessante perché per la prima volta – o quasi – dà consistenza reale (e tangibile) al cosiddetto proximity marketing (o marketing di prossimità). Un concetto troppo spesso raccontato e poco vissuto. L’operazione di Renew, infatti, è stata efficace, rapida, massiva e accurata nel contempo e, soprattutto non gravata da troppi impedimenti tecnologici (niente bluetooth, con tutte le sue complicazioni e limitazioni, ma solo wi-fi). Un’operazione in grado di ridurre l’incertezza che i futuri clienti (le aziende) possono nutrire sull’efficacia di campagne di questo tipo e, di conseguenza, su un reale ritorno dell’investimento. E per chi ha sborsato dei soldi per promuovere il proprio prodotto o servizio, questi elementi contano parecchio. La stessa Renew, lanciando l’iniziativa dei cestini traccianti, aveva parlato di voler portare “i cookies di internet nella vita reale”.

Gli scenari che possiamo intravedere sono molteplici e sembrano proprio andare incontro alle esigenze delle aziende e del loro più grande e pressante desiderio-ossessione: avere dati sempre più targettizzati e precisi sia per soddisfare meglio le esigenze dei potenziali clienti sia – sogno ancora più proibito – per stimolarne i bisogni. Sapere che in una data zona, a una data ora, in determinati giorni, diversi possessori di smartphone si dirigono verso un fast-food o un’attività commerciale farebbe risparmiare molto tempo e denaro a coloro che si dannano per scoprire il modo per tenersi stretti i clienti e per conquistarne di nuovi. Le prime ad essere interessate potrebbero essere proprio le aziende di telefonia mobile: Samsung, Apple o Motorola avrebbero meno incertezze nell’aprire un negozio di accessori in una strada che sanno essere frequentata da tanti utilizzatori di loro prodotti.

Quindi: prendere dati, studiare comportamenti, scoprire i consumi per poi inviare messaggi e comunicazioni commerciali. Tutto bello e tutto interessante. Eppure sento che qualcosa continua a non convincermi fino in fondo. Qualcosa che ha a che vedere con i seguenti due fattori.

  1. La valanga di comunicazioni che quotidianamente ci sommerge. Il rischio – e non è un problema nuovo – è quello del “tanti messaggi, nessun messaggio”. Spesso il consumatore troppo sollecitato da notifiche, sms, richieste di accettazione, di attivazione, promozione etc. non ascolta e non risponde più.
  2. L’importanza del consenso e (il vero) ascolto dell’opinione del consumatore. Il consenso va sempre chiesto: raccogliere dati in maniera furbesca e borderline è – oltre che in certi casi illegale e poco etico – anche pericoloso, perché potrebbe trasformarsi in un boomerang per l’azienda (gli anni Cinquanta e Sessanta, quando il consumatore era nulla, sono finiti da un pezzo). Siamo cittadini consumatori con diritti che non vogliamo veder violati.

Cosa fare allora? Avessi la risposta avrei già scritto un best seller. Mi limito a una banalità (e forse, proprio perché tale, trascurata): in questa giungla intricatissima senza dubbio è importante essere sicuri di almeno due cose:

  • La prima, che il consumatore davvero voglia ricevere le informazioni e le offerte commerciali che l’azienda sta proponendo (cioè che queste non arrivino in momenti sgraditi, magari mentre si sta usando il telefono per lavoro. È sufficiente un incidente del genere per perdere per sempre un cliente).
  • La seconda, che non abbia fornito i suoi dati solo perché “sotto ricatto”. Del tipo: il servizio non parte se tu non mi dai un’email valida e non hai compilato un form… (molte applicazioni oggi partono da questi presupposti).

Esiste una via alternativa? È la libertà di scelta l’arma più appuntita per ottenere i migliori risultati?

Ne discutiamo nel prossimo post.