dimanche 3 février 2008 à 23h15
Connaissez-vous cette vidéo de très bonne qualité d'une démo extra présentant certaines fonctionnalités de Thermo, le nouvel outil préparé par Adobe destiné aux développeurs / designers ? Si non je vous invite à aller la visionner au plus vite ; elle donne un premier aperçu très intéressant du fonctionnement de l'outil.
On parle de double compétence, de profil designer / développeur, mais du coup comment appréhender ce nouveau profil pour des outils comme Thermo ou même la suite Expression ? Les deux profils peuvent tenter de se rapprocher, rencontrant toutefois certaines limites.
Le designer a une certaine "capacité créative" qui permettra de créer les éléments graphiques de l'interface aussi simplement que sous les autres applications que sont Expression Design ou Flash. Mais il lui est peut-être difficile d'appréhender la logique d'événements, prendre en compte certaines contraintes comme l'optimisation, la fluidité d'animation, la modularité de son application, etc.
Le développeur cherchera lui à trouver les images et graphiques associés à son application : sa vue sera toutefois très limité de part son approche différente et certainement trop technique. Bien évidemment il saura décrire son besoin maispourra-t-il le créer, et l'exprimer correctement ?
Comment arriver à ce nouveau profil qui reliera ces deux profils, en permettant de relier les besoins des technologies et la créativité ? Tout simplement en essayant de sensibiliser des designers aux contraintes techniques, et en sensibilisant les développeurs à l'intégration et la réutilisation de composants déjà créé par une chaîne. Quel serait donc le profil souhaité pour cet utilisateur deThermo, ce collaborateur idéal aussi à l'aise pour coder le fonctionnement d'une application que lui fournir une apparence ?
Tout simplement quelqu'un qui saura reprendre des éléments graphiques, qu'il aura pu auparavant décrire ou même créé lui-même, puis en les intégrer viaThermo et ainsi y définir les comportements associés (quelle vue pour quel état, quel événement pour quelle action, etc.). Ce profil faisantdonc le lien entre les développeurs et les designers :
En arrivant à réunir des qualités de communication, d'expression de besoins mais également une base technique et créative, le designer / développeur pourra mettre en relation ces deux mondes et en retirer le meilleur. La technologie (dontThermo fait partie) pourra-t-elle permettre l'éclosion de ce nouveau type de profil ?
On parle de double compétence, de profil designer / développeur, mais du coup comment appréhender ce nouveau profil pour des outils comme Thermo ou même la suite Expression ? Les deux profils peuvent tenter de se rapprocher, rencontrant toutefois certaines limites.
Le designer a une certaine "capacité créative" qui permettra de créer les éléments graphiques de l'interface aussi simplement que sous les autres applications que sont Expression Design ou Flash. Mais il lui est peut-être difficile d'appréhender la logique d'événements, prendre en compte certaines contraintes comme l'optimisation, la fluidité d'animation, la modularité de son application, etc.
Le développeur cherchera lui à trouver les images et graphiques associés à son application : sa vue sera toutefois très limité de part son approche différente et certainement trop technique. Bien évidemment il saura décrire son besoin maispourra-t-il le créer, et l'exprimer correctement ?
Comment arriver à ce nouveau profil qui reliera ces deux profils, en permettant de relier les besoins des technologies et la créativité ? Tout simplement en essayant de sensibiliser des designers aux contraintes techniques, et en sensibilisant les développeurs à l'intégration et la réutilisation de composants déjà créé par une chaîne. Quel serait donc le profil souhaité pour cet utilisateur deThermo, ce collaborateur idéal aussi à l'aise pour coder le fonctionnement d'une application que lui fournir une apparence ?
Tout simplement quelqu'un qui saura reprendre des éléments graphiques, qu'il aura pu auparavant décrire ou même créé lui-même, puis en les intégrer viaThermo et ainsi y définir les comportements associés (quelle vue pour quel état, quel événement pour quelle action, etc.). Ce profil faisantdonc le lien entre les développeurs et les designers :
- il comprendra les contraintes et souhaits techniques des développeurs
- il pourra décrire et expliquer ces contraintes aux designers
- il comprendra les mécanismes d'utilisation et d'ergonomie souhaité par l'équipe de designers et saura les implémenter
En arrivant à réunir des qualités de communication, d'expression de besoins mais également une base technique et créative, le designer / développeur pourra mettre en relation ces deux mondes et en retirer le meilleur. La technologie (dontThermo fait partie) pourra-t-elle permettre l'éclosion de ce nouveau type de profil ?
Commentaires
1 . Le lundi 4 février 2008 à 00h09, par neolao
Tu penses vraiment que Adobe a présenté Thermo comme un logiciel qui fera le produit final ?
Moi je l'ai bien vu comme un outil de prototypage.
Mais même s'il était destiné au produit final, il ne s'occuperai que de n'ergonomie, les développeurs s'occupant des composants.
Ensuite, niveau optimisation, c'est le même cas que le designer web. En gros, le designer doit avoir des compétences d'intégrateur, mais pas forcément de développeur.
Le prototypage est une étape très importante qui permet de gagner beaucoup de temps parfois, quand on a pas la vision ultime.
2 . Le lundi 4 février 2008 à 14h56, par FabienD
Intéressant :)
Je ne pense pas que Thermo servira pour produire le produit final. Par contre, je doute franchement qu'il ne servira qu'à faire de l'ergonomie et du prototypage. Pour ça, il y a déjà Flash, Photoshop, etc.
Pour moi le but de Thermo c'est tout simplement :
- en entrée : des design de la CS3
- en sortie un composant Flex avec les comportements, les événements, etc.
Le but est que le Flexeur n'ai plus qu'à insérer son composant et hop, plus rien à faire.
Voilà, je pense qu'ainsi le designer / développeur va avoir un rôle important.
3 . Le lundi 4 février 2008 à 16h00, par neolao
Hmm, comment se fait un prototypage en Flash ? Ca se programme
Et sur photoshop, c'est des mockup
Design de la CS3 ? ben design tout court, on peut insérer les éléments graphique qu'on veut.
Faire un composant Flex ? ça je suis sûr que non.
Je vois plutôt thermo comme le flex builder du designer. Bien qu'étant graphique, Flex builder est quand même technique. Thermo pourrait supplanter flex builder peut-être.
Je doute comme toi qu'il ne serve QU'A du prototypage, ca serait trop peu.
Donc, ça pourrait faire le produit final comme le fait Flex Builder, à condition d'avoir des composants bien balèzes. Et ça, c'est le rôle du développeur.
Dans les vidéos, on a vu que ça faisait du flex derrière.
Le résultat de Thermo ne fera pas de composant de toute façon. Ca c'est certain, un composant ne se fait pas comme ça.
Moi je dis que thermo permet de donner beaucoup plus d'autonomie au designer, mais pas d'en faire un designer/developpeur.
Moins d'aller/retour entre le designer et le developpeur, juste pour mettre à jour une interactivité qui existe déjà, mais qu'il suffit d'activer. Dans ce genre là.
4 . Le lundi 4 février 2008 à 22h21, par Arnaud
Hello,
Si un nouveau profil de ce type apparait, je postule... mais j'en doute.
Je vois Thermo plutôt comme un outil qui facilitera :
- le recueil des besoins client ou la mise en place d'un proto par un chef de projet (donc pas forcément technique).
Avec un tel outil, il devient très facile de construire l'appli sous les yeux d'un client, presque sous sa dictée. Pas besoin de développeur sous la main et le résultat est immédiatement fonctionnel. Royal et un avantage concurrentiel.
- la compréhension / collaboration entre designer et développeur.
Mais elle a ses limites je pense avec ce genre d'outil. Car le designer qui a enfin la possibilité de voir rapidement un résultat fonctionnel aura tendance à pousser un peu loin son design voire empiéter sur le territoire du dév. Le développeur qui va récupérer le bébé aura une belle appli dont le code (apparemment uniquement en mxml) a été généré automatiquement... avec des règles qui ne lui conviennent peut-être pas et qu'il faudra tout d'abord modifier, refactoriser avant de pouvoir y implémenter les règles métiers ou autres classes de traitements. Bref pas très réjouissant pour un certain nombre d'entre eux mais à voir. Et à voir également si cela représente un gain de temps ou pas pour le développeur.
Dans ce cadre là, il y aura donc je pense un équilibre à trouver (designer -> mxml et développeur -> AS3 ? ensuite on connecte ?)
- le développement d'application par plus de novices dans mon genre.
Débutant en flex, j'adorerai avoir ça sous la main. Je pourrais dégrossir le développement pour créer un squelette mxml puis me lancer dans le coeur de l'appli en AS3, probablement sous Flex Builder car j'ai rien vu dans la vidéo qui laisse supposer qu'on puisse faire aussi de l'AS3.
Bref, ici, on est dans le cas d'un designer qui a des compétences en développement ou un développeur qui fait aussi du design (ce qui est à mon avis le cas de pas mal de développeur Flex/Flash) ?
5 . Le lundi 4 février 2008 à 23h57, par FabienD
Merci neolao et Arnaud de vos contributions. Pour revenir rapidement sur quelques points :
- Thermo et les composants
Je pense au contraire que Thermo est là pour créer des composants ! C'est pour moi son grand avantage. Au delà d'un simple bouton skinné exportable vers Flex (comme avec Flash CS3), il sera possible via Thermo de créer, imaginons, un cadre servant de fenêtre qui au clic sur un bouton, effectuera un effet de disparition. On peut créer ce composant avec Thermo et développer son comportement interne (via une certaine connaissance de développement AS3). C'est à mon avis là qu'il serait intéressant d'avoir ce designer / développeur : il saura se servir de cet outil pour créer des composants graphiques avancés qui seront réutilisables par les "dév purs".
- plutôt designer ou développeur ?
Au final je penche aussi pour une utilisation du designer : cela le rapprochera du développeur et il n'y aura plus ce "gap" entre les deux équipes quand il faut joindre les deux bouts. Un bon pas en avant (au vu de ma courte expérience). Si le designer a les bases techniques pour créer un vrai rapprochement, technique comme relationnel, entre ces deux mondes, le pari de Thermo (mais on peut aussi penser à Expression) sera gagné.
- vite et bien
C'est tellement évident que j'ai oublié d'en parler : n'importe qui (ou presque) pourra facilement créer des applications Flash/Flex via cet outil, sans devoir se plonger dans un outil "lourd" comme Flex Builder (basé sur Eclipse) ou dans du graphisme pur. Et puis il y a ce petit effet "wahou" du designer qui voit ses graphiques intégrés dans l'appli, et le "wouha" du développeur qui voit la création du designer se transformer en mxml.
En tout cas, je pense que l'on pourra tous se faire une première idée de la bête lors d'une future alpha ! Le concept, on le comprend tous relativement bien ; de la même manière, on le positionne entre le designer et le développeur ; il ne reste plus qu'à savoir quand et comment l'utiliser dans la chaîne de production d'une RIA ! :)
6 . Le mardi 5 février 2008 à 10h05, par neolao
ah non, moi je ne pense pas du tout comme toi.
Et je le redis, on ne fait pas comme ça des composants. A la limite, on fait des macros, des templates, mais pas des composants.
On ne peut pas "créer ce composant avec Thermo et développer son comportement interne", ça ne se fait pas comme ça.
Thermo utilise des composants, il ne les crée pas. Si tu veux faire des composants de composants, fait des templates, des snippets ou des trucs dans ce genre.
Moi je verrai bien Thermo comme un grand outil d'intégration.
Et si Adobe fournit ce qu'il faut, le designer et le developpeur pourront travailler dans leur coin, le développeur fournissant toujours plus d'outils au designer.
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.