Pourquoi certains programmeurs détestent-ils la partie interface de développement? [fermé]

Beaucoup de programmeurs que j'ai rencontrés disent toujours "Il n'est pas un gars de l'interface utilisateur". Le fait est que le développement actuel, qu'il soit Web, Windows, Linux, OSX ou tout autre type de développement, comprend désormais un logiciel avec une interface utilisateur attrayante. Pourquoi tant de développeurs ne semblent pas aimer le travail d'interface utilisateur?

Je ne suis pas non plus une personne de l'assurance-chômage. Eh bien, je fais de l’interface utilisateur pour mes propres projets, mais au travail, j’ai rien à voir avec ça - mon travail est dans les tripes de l’application, pas dans le front-end.

Au-delà de cela, je pense que c'est plus de l'ennui que de la haine. La conception de l'interface utilisateur est la partie la plus difficile et la plus difficile. La mise en œuvre est principalement un travail difficile. Il existe très peu de défis ou d’innovations dans la manière de mettre en œuvre une interface utilisateur, et il est très rare de pouvoir cocher une case à l’écran avant de passer à autre chose. Et ce n'est même pas question de passer des heures à aligner les pixels "exactement".

Faire une bonne interface utilisateur implique beaucoup de compétences différentes que l'écriture de code backend.

Les exigences principales peuvent généralement être spécifiées comme une boîte noire, x entre et on s'attend à ce que y apparaisse. Pour que cela fonctionne, il faut implémenter la logique et vous pouvez tester par programme si cela fonctionne ou non.

Pour créer une bonne interface utilisateur, vous devez prendre en compte la convivialité, la conception visuelle, la mise en page et des éléments tels que les combinaisons de couleurs. Avoir un peu de créativité artistique est un bonus ici, et beaucoup de programmeurs ne le pensent pas. Pour un cerveau logique, la solution à un problème d’assurance-chômage peut sembler subjective, car il n’existe pas de réponse correcte ni de moyen simple de valider qu’il est fait «correctement».

Je pense que beaucoup de programmeurs qui n'ont pas beaucoup d'expérience en interface utilisateur ou qui n'ont pas fait beaucoup de recherche ne se rendent pas compte qu'il existe des règles et des bases scientifiques à la fois pour une bonne conception de l'interface utilisateur, à la fois du point de vue de la convivialité et du théorie).

Bien sûr, certains programmeurs n'ont pas de problème avec cet aspect, mais le détestent, car de nombreuses interfaces utilisateur sont simplement ennuyeuses pour le code. Ils peuvent consister en un grand nombre de travaux répétitifs, tels que des pages de formulaires pour des pages d’administrateur, où ils doivent simplement être fonctionnels et sans problème de conception.

Les gens ont juste des intérêts différents. Certains programmeurs sont plus intéressés par les structures de données et les algorithmes, certains par l’architecture, certains par la convivialité et la conception de l’interface utilisateur, ou toute combinaison de ceux-ci et d’autres créneaux. Chacun requiert des compétences différentes et des manières différentes de penser un problème. Si vous aimez les détails basiques de la programmation, vous ne vous souciez peut-être pas autant de la façon dont l’utilisateur pense, ou vice versa.

Personnellement, je tombe dans ce dernier camp. Je préférerais de beaucoup concevoir une interface utilisateur plutôt qu'un algorithme complexe. C'est juste le genre de chose que je trouve intéressante.

Qu'une conception d'interface utilisateur soit bonne ou mauvaise est assez subjectif , ce que les programmeurs trouvent généralement peu attrayant. Quelques décennies d'efforts pour quantifier et qualifier de bonnes techniques d'interface utilisateur ont permis de créer des règles générales applicables, mais le plus souvent pour déterminer réellement si une interface utilisateur est bonne nécessite de nombreux tests A / B et autres observations de l'utilisateur. techniques.

Bien que la programmation soit certes subjective, vous pouvez généralement indiquer certaines raisons objectives pour lesquelles un choix est meilleur qu’un autre: rapidité d’exécution, besoins en mémoire, souplesse nécessaire pour faire face aux besoins futurs probables, pratiques qui se sont avérées plus efficaces en le passé, etc. Défendre un choix donné d’UI - et par conséquent même faire le choix lui-même - se dégrade généralement en "je l’aime bien", ce qui est un tout autre type d’argument à soutenir.

Personnellement, je ne profite pas du développement de l'interface utilisateur parce que je ne suis pas bon pour ça. Il existe un élément ÉNORME de la psychologie de l'utilisateur que je ne suis tout simplement pas bon à comprendre. Je pense que mon plus gros problème est que je ne peux pas me mettre à la place de l'utilisateur. Je ne sais pas comment faire des mises en page intuitives en grande partie parce que je ne sais pas ce qui est intuitif pour l'utilisateur, ni comment rendre les choses jolies.

