Gennaio 2016

Volume 31 Numero 1

Il presente articolo è stato tradotto automaticamente.

Non scherzare con l'esperienza utente - Usa i wireframe

Da Dino Esposito | Gennaio 2016

Parafrasarne scienziato immortale Albert Einstein, è possibile utilizzare ad esempio, che non si è certi di cosa è il futuro nell'archivio per la progettazione del software, ma se eventuali modifiche future, uno sarebbe certamente essere l'adozione di una metodologia dall'alto in basso nella struttura dei livelli. Abbreviazione di progettazione basata su UX, UXDD è un approccio principalmente per l'utilizzo di wireframe e storyboard come punto di partenza dell'architettura software. In UXDD, il risultato del processo di estrapolazione non è una raccolta asciutto e semplice di requisiti, ma invece piace lavorare insieme attivo-e-qui di bozze che indichi chiaramente i modo gli utenti. E naturalmente il modo in cui gli utenti piace lavorare è la rappresentazione software normale dei processi di business reale. A mio parere cose, tecnologia perde il ruolo centrale nell'architettura software che aveva per decenni. Oggi sono necessari ulteriori dal progettista di combinare le tecnologie disponibili e i prodotti per ottenere un set specifico di obiettivi, tenendo conto gli investimenti esistenti specifiche tecnologie, piattaforme legacy, competenze e budget.

Sembra proprio un pensiero foregone? Beh, probabilmente è. Questo concetto di software non è nuovo, ma è anche un concetto di software che non è diventata mai tradizionali.

Definizione di wireframe

Utilizza già la parola "wireframe" e utilizzarlo anche in modo intercambiabile con la parola "tracciate". Vorrei chiarire e già soddisfatta la differenza, da una prospettiva UXDD, wireframe e "modelli". Ecco alcune definizioni dei termini in UXDD:

• Uno sketch è un disegno a mano libera effettuato principalmente per annotare e acquisire un'idea lampeggiante. Area ideale per rendere persistente un sketch è documento, inclusi pannolini carta da caffetterie. Uno sketch può rappresentare la struttura di livello superiore di un'architettura, ma più probabile, acquisisce l'idea di un'interazione tra l'utente e il sistema.
• Un wireframe è un tipo più preciso e accurato di sketch durante l'aggiunta di informazioni sul layout, la logica di spostamento e dettagli relativi all'organizzazione del contenuto. Allo stesso tempo, un wireframe è agnostico di eventuali dettagli dell'interfaccia utente, ad esempio i colori, grafica, ombreggiature e i tipi di carattere.
• Quando un wireframe viene esteso per incorporare le interfacce grafiche, diventa un modello.

Esiste una differenza fondamentale psicologica tra modelli e wireframe. Quando si visualizzano bozze agli utenti di un'applicazione, l'attenzione è inevitabilmente acquisito da aspetti grafici, ad esempio immagini di sfondo, colori e lo stile. Raramente, attenzione degli utenti viene rilevata da organizzazione delle informazioni e come vengano spostate e disposto le stesse informazioni. Wireframe sono molto ridotta bozze completamente privo di contenuto del grafico. Wireframe possono essere disegnate manualmente o mediante gli strumenti di disegno generici, ad esempio PowerPoint, Visio o, forse, Balsamiq. Strumenti più specializzati, tuttavia, vengono visualizzate per collegare wireframe, in modo da formare gli storyboard per consentire agli utenti un'idea concreta dell'esperienza finale.

Perché sono economicamente convenienti wireframe

Gli sviluppatori in teoria concordino utilizzando wireframe form un'idea del livello di presentazione prima di pianificare anche il back-end è molto utile. Per molti anni, gli amministratori in questo settore coltivata l'idea che progettazione software è molto simile all'architettura di edifici. Lo spostamento Agile emersi quindi per contrastare l'idea che era necessaria una progettazione big anticipata e chiusa prima di scrivere codice. Non Agile non significa effettivamente alcuna analisi della progettazione e-piuttosto inverso, direi, ma Agile probabilmente non è stato risolto il problema di base dello sviluppo software. Che cos'è l'obiettivo finale del software? Stiamo è semplicemente la scrittura di software per archiviare e gestire i dati? Al contrario, non è la scrittura di software principalmente per gli utenti eseguire attività di business in modo più efficiente e più rapidamente? Nel secondo scenario, sempre maggiore rilevanza oggi, il livello di presentazione è tutto ciò che è importante. In questo caso, agilità significa che l'iterazione e collaborare con utenti di definire un set di wireframe accettabile e storyboard anziché informazioni sufficienti per creare un modello di persistenza valida.

