Applicare convenzioni per il rilevamento di oggetti nei wireframe

Molte grandi idee nascono su un foglio di carta o su una lavagna. Perché? Perché disegnare a mano è ancora il modo più naturale, intuitivo ed efficace per organizzare pensieri astratti o visivi. Nonostante gli sforzi per adattarsi al mondo digitale, le persone spesso ottengono risultati migliori in situazioni analogiche.

Partendo da questa osservazione, abbiamo deciso di concentrarci su un caso d'uso specifico: automatizzare la generazione di codice pronto per la produzione a partire da wireframe disegnati a mano. In questa fase, crediamo che ottenere una prova di concetto digitale direttamente da una riunione con gli stakeholder non sia più un sogno lontano.

Come spiegato in questo articolo precedente, puntiamo a usare l'intelligenza artificiale (IA) e l'apprendimento automatico (ML) in diversi punti della nostra piattaforma. Sappiamo però che, almeno per ora, il ML non può risolvere ogni problema. La nostra API di visione fa parte di un ecosistema più ampio e si occupa «solo» di rilevare i riquadri di delimitazione. Questi dati grezzi devono poi essere convertiti in una rappresentazione nel linguaggio di definizione dell'interfaccia utente (UIDL). A quel punto, i nostri generatori di codice e alcuni livelli proprietari di elaborazione decisionale possono occuparsi della generazione del codice.

Screenshot e wireframe di Stackoverflow.com

Esigenza di dati#

Sulla carta, per un data scientist, il problema sembra molto semplice: abbiamo immagini o scansioni di wireframe annotati che indicano la posizione di elementi come immagini, pulsanti e testi. Sembra facile, quindi colleghiamoci a Internet, raccogliamo qualche immagine e annotiamola in seguito.

Alcuni wireframe trovati sul web

Per iniziare, abbiamo deciso di raccogliere dati gratuiti dal web. Questo è stato sufficiente per farci un'idea generale della natura dei dati con cui avremmo lavorato, ma ci ha anche permesso di capire che questa fonte non avrebbe potuto fornire abbastanza immagini per addestrare un modello di machine learning. Poi ci siamo imbattuti in un secondo problema: nessuno seguiva le stesse convenzioni nel disegnare i wireframe... In effetti, più avanti, durante la raccolta dei dati, abbiamo scoperto che spesso ogni organizzazione ha linee guida specifiche.

Per risolvere questi primi problemi, abbiamo deciso di definire le nostre linee guida e abbiamo iniziato a disegnare wireframe in autonomia. Dopo aver raccolto il contributo di tutti i membri del team, abbiamo deciso di coinvolgere i nostri amici nella raccolta dei dati e abbiamo chiesto a ciascuno dei nostri fantastici amici di disegnare wireframe per noi. È certamente una strategia poco praticabile su larga scala, perché gli amici sono disponibili in numero limitato, ma ci ha permesso di creare una prima raccolta coerente di wireframe disegnati a mano.

Le attuali linee guida per disegnare i wireframe

Avevamo X, ma ci serviva ancora Y#

L'intuizione più semplice sul machine learning è che il computer impari autonomamente una funzione per prevedere Y da X, osservando un gran numero di esempi. A quel punto, avevamo raccolto qualche centinaio di immagini, quindi avevamo X. Sapevamo che sarebbero bastate per una prova di concetto, così siamo passati alla fase successiva: le annotazioni per ottenere Y.

Abbiamo iniziato ad annotare manualmente ogni wireframe disegnato, per individuare la posizione di immagini, pulsanti e testi. Inutile dire che questa attività non è stata la parte più piacevole dell'iniziativa, ma nulla è gratis nella vita, quindi ci siamo rimboccati le maniche.

Nel nostro caso, il processo è stato piuttosto lungo. È iniziato con alcuni esperimenti casuali con chatbot e interfacce conversazionali. All’epoca, nel 2015, la maggior parte di noi lavorava ancora nel reparto JavaScript di Evozon. Quel lavoro non è mai arrivato in produzione, ma eravamo tutti entusiasti: aveva aperto molte nuove prospettive su come creare nuove esperienze utente. Il lato positivo è che ha aiutato tutti i membri del nostro team ad apprezzare appieno il valore reale dei dati puliti e strutturati, una risorsa estremamente scarsa e un collo di bottiglia per la maggior parte dei progetti di data science.

La necessità di dati coerenti#

Una volta ottenuti X e Y, potevamo finalmente passare alla parte divertente: l’addestramento del modello. Ci è voluto molto meno tempo della raccolta dei dati e, naturalmente, la conclusione è stata che ci servivano più dati!

Ciononostante, abbiamo ottenuto una prova di fattibilità e un’ottima base da cui partire per migliorare. L’accuratezza del modello era del 55% sul nostro set di test: il 55% degli elementi veniva rilevato correttamente.

Oltre al numero esiguo di punti dati, fu allora che ci rendemmo conto di dover affrontare una nuova sfida: nelle annotazioni si verificavano molte sovrapposizioni. Alcune annotazioni erano ambigue persino per una persona:

• È un’immagine o un pulsante?
• È un’intestazione o un paragrafo?
• È un campo di testo o un pulsante?

In alcuni casi, come per le intestazioni e i paragrafi, la struttura generale del wireframe poteva aiutare a decidere. In molti altri casi, però, era impossibile distinguere gli elementi. Di conseguenza, non era possibile addestrare correttamente il modello.

A sinistra, un wireframe caricato da un utente; a destra, un wireframe tratto dal nostro set di dati di addestramento

Necessità di linee guida più rigorose#

Come accade con molti problemi di ingegneria, la parte più difficile è definire una prima base solida da cui partire per migliorare. Il machine learning non fa eccezione. Nel nostro caso, una base solida significava imporre vincoli rigorosi su ciò che il modello poteva rilevare e su come poteva rilevare le intenzioni dell’utente. Anche se in futuro prevediamo di ampliare le nostre capacità, sia in termini di varietà degli elementi sia di libertà di disegno, per ora ci limiteremo alle seguenti convenzioni (molte delle quali ispirate al Markdown):

• Intestazione: poiché può essere confusa con un paragrafo, proponiamo di anteporle un cancelletto
• Campo di testo: poiché può essere confuso con un pulsante, proponiamo di usare solo un campo di testo vuoto
• Collegamento: lo racchiuderemo tra parentesi quadre
• Etichette: verranno riconosciute come tali solo se associate a un campo di input
• Paragrafo: se il testo non è un’etichetta, un’intestazione o un collegamento, è un paragrafo
• Immagine: può essere solo un rettangolo o un cerchio con una croce all’interno

Le nostre future linee guida per disegnare wireframe

È stata una decisione difficile da prendere, ma siamo convinti che i vincoli introdotti apporteranno importanti benefici, tali da superare le limitazioni, come ad esempio:

• È un campo di testo o un pulsante?
• È un'immagine o un pulsante?
• Rendi l'annotazione inequivocabile

Conclusione#

Per il momento, la nostra API di visione segue ancora le vecchie linee guida, ma nella prossima versione (in arrivo a breve) adotteremo quelle nuove. Come sempre, ricordiamo ai nostri lettori che si tratta di un lavoro in corso e che è tutt'altro che perfetto, ma siamo felici di ricevere commenti o idee su come migliorare la nostra API di visione. Scriveteci pure in qualsiasi momento sul nostro account Twitter e seguiteci per restare aggiornati sulle prossime novità.