Je ne pense pas nécessairement que certains programmeurs détestent concevoir des interfaces utilisateur autant qu'ils détestent faire des choses pour lesquelles ils ne sont pas bons. Il se trouve que de nombreux développeurs ne sont pas bons en développement d'interface utilisateur.

Le problème avec la conception de l'interface utilisateur est que tout le monde a un avis ... Et il n'y a pas de bonne ou de mauvaise réponse. Les développeurs, quant à eux, aiment le noir et blanc et la logique. Dans toutes les entreprises de taille, tout le monde sera d’accord 1+1=2, mais demandez quelle police vous facilite la lecture (Comic Sans Obviously)… préparez-vous à l’inondation. Dix mille réponses différentes et tout le monde a raison, car tout le monde est différent.

En tant que développeur qui aime réellement travailler sur l'interface utilisateur (en particulier, j'ai fait ma juste part de la conception web), j'apprécie le fait que quelqu'un qui n'a pas les compétences requises reste en dehors de cela.

Le développement nécessite la capacité de conserver beaucoup de données dans votre esprit et de gérer beaucoup de choses en même temps. La conception de l'interface utilisateur nécessite la capacité de la réduire le moins possible, sans sacrifier son intégrité. J'aime le défi de cette; et je m'émerveille quand je vois quelqu'un créer une interface utilisateur qui est un mur-o-data ingérable sur l'écran. (Je suis aussi un geek total en matière de mise en page, de théorie des couleurs, etc.)

Par contre, je déteste les trucs de bas niveau. Je ne toucherai jamais au code des pilotes, des noyaux ou de tout autre chose du genre: frissonner: je laisserai cela aux «gars sans interface utilisateur», et je suis heureux que quelqu'un d'autre aime le faire, sinon cela ne se ferait jamais.

Je pense que cela dépend de la plupart des programmeurs utilisent la partie gauche de leur cerveau.

Une bonne source pour approfondir la lecture de ce sujet.

Le développement de l'interface utilisateur devient complexe parce que vous obtenez trop d'informations de la part des mauvaises personnes. Ils sont tous des experts en conception graphique. Ils ne sont pas où trouver quand vous voulez connaître la formule pour quelque chose.

Ils ne savent pas ce qu'ils veulent mais le savent quand ils le voient, ils n'ont pas de goût et ceux qui ont le pouvoir de décision n'utiliseront pas l'application de toute façon, mais sont certains que cela devrait être vert. Vous suivez les directives pour une bonne interface utilisateur, comme limiter le nombre de champs d'un formulaire et vous recevez une demande d'ajout de 50 champs supplémentaires, car ils ont «besoin» de tous et il est trop fastidieux de les avoir sur des onglets séparés. Vous savez, la même chose qu'Excel. Paysans!

Vous ne pouvez pas inventer ça. J'ai assisté à une réunion au cours de laquelle les deux premières personnes du service de la comptabilité (environ 500 000 dollars par an) d'un grand cabinet d'avocats ont passé une demi-heure à discuter d'une étiquette sur une page de site de facturation utilisée par les avocats. Cela devait faciliter la compréhension des avocats. Pourquoi ne pas demander aux avocats? Trop facile. Le service informatique reçoit donc 50 appels téléphoniques d'avocats qui souhaitent connaître le «montant de la facturation nette résiduelle» de la WTF et pourquoi cela se trouve sur leur formulaire de saisie de l'heure.

Certaines personnes aiment le brocoli, d'autres non. Il se peut que nous devions le manger, mais nous n’avons pas à l’aimer et nous ne l’apprécierons pas quand nous le mangerons. Non seulement cela, nous allons éviter d'avoir à manger autant que possible.

Il y a beaucoup d'autres choses à coder que l'interface utilisateur. Services Web, services Windows, intégrés (pas beaucoup d’interface utilisateur sur un four à micro-ondes), pour ne citer que quelques exemples.

Cela s'explique peut-être par le fait que, dans certains cas, des outils conçus expressément pour vous aider à dessiner l'interface utilisateur aspirent plutôt les bébés singes morts à l'aide d'une paille.

Il y a certaines choses dans le développement de l'assurance-chômage qui sont difficiles à obtenir.

La mise en page est l'un d'entre eux. Je construis des interfaces utilisateur depuis plus de 15 ans et je n’ai pas encore de solution décente pour la gestion de l’agencement.

Une autre solution est le routage des événements. Même avec les architectures MVP et les tâches imposées par les frameworks, je dirais que la plupart des interfaces utilisateur complexes ont des problèmes de routage des événements, qui pourraient être découverts si l'un des frameworks de test pouvait les traiter correctement.

