Perché alcuni programmatori odiano la parte dell'interfaccia utente dello sviluppo? [chiuso]

Molti programmatori che ho incontrato dicono sempre che "Non è un ragazzo dell'interfaccia utente". Il fatto è che al giorno d'oggi lo sviluppo, sia esso web, Windows, Linux, OSX o qualsiasi altro tipo di sviluppo, comprende ora un software con un'interfaccia utente di bell'aspetto. Perché così tanti sviluppatori sembrano non apprezzare il lavoro dell'interfaccia utente?

Non sono nemmeno una persona dell'interfaccia utente. Bene, faccio l'interfaccia utente sui miei progetti, ma al lavoro non ho nulla a che fare con esso: il mio lavoro è nelle viscere dell'app, non nel front-end.

Oltre a ciò, penso che sia più noia che odio. Progettare l'interfaccia utente è la parte difficile e impegnativa. L'implementazione è per lo più un lavoro duro. C'è pochissima sfida o innovazione nel modo in cui è possibile implementare un'interfaccia utente e ci sono solo tante volte che si può mettere una casella di controllo sullo schermo prima di diventare leggermente mentale. E questo non tocca nemmeno passare ore ad allineare i pixel "proprio così".

Realizzare una buona interfaccia utente implica molte competenze diverse rispetto alla scrittura di un codice di back-end.

I requisiti di back-end di solito possono essere specificati come una scatola nera, x entra e si prevede che y dovrebbe uscire. Farlo funzionare implica implementare la logica e puoi testare programmaticamente se funziona o no.

Per creare una buona interfaccia utente, è necessario considerare l'usabilità, il design visivo, il layout e cose come le combinazioni di colori. Avere un po 'di creatività artistica è un vantaggio qui, e molti programmatori non pensano di avere questo. A un cervello logico la soluzione a un problema di interfaccia utente può sembrare soggettiva in quanto non esiste una risposta corretta o un modo semplice per convalidare che sia fatto "correttamente".

Penso che molti programmatori che non hanno molta esperienza nella UI o non hanno fatto molte ricerche al riguardo non si rendono conto che ci sono regole e scienza dietro sia una buona progettazione della UI sia da una prospettiva di usabilità che da una di progettazione (ad es. Colore teoria).

Naturalmente, alcuni programmatori non hanno problemi con questo aspetto, ma lo odiano perché molte UI sono solo noiose da programmare. Possono consistere in un sacco di lavoro ripetitivo come pagine di moduli per pagine di amministrazione in cui devono solo essere funzionali e non c'è sfida di progettazione.

Le persone hanno solo interessi diversi. Alcuni programmatori sono più interessati alle strutture di dati e agli algoritmi, altri all'architettura, altri all'usabilità e alla progettazione dell'interfaccia utente, oppure a qualsiasi combinazione di queste e altre nicchie. Ognuno richiede competenze diverse e modi diversi di pensare a un problema. Se ti piacciono le cose di basso livello della programmazione, forse non ti interessa tanto come pensa l'utente, o viceversa.

Personalmente, cado in quest'ultimo campo: preferirei piuttosto progettare un'interfaccia utente piuttosto che un algoritmo complesso. È proprio il genere di cose che trovo interessanti.

Se un determinato design dell'interfaccia utente sia buono o cattivo è abbastanza soggettivo , cosa che penso che i programmatori in generale trovino poco attraente. Qualche decennio di sforzi per quantificare e qualificare le buone tecniche di interfaccia utente ha contribuito a creare alcune regole generali che è possibile applicare, ma il più delle volte per determinare realmente se un'interfaccia utente è valida richiede molti test A / B e altre osservazioni degli utenti tecniche.

Sebbene vi sia sicuramente soggettività nella programmazione, comunemente puoi indicare una qualche forma di ragioni oggettive sul perché una scelta è migliore di un'altra: velocità di esecuzione, requisiti di memoria, flessibilità per soddisfare le probabili esigenze future, pratiche che si sono dimostrate più efficaci in il passato, ecc. La difesa di una determinata scelta dell'interfaccia utente - e quindi anche la scelta stessa - si degrada comunemente in "Mi piace", che è un tipo completamente diverso di argomento da sostenere.

