Vaut-il encore la peine d'apprendre le développement d'une interface graphique de bureau? [fermé]

18

Au cours des deux dernières années, tous les projets sérieux sur lesquels j'ai travaillé étaient soit basés sur le Web, soit dotés d'une interface utilisateur non graphique (services, scripts de ligne de commande, etc.). Je peux créer une application WinForms ou faire du WPF simple si nécessaire, mais je n'ai jamais vraiment exploré certaines des API de niveau inférieur comme MFC ou QT.

Je comprends que cela dépend de la situation, mais en général, cela vaut-il la peine de bien apprendre le développement de bureau ou les applications se déplacent-elles sur le Web et les appareils mobiles à un rythme qui rend ces connaissances moins pertinentes? En outre, vous attendez-vous à ce que les développeurs avec lesquels vous travaillez possèdent une expertise en interface graphique de bureau?

learning education gui aubreyrhodes
la source
5
Avoir le développement d'applications de bureau est génial, mais pour l'amour de Knuth, ne vous embêtez pas avec MFC. Tout ce dont vous aurez besoin pour 95% des travaux d'application de bureau Windows est WinForms ou WPF / XAML. Les 5% restants des emplois que vous ne voulez pas avoir.
Adam Crossland
1
@Adam: +1 pour "Les 5% restants des emplois que vous ne voulez pas avoir." - Tellement vrai. :)
Bobby Tables

Réponses:

38

Je dirais que oui. Il y a une sorte d'effet pendulaire dans le développement du programme. Tout d'abord, tout s'est déroulé directement sur l'ordinateur. Puis, lorsque l'ordinateur est devenu suffisamment puissant pour exécuter plusieurs programmes, ils ont obtenu des ordinateurs centraux avec des terminaux stupides. Mais les terminaux stupides sont vraiment nuls en termes de convivialité, donc dès que les ordinateurs sont devenus assez puissants pour mettre des quantités raisonnables de matériel dans un système de la taille d'un terminal, nous avons eu des ordinateurs personnels, et tout fonctionnait directement sur l'ordinateur.

Ensuite , ils ont inventé le World Wide Web, et nous sommes de retour à un ordinateur central (serveur) et un terminal muet (navigateur.) Mais muets terminaux encore sucent vraiment en termes de facilité d' utilisation, et les gens commencent à réapprendre les leçons d'il y a 30 ans , et nous nous éloignons à nouveau de cela. Une grande partie du développement vraiment chaud de nos jours concerne les applications de bureau (ou mobiles) qui s'exécutent localement, mais sont capables de se connecter à Internet à des fins spécifiques pour améliorer leurs fonctionnalités.

Mason Wheeler
la source
5
+1 pour avoir souligné que ces tendances se déroulent en cycles. Cependant, j'ai vu un cas où une application de terminal a été réécrite en tant qu'application de bureau et où les utilisateurs ont pu travailler plus efficacement avec l'application de terminal.
Larry Coleman
2
La différence avec les navigateurs est qu'ils peuvent en fait exécuter du code sur le système local, et cette capacité augmente avec chaque génération de navigateur. La conséquence de cela est que la différence d'utilisation entre les applications de bureau et les applications Web n'est pas si grande. Pour de nombreuses personnes (y compris moi-même), Gmail est plus utilisable que Outlook. Le pendule oscille moins loin à chaque fois, et il s'arrêtera à mi-chemin, les applications étant un mélange de parties locales et cloud, quelle que soit la technologie sous-jacente.
Joeri Sebrechts
13
+1, je déteste quand les gens prétendent que le bureau est mort, c'est ridicule.
dr Hannibal Lecter
1
@Joeri: La plupart des terminaux pourraient toujours faire au moins quelques bits localement. Une quantité déprimante de JavaScript que j'ai vue fait des choses qu'un IBM 3270 (par exemple) aurait également pu faire localement.
Jerry Coffin
1
@Joeri Sebrichts - lorsque Gmail me permet de glisser-déposer un e-mail dans une tâche ou un élément de calendrier, je suis d'accord avec vous, mais jusque-là, beaucoup trop de fonctionnalités.
JeffO
11