Je sais que pour moi, j’avais l'habitude de détester l'interface utilisateur parce que je trouvais cela très fastidieux et lent, en particulier l'écriture de code de mise en page pour positionner les choses sous une forme ou une fenêtre. Maintenant, avec des outils de conception d'interface utilisateur tels que le concepteur de formulaires dans Visual Studio, j'apprécie presque de l' apprécier . J'ai entendu d'autres commentaires sur les raisons pour lesquelles je déteste ça: "c'est stupide", "ça change toujours trop", "ce n'est pas assez difficile", "c'est ennuyeux / ennuyeux".

Pourquoi tous les joueurs d'échecs n'aiment-ils pas concevoir des échiquiers et les pièces avec lesquelles ils jouent?

Ce n'est pas bizarre que certaines personnes n'aiment pas ça ... c'est bizarre, vous pensez que nous devrions le faire.

J'aime travailler sur l'interface utilisateur. Cela n'a pas toujours été vrai pour moi, mais le plaisir de travailler avec l'assurance-chômage a augmenté à mesure que je me perfectionnais depuis quelques années. Je sais que certains développeurs ne devraient pas être autorisés près d'une feuille de style ou d'une palette de couleurs. C'est certainement une compétence différente, et tout le monde ne l'a pas.

Je ne déteste pas autant le travail d'interface utilisateur que certains frameworks d'interface utilisateur. Par exemple, je programme .NET depuis> 10 ans. Les infrastructures de création d'applications Web sont excellentes (ASP.NET WebForms et ASP.NET MVC). Mais les frameworks pour écrire des applications bureautiques, eh bien, je ne les aime pas (WinForms et WPF).

Ainsi, à cet égard, l'écriture d'applications graphiques est plus un aspect de l'utilisation de frameworks que je n'aime pas.

Il y a un autre aspect. Je travaille souvent avec des applications de type "entreprise", c'est-à-dire des applications dans lesquelles une application de bureau doit recevoir des données d'un serveur. Dans ce cas, il y a tellement de couches de conversion de données d'un format à un autre que cela devient vraiment ennuyeux.

Par exemple, l'application reçoit des informations via une série d'objets DTO. L'application crée ensuite son propre modèle de représentation des données (sans réutiliser les mêmes classes de domaine que celles créées sur le serveur). Les classes de modèle sont utilisées par un modèle de vue (dans un modèle WPF MVVM), qui expose les propriétés du modèle.

C’est souvent que les mêmes données sont représentées par différentes classes. Et ça devient ennuyeux. Mais il s’agit d’un problème spécifique à ce type d’application de bureau.

Il existe également des défis intéressants dans ce type d’application, par exemple comment obtenir les modifications d’un client pour les mettre à jour immédiatement sur un autre client.

Je ne suis pas un grand fan du développement d'interface utilisateur pour ces raisons:

1. En tant que développeur, vous avez moins de liberté pour créer: le client peut voir et avoir des opinions sur chaque petite facette de l'interface utilisateur, sur laquelle vous devez réagir. Vous recevrez des demandes du type: changez la couleur de ceci; déplacez ce bouton là; tant pis, déplacez-le. Le code back-end est rarement aussi visible.

2. L'interface utilisateur est plus compliquée, alors que l'arrière est plus "platonique". Bien que j'ai vu de gros dégâts dans le code back-end, je pense qu'il est plus courant que ce soit propre (du point de vue du code) que le code de l'interface utilisateur. Une interface utilisateur peut être vraiment propre et bien conçue pour l'utilisateur, mais comme je suis un développeur et que je passe plus de temps dans le code que dans son utilisation, je préfère le code propre.

3. Je pense que l'interface utilisateur est plus une "plomberie" que le back-end, c'est-à-dire qu'il y a moins de possibilités pour des algorithmes intelligents et qui poussent vraiment votre cerveau à la limite.

Je fais à la fois l'interface utilisateur (bureau, pas Web) et les tripes internes.

Le montant que j'aime ou que je n'aime pas l'un ou l'autre dépend de ce que je peux faire avec quelque chose comme un langage de domaine (DSL).

Dans le domaine de l'interface utilisateur, ce que je présente aux utilisateurs et à la complexité des informations qu'ils me fournissent est telle que je deviendrais fou si je devais utiliser des outils classiques, tels que des concepteurs de formulaires, de nombreux gestionnaires d'événements, MVC. , tout ce "truc de pointe". Heureusement, il y a des décennies, j'ai découvert ce qui me semble être un meilleur moyen, à savoir faire une connexion DSL, et y travailler. Actuellement, j'appelle cela le dialogue dynamique, basé sur une structure de contrôle que j'appelle l' exécution différentielle . La bonne nouvelle est que, pour une fonctionnalité donnée, le code source est à peu près d'un ordre de grandeur inférieur, ce qui me permet d'ajouter beaucoup plus de fonctionnalités à l'interface utilisateur. La mauvaise nouvelle est que, même si j'ai essayé de l'enseigner, je n'ai pas eu beaucoup de chance de transférer la technologie.