Non è ancora insolito per i gestori del software visualizzare qualsiasi tempo trascorso nel wireframe come un costo inutile che riporta Nessun risultato finale e non money diretto. Di conseguenza, è possibile evitare che abbia lo stato attivo del team su elementi software effettivo. L'analogia tra software e di ingegneria civile è un'analogia da molto tempo ed è utile ricordare adesso per indicare che le operazioni seguenti: Quando desidera compilare un garage (per non parlare di tipi più complessi di edifici), si dovrà per spiegare cosa si desidera o si è appena previsto bricklayers raccolto brick e quindi protestare quando si distribuiscono mai voluto o richiesto?

Creazione e la convalida wireframe è un'attività aggiuntiva per la gestione e il costo di un dato aggiuntivo. Tuttavia, è necessario modificare un file di wireframe jots verso il basso una schermata visual; è molto altro per modificare un sistema a più livelli di migliaia di righe di codice. Adottando wireframe e UXDD, è senz'altro dedicare più tempo prima di qualsiasi riga di codice viene scritto, ma salvare molto più tempo dopo il primo sprint viene recapitato. E risparmiare tempo ancora maggiore quando il sistema si trova a metà e relativi effetti e i vantaggi possono essere meglio si è verificati e valutati. Con UXDD, si passa molto più simile a mai per realizzare il sogno di fornitura subito il progetto. Si salva in remakes e gli sprint successivi è molto più trascorso fin dall'inizio con wireframe.

Come produrre wireframe

AT le basi di UXDD e wireframe si trova l'idea che software non deve essere creato per modellare il dominio aziendale. Piuttosto, deve essere scritto per eseguire il mirroring del dominio aziendale. Questo cambiamento di prospettiva ha effetti rilevanti nei modelli di classe che viene utilizzata per definire il sistema. In particolare, offre un'attenzione particolare fortemente orientati alle attività dell'analisi preliminare e attenua la pertinenza di modellazione. Questo aspetto scares la maggior parte dei responsabili in quanto può sembrare una cosa da fare strana che nessuno ha per decenni. Il risultato previsto dei colloqui con i clienti già da tempo, le informazioni per creare un modello di dati completo per leggere e aggiornare lo stato del sistema. Man mano che aumenta la complessità dei domini e delle applicazioni, questo approccio è meno efficace e gestibile.

Classica singoli e interviste di gruppo sono comunque accettabile, ma più utile se lo scopo di comprendere gli eventi rilevanti per la gestione del sistema e le attività e circostanze che ne. Evento storming è una metodologia emergente per acquisire wireframe e il layout di livello di presentazione rapido ed efficace. È possibile trovare una breve introduzione alla pratica di evento storming, scritto da autore vero e proprio e master, all'indirizzo bit.ly/1N25MJl. In breve, questo è un metodo per esplorare i domini aziendali complessi in modo rapido e direttamente con il punto. Dispone di una versione avanzata e orientati alle attività e consente di apprendere il dominio e, in particolare, le attività da implementare. Ancora meglio, consente di ascoltare ciò che gli utenti veramente necessario e il flusso effettivo di eventi che è necessario eseguire il mirroring e riflettere tramite software, trigger e azioni.

Come convalidare wireframe

Questo è un punto chiave: Senza una conclusione esplicita e l'accettazione del cliente al momento della creazione di wireframe, qualsiasi lavoro viene perso perché non garantisce un'esperienza utente. ideale finale UXDD, è necessario disporre per wireframe approvazione prima di iniziare la scrittura di qualsiasi grave quantità di codice.

Con i clienti di esaminare wireframe solo il primo passaggio, però. Convalida efficace di wireframe richiede in genere più complessa. È necessario mostrare agli utenti cosa significa eseguire un'attività e la sequenza di passaggi e le schermate risultante che completa le attività. Lo storyboard è il termine utilizzato per fare riferimento per la concatenazione di più wireframe per comporre un'attività di business. Se il contenuto di wireframe è abbastanza accurato, la riproduzione di uno storyboard è molto vicino al test di un prototipo apportate al software, ad eccezione del fatto che il costo di uno storyboard non è una frazione del costo di un prototipo di software e può essere risolto quasi istantaneamente. Negli scenari più avanzati, potrebbe anche essere ragionevole agli utenti di utilizzare film durante la riproduzione di storyboard. Il linguaggio del corpo può indicare un lotto, nonché il tempo medio impiegato in ogni operazione. Un processo di convalida accurata può anche includere elementi di analisi cognitive, ad esempio Test operano-Test-uscita (borse). Come illustrato nella Figura 1, borse è destinato essenzialmente una sessione di versione di valutazione e di errore iterativa progressivamente migliorare la soddisfazione degli utenti e il conseguimento di condivise obiettivi.

