I programmatori della GUI hanno un vantaggio indebito rispetto ad altri?

Penso di vedere il tuo punto, ma sospetto che ci sia anche un problema opposto da considerare.

In sostanza, ritengo che tu stia suggerendo che, poiché l'interfaccia utente è l'elemento dell'applicazione "in prima fila" degli utenti finali, gli sviluppatori dell'interfaccia utente godono di una visibilità maggiore rispetto ai membri del team che lavorano in livelli più profondi dell'app.

Sono certo che potrebbe esserci una maggiore visibilità. Ad esempio, gli sviluppatori che lavorano sugli elementi dell'interfaccia utente possono interagire con gli utenti più spesso (probabilmente, per validi motivi, dal momento che si concentrano sull'aspetto Interazione uomo / computer).

Tuttavia, penso che la visibilità più elevata entri in gioco anche nei casi in cui c'è un problema. Ad esempio, è molto probabile che gli utenti finali segnalino problemi come "Problemi della GUI" anche quando non lo sono.

Tutto può ridursi alla percezione, e un'organizzazione matura dovrebbe essere in grado di riconoscere valori, virtù e debolezze dei vari membri del team indipendentemente dal livello dell'app su cui lavorano. Un'organizzazione matura può anche andare oltre le distinzioni come "sviluppatore dell'interfaccia utente" e "sviluppatore del livello aziendale", riconoscendo che sono comunque tutti membri del team, forse con competenze diverse, ma sempre cercando di educarsi a vicenda in quelle aree di competenza.