Même si vous n'avez jamais l'intention de faire du développement de bureau, je vous suggère d'acquérir suffisamment d'expérience pour avoir une opinion éclairée sur le moment où il est préférable d'utiliser une solution de bureau sur un client Web.

Facture
la source
+1: En supposant que "le bureau est mort" et les applications de pigenholing, c'est le contraire des développeurs de bureau purs qui disent "cela ne pourrait jamais être bon comme application web". Choisissez ce avec quoi vous voulez travailler, mais connaissez l'autre juste assez pour connaître ses véritables avantages / pièges.
Steven Evers
8

Oui, mais pas de la façon dont vous pensez.

La programmation GUI n'est pas plus difficile et ne nécessite pas de compétences spécialisées en plus de la familiarité avec l'interface de programmation gui. Connecter des boutons, des fenêtres et des commandes n'est pas très difficile et est assez facile avec des environnements de programmation modernes par rapport aux premiers jours avec des trucs comme MFC. La programmation GUI est quelque chose qui est assez facile à apprendre quand cela est demandé.

Cependant, alors qu'il est assez facile de connecter des boutons et des zones de texte, il est très difficile de savoir quand et où placer les boutons, et de concevoir une interface graphique à utiliser par les êtres humains. C'est une compétence très précieuse et importante à posséder. Cependant, les principes de conception qui s'appliquent aux interfaces natives et au Web sont très similaires.

Apprenez donc à concevoir de bonnes interfaces utilisateur qui sont efficaces et ne confondent pas les utilisateurs, et vous vous familiariserez gratuitement avec la programmation pour eux.

comment s'appelle-t-il
la source
2
Surtout de nos jours, l'expérience utilisateur est en charge de la conception de logiciels. L'architecture n'est plus en charge.
rwong
5

Cela dépendra vraiment de votre situation. J'ai récemment travaillé pour une entreprise du Fortune 500 qui avait plusieurs projets pour reconvertir des applications Web en applications de bureau (SmartClient / Click-Once). Dans leurs circonstances particulières, cela avait beaucoup de sens et éliminait plusieurs problèmes d'utilisation dont leurs applications existantes souffraient.

Si vous êtes un employé à temps plein et que votre entreprise ne conçoit généralement pas d'applications de bureau, il n'est probablement pas logique d'être à jour sur Winforms ou WPF. Cependant, si vous êtes consultant et que vous souhaitez être en mesure d'offrir un autre service à vos clients, cela ne peut pas faire de mal.

Walter
la source
4

Hmm, outre GMail, Stack-Exchange et les services bancaires à domicile de ma banque, j'utilise toute la journée des logiciels non Web. Désormais avec l'avènement des smartphones et tablettes, les applications web sont encore moins attractives pour moi (j'utilise mon smartphone client Facebook). C'est côté utilisateur.

Côté développeur: au cours de mes 10 dernières années, j'ai travaillé presque uniquement sur des logiciels non Web (et ma carrière a couvert de nombreux domaines très différents en tant que consultant logiciel) et je ne vois aucune future tendance Web dans mon travail.

Alors oui, c'est toujours un environnement d'apprentissage graphique de bureau indispensable .

Wizard79
la source
2
Wow, vous n'utilisez pas de moteur de recherche Internet?
JBRWilkinson
1
@JBRWilkinson: non, je compte sur Gopher. Sérieusement, j'utilise Google toute la journée, mais ce n'est pas vraiment un remplacement pour un outil ou une application de bureau.
Wizard79
2

Bien sûr "ça dépend" - mais je pense que votre expérience est typique. J'ai rarement eu à créer un client lourd pour l'une des applications que j'ai écrites. À moins qu'il n'y ait une raison spécifique pour laquelle le client doit être exécuté sur le bureau (problèmes de connectivité ou jeu 3D, etc.) - je pense qu'il est plus facile pour le développeur et les administrateurs de maintenir une "instance" de l'application. S'ils ont les compétences nécessaires pour concevoir une application Web, ils devraient être en mesure de passer dans le domaine des applications de bureau en général.

En fait, je pense qu'il est plus important qu'un développeur client épais apprenne la programmation d'applications Web - l'héritage d'apatridie de HTTP en fait un paradigme de développement d'applications plus difficile à comprendre (ou au moins vous devez réfléchir un peu plus que simplement gifler sur un panneau).

N'oubliez pas - vous avez des technologies comme Silverlight et Adobe Flex / AIR qui peuvent chevaucher la ligne entre l'application de bureau / Web.

Watson
la source
+1 pour le développement web étant plus difficile. J'ai commencé en tant que développeur de bureau et j'ai dû passer au développement Web sur le tas. C'est certainement plus complexe (évidemment, cela suppose des tâches comparables, ce qui n'est pas facile).
Bobby Tables
@Guzica - oui, j'ai rencontré une attitude similaire de la part de bons développeurs avec qui j'ai travaillé et qui ont été verrouillés sur le développement d'applications de bureau. Une fois qu'ils essaient de faire le changement ce n'est pas aussi facile pour eux qu'ils le pensaient. Je ne sais pas si c'est une complexité inhérente à la programmation d'applications Web, c'est juste une façon différente de programmer, et beaucoup de vos hypothèses sous-jacentes de ce que le système peut faire doivent changer (en plus d'apprendre de nouveaux cadres).
Watson
Il est toujours plus difficile de faire des choses avec des outils plus limités, cela ne le rend pas "plus complexe". Cela le rend plus compliqué.
Sam
0