Dans le domaine non-interface utilisateur, j'ai tiré des leçons d'un certain nombre de produits initialement conçus en tant que DSL utilisables à partir de la ligne de commande, sur lesquels une interface utilisateur a ensuite été greffée. Cela donne à l'utilisateur expert quelque chose où ils peuvent contourner l'interface utilisateur, tout en donnant à l'utilisateur occasionnel quelque chose qu'ils peuvent utiliser avec désinvolture. (Exemples: R, SPlus, Matlab, SAS, WinBugs.) Notre produit dispose donc d’un langage de ligne de commande pour les experts. J'aime développer de telles choses, avec un analyseur syntaxique, un générateur de code, un précompileur et un moteur de modélisation au moment de l'exécution. L'effort consacré à cette opération est au moins 10 fois inférieur à celui de l'interface utilisateur.

Une des raisons pour lesquelles l’assurance-chômage est si importante est qu’il reste encore beaucoup de "colle" qui ne peut pas être faite avec un DSL - la gestion des grilles de données, toutes sortes de façons de trier les données, tout ce qui tombe dans le "crack" béant. entre l'interface utilisateur pure et la langue sous-jacente.

Votre question était donc "Pourquoi certains programmeurs détestent-ils la partie interface de développement du développement?". Je ne le déteste que pour cette "colle" pour laquelle je n'ai pas de DSL.

Honnêtement, je trouve que trouver la meilleure boîte à outils de l’interface graphique, puis réellement apprendre ce qu’il en est, est un peu un PITA ... pour ne pas dire que vous n’apprenez pas beaucoup de choses sur l’interface utilisateur à la fac et dans un novice, alors ...... ya ..

Au-delà de ce qui a déjà été dit (c’est fastidieux, ennuyeux et frustrant de coder cela et la conception est généralement faite à l’avance par quelqu'un qui n’a aucune idée des problèmes que ses idées posent à ceux qui essaient de les mettre en œuvre), un facteur important est que vous Vous devez travailler avec des personnes dont les idées sur ce que vous devriez apporter changent constamment, bien plus que pour le backend. En conséquence, vous tirez encore plus contre une spécification en mouvement, et ces personnes ont également tendance à être des nitpickers. J'ai littéralement des tests d'échec d'interface utilisateur car un composant se trouvait à 1 pixel de l'endroit où la personne qui l'a testé a pensé qu'il aurait dû l'être. Cela a-t-il fonctionné? Oui. Est-ce que ça avait l'air bien? Oui. Mais il a commencé à compter les pixels et quelque chose n’était qu’un pixel décalé par rapport au reste, il l’a donc renvoyé pour qu’il le retravaille.

Quelques points supplémentaires:

1) La conception de l'interface utilisateur peut être plus difficile à tester. Assurez-vous de pouvoir vérifier si ce bouton fonctionne comme il se doit, mais il est également plus difficile de vérifier s'il est facile à utiliser. Qu'en est-il des tests s'il est utilisable avec une personne handicapée?

2) Beaucoup de programmeurs ne sont pas formés à ce sujet et ne savent pas grand chose à ce sujet.

Le fait est que beaucoup d'outils / framework / API d'interface utilisateur sont mauvais, complexes, loin d'être intuitifs. J'ai développé avec Win32 API en C / C ++, avec javax.swing, CSS, etc. Depuis, je déteste avoir à traiter avec le développement de l'interface utilisateur ... Jusqu'au framework Qt!

En tant qu'étudiant en CS, vous apprendrez la structure de données, la base de données, C ++ ... sauf l'interface utilisateur. Donc, vous ne serez pas bon à ça depuis le début . Si vous n'êtes pas bon, vous allez le détester.

Ayant travaillé des deux côtés de la médaille, à savoir la conception de l'interface utilisateur et le code de gestion, j'ai constaté que les deux côtés de la médaille sont fondamentalement la même chose.

Les exigences qui diffèrent de ce que vous faites au jour le jour ne viennent pas tout le temps et maintenant, à l'ère où tous les services tournent autour du CRUD, alors cela devient ennuyeux.

Quoi qu’il en soit, le codage de l’interface permet une meilleure interaction et des dynamismes insensés qui se résument à une main inexpérimentée dans la conception d’une interface. J'ai personnellement appris à la dure en face-à-face et peux facilement dire que concevoir une interface est beaucoup plus intéressant et stimulant.