In generale, è meglio creare tutte le parti funzionali o far funzionare l'interfaccia per prima - o un mix dei due?

C'è una concezione generale tra molti utenti business e clienti che quando sembra completa, è quasi completa. Come probabilmente saprai, questo è lontano dalla verità. Si può avere un aspetto gradevole, ma senza back-end e alcuni utenti pensano che rendere l'aspetto gradevole sia l'80% del lavoro, non il 20% ( o l'altro 80% ).

Innumerevoli sviluppatori possono raccontare storie horror di questo: ottenere un mockup delle pagine fatte in Microsoft Word usando le schermate di qualche altro strumento, e il cliente dice "così, hai quasi finito?"

È necessario farlo in modo che tutte le parti vengano completate al termine. Cercare di eseguire prima tutto il backend e poi tutto il front-end porterà l'utente finale a pensare che non stai facendo nulla e chiedendoti perché sei pagato quando non c'è niente da mostrare per questo. D'altra parte, il front end è il primo e troverai l'utente finale che apporta cambiamenti e consuma tutto il nostro tempo.

Il caso peggiore con un 'uno prima e l'altro' è quando arrivi all'altra parte, scopri che non si adatta affatto al design.

Quindi, costruisci entrambi. Mostra progressi nel front end, fai in modo che il back end funzioni con quello che stai creando. In molti casi è una buona idea fornire build incrementali e assicurarsi di fare ciò che il cliente desidera (questo entra in Agile). Andare troppo a lungo senza "miglioramenti visibili" può danneggiare la relazione con il cliente (questo è per i casi entrambi di "tutto sembra fatto presto" e "niente è fatto fino alla fine" - è difficile per il cliente per vedere il quadro in fase di scrittura o i test unitari o la disinfezione dei dati come progresso).

Joel ha scritto su questo in Il segreto dell'iceberg, rivelato :

Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.

Questo è ancora una volta reiterato nel post del blog Non rendere la Demo un aspetto che ha questo utile grafico:

