Perché alcuni programmatori odiano l'interfaccia utente dello sviluppo? [chiuso]

Anch'io non sono una persona con l'interfaccia utente. Bene, faccio l'interfaccia utente con i miei progetti, ma al lavoro non ho nulla a che fare con questo: il mio lavoro è nel cuore dell'app, non nel front-end.

Oltre a ciò, penso che sia più la noia che l'odio. Progettare l'interfaccia utente è la parte difficile e impegnativa. L'implementazione è per lo più lavoro da grugnito. C'è davvero poca sfida o innovazione nel modo in cui si può implementare un'interfaccia utente, e c'è solo così tante volte che si può mettere una casella di controllo sullo schermo prima di diventare leggermente mentali. E questo non significa nemmeno passare ore e ore allineando i pixel "solo così".

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

I requisiti back-end di solito possono essere specificati come una scatola nera, x entra e si prevede che y dovrebbe uscire. Per farlo funzionare è necessario implementare la logica e testare in modo programmatico se funziona o meno.

Per fare una buona interfaccia utente, devi 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 sentono di avere questo. Per 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 è stato eseguito correttamente.

Penso che molti programmatori che non hanno molta esperienza di interfaccia utente o non abbiano fatto molte ricerche su di esso non si rendono conto che ci sono regole e scienza alla base sia della buona progettazione dell'interfaccia utente sia da una prospettiva di usabilità e da una progettazione (es. teoria dei colori).

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

Le persone hanno solo interessi diversi. Alcuni programmatori sono più interessati a strutture e algoritmi di dati, alcuni in architettura, alcuni in usabilità e progettazione dell'interfaccia utente o qualsiasi combinazione di questi e di altre nicchie. Ognuno richiede competenze diverse e diversi modi di pensare a un problema. Se ti piacciono i bassi livelli di programmazione, forse non ti interessa tanto quanto l'utente pensa, o viceversa.

Personalmente, cado nel secondo campo: preferirei piuttosto progettare un'interfaccia utente piuttosto che un algoritmo complesso. È solo il tipo di cosa che trovo interessante.

Se un dato design dell'interfaccia utente è buono o cattivo è abbastanza soggettivo , che ritengo che i programmatori in generale non siano interessanti. Alcuni decenni di sforzi per quantificare e qualificare le buone tecniche di interfaccia utente hanno contribuito a creare alcune regole generali che è possibile applicare, ma il più delle volte a determinare realmente se un'interfaccia utente è utile richiede un sacco di test A / B e altre osservazioni dell'utente tecniche.

Sebbene esista una certa soggettività nella programmazione, in genere si può indicare una qualche forma di ragioni oggettive sul perché una scelta sia migliore di un'altra: velocità di esecuzione, requisiti di memoria, flessibilità per soddisfare i probabili bisogni futuri, pratiche dimostrate in modo dimostrabile più efficace nel passato, ecc. Difendere una determinata scelta dell'interfaccia utente - e quindi persino fare la scelta stessa - degrada comunemente in "Mi piace", che è un tipo di argomento completamente diverso da supportare.

Personalmente non mi diverto nello sviluppo dell'interfaccia utente perché non sono bravo in questo. C'è un ENORME elemento di psicologia dell'utente che non sono bravo a capire. Penso che il mio più grande problema è che non posso mettermi nei panni dell'utente. Non so come rendere i layout intuitivi in gran parte perché non so cosa sia intuitivo per l'utente, né so come far apparire le cose belle.

Non penso necessariamente che alcuni programmatori odiano progettare l'interfaccia utente tanto quanto odiano fare cose a cui non sono abili. Succede solo 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 c'è una risposta giusta o sbagliata. Gli sviluppatori d'altra parte amano il black & bianco e logica. In qualsiasi azienda di dimensioni tutti saranno d'accordo che 1+1=2 , ma chiedi quale font rende più facile leggere (Comic Sans Obviously) ... preparati per l'alluvione. 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 di 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 occuparsi molto di una volta. La progettazione dell'interfaccia utente richiede la capacità di farla bollire nel modo più minimale possibile, senza sacrificare la sua integrità. Io amo la sfida di ciò; e rabbrividisco quando vedo qualcuno creare un'interfaccia utente che è un ingestibile wall-o-data sullo schermo. (Sono anche un disadattato quando si tratta di layout, teoria dei colori, ecc.)