Personalmente non mi piace lo sviluppo dell'interfaccia utente perché non sono bravo a farlo. C'è un ENORME elemento della psicologia dell'utente che non sono bravo a capire. Penso che il mio problema più grande sia che non riesco a mettermi nei panni dell'utente. Non so come realizzare layout intuitivi in ​​gran parte perché non so cosa sia intuitivo per l'utente, né so come rendere le cose belle.

Non penso necessariamente che alcuni programmatori odino progettare l'interfaccia utente tanto quanto odiano fare cose in cui non sono bravi. Accade semplicemente che ci sono molti sviluppatori che non sono bravi nello sviluppo dell'interfaccia utente.

Il problema con la progettazione dell'interfaccia utente è che tutti hanno un'opinione ... E non esiste una risposta giusta o sbagliata. Gli sviluppatori invece amano il bianco e nero e la logica. In qualsiasi dimensione aziendale tutti lo concorderanno 1+1=2, ma chiedi quale font rende più facile la lettura (Comic Sans Obviously)... preparati per il diluvio. Diecimila risposte diverse e tutti hanno ragione, perché ognuno è diverso.

Come sviluppatore che si diverte a lavorare sull'interfaccia utente (in particolare, ho fatto la mia giusta parte del web design), apprezzo quando qualcuno che non ha il set di abilità rimane fuori da esso.

Lo sviluppo richiede la capacità di contenere molti dati nella tua mente e di gestirli contemporaneamente. Il design dell'interfaccia utente richiede la capacità di ridurlo il più minimamente possibile, senza sacrificare la sua integrità. Mi piace la sfida di questo; e mi arrabbio quando vedo qualcuno creare un'interfaccia utente che è un ingestibile wall-o-data sullo schermo. (Sono anche un geek totale quando si tratta di layout, teoria dei colori, ecc.)

D'altra parte, odio le cose di basso livello. Non toccherò mai il codice per driver, kernel o altro: shudder: lo lascerò ai "non-UI guy", e sono felice che qualcun altro si diverta a farlo, o non lo farebbe mai.

Penso che dipenda dalla maggior parte dei programmatori che usano la parte sinistra del loro cervello.

Una buona fonte per ulteriori letture su questo argomento.

Lo sviluppo dell'interfaccia utente diventa complesso perché ricevi troppi input dalle persone sbagliate. Sono tutti esperti di design grafico. Non sono dove trovarli quando vuoi conoscere la formula per qualcosa.

Non sanno quello che vogliono, ma lo sanno quando lo vedono, non hanno gusto e quelli con il potere decisionale non useranno comunque l'applicazione ma sono sicuri che dovrebbe essere verde. Segui le linee guida per una buona interfaccia utente come limitare la quantità di campi in un modulo e ricevi una richiesta per aggiungere altri 50 campi perché "hanno bisogno" di tutti loro e averli in schede separate è troppo sforzo. Sai, lo stesso di Excel. I contadini!

Non puoi inventarlo. Mi sono seduto in una riunione in cui le prime due persone nel reparto contabilità (circa 500.000 di stipendio all'anno) per un grande studio legale hanno trascorso mezz'ora a discutere su un'etichetta su una pagina del sito Web di fatturazione utilizzata dagli avvocati. Ciò doveva supporre che gli avvocati potessero capire facilmente. Perché non chiedere semplicemente agli avvocati? Troppo facile. Quindi il dipartimento IT arriva al campo 50 chiamate telefoniche di avvocati che vogliono sapere che "importo di fatturazione netto residuo" di WTF è e perché si trova sul loro modulo di iscrizione.

Ad alcune persone piacciono i broccoli, altri no. Potremmo doverlo mangiare, ma non ci deve piacere e non ci divertiremo quando lo mangiamo. Non solo, eviteremo di doverlo mangiare il più possibile.

Ci sono MOLTE altre cose da codificare oltre all'interfaccia utente. Servizi Web, servizi Windows, integrati (non molto di un'interfaccia utente su un forno a microonde), solo per citarne alcuni esempi.

Ciò potrebbe essere dovuto al fatto che - in alcuni casi - strumenti concepiti espressamente per aiutarti a disegnare l'interfaccia utente succhiano invece scimmie di bambini morti attraverso una cannuccia.

Ci sono alcune cose nello sviluppo dell'interfaccia utente che sono difficili da ottenere.

Il layout è uno di questi. Costruisco interfacce utente da oltre 15 anni e non ho ancora una soluzione decente alla gestione del layout.