Notaquiledueopzionigeneralmenteriflettonoilcomando"ottieni l'interfaccia utente" (e poi l'aspettativa è che sarai fatto presto) e "fai il back-end" (e poi il cliente è preoccupato per la mancanza della scadenza ).

How 'done' something looks should match how 'done' something is.

Every software developer has experienced this many times in their career. But desktop publishing tools lead to the same headache for tech writers--if you show someone a rough draft that's perfectly fonted and formatted, they see it as more done than you'd like. We need a match between where we are and where others perceive we are.

Questo articolo riporta anche un punto importante sul tipo di feedback che ottieni con diversi livelli di doneness dell'interfaccia utente. Se hai qualcosa che sembra completo, hai maggiori probabilità di ottenere un feedback su "potresti cambiare il carattere" rispetto a "questo layout non funziona - ci sono troppe schede".

Per coloro che stanno combattendo con questo nel mondo Java Swing, c'è un aspetto grafico chiamato Napkin che rende l'interfaccia utente non completa (anche se lo è).

Lachiavequièfareinmodochenonguardifatto.L'aspettodell'interfacciautenteèunsegnalepermoltiutentiaziendalichel'applicazioneècompleta(anchesesitrattadipochepaginestaticheprivedilogicaodiqualcosacostruitoinungeneratorediinterfacce).

Ulterioriletture(ecollegamentidall'articolo):

• Il segreto dell'iceberg, rivelato
• Non rendere l'aspetto Demo Fatto
• Aspetto e aspetto del tovagliolo; Senti per Swing
• Perché i grafici in stile xkcd sono importanti

Dipende: Hai bisogno di un ciclo di feedback stretto attorno alla tua funzionalità più importante

Se il nocciolo di ciò che fai, la parte rischiosa e spaventosa, è un motore interno, quindi fai in modo che la parte principale funzioni nella console o tramite il test dell'unità. Ad esempio, un parser di protocollo non ha bisogno di un'interfaccia utente per sapere se funziona correttamente.

Se la tua cosa interessante coinvolge qualsiasi interattività - l'interattività devi risolvere costantemente, gettare via e riscoprire - allora un approccio UI-first è cruciale. Ad esempio, voglio creare un'app per consentire alle persone di interagire con una visualizzazione dei dati. La cosa più importante che ho bisogno di capire è se la visualizzazione è significativa, quindi probabilmente eliminerò una mezza dozzina di approcci prima di sistemarla. Lo farò tutto prima di scrivere un test di unità singola.

C'è una zona grigia sfocata in mezzo alla quale si decide la migliore combinazione su come interagire e convalidare al meglio il proprio codice (test automatizzati? UI per la sperimentazione?). Personalmente ho fatto entrambi gli estremi e tutto il resto, e decidere quale sia il posto giusto in questo spettro è una delle cose più difficili da decidere e dipende al 100% dal tipo di cose che sto costruendo.

In un ambiente Agile, potresti sentire discussioni su "scheletri ambulanti" o "fette verticali sottili". L'idea è che dal momento che il software di lavoro è ciò che è importante per l'utente, si costruisce il software in un modo di lavorare pezzo per pezzo.

Nell'applicazione di esempio che hai menzionato, inizieresti con la finestra e forse una scheda e farai funzionare tutto in un modo diverso. Quindi, nel tempo, aggiungere funzionalità e quindi schede caso per caso, in modo che ogni funzione funzioni mentre la costruisci. Questo fa parte di ciò che le frequenti dimostrazioni dei clienti ti danno: la possibilità di mostrare qualcosa di nuovo funzionante e ricevere feedback su di esso all'istante.

In breve, sì, l'interfaccia utente è assolutamente parte integrante di un'unità di lavoro funzionale, se hai un'interfaccia utente.

Inizia con qualcosa di piccolo che funziona e itera la sua funzionalità fino a fornire un intero software.

Raccomando di creare una combinazione di entrambe le funzionalità e l'interfaccia utente (e di ottenere il feedback o l'esperienza di test al più presto possibile).

BTW, non è il modo in cui viene sviluppato il software GUI più grande? Guarda ad esempio il browser Firefox : da una versione alla successiva si sono evolute sia la funzionalità che l'interfaccia utente.

In applicazioni di grandi dimensioni (basate sul web PHP) su cui lavoro, cerco di ottenere in primo luogo le classi e i metodi, che restituiscono valori fittizi . Questo per stabilire uno pseudo-contratto che gli altri sviluppatori possano utilizzare per implementare l'interfaccia utente per.

Un secondo vantaggio di questo metodo è che possiamo perfezionare il contratto / l'interfaccia con i requisiti per l'interfaccia utente modificati (e cambiano sempre), anche prima che tutto il codice sia scritto e consegnato.

Quello che tendo a fare è iniziare con un'interfaccia utente scadente : qualcosa che scarica semplicemente i dati variabili sullo schermo. Nessun carattere, nessun allineamento, niente di realmente grafico per un lungo periodo. Solo "Benvenuto utente x" e pulsanti chiamati "carica foto" ecc. Ciò che è positivo è che scoprirai se qualcosa nel back-end è rotto.

Man mano che lo sviluppo procede, potresti scoprire che altre cose devono andare avanti, o meno. Ma a un certo punto, deciderà che il back-end è quasi completato. Ora hai un'interfaccia utente che contiene tutti gli allegati necessari e puoi dedicare molto tempo a tutto il materiale grafico.

Attenzione però, non è infallibile. Hai bisogno di un po 'di lungimiranza per vedere sorgere certi problemi. Ad esempio, potrebbe essere necessario ricercare i componenti dell'interfaccia utente per visualizzare i dati in modo ragionevole.

Se si utilizza un buon traguardo e si rilascia un sistema di tracciamento, è possibile evitare alcuni di questi problemi perché, a prima vista, la direzione può vedere quanto produttivi siete. Saranno in grado di vedere che l'80% ha terminato il back-end e che l'interfaccia utente è il prossimo traguardo; Saranno in grado di vedere che hai una serie di UI e attività di back-end da completare per una specifica pietra miliare. Ma tutto inizia con i requisiti del progetto e la risposta di Doug T solleva alcuni punti positivi su questo aspetto della progettazione di un sistema.

Pensa nel punto di vista dei tuoi utenti / clienti. Un sistema software è una raccolta di funzionalità che dà a questi utenti / clienti un certo valore. Ovviamente ognuna di queste funzioni ha e UI, un back-end e alcune altre cose.

Costruisci il tuo sistema sempre in base alle funzionalità e prova a dividere in funzioni molto piccole. In questo modo sei sempre vicino ad avere qualcosa in più da offrire ai tuoi clienti, ricorda che lo sviluppo del software non riguarda la versione 1.0 di andare alla versione 1.0.1 alla 1.0.2 e così via ...

Dipende. Quanto sono ben definiti i tuoi requisiti? Quanto del sistema è rivolto verso l'interfaccia?

Dalla mia esperienza la maggior parte dei clienti non sa cosa vogliono finché non vede qualcosa di fronte a loro. Di solito fornisco alcuni wire-frame degli aspetti chiave dell'interfaccia utente o fornisco la maggior parte dell'interfaccia utente (non funzionante). Ciò consente al cliente di cambiare idea su funzioni / funzioni senza un impatto eccessivo dato che la struttura del database e la struttura del codice sono ancora solo in fase di progettazione: è facile modificare il progetto. È più facile / veloce modificare gli ordini di grandezza prima nel progetto, poi più tardi.

Agile afferma che dovresti lavorare anche sugli oggetti più difficili e sugli oggetti più importanti. Errore veloce . Quindi, una volta che il cliente ha visto l'interfaccia utente, mi concentro sulla creazione di componenti di piccole dimensioni che siano perfettamente funzionanti e che parlino del più importante e più difficile da implementare per primi, in modo da sapere il prima possibile in caso di ostacoli.

Poi hai i tuoi sprint e hai una comunicazione costante con il cliente, sviluppando sia l'interfaccia utente che gli aspetti funzionali in un momento qualsiasi.