D'altra parte, io odio roba di basso livello. Non toccherò mai il codice per i driver, i kernel, o qualsiasi altra cosa del genere: brivido: lo lascerò ai "non-UI guys", e sono felice che qualcun altro si diverta a farlo, altrimenti non lo farebbe mai.

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

Una buona fonte per ulteriori letture di questo argomento.

Lo sviluppo dell'interfaccia utente diventa complesso perché ottieni troppi input dalle persone sbagliate. Sono tutti esperti di design grafico. Non sono dove possono essere trovati quando vuoi sapere la formula per qualcosa.

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

Non puoi inventarlo. Mi sono seduto in un incontro in cui le prime due persone nel reparto contabilità (circa 500K / anno di stipendio) 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ò avrebbe dovuto facilitare la comprensione degli avvocati. Perché non chiedi solo agli avvocati? Troppo facile. In questo modo, il reparto IT ottiene 50 chiamate telefoniche da avvocati che desiderano conoscere il WTF "importo di fatturazione netta residua" e perché si trova sul modulo di iscrizione all'orario.

Alcune persone amano i broccoli, altri no. Potremmo doverlo mangiare, ma non dobbiamo piacerci e non ci divertiremo quando lo mangeremo. Non solo, eviteremo di doverlo mangiare il più possibile.