Diagramma di flusso della figura 1 borse dall'analisi cognitivo adattato all'analisi dell'esperienza utente

Vi è nessun trucco dietro borse, è comune buon senso, ma come foregone come sembra, funziona in modo efficace. Più si applicano cognitivo analysis e più trascorso fin dall'inizio, più salvate in un secondo momento. Per coloro che a tale scopo, il saldo è in gran parte positivo. In generale, non può essere peggiore rispetto a quando si avvia la codifica in base ai modelli assunto e quindi sono stati recapitati individuare gli elementi non corretti.

Una storia tipici

La procedura che segue è real. Dopo una serie infinita di riunioni, il team che il cliente sono stati entrambi verificare che tutti gli aspetti del sito Web per compilare erano stato discussi e analizzati correttamente. Tutti i singoli aspetti del sistema è stato sarebbero stati chiariti e scritto nella pietra; sono stati sorprese non valide in ordine. La durata di nozze per pochi giorni fino a quando lo sviluppatore che opera nella pagina di accesso generato la prima eccezione. Account di accesso verrà eseguito solo tramite l'appartenenza? È opportuno Nessuna autenticazione social? La risposta è stato un resounding "No, il cliente non menzionare che." L'account di accesso è stato recapitato senza autenticazione, Facebook e Twitter. Indovinate un po'? Gli account di accesso social network sono stati per il cliente un requisito; è stato in modo rigoroso e ovvio che non è stato anche indicato. Gli account di accesso social erano un lavoro aggiuntivo e la consapevolezza che in precedenza sarebbe dispone probabilmente orientata ai servizi l'implementazione del sistema di appartenenze in modo diverso. Allo stesso tempo, era chiaro a tutti gli utenti all'interno del team che se un sketch della pagina di accesso, la mancanza del pulsante social chiunque agli utenti verrà indicato e segnalato, come illustrato nella Figura 2.

Figura 2 wireframe per accesso dai social network che Nobody creato

Da wireframe ai prototipi

Si ritiene più impegnati opportunità di usare l'analisi cognitivo nel processo di estrapolazione, più che si stia cercando di strumenti specifici che contribuiscono a creare wireframe e storyboard. Wireframe sono relativamente semplice e rapido creare, ma lo stesso può dire per storyboard. Si noti che la concatenazione semplice di wireframe alcuni potrebbe non essere sufficiente per alcuni utenti e alcuni scenari di business. In alcuni casi, è necessario scritto codice ai concetti di prova. La terminologia applicabile in questo caso che risulta utile per chiarire. Verifica dei concetti è in genere un piccolo esercizio per verificare un presupposto o riprodurre con una nuova tecnologia in un determinato contesto. Mi piace un proof-of-concept uno specifico dominio "hello world". Un prototipo è invece un sistema fittizio che tenta di simulare il sistema completo e ha lo scopo di test dell'affidabilità o anche l'utilità di un sistema. Questo è ciò che occorre avere quando storyboard dimostrare di non per essere sufficiente. Infine, un altro termine che viene spesso utilizzato intercambiabilmente con una propria definizione strict è "pilota". Un progetto pilota è un sistema di produzione completo testato solo un subset del set di dati o destinatari generale.

Avvolgendo

Per essere efficace, wireframe deve essere la valuta per lo scambio tra le parti interessate, solo a un livello di astrazione diversa da quella di dominio unità progettazione molto diffusa. Linguaggio universale sia wireframe hanno lo scopo di semplificare la conversazione e riducendo il rischio di non comprendere correttamente, falsa rappresentazione dei dati e presupposti non corretti a causa di mancanza di informazioni e istruzioni.

Wireframe e linguaggio universale non sono metodi che possono magicamente idee in esecuzione di codice. Il punto di entrambi è molto meno ambitiously, per trovare una sequenza di passaggi concreti che può ridurre il costo di scrittura di software vicino al budget previsto e le scadenze.

Il prossimo mese verrà tenere questo ulteriore e vengono descritte le implicazioni dell'utilizzo di wireframe (profondità) dell'architettura.

Dino Espositoco-autore di "Microsoft .NET: Architecting Applications for the Enterprise"(Microsoft Press, 2014) e" programmazione ASP.NET MVC 5"(Microsoft Press, 2014). Technical evangelist per Microsoft .NET Framework e piattaforme e Android in JetBrains e spesso come relatore a eventi del settore in tutto il mondo, Esposito condivide la sua visione di software software2cents.wordpress.com e su Twitter: @despos.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Jon Arne Saeteras