Selon l'équipe IE9:

Il ne devrait pas y avoir d'écart entre les applications natives et Web. L'accélération matérielle, le JS rapide et l'épinglage du site le démarrent

Je pense que c'est une valeur sûre que ces technologies se rapprochent. Si vous êtes un développeur Java, il y a très peu de différence entre le développement d'applications de bureau et d'applications Web (à l'aide de GWT). Il n'est pas déraisonnable de s'attendre à ce que de plus en plus de plates-formes de développement "de bureau" puissent cibler le moteur de navigation. Il n'est pas non plus déraisonnable de s'attendre à ce que de plus en plus d'applications de bureau aient un modèle de distribution de type Web (mise à jour automatique en arrière-plan, exécution en bac à sable, comme Chrome).

Joeri Sebrechts
la source
3
C'est BS total. Je travaille sur une application de mesure de latence qui doit être localisée localement pour mesurer et afficher en "temps réel" les latences de livraison des données de marché. Ce genre de chose ne sera JAMAIS déplacé vers le cloud.
Tim
C'est total BS parce que vous avez trouvé un besoin ridiculement obscur pour une application d'être locale?
Mike M.
@Tim: vous avez raison, certaines applications seront toujours locales. Il est également vrai que d'autres applications ne peuvent jamais être locales (par exemple, google translate). Mais, exécuter localement ne signifie pas qu'il ne provient pas du cloud. Chrome fonctionne localement mais est une application basée sur le cloud (vous avez peu de contrôle sur sa "version"). Il existe des tentatives pour lier l'exécution de code natif à des plates-formes de navigateur (Google NaCl) et des tentatives pour lier des langues Web à des applications natives (Adobe Air).
Joeri Sebrechts
1
@Mike M - ce n'est pas ridiculement obscur. Lors de mon travail précédent, j'ai travaillé sur un logiciel de bord de la marine. Ceux-ci sont également susceptibles de ne pas être dans le cloud. Les domaines dans lesquels je travaille ne migreront probablement pas - ils doivent être locaux pour des raisons de latence et d'interface matérielle. Le Web est agréable, mais certains d'entre nous travaillent toujours dans la zone d'application native pour une raison.
Tim
@Tim Mon point est que vous avez trouvé un scénario qui ne tient pas. L'auteur s'en rend compte lorsqu'il dit MOST. Vous avez trouvé un contrepoint, et c'est super. Vous n'avez nullement prouvé que tout cela n'a aucun fondement. Bien sûr, il y aura des moments où il devra être local pour une multitude de raisons. Mais pour la grande majorité, jetez un câble à fibre optique et vos 1200 miles peuvent être franchis en quoi, 10 millisecondes? En tant qu'utilisateur, je serais d'accord avec chacune de mes applications de bureau prenant 10 millisecondes de plus pour charger un formulaire.
Mike M.