Un altro è il routing degli eventi - anche con architetture MVP e cose obbligate dai framework, direi che la maggior parte delle UI complesse hanno problemi di routing degli eventi - che potrebbe essere scoperto se qualcuno dei framework di test potesse risolverli bene.

So che per me odiavo gli sviluppatori dell'interfaccia utente perché l'ho trovato molto noioso e lento, soprattutto scrivendo codice di layout per posizionare le cose in un modulo o in una finestra. Ora con gli strumenti di progettazione dell'interfaccia utente come Forms Designer in Visual Studio, quasi mi diverto . Altre ragioni per odiarlo che ho sentito da altri includono "è stupido", "cambia sempre troppo", "non è abbastanza impegnativo", "è noioso / noioso".

Perché a tutti i giocatori di scacchi non piace progettare le scacchiere e i pezzi con cui giocano?

Non è strano che ad alcune persone non piaccia ... è strano che ti aspetti che dovremmo.

Mi piace lavorare sull'interfaccia utente. Questo non è sempre stato vero per me, ma il mio divertimento con il lavoro sull'interfaccia utente è aumentato man mano che sono migliorato negli ultimi anni. So che alcuni sviluppatori non dovrebbero essere ammessi vicino a un foglio di stile o una tavolozza di colori. È sicuramente un set di competenze diverso e non tutti ce l'hanno.

Non odio tanto l'interfaccia utente, quanto odio alcuni framework dell'interfaccia utente. Ad esempio, sto programmando .NET da> 10 anni. I framework per la creazione di applicazioni Web sono fantastici (ASP.NET WebForms e ASP.NET MVC). Ma i framework per la scrittura di applicazioni desktop, beh, non mi piacciono (WinForms e WPF).

Quindi, a questo proposito, scrivere applicazioni GUI è più un aspetto dell'uso di framework che non mi piacciono.

C'è un altro aspetto Lavoro spesso con applicazioni di tipo "enterprise", ovvero applicazioni in cui un'applicazione desktop deve ricevere dati da un server. In questo caso, ci sono così tanti livelli di conversione dei dati da un formato all'altro che diventa davvero noioso.

Ad esempio l'applicazione riceve informazioni attraverso una serie di oggetti DTO. L'applicazione crea quindi il proprio modello di rappresentazione dei dati (non riutilizzando le stesse classi di dominio create sul server). Le classi del modello sono utilizzate da un modello di vista (in un modello MVPM WPF), che espone le proprietà sul modello.

Questo è molte volte che gli stessi dati sono rappresentati da classi diverse. E questo diventa noioso. Ma questo è un problema specifico per questo tipo di applicazione desktop.

Esistono anche sfide interessanti in questo tipo di applicazione, come ad esempio come ottenere modifiche da un client per l'aggiornamento immediato su un altro client.

Non sono un grande fan dello sviluppo dell'interfaccia utente per questi motivi:

1. Come sviluppatore, hai meno libertà di creare: il cliente può vedere e avere opinioni su ogni piccolo aspetto dell'interfaccia utente, a cui devi reagire. Riceverai richieste come: cambia il colore di questo; sposta quel pulsante lì; non importa, spostalo indietro. Il codice back-end è raramente così visibile.

2. L'interfaccia utente è più complessa, mentre il back-end è più "platonico". Mentre ho visto brutti pasticci di codice back-end, penso che sia più comune che sia pulito (dal punto di vista del codice) rispetto al codice dell'interfaccia utente. Un'interfaccia utente può essere davvero pulita e ben progettata per l'utente, ma dal momento che sono uno sviluppatore e trascorro più tempo nel codice che nell'usarlo, mi piace molto ripulirlo.

3. Sento che l'interfaccia utente è più un "impianto idraulico" rispetto al back-end, cioè c'è meno opportunità per algoritmi intelligenti e davvero spingendo il cervello al limite.

Faccio sia UI (desktop, non web) che budella interne.

L'importo che mi piace o non mi piace dipende da quanto posso fare usando qualcosa come un dominio specifico del linguaggio (DSL).