Ci sono MOLTE altre cose da programmare rispetto alla sola interfaccia utente. Servizi Web, Servizi Windows, incorporati (non molto di un'interfaccia utente su un forno a microonde), solo per citarne alcuni esempi.

Questo potrebbe essere dovuto al fatto che - in alcuni casi - strumenti espressamente concepiti per aiutarti a disegnare l'interfaccia utente, invece di succhiare le scimmie monache morti attraverso una cannuccia.

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

Il layout è uno di questi. Ho costruito interfacce utente per oltre 15 anni e non ho ancora una soluzione decente per la gestione del layout.

Un altro è il routing degli eventi - anche con le architetture MVP e roba imposto dai framework, direi che le UI più complesse hanno problemi di routing degli eventi - che potrebbero essere scoperti se uno qualsiasi dei framework di test potesse risolverli bene.

So che per me odio l'UI dev perché l'ho trovato molto noioso e lento, specialmente quando ho scritto il codice di layout per posizionare le cose in una forma o in un winow. Ora con gli strumenti di progettazione dell'interfaccia utente come Forms Designer in Visual Studio, quasi mi piace goderne . Altri motivi per odiarlo Ho sentito da altri "è stupido", "cambia sempre troppo", "non è abbastanza impegnativo", "è noioso / noioso".

Perché non tutti i giocatori di scacchi amano 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. Non è sempre stato vero per me, ma il mio godimento del lavoro di UI è aumentato mentre negli ultimi anni mi sono migliorato. So che alcuni sviluppatori non dovrebbero essere autorizzati vicino a un foglio di stile o una tavolozza di colori. È sicuramente uno skillset diverso, e non tutti ce l'hanno.

Non odio l'interfaccia utente tanto quanto odio alcuni framework dell'interfaccia utente. Per esempio. Ho programmato .NET per > 10 anni. I framework per la creazione di applicazioni Web sono eccezionali (ASP.NET WebForms e ASP.NET MVC). Ma i framework per scrivere applicazioni desktop, beh, non li amo (WinForms e WPF).

Quindi, a questo proposito, scrivere applicazioni GUI è più un aspetto dell'utilizzo 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 veramente noioso.

es. l'applicazione riceve informazioni attraverso una serie di oggetti DTO. L'applicazione crea quindi la propria rappresentazione del modello dei dati (non riutilizzando le stesse classi di dominio create sul server). Le classi del modello vengono utilizzate da un modello di visualizzazione (in un modello MVVM WPF), che espone le proprietà sul modello.

Questo è un sacco di 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.

Ci sono anche sfide interessanti in questo tipo di applicazione, ad esempio come otteniamo le modifiche da un client all'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; muovi quel bottone lì; non importa, spostalo indietro. Il codice back-end è raramente visibile.

2. L'interfaccia utente è più disordinata, 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 UI. 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 rispetto al suo utilizzo, mi piace il codice più pulito.

3. Ritengo che l'interfaccia utente sia più di un "impianto idraulico" rispetto al back-end, cioè ci sono meno opportunità per algoritmi intelligenti e davvero spinge il cervello al limite.

Faccio entrambe le interfacce utente (desktop, non web) e quelle interne.

La quantità che mi piace o non mi piace dipende da quanto posso fare usando qualcosa come un dominio specifico della lingua (DSL).

Nel dominio UI, ciò che sto presentando agli utenti, e la complessità delle informazioni che ottengo da loro, è tale che diventerei pazzo se dovessi usare strumenti tipici, come i designer di moduli, un sacco di eventi gestori, MVC, tutta quella roba "all'avanguardia". Per fortuna, decenni fa ho scoperto quello che penso sia un modo migliore, che è quello di fare una DSL per esso, e lavorare in questo. 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 aggiungere molte più funzionalità all'interfaccia utente. La cattiva notizia è che, per quanto abbia provato a insegnarlo, non ho avuto molta fortuna nel trasferire la tecnologia.

Nel dominio non dell'interfaccia utente, ho preso una lezione da un numero di prodotti iniziati come DSL utilizzabili dalla riga di comando, su cui successivamente è stata innestata un'interfaccia utente. Ciò conferisce all'utente esperto qualcosa in cui è possibile aggirare 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 a riga di comando per esperti. Adoro lo sviluppo di queste cose, con un parser, un generatore di codice, un precompilatore e un motore di modellazione run-time. Lo sforzo speso per questo è almeno una potenza di 10 in meno rispetto allo sforzo speso per l'interfaccia utente.

Un motivo per cui lo sforzo di interfaccia utente è talmente strong che c'è ancora un sacco di "colla" che non può essere fatto con un DSL: gestire le griglie di dati, tutti i tipi di ordinamento dei dati, tutte le cose che cadono nello sbadiglio "crack" tra l'interfaccia utente pura e il linguaggio sottostante.

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

Onestamente trovo che trovare il miglior toolkit per GUI, in realtà, apprendere i dettagli di questo è un PITA ... per non parlare del fatto che non impari molte cose UI al college e im un principiante quindi .... ..ya ..

Al di là di quanto già affermato (è noioso, noioso, frustrante lavorare per codificarlo e il design di solito è fatto in anticipo da qualcuno che non ha idea di quali siano i problemi che le sue idee causano a coloro che cercano di implementarli), un fattore importante è che devi lavorare con persone le cui idee su ciò che dovresti fare cambiano continuamente, molto più di quanto non facciano per il backend. Di conseguenza, stai sparando ancora di più contro una specifica in movimento, e anche queste persone tendono ad essere dei nitpicker. Ho letteralmente fallito il test delle interfacce utente perché un componente era a 1 pixel dalla posizione in cui la persona che stava testando pensava che avrebbe dovuto essere. Ha funzionato? Sì. Ha un bell'aspetto? Sì. Ma ha iniziato a contare i pixel e qualcosa era un singolo pixel fuori linea rispetto al resto, quindi lo ha rimandato per la rielaborazione.

Alcuni altri punti:

1) La progettazione dell'interfaccia utente può essere più difficile da testare, assicurarsi di poter controllare se quel pulsante fa ciò che dovrebbe, ma testare se è facile da usare è più difficile. Che ne dici di testare se sarà utilizzabile con qualcuno con una disabilità?

2) Molti programmatori non sono addestrati 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 Win32 API in C / C ++, con javax.swing, CSS, ecc Da allora, io odio avere a che fare con lo sviluppo dell'interfaccia utente ... Fino al framework Qt!

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

Avendo lavorato su entrambi i lati della moneta, ovvero il design dell'interfaccia utente e il codice backend, ho scoperto che entrambi i lati della medaglia sono fondamentalmente la stessa cosa.

I requisiti che differiscono da quello che fai giorno per giorno non arrivano sempre e ora nell'era in cui tutti i servizi ruotano attorno a CRUD diventa noioso.

In ogni caso, la codifica del frontend consente una migliore interazione e dinamismi folli che sostanzialmente avvitano una mano inesperta nel design frontend. Personalmente ho imparato a fondo il frontend e posso tranquillamente dire che progettare frontend è molto più interessante e impegnativo.