Un webdesigner doit-il avoir des notions en développement ?
Le 28 novembre 2008
Le petit monde du web ne cessera jamais de me surprendre. Malgré le lien évident qu’il éxiste entre l’aspect graphique et l’aspect technique d’un site, je reste toujours surpris de voir l’incompréhension qui persiste entre le monde des webdesigners et celui des développeurs. Peut-être mon étonnement est-il due au fait que j’appartiens en quelque sorte à ces deux univers… Pour autant je reste preplexe.
Pourquoi certains webdesigners ne souhaitent que ce « limiter » à la seule réalisation de l’aspect visuel d’un site internet ?
Et pourquoi certains développeurs restent-ils « emprisonnés » dans leur code ?
Le point de vue du développeur |
Pour ma part je suis bien évidement pour que les graphistes aient quelques notions puisque c’est mon cas, je réalise des interfaces de sites et les développe. Cependant il est vrai qu’à partir du moment où vous êtes « catalogué » dans une catégorie, il est relativement difficile d’en sortir au vue des gens… Ce qui est très français comme attitude d’ailleurs me semble-t-il.
J’ai du mal à comprendre les designers qui ne veulent pas entendre parler de l’envers du décors. Il me semble que savoir un minimum comment marche un site internet peu grandement améliorer l’approche d’un graphiste dans la conception de son interface.
Bien entendu je ne parle pas ici de codage PHP, ASP, ou autre langages de programmation, ça c’est un choix qui regarde chacun. Pour autant le couple HTML/CSS me semble indispensable. D’autant plus que ce ne sont pas des langages de programmation ! Le HTML s’apparentant plus à un langage descriptif permettant d’organiser le contenu, le CSS servant à construire le design du site avec des couleurs, des formes, … (du design donc 
).
De ma propre expérience, il arrive parfois que j’ai à passer une création de designer (un fichier Photoshop, PDF, …) en site internet parfaitement exploitable. Et ce n’est pas toujours des plus aisé croyez-moi 
.
Il y a une chose fondamentale dans un site internet, c’est l’ergonomie. Et je conçois difficilement qu’un webdesigner, sans aucune idée de la logique du duo HTML/CSS, puisse créer une interface ergonomique pour l’utilisateur. Car un site peut-être le plus beau du monde, il n’en reste pas moins bancale si son ergonomie est sacrifiée à son esthétisme. Et un site internet ne se construit pas vraiment comme un document imprimé.
Le rapport peu sembler moins évident au premier abord mais prenons l’exemple de l’impression justement.
Tout graphiste qui se respecte possède un certain savoir sur le chaîne graphique et le procédé d’impression offset et/ou sérigraphie (voir plus). C’est tout simplement essentiel à son travail car sans pour autant avoir des compétences d’imprimeur, ces connaissances lui servent tous les jours dans le choix de ses couleurs etc, etc… Personne n’irai envoyer un fichier RVB à un imprimeur. N’est-ce pas ?
Et bien pour internet c’est un peu la même chose, sans savoir comment écrire une fonction en PHP, il me semble important de ne pas tomber dans la facilité :
Moi j’fait le design après le reste c’est pas mon problème… J’ai pas besoin de savoir comment ça marche !
Un peu dommage comme réflexion je trouve, et pourtant elle n’est pas inventée si vous voyez ce que je veux dire.
Le point de vue du designer |
D’un autre côté la réciproque est également valable.
Une fois encore il n’est pas question ici de faire d’un codeur un peintre, mais quand même… Si un site ne peut se contenter d’être juste « beau », il ne peut non plus se contenter de fonctionner à la perfection s’il est rebutant à souhait.
Car l’ergonomie passe bien évidement à la fois par le ressentie de l’utilisateur lors de son utilisation, mais également par l’aspect visuel du site.
Un jolie site fatiguera vite un utilisateur si ses requêtes prennent trop de temps à s’effectuer, mais un site ultra-rapide ne suscitera pas pour autant la fidélité de l’internaute s’il fait mal aux yeux.
Il m’est déjà arrivé de rencontrer des programmeurs « purs et durs » qui ne font réellement que ça… Et sans avoir la bêtise de croire que tous les développeurs sont réfractaires à la moindre petite notion de design, certains m’ont fait l’impression de voir le monde comme une suite de 0 et de 1, je vous laisse imaginer l’aspect visuel des interfaces…
Un site ne doit pas forcement présenter une structure avec un menu en haut, un menu à gauche, et le contenu au centre (je caricature là bien entendu) ! C’était peut-être la norme à une certaine époque (enfin y’a un moment déjà), mais il faut aussi savoir bousculer les normes et proposer de la nouveauté aux gens.
‘tain c’est pas vrai il m’a encore mis du texte dans tous les sens ! Et comment je vais moi pour caler ça en HTML ??
Certes tout n’est pas toujours facile à retranscrire depuis l’idée du graphiste jusqu’à la réalité du développeur (intégrateur), mais avouez qu’un beau design incite aussi les gens à aller utiliser les fonctions si pratiques que vous avez mis tant de temps à écrire…
Comprenons-nous bien, mon but n’est pas de critiquer l’un ou l’autre des deux profils ici présents, mais plutôt de tenter de mettre en avant le fait que leurs tâches sont complémentaires, donc autant que chacun s’intéresse un peu à, si ce n’est apprécier, du moins comprendre ce que fait l’autre.
Conclusion |
Personnellement je retire une grande satisfaction à avoir un pied dans chacun de ses mondes. D’abord parce tous deux sont très intéressants et vastes à explorer, et ensuite parce que j’aime comprendre ce que je fait dans son ensemble. Ce qui fait qu’il m’est impossible de juste créer une interface sans imaginer les CSS ou les fonctions PHP qui tourneront derrière pour permettre à l’homme et à la machine de se comprendre.
Et vous ? Quel est votre avis sur la question ?
Wikio
[4,56 / 5 - 9 vote(s)]
Loading ...
Tiens tiens…
Malgré mon dernier post, je tiens à dire que je ne suis pas réfractaire à l’idée de me faire des compétences dans le domaine du design, d’où le « (encore) » dans le titre.
J’exprimais juste un ras-le-bol qu’on me demande des modifications typiquement de designer alors que je suis principalement développeur. Ce n’est pas que je ne peux pas les faire, c’est que ça me prend le triple de temps d’un designer spécialisé.
Évidemment, maîtriser l’ensemble du développement d’un site est l’idéal, mais ça demande *beaucoup* de temps et de capacités. Que ceux qui en sont capables s’y attèlent
Cela dit ce que tu proposes (avoir les bases du domaine complémentaire) me semble être de bon sens. Un designer se doit de connaître HTML et CSS (personnellement, en tant que développeur, rien ne m’ennuie plus que d’être obligé de retoucher du CSS), et un développeur se doit de connaître HTML et JS. Entre le design et le développement backend, cela permet de créer l’ergonomie, ou UX.
Néanmoins, un autre problème se pose dans la manière de concevoir des sites habituellement. Le problème ne vient pas tant, à mon avis, que le designer est trop designer et le développeur trop développeur, mais plutôt du fait qu’ils ne travaillent pas ensemble (comprendre: en même temps, en communiquant). Souvent, le designer fait sa maquette, puis le développeur en fait le produit final.
C’est une grave erreur, car le développeur n’est pas forcément au courant des intentions du designer, et encore moins des requêtes originales du client qu’elles transcrivent. Enfin, le produit est montré au client, alors qu’il est presque terminé. Et c’est là que le client note les dérives par rapport à ses souhaits et demande des rectification, dont beaucoup seront visuelles.
Pour éviter les gros problèmes, une solution est effectivement que le designer ait bien conscience du monde de l’intégration, et que le développeur ait des notions de design.
Une autre solution est de faire du développement agile : le développeur intègre les fonctionalités dans le site en même temps que le design se précise, le produit est immédiatement montré au client qui peut suivre son évolution et préciser ses désirs, et on procède par itérations. L’avantage est d’être toujours impliqué dans le domaine de la contre-partie, tout en pouvant se focaliser entièrement sur sa spécialité.
Bien évidemment, pour moi il serait primordial pour tous webdesigner de ne pas se limiter au seul univers de logiciels d’imagerie. Mais bon, la pluspart (70%) finir par en apprendre au moins le xhtml/css.Aussi, ca dépends de la méthode d’apprentissage ! Un autodidacte designer aura bien plus de mal de se mettre au code que celui passé par une école car ce dernier lui à un passage obligatoire à tous les stades de developpement web et après se spécialise.Très bel article mister !
Effectivement il pourrait être très intéressent (et salutaire pour tous) de travailler main dans la main entre designer et développeur, mais pour ce faire il faut que l’on puisse parler le même langage (du moins se comprendre) et c’est un peu ce que je voulais exprimer dans l’article.
Également ce que tu montre du doigt par rapport au souhait initial du client est assez vrai je pense, à condition d’exclure une partie des clients (qui change d’avis au fur et à mesure que l’on leur montre l’avancée du projet). Après reste à savoir si c’est au designer et/ou développeur d’arriver à limiter le client dans ses changements de dernière minute ou s’il faut se contenter de lui présenter le produit fini, la question reste entière. Encore que pour la seconde solution, mieux vaut rester le plus fidèle possible aux souhaits exprimés par le client lors de la création du cahier des charges, afin d’éviter de se retrouver à devoir refaire tout le site
.
Finalement le plus dur serait presque d’arriver à former un couple fonctionnel designer/développeur où chacun puisse écouter et entendre l’avis de l’autre afin de monter le projet à 4 mains (ou plus).
@kac : Je ne suis pas complètement d’accord. Certes les écoles forment leurs étudiants en leur proposant un panel assez large, maintenant à vouloir tout faire en même temps, j’en viens à me demander si l’on ne survole pas trop les choses, ce qui de mon point de vue, ne laisse pas le temps aux étudiants de clairement aperçevoir les avantages et inconvéniants de chaque dicipline, et du coup chacun se dirige vers celle avec laquelle il a le plus d’affinité en délaissant totalement les autres.
C’est un peu ce qu’y m’est arrivé lorsque j’étais en cours. Nous avons eu des cours de Design( Photoshop, Illustrator, …) puis flash, le HTML (pas de CSS à l’époque), Algorithmique, JavaScript, PHP, … Mais tout ça dans la même année (je parle pour les langages de programmation). Du coup personnellement j’ai complètement délaissé le PHP pour m’axer sur le HTML et le flash.
) j’ai commencé à me pencher sur le PHP et aujourd’hui j’aime me plonger dedans pour chercher comme faire telle ou telle chose, savoir pourquoi la fonction A est plus adaptée que la fonction B, etc, etc, …
Et quelques années plus tard (2 ans seulement
Ce que je veux dire c’est qu’un autodidacte aujourd’hui, avec le développement d’internet à quasiment autant de chance d’être performant qu’une personne ayant suivit un cursu complet. Il est vrai que l’on peut tomber sur un prof génial, amoureux de sa discipline et qui saura transmettre ça à ses élèves…
Mais une personne passionnée ira d’elle-même passer ses nuits à parfaire ses connaissances.
Je crois que les métiers du design et du développement nécessite une constante remise en question car ce sont des secteurs en constantes évolutions (regardez l’essort de l’AJAX par exemple ou la rapidité avec laquelle les tendances du design changent). Du coup même une personne sortie d’école doit se « transformer » en autodidacte pour continuer évoluer et suivre le mouvement.
@oelmekki : Comme tu l’as deviné c’est ton post qui m’a querlque peu inspiré l’article. Pour autant j’ai bien compris que tu n’est pas « anti-designer ». Et je t’en félicite !
)
La réponse est oui oui oui. Je suis Webdesigner et j’ai vraiment compris mon métier quand j’ai appris les bases du développement. Avant , bonjour les maquette impossible à intégrer.Attention cependant quand l’on créé il faut débrancher le fil « développement » sinon on ne fait que du site carré
Tu soulève une erreur importante que fond bon nombre de designers dès lors qu’ils commence à intégrer des notions de programmation (du moins ce fut mon cas également) : on veux tellement « coller » au développement qu’on en produit des design trop « carrés ».
Mais bon une fois les premières fois passées ça rentre dans l’ordre je pense.
Hum. Je me sens comme un enfant qui découvre la neige.À ces deux commentaires, je réalise que chaque fois que je m’essaie à faire un design, je raisonne *toujours* à base de blocs, et je commence par tracer des carrés et rectangle pour me contenter ensuite d’y mettre des dégradés ou des ombres…Décidément, je ne suis pas (encore) designer :]
Hé hé, courage l’ami ça ne viens en un jour ! (dit-il conscient qu’il a lui-même bien des progrès à faire).
tiens, à ce propos : http://www.alistapart.com/arti.....giledesign
Arrrgh, tu met à contribution ma pauvre (très pauvre, trop pauvre) maîtrise de l’anglais….
Bon j’ai lu l’article qui m’a l’air très intéressent. J’avoue que je ne connaissais pas du tout donc je vais relire bien au calme l’article (histoire de combler mes incompréhensions
) et je vais aussi regarder les articles en liens (comme la page Wikipédia) car ça m’a l’air d’assez bien correspondre à mon approche du métier ou du moins à l’idée qeu je m’en fait …
J’ai beaucoup aimé :
« Regardless of the label, it’s time for the Agile and design communities to agree on our common future. We need each other, but also need to dismount from our high horses and jump from our ivory towers. After all, we have the same goal: giving our clients and users the best we can.«
Merci pour le lien !
Si tu en as d’autres dans le style n’hésite pas
En fait, la notion de développement agile, bien qu’ancienne, a été remise au goût du jour et a acquis sa popularité d’aujourd’hui par l’intermédiaire de ruby on rails, et notamment par l’un des premiers ouvrages à avoir traité rails : agile web developement with ruby on rails.De ce fait, c’est encore très lié au développement, bien que ça fait plusieurs fois que j’en entend parler dans le cadre du design. Maintenant que c’est apparu sur ALA, ça risque bien de devenir moins rare.Une lecture intéressante peut-être le bouquin (lisible en ligne) de 37signals. Cette boite est celle où bosse David Heinemeier Hansson, le créateur initial de ruby on rails.Si je te parle de ce livre, c’est qu’il s’appelle… « Getting real ». Le titre de l’article de ALA prend alors tout son sens
Ce livre traite du processus agile en général, sans uniquement se focaliser sur le développement. On peut même dire, à mon avis, qu’il traite plus de fonctionnement d’entreprise que du produit même.Voici le lien : http://gettingreal.37signals.com/toc.php
Merci merci, j’irais voir tous ses liens qui m’intéresse fortement, mais je suis d’accord avec toi, ça relève presque plus d’une méthode de penser et d’appréhender son travail que le seul monde du développement et du design.
La première mise en application a peut-être était faite dans le monde du développement mais le concept est tout à fait applicable à tout type de travail en équipe si j’ai bien compris l’article sur ALA.
En temps que graphiste, je me suis essayé au codage (tout d’abord lors de ma principale formation, ensuite d’autre formations non officielles, et enfin pour ma satisfaction personnelle). Rien à faire, je suis profondément ancré dans l’esthétique et la création purement artistique, et tout ce qui touche au code me décourage très vite, bien que je trouve ça très intéressant. Tant que ça ne dépasse pas le niveau du terminal sous Linux, ça va. Ensuite ça coince.Les graphistes qui arrivent à allier le talent artistique à la connaissance et la maitrise du codage sont extrêmement peu nombreux, et ceux-là n’ont en général pas trop de problème pour travailler en indépendant. Une qualité indéniable que eux seuls ont parfois du mal à se rendre compte de la valeur tellement ça leur parait naturel (toi par exemple). Un graphiste purement designer et non codeur se retrouve vite dépassé en indé et ne peut généralement pas suivre le marché dans la voie de l’infographie pure et dure (j’entends par là la création et le développement de site web) et doit alors s’allier avec un codeur, ou bien éllargir ses offres pour subvenir à ses besoins, en faisant de la photo ou de la peinture par exemple.En ce qui concerne les codeurs purs et durs, j’ai eu la « chance » d’en voir plusieurs créer un site de A à Z. C’est en général très complet et bigrement bien pensé, mais aussi très violent pour les yeux (d’ou le « chance » placé entre guillemets)!Donc pour résumer, un codeur devrait se contenter de coder, un graphiste de créer la partie esthétique, et pour ceux qui allient les deux, je les maudit de ne pas avoir leur talent
Pour ma part je ne suis pas freelance (en tout cas pas actuellement), mais c’est vrai que je suis assez content de ne pas avoir trop de mal à faire les 2 parties (graphisme et programmation). Après je serai bien incapable de dire si je suis suffisamment bon dans l’un ou l’autre des domaines.
En fait pour moi c’est assez « naturel » de faire les 2, je veux dire que c’est un tout en fait. Mais c’est vrai que c’est loin d’être facile car du coup les 2 facettes rentrent en conflit parfois (si j’ai trop privilégié un aspect je dois réajuster l’autre en conséquence, etc…).
C’est aussi un choix que j’ai fait durant mes études lorsque j’ai pris conscience que c’était un corps de métier où il fallait être le plus polyvalent possible (ça laisse plus de perspectives aussi dans les postes visés), et puis j’ai besoin d’être en constant renouvellement, de ne pas avoir l’impression de faire toujours la même chose (je n’aurais pas pu faire que du print par exemple). Dans mon précédent poste je faisait même de la 3D aussi. Mais là j’avoue que c’est une discipline qui demande beaucoup de travail à elle seule et du coup laisse trop peu de place aux autres pour moi…
Après quelque part ce n’est peut-être pas plus mal de travailler à 2 (un graphiste et un codeur) car l’échange d’idées peut être bénéfique (et puis ça fait bosser 2 personnes donc c’est « sociale »
) . De plus, plus on est spécialisé dans son domaine, et plus on y est performant (à priori). Maintenant ça demande de trouver le « compagnon » avec qui le courant passe pour pouvoir travailler de concert (pas toujours évident).
P.S. : pour moi tu as ton propre talent -> je suis carrément fan de ton site !
Désolé de revenir si tard mais la fin d’année est assez chargée…
Bref, Olivier j’ai commencé à lire tous les liens que tu m’as donné plus d’autres que j’ai trouvé e français (oui des fois j’ai la flemme de faire des efforts
).
A première vue le concept du développement Agile me semble très intéressent et j’avoue qu’il me semble assez « naturel » (du moins sur certains points).
En revanche il y a un point qui peux poser problème je pense : l’implication du client.
Sans vouloir médire ou paraître pessimiste, et même si je ne développe pas vraiment de systèmes très gros (quoique des fois…), il est assez rare que les clients se sentent suffisamment impliquées pour qu’un système agile puisse réellement être mis en place.
Souvent le client a une idée assez flou de ce qu’il veux, et naturellement le développeur doit « dégrossir » ça puisqu’il est le seul à avoir une vision technique des choses. Puis au fil des étapes de contrôle, le client fait faire des changements qu’il désir car son idée se précise au fur et à mesure qu’il voit la solution évoluer.
Malheureusement il arrive que le client « saute » quelques étapes de contrôle car occuper à des tâches plus importantes. Oui seulement le développement ne peut pas se mettre en standby car sinon les délais ne seraient pas respectés. Et ce genre de situation peut parfois déboucher sur un désastre car suite à une incompréhension et à la négligence des contrôles réguliers, la solution à l’arrivée peut ne plus correspondre à ce qu’attendait le client. Du coup une grosse partie du travail devra être refaite…
Tout ça pour dire que le principe du développement agile reprose sur l’engagement du client (entre autres choses bien entendu) et ne peut donc donner un résultat satisfaisant que si les deux parties sont pleinement conscientes que leur engagement est primordiale au bon déroulement des choses.
Désolé de revenir si tard mais la fin d’année est assez chargée…
Pas de problème, c’est pareil pour moi (et pas que pour nous j’imagine)
il est assez rare que les clients se sentent suffisamment impliquées pour qu’un système agile puisse réellement être mis en place.
Note quand même que ce n’est pas purement de la théorie, ce type de fonctionnement sont déjà mis en place
En fait, le plus important à saisir dans le développement agile, à mon avis, c’est le concept d’itération. Lorsqu’on dit que tout le monde travaille en même temps, c’est en fait un abus. Il s’agit plutôt de faire passer le processus de développement d’un bloc à plusieurs blocs. Les designers proposent un design, les développeurs développent les fonctions directement nécessaires, puis le client regarde et dit ce qu’il en pense à ce moment, et on recommence. De nombreuses fois. Cela permet de rectifier le tir très vite si les désirs du client ne correspondent pas à la réalité (ou ne sont pas réalisable, ou encore, sont mal exprimés). Ainsi, le client n’a pas a venir voir le site tous les jours. Une fois par semaine suffit. J’ai déjà mis en application ce type de fonctionnement, et c’est assez efficace, parce qu’on se rend compte que ce qu’on juge important et que ce que le client juge important ne sont pas la même chose.
Souvent le client a une idée assez flou de ce qu’il veux, et naturellement le développeur doit “dégrossir” ça puisqu’il est le seul à avoir une vision technique des choses. Puis au fil des étapes de contrôle, le client fait faire des changements qu’il désir car son idée se précise au fur et à mesure qu’il voit la solution évoluer.
Une des variantes les plus utilisées, le behaviour driven development implique même de limiter au maximum les instructions fournies par le client à la base. Il ne s’agit pas de faire faire un gros cahier des charges, mais de faire écrire au client des histoires qui révèlent explicitement comment il veut que l’application se comporte.
Oui, c’est précisément ainsi que se déroule le développement agile
1°) Paul s’enregistre, se log, écrit un article et le post.
2°) Pierre du groupe adhérent peut voir les articles qui lui sont réservés.
3°) Jacques, administrateur, se log pour valider un article et peut le voir en tant que simple viisteur une fois déloggé.
Certains frameworks de tests permettent même d’écrire directement ces histoires en anglais (avec, nécessairement, quelques contraintes syntaxiques) et de les exécuter, pour s »assurer que l’application fonctionne correctement. (je pense en fait à cucumber).
Malheureusement il arrive que le client “saute” quelques étapes de contrôle car occuper à des tâches plus importantes. Oui seulement le développement ne peut pas se mettre en standby car sinon les délais ne seraient pas respectés.
Oui, je suis d’accord avec toi, c’est clairement le gros défaut du développement agile. Il faut au moins que le client puisse y accorder un heure dans la semaine pour venir. Il s’agit cependant d’une opportunité qui lui est offerte. S’il n’en veut pas, tant pis, le développement s’effectuera, à ses yeux, selon une procédure normale. Je ne pense pas, néanmoins, que le développement soit bloqué : les développeurs et les designers savent à peu prêt où ils doivent aller, le résultat final sera juste plus proche de leurs choix que de ceux du client (qui ne manquera pas de toutes façons de signaler son opinion lors de la validation finale).
Et ce genre de situation peut parfois déboucher sur un désastre car suite à une incompréhension et à la négligence des contrôles réguliers, la solution à l’arrivée peut ne plus correspondre à ce qu’attendait le client. Du coup une grosse partie du travail devra être refaite…
C’est justement ce problème que vient palier le développement agile
Ce cas est celui qui arrive couramment lorsqu’on procède sans itérations et sans investissement du client. Si le client ne joue pas le jeu du développement agile, c’est effectivement ce qui se produira, mais ce n’est pas là une faiblesse du développement agile : c’est une faiblesse du développement classique en un bloc.
Tout ça pour dire que le principe du développement agile reprose sur l’engagement du client (entre autres choses bien entendu) et ne peut donc donner un résultat satisfaisant que si les deux parties sont pleinement conscientes que leur engagement est primordiale au bon déroulement des choses.
Oui, tout à fait d’accord, à condition qu’on reconnaisse que du développement agile sans participation de l’une des partie est du développement classique
Néanmoins, même si l’implication du client échoue, le processus par itération aura quand même permis que les designers et les développeurs travaillent ensemble, ce qui empêche qu’un développeur soit obligé de faire du mauvais design pour compléter des manquements imprévus.
C’est vrai que mes exemples correspondent surtout à des développements de « petite » envergure et c’est principalement de ce cas où le client se sent relativement peu concerné je pense (du moins c’est ce que j’ai déjà vécu).
Quand au fait de demander au client de raconter une « histoire » pour qu’ensuite le développeur en fasse un cahier des charges, en fait c’est exactement comme ça que j’essaie de travailler !
Je dit aux gens :
- « Allez-y racontez-moi juste comment vous vivriez l’utilisation du système et je verrai ce que cela implique au niveau technique ».
Après tout ce n’est pas au client de concevoir la base de données et les interactions entre les différentes composantes du système.
Mais malgré mon petit reproche il n’en reste pas moins que je trouve l’idée vraiment intéressante et importante aussi. En fait j’ai même du mal à concevoir qu’un projet d’envergure puisse se gérer différemment. Ce serait perdre beaucoup de temps que de fonctionner autrement. Néanmoins cela semble demander une réelle capacité de coordination et d’entente entre les équipes.
Pour ma part jusqu’à présent j’ai quasiment toujours travaillé seul sur les différents projets que j’ai due mené donc même si je met en pratiques certaines composantes du développement agile, je suis loin de l’avoir réellement exploré (un jour sûrement
).
Intéressant, il faut croire (et ce n’est pas si surprenant que ça finalement) que les usages précèdent les modes
Je dis ça parce que plusieurs fois, alors que je discutais avec Bouctoubou, je l’ai entendu tenir des propos qu’on aurait pu croire directement sortis de la bouche des tenants anglosaxons du dév agile alors qu’il ne les connaissait pas (et en particulier les propos de dhh).
Oui, il y a quelque chose d’évident là-dedans, le gros problème, et pour en revenir au point qui m’avait fait introduire le dév agile, c’est que ce n’est pas toujours pratiqué, notamment lorsqu’un développement est réalisé « chacun son tour » : d’abord le design, ensuite le développement et enfin le consentement du client, en signifiant que tout retour en arrière est un contretemps.
Pour les user stories, je ne sais pas si tu es de ceux que ça rassure de voir que ce qu’ils font a un nom (c’est une tendance que j’ai personnellement), mais c’est le principe même du behaviour driven developement
Je t’avoue ne pas avoir pensé aux « petits projets ». C’est sûr que ce type de développement s’applique plus aux grosses applications, développées sur plusieurs semaines. Si le temps accordé en total est de 5 jours, on ne va clairement pas demander au client de venir tous les jours, voir plusieurs fois pas jours… Je doute, cependant, qu’il y ait besoin de quelqu’un d’autre, sur ce type de projet, que d’un designer/intégrateur, le problème du travail en équipe s’en trouve résolu de lui-même :]
Quant à l’exploration, j’ai envie de dire : elle est encore à faire pour tous
. Cela passe aujourd’hui principalement par l’utilisation de frameworks pour développer très vite (les plus « à-la-pointe » étant ruby on rails et symfony). L’implication des tests dans l’agile developement est assez récente, et cucumber, dont je viens de te parler, n’a pas une renommée internationales plus vieille que quelques mois. Dans l’article de ALA concernant l’application du développement agile au design, l’auteur insiste sur le fait que la réalisation rapide et directement associée à la volonté du client est un must en période de crise économique (ce qui confère une allure franchement actuelle). Bref, le développement agile n’est qu’une impulsion face des réalités actuelles qui prennent nécessairement l’allure d’évidences à l’instant T d’une suite d’événements.
Si tu me permets de me projetter dans des perspectives à venir, je dirais que je crois personnellement en un phase de ce type de développement où les frameworks fusionnent avec les CMS. Alors que je détestais avec (trop) de passion les CMS il y a quelques mois, Bouctoubou m’a fait découvrir Typolight, auquel il manque peu de chose pour servir de framework.
Le gros problème des frameworks, c’est qu’ils sont impropres à réaliser des sites avec quelques pages statiques + une ou deux fonctions dynamiques. Le gros problème des CMS, c’est qu’ils deviennent vite plus un poids qu’un atout quand il faut faire des fonctionalités particulièrement custom.
Dans le cadre du développement agile, j’ai l’intime conviction qu’un CMS permettant une utilisation de type framework offre la possibilité de réaliser tout type de site, avec un réactivité forte autant de la part des développeurs que de la part des designers face aux requêtes des clients.
C’est ma propre conception de l’avenir du développement agile, juste pour te dire que oui, à mon avis, il y a beaucoup à explorer
Entièrement d’accord !
Je te rejoins sur les CMS qui, et j’en parle en connaissance de cause car je ne m’y étais pas du tout intéressé avant de lancer le blog, sont à mon sens extrêmement flexibles pour un designer. En tout pour moi qui connais le PHP, Wordpress est vraiment bien foutu au niveau des thèmes (même si certaines choses restent encore à améliorer). Et du coup développer un nouveau thème (et donc un nouveau design, ne prend que quelques jours (voir moins suivant la compléxité de la chose).
Pour ce qui est de Typolight je ne peux pas trop en parler car je ne l’ai vu que de très loin (quelques captures sur le site mais sans faire d’installation de test).
Ensuite les frameworks… J’ai regardé un peu ce que c’était (Ruby on rails) suite à ton premier commentaire et je ne sais pas si j’étais pas dedans ou autre mais j’ai trouvé ça, au premier abord, un peu compliqué. Je veux dire que ça viens rajouter une nouvelle syntaxe supplémentaire dans le processus de développement et je trouve ça dommage.
Du coup la fusion entre frameworks et CMS dque tu évoque me séduit assez et je pense que ça va finir comme ça (après totu il y a déjà des thèmes orientés Portfolio sur Wp par exemple, ce qui est déjà un « détournement » du système).
Par exmple lorsque je suis passé du design sous Photoshop à la création du nouveau thème via les CSS pour le nouveau design du blog, j’ai découvert un plugin pour Wp qui permet de créer son propre widget pour la sidebar en y intégrent litérallement son prore code PHP.
Donc ne reste plus qu’à développer le même type de plugin qui permet d’intégrer des fonctionnements supplémentaires au blog et nous voilà encore un peu plus prêt d’un outil regroupant CMS et Framework.
P.S. : Oui je fait partie de ceux qui sont rassurés que leurs pratiques porte un nom
Même si ça va un peu l’encontre de ma tendance à être très fier de ne pas faire comme tout le monde 8/
je ne sais pas si j’étais pas dedans ou autre mais j’ai trouvé ça, au premier abord, un peu compliqué.
Non, c’est tout à fait normal
L’apprentissage de Ruby on Rails est difficile, quoi que les fanatiques puissent en dire. Le but n’est pas tant de permettre à quelqu’un qui utiliserait une première fois l’outil de développer rapidement que de permettre à qui le maîtrise de battre tous les records de vitesse.
Cela est d’autant plus vrai que ruby on rails utilise le langage ruby qui, bien que très populaire, est loin d’être le plus répandu. Cela dit, même en le connaissant, il y a des surprises. Je faisais du ruby depuis quelques années avant de débuter avec ruby on rails et j’ai vraiment eu l’impression, dans les premiers temps, de me retrouver face à un langage inconnu.
Cette difficulté d’apprentissage et cet aspect d’étrange particularité viennent en fait de ce qui fait le point fort de rails et de symfony, et qui les distingue d’autres frameworks comme code igniter ou cakePHP : convention over configuration. J’ai tendance à considérer que l’informatique est finalement plus une histoire de conventions qu’une histoire de logique, mais cela prend tout son sens dans ces frameworks qui érigent cela en principe fondamental.
Cela signifie que le framework fonctionne sur un vaste ensemble de choix par défaut et de règles conventionnelles, le grand tour de force ayant été de trouver les choix par défaut qui seront les meilleurs dans la plupart des cas. Cela signifie concrêtement qu’il faut connaître ces conventions, faute de quoi l’utilisation du framework devient vite un enfer ( « wtf? mais pourquoi il fait ça? » )
C’est à mon avis en ce point que les frameworks rejoignent les CMS : proposer des solutions qui permettent de réaliser extrêmement vite les tâches les plus courantes. La différence majeure étant qu’il devient vite difficile d’intégrer une fonctionalité non courante avec un CMS alors que c’est simple avec le framework, une fois qu’on le maîtrise. Une autre différence est que le CMS permet de fournir une batterie d’outils pour l’utilisateur final, alors que le framework n’aide que le développeur, et que tout est à construire pour l’utilisateur final.
En résumé, framework et CMS ont l’immense avantage d’accélérer considérablement la création d’une partie de l’application, mais pas l’autre. D’où le besoin d’une fusion
Mais oui, il y a une distinction claire à faire entre la vitesse de prise en main et la vitesse de développement une fois l’outil pris en main…
Donc on en reviens bien à ce que tu disais : il faut fusionner les deux système.
Mais pas trop quand même sinon on aura bientôt plus de boulot nous si tout le monde peut faire son site tout seul sans rien connaître
(même si on en est encore très loin fort heureusement)
Tiens, je viens de tomber là dessus : certains ont une conception radicale de l’implication du client dans le cadre du développement agile :]
Ah ah, tu m’a eu là !
La solution a ce problème du Développeur VS Designer existe, ca s’appelle les systèmes de templates. Si vous ne savez pas ce qu’est un système/moteur de templates, voir par exemple l’introduction de : http://genova.developpez.com/a.....ate_phpbb/
Personnellement j’utilise l’excellent moteur de template TinyButStrong, à voir :
http://www.tinybutstrong.com/fr/template.php
Les systèmes de template de 3ème génération : http://www.tinybutstrong.com/article_3rd_kind.html
En très gros, un moteur de template va séparer le CODE (php, mysql, …) de la PRESENTATION (html/css). Cela permet de bien segmenter les calculs de l’affichage, et d’avoir deux travails bien distincts :
-celui qui fait les traitements (requêtes bdd, calculs, enregistrements, détermination des données à afficher)
-celui qui fait l’affichage, à savoir la présentation (disposition, ordre, esthétique, couleurs…)
Les moteurs de templates ont d’autres avantages du fait de cette judicieuse séparation, et ils ont tous leur spécificités… Je vous laisse découvrir ces avantages de vous même.
Le seul inconvénient à l’utilisation d’un système de template est l’introduction d’un nouveau langage : le langage du moteur de template qui va permettre de fusionner données obtenues par les traitements avec les données de présentation (html). Cela dit, ce langage est relativement simple à appréhender quelque soit les moteurs de templates, et consiste en principalement 2 choses :
-affichage d’une variable
-fusion d’un block (boucle sur un ensemble de données)
Dernière chose pour essayer de vous faire comprendre la chose :
-Si par exemple la page web sur laquelle vous travaillez comporte un block de texte en haut et un block de texte en bas
-et que vous souhaitez inversez la position de ces deux blocks
(Sans utiliser une technique de positionnement css ! C’est à dire que dans la code source de la page html, il y’aura bien un inversement des blocks)
-et bien seul le template (ou « modèle » en fr) sera édité, par le designer
Le code php générateur de la page n’aura pas été modifié pour cette manipulation !
Vous allé me dire : oui mais bon le designer doit quand même connaître HTML.
A mon sens un designer doit quand m connaître html, mais je peux vous prouvez que cela n’est pas nécessaire !!
Avec les systèmes de template de 3ème génération comme TinyButStrong (cf lien plus haut),
Le designer peut se permettre de travailler dans un navigateur web ou autre wysiwyg (dreamweaver typiquement) et voir le résultat directement, sans avoir à appeler la page (php) qui s’occupe des traitements !
Yeah
Merci pour toutes ces informations.
Pour ma part je connaissais les moteurs de templates.
Maintenant je me rend compte que je me suis mal exprimé (même le titre de l’article est trompeur à vrai dire et j’en suis désolé). Car en fait mon propos était bien plus large que le développement (PHP ou autres langages côté serveur).
En fait le « designer » que j’évoque au tout début de l’article serait plus une personne ne souhaitant pas ’sortir’ de Photoshop (si tu vois ce que je veux dire) : il se contente de faire un design sans se soucier du reste (HTML, CSS et autres joyeusetés du web).
Du coups même s’il existe plusieurs méthodes pour séparer le code du design, cela ne résoudra pas pour autant le problème si le designer de souhaite que réaliser l’aspect créatif et rien d’autre (pas même sa mise en pratique (découpage/CSS,…).
@Titi
Tout à fait. C’est vrai que je ne l’ai pas clairement explicité en parlant du dév agile, mais dév agile et framework MVC vont toujours de pair. Ça n’a rien de nécessaire en soi, c’est juste que « c’est comme ça que ça se fait », un peu comme dans le cas de l’ajax et des framewoks js : on peut faire de l’ajax sans, mais la plupart des dévs utilisent jquery, mootools ou prototype pour faire de l’ajax, parce que « ça va de soi » (comprendre: c’est bougrement plus simple, parce que pensé pour).
Tu as raison sur ce point : il est clairement inimaginable de faire du dév agile (dont on parlait pour répondre au problème de l’ordre du traitement des tâches dans la conception d’une application web et de qui doit les accomplir) avec un style de code « à l’ancienne », plaçant toute la logique et le html dans le même fichier (ne serait-ce que pour éviter les conflits de versions sur les fichiers). C’est précisément ce problème que règlent les framework s MVC (model, view, controller) en distinguant les modèles (qui traitent les données), les contrôleurs (qui traitent les requêtes) et les vues (qui représentent les templates).
@explain-me
J’imagine que dans le cas de ce genre de designer, il est absolument nécessaire qu’il travaille de pair avec un intégrateur
. Mais je reste d’accord avec toi : il est indispensable d’avoir les bases des autres domaines.
Une petite citation de Jay Fields là dessus :
»The truth is, if you focus on one technology you’ll never be as good as your teammates who have more experience mixing technologies to produce the best solution ».
À noter qu’il parlait du fait d’apprendre plusieurs langages, dans le cadre du développement, et non d’apprendre aussi à faire du design pour un développeur et de développer pour un designer, mais je ne pense pas trahir sa pensée en l’appliquant ici. À noter aussi qu’il revient dans un article suivant pour dire qu’il ne fallait surtout pas comprendre qu’il préférait les « généralistes », mais juste qu’il estime qu’un spécialiste doit avoir des notions dans les autres domaines.
Pour ceux que le sujet intéresse, je suis tombé sur cet article la semaine dernière :
http://www.webdesignerdepot.co.....ould-code/
Comme quoi nous ne sommes pas les seuls à penser ça !
J’aime particulièrement la phrase :
The more you know about the medium you work in, the better you work in that medium.
J’ai un gros doute sur le fait qu’un designer codant devient meilleurs en SEO, mais je suis assez d’accord avec le reste
Il y a un autre point qu’on pourrait rajouter : un designer avec des bases en développement est plus à l’aise lorsqu’il s’agit de rajouter des effets et de la logique en js et ne se contente pas de copier/coller.
Moi je suis assez d’accord avec lui sur le SEO, mais en gardant une certaine mesure cependant.
Je crois effectivement qu’un designer qui connais l’attribut title de la balise a ou la balise alt de la balise img sera, de fait, plus performant en référencement qu’un designer qui s’en prive.
Cela dit ça ne concerne que le référencement dit « naturel » et pas le référencement plus pointu.
Pour le JS je te rejoint aussi puisque pour ma part j’ai beaucoup de mal à appliquer un effet sans comprendre un minimum ce que fait le code. Mais lors de l’utilisation d’un framework comme jQuery, inutile de savoir en quoi consiste les routines internes à la bibliothèque, il suffit de coomprendre les méthodes.
Oui tout à fait, je ne recommanderais pas à un designer de lire le code de jQuery avant de s’en servir
(bien que pour celui qui veut apprendre en profondeur javascript, il fait partie des meilleures lectures qui nous sont offertes).
Je pensais plus aux formes communes à la plupart des langages, comme les branchements conditionnels ou les boucles.
Un designer qui voudra faire apparaître et disparaitre un le block #image lorsqu’on clique sur un lien #toggle aura vite fait de comprendre qu’il faut mettre $(’#toggle’).click(function(){ $(’#image’ ).fadeIn(); return false; });
Puis ensuite, il se dira : « ah oui, mais je ne veux le faire apparaitre que si l’option «montrer les images» est cochée » (hum, pas terrible comme exemple, j’ai pas trouvé mieux sur le coup
). Il faudra donc qu’il introduise une structure « if », ce qui est relativement basique mais peut donner des maux de crânes si on n’a jamais abordé aucun langage.
Avec quelques bases en développement, le designer peut rapidement rajouter une couche à la fois propre et efficace dans ce domaine dont on ne sait pas trop s’il relève du design ou du développement (c’est du moins l’impression que j’en ai).
Eh bien c’est exactement le but que je me suis fixé concernant le cours sur l’algorithmique (prévu depuis un moment mais pas encore prêt) :
Rendre accessibles au plus grand nombre tous ces if, for, while,…
Maintenant on verra si j’y parviens…
Pour ce qui est de jQuery, je n’ai encore regardé dans ses entrailles (j’avoue de le JS n’est pas le langage que j’aborde le plus facilement). Mais déjà je trouve que sa simplicité d’utilisation, de par sa syntaxe relativement « naturelle », le place bien au-dessus des autres framework que j’ai pu testé (ajax, prototype,…). Du moins c’est mon opinion.
P.S. : moi je le trouve pas mal ton exemple
Excellent article en rapport à consulter:
- http://www.webdesignerdepot.co.....ould-code/
Oui en effet, mais à vrai dire j’avais déjà posté le lien un peu plus haut dans les commentaires.