Nel dominio dell'interfaccia utente, ciò che sto presentando agli utenti e la complessità delle informazioni che sto ricevendo da loro, è tale che impazzirei se dovessi usare strumenti tipici, come progettisti di moduli, molti gestori di eventi, MVC , tutta quella roba "allo stato dell'arte". Per fortuna, decenni fa ho scoperto quello che penso sia un modo migliore, che è quello di creare un DSL per esso e lavorare in quello. Attualmente lo chiamo Dialoghi dinamici, ed è basato su una struttura di controllo che chiamo Esecuzione differenziale . La buona notizia è che, per una data funzionalità, il codice sorgente è all'incirca un ordine di grandezza inferiore, permettendomi di mettere molte più funzionalità nell'interfaccia utente. La cattiva notizia è che, per quanto abbia cercato di insegnarlo, non ho avuto molta fortuna nel trasferire la tecnologia.

Nel dominio non UI, ho preso una lezione da una serie di prodotti che sono iniziati come DSL utilizzabili dalla riga di comando, su cui è stata successivamente innestata un'interfaccia utente. Ciò fornisce all'utente esperto qualcosa in cui può ignorare l'interfaccia utente, mentre fornisce all'utente casuale qualcosa che può usare casualmente. (Esempi: R, SPlus, Matlab, SAS, WinBugs.) Quindi il nostro prodotto ha un linguaggio da riga di comando per esperti. Adoro sviluppare queste cose, con un parser, un generatore di codice, un precompilatore e un motore di modellazione runtime. Lo sforzo speso per questo è almeno una potenza di 10 in meno rispetto allo sforzo speso sull'IU.

Uno dei motivi per cui lo sforzo dell'interfaccia utente è così tanto è che c'è ancora molta "colla" che non può essere eseguita con un DSL: gestione delle griglie di dati, tutti i tipi di ordinamento dei dati, tutto ciò che cade nella "crepa" che sbadiglia tra interfaccia utente pura e linguaggio sottostante.

Quindi la tua domanda era "Perché alcuni programmatori odiano la parte dell'interfaccia utente dello sviluppo?". Lo odio solo per quella "colla" per la quale non ho una DSL.

Sinceramente trovo che trovare il miglior toolkit della GUI e poi apprenderne i dettagli sia un pita ... per non parlare del fatto che non impari molte cose dell'interfaccia utente al college e sono un novizio quindi ...... ya ..

Al di là di ciò che è già stato dichiarato (è noioso, noioso, frustrante lavorare per codificarlo e il design è di solito fatto in anticipo da qualcuno che non ha idea di quali problemi le sue idee causino a coloro che cercano di implementarle), un fattore importante è che tu devi lavorare con persone le cui idee su cosa dovresti fare cambiano costantemente, molto più di quanto facciano per il backend. Di conseguenza, stai sparando ancora di più contro una specifica in movimento, e anche queste persone tendono ad essere pignoli. Ho letteralmente superato i test delle interfacce utente perché un componente era a 1 pixel di distanza dalla posizione che la persona che stava testando pensava dovesse essere. Ha funzionato? Sì. Sembrava buono? Sì. Ma ha iniziato a contare i pixel e qualcosa era un singolo pixel fuori linea rispetto al resto, quindi lo ha rispedito per essere rielaborato.

Alcuni altri punti:

1) Il design dell'interfaccia utente può essere più difficile da testare, assicurati di poter verificare se quel pulsante fa quello che dovrebbe, ma testare se è facile da usare è più difficile. Che ne dici di testare se sarà utilizzabile con qualcuno con disabilità?

2) Molti programmatori non sono addestrati su di esso e non ne sanno molto.

Il fatto è che molti strumenti / framework / API dell'interfaccia utente sono cattivi, complessi, molto lontani per essere intuitivi. Ho sviluppato con API Win32 in C / C ++, con javax.swing, CSS, ecc. Da allora, odio dover gestire lo sviluppo dell'interfaccia utente ... Until Qt framework!

Come studente CS ti verrà insegnato struttura dati, database, C ++ ... tranne l'interfaccia utente. Quindi non sarai bravo fin dall'inizio . Se non sei bravo, lo odierai.

Avendo lavorato su entrambi i lati della medaglia, ad esempio il design dell'interfaccia utente e il codice di backend, ho scoperto che entrambi i lati della medaglia sono sostanzialmente la stessa cosa.

I requisiti che differiscono da ciò che fai ogni giorno non arrivano sempre e ora nell'era in cui tutti i servizi ruotano attorno a CRUD, allora diventa noioso.

Comunque, codificare il frontend consente una migliore interazione e dinamici pazzi che fondamentalmente avvitano una mano inesperta nel design del frontend. Personalmente ho imparato a mie spese in frontend e posso tranquillamente dire che progettare frontend è molto più interessante e stimolante.