Per una persona che non ha a che fare con programmatori, posso dire con sicurezza che crederanno a questo genere di cose. Non conoscono la quantità di lavoro che viene eseguita in background, tutto ciò che vedono è un insieme di pulsanti / caselle di testo / menu / [inserire l'elemento della GUI] e la velocità necessaria per eseguire l'avvio del pulsante. Quindi inizialmente, le persone GUI sono piaciute di più.

Se la persona fa si occupa di programmatori, è un po 'diversa. Come hai detto, avrebbero notato che se lo rendevi scalabile, più facile da mantenere, riscriveva un algoritmo in modo da avere più senso o qualsiasi altro tipo di attività di manutenzione. Questo tipo di persona guarderebbe tutti i programmatori allo stesso modo.

Nel mezzo dipende da cosa stai facendo. La velocità diventa quindi il fattore importante qui. Se riesci a mostrare prima e dopo le registrazioni di quanto tempo impiega un modulo per essere elaborato e memorizzato e c'è un miglioramento, sei uguale. Se è possibile mostrare l'app sotto carico da 100 client e mostrare loro il server che si sta sciogliendo, quindi mostrare loro la tua versione in cui tutto è a posto, la tua pari. Ecc.

In breve, dipende dalla persona e da ciò che fai.

Come "esperto di interfaccia utente" della mia azienda (il responsabile di tutto lo sviluppo dell'interfaccia utente, non solo del design), penso che potresti perdere parte della storia. Mentre io sono il ragazzo responsabile dell'interfaccia utente, lavoro anche sul back-end, sui database, ecc. Faccio tutto (siamo una piccola squadra). [Sviluppo di C # e ASP.Net WebForms]

Prima di tutto, sì è molto più facile per le persone non tecniche apprezzare il lavoro di uno sviluppatore della GUI perché questo è ciò che è di fronte alle persone. Per le persone non tecniche, la GUI è l'applicazione . Lo svantaggio è che la GUI è anche la prima da incolpare quando qualcosa va storto.

In secondo luogo, lo sviluppo del front-end è stato per me molto più impegnativo di quanto lo fosse il back-end (a parte algoritmi oscuri / complessi). C'è molto di più da proteggere, è senza stato (le nostre app sono sul Web), i browser non si comportano in modo coerente (le librerie JavaScript erano una manna dal cielo), ecc. Spero che gran parte di questa complessità sia dovuta al framework che ho lavorare con (ASP.Net WebForms) e che tutte le cose difficili non saranno un problema in futuro.

Nel complesso, ho avuto molte più difficoltà a risolvere i problemi di interfaccia utente rispetto ai problemi di back-end.

Odio lo sviluppo di GUI per due ragioni,

1. Sono più logico che graficamente artistico e la mia interfaccia utente soffre sempre di conseguenza.
2. Poiché l'interfaccia utente non è basata sulla logica, i test di unità sono praticamente impossibili da scrivere con qualsiasi significato

Alla fine della giornata, tuttavia, penso che il mio codice sarà meglio apprezzato dall'utilizzatore finale (al contrario, forse da uno sponsor del progetto), rispetto a quello di uno sviluppatore mediocre che è un mago dell'UI, come generalmente funziona.

Per (forse) espandere un po 'la risposta @ TheLQ, penso che dipenda anche dal "visualizzatore".

Ho avuto qualche esperienza con alcuni manager / supervisori di livello superiore che non hanno un background di programmazione. Alcuni apprezzano che non programmino, ma capiscono che il cromo e i coprimozzi sono importanti tanto quanto il motore e il telaio.

E ho avuto esperienza con alcuni manager / supervisori di livello superiore che non si preoccupano di metriche diverse dall'interfaccia utente. Anche affermando che più sviluppatori orientati all'interfaccia utente sono importanti.

IMHO, sappiamo tutti che non è possibile lucidare uno stronzo e un'app veloce, affidabile ma brutta sarà molto peggio di un'app che sembra sia bella e funzioni bene. È tutto negli occhi di chi guarda e in una certa misura, hai il potere (indipendentemente da ciò che fai) di essere visto alla luce che vuoi, lavorando per coloro che apprezzano le tue stesse qualità.

EDIT: Potrei aggiungere che, essendo qualcuno che si sente più a suo agio nel lavorare su articoli di livello inferiore, sono stato sfinito quando lavori altrettanto duro quanto il team di UI ed è lo smalto che è stato lodato nella demo e non il fatto che il sistema "ha funzionato ". Ma come ho detto, so che il mio supervisore sa che il lavoro è necessario in tutte le aree.

Penso che ci sia una presunzione generale sul fatto che gli sviluppatori dell'interfaccia utente siano gli sviluppatori "junior". Posso solo pensare a un caso in cui mi sono imbattuto in un ragazzo dell'UI considerato senior.

Detto questo, penso che l'interfaccia utente sia molto più difficile di qualsiasi altra parte delle nostre app. E non sto parlando del design UX, sto parlando della codifica. Quante altre aree dobbiamo codificare dove dobbiamo dare conto di dozzine, se non centinaia, o possibili scenari? Il ridimensionamento di uno schermo può a volte diventare un dolore reale quando è necessario capire che cosa deve accadere con un paio di dozzine di elementi. Questo emerge principalmente quando si hanno delle linee guida che dicono "dobbiamo supportare 800x600" e quindi i progettisti UX che non usano mai altro che risoluzioni HD.

Quindi, se ottengono più bontà a causa di una maggiore esposizione, probabilmente se lo meritano. Di solito, si trovano nella parte ricevente sbagliata più spesso della buona fine di ricezione.

Spesso sembra esserci l'idea che un programmatore GUI sia in fondo alla catena dei programmatori. Quanto può essere difficile trascinare & rilasciare un pulsante in VS su un modulo? Cosa, ti ci vorrà una settimana per programmarlo? Sta disegnando alcune barre. Quindi non sono sorpreso di vedere l'idea che i programmatori della GUI, essendo i pulsanti pulsante così come sono, devono scrivere anche un codice orribile.

La programmazione della GUI ha alcune sfide uniche. Multithreading per mantenere attiva la GUI durante il caricamento dei dati. Questo porta al thread codice sicuro e corretto. Le prestazioni sono molto importanti. A nessuno piace aspettare due minuti prima che riprendano il controllo dell'applicazione. Anche la riutilizzabilità diventa un grosso problema. Se devi scrivere dieci schermate simili, ti conviene strutturare meglio il tuo codice. Questo porta a un codice migliore. E, naturalmente, la creazione di una buona GUI è di per sé una sfida.

Ma per alcune persone trascinerà semplicemente un pulsante sulla tua app. Proprio come per alcune persone, la logica aziendale non è altro che "analizzare un messaggio e inserirlo nel DB".

Penso sia ovvio che lo facciano. Forse le case degli sviluppatori di alto livello sono esenti, ma la maggior parte delle altre no.

Quando il tuo manager ti chiede cosa hai fatto nell'ultimo mese, è facile mostrare una GUI interessante. È difficile mostrare un'API interessante. Molto difficile. La freddezza dell'API è evidente solo attraverso l'uso effettivo: non può essere apprezzata a colpo d'occhio.

Puoi cavartela con tutti i tipi di hackery e scorciatoie nei sistemi interni. Quando si ha a che fare con la GUI non si ha quella libertà. La tua API interna potrebbe avere incoerenza e ti aspetti che i programmatori lo affrontino perché è troppo difficile da risolvere. Non puoi provare e far fare ai tuoi clienti la stessa cosa. Quindi, in un certo senso, le persone che hanno a che fare con i componenti visibili dell'utente devono effettivamente seguire uno standard più elevato.

Dirò di sì, per una semplice ragione: l'iPhone. Tutti quelli con cui ho parlato pensano che sia fantastico grazie all'interfaccia sdolcinata, ma posso solo immaginare il lavoro sottostante per rendere tutto ciò possibile.

Dipende dal pubblico. Lavoro con un sacco di analisti finanziari e la loro idea di un buon design di gui è quella che ha tanti campi quanti ne puoi contenere su un modulo. Seriamente, sto parlando da 75 a 100. Sono drogati di dati che vogliono sempre di più. Recentemente ho migliorato le prestazioni su alcune stored procedure che potrebbero richiedere 45 secondi per il caricamento (calcolare le medie ponderate dall'inizio del tempo). Ottenuto fino a 30 secondi; Sto pensando wow, tagliato un terzo del tempo; dovrebbe essere un elemento pubblicitario sul mio curriculum. Nessuno ha nemmeno notato. Continuò a lavorarci e arrivò a 15-20. Cambiamento Noticable. Tutti erano molto felici. Continuo a pensare che la GUI sia un abominio e se prendessimo questa schifezza inutile, si caricherebbe in 2 secondi, ma quando ci sono 15 diverse caselle di testo multilinea (conosci quelle che hanno tutte le capacità di formattazione con le impostazioni dei caratteri MAX .), è senza speranza.

Quindi, se vuoi che gli utenti ti amino davvero, ricorda che la migliore interfaccia utente non ha alcuna interfaccia (vorrei ricordare che l'ha detto). Dopo aver voluto vedere tutti questi dati, i miei analisti hanno capito che sono loro a fare tutto il data entry - l'horror.

Test delle parti dell'interfaccia utente dell'applicazione è un incubo.

Ogni persona intorno si sente competente a dare un consiglio o a stabilire una domanda su come dovresti farlo.

Dopo che il sistema ha funzionato correttamente, in seguito, anche se qualcuno potrebbe ricordare per caso chi ha la virtù in esso, nessuno ricorderà chi ha fatto cosa.

Ma se qualche errore verrà visto (succede sempre alcuni ), il primo uomo a essere condannato sarà il programmatore della GUI, L'utente semplicemente non ha mai visto gli altri!