Marrant tous ces retours négatifs sur le travail à distance étant donnée la proportion de freelancer dans la communauté rails. Personnellement j'aime bien travailler à distance avec les designers et je ne trouve pas ca plus compliqué qu'en avoir un in-house.
Edit: attention tl;dr; :) # Ce dont il a besoin: C'est le point le plus important, il faut que vous sachiez ce que vous voulez et que vous sachiez le communiquer. C'est ennuyeux de balader un designer in-house sur des projets pas clairs, mais c'est très couteux et stressant avec quelqu'un en remote car quand vous raccrochez il devrait savoir exactement ce que vous attendez de lui. Globalement un designer/web designer/ui designer ne design que quelques pages. Ce n'est donc pas la peine de lui envoyer tout le site en html, il n'en fera rien. Choisissez les pages qui sont représentatives et que vous voulez faire designer. Si vous avez encore les .psd/wireframe d'origine ca peut l'intéresser, sinon screenshot des pages concernées et version texte des contenus pour un rapide copy/ paste dans ses psd. La partie html + css n'est pas indispensable de suite, ni pour les wireframes ni pour le design. Les designers sont comme les développeurs, ils n'aiment que modérément reprendre l'existant. De plus la réutilisabilité d'une css inconnue est plutôt limitée. A moins que le site soit très complexe ou très legacy ou que la css d'origine soit très bien découpée laissez le repartir de zero s'il le souhaite ca coutera moins cher. S'assurer avant qu'il sache faire de la css, car si c'est pour faire pire, autant reprendre. Pour le html par contre c'est clairement intéressant de reprendre afin de ne pas avoir à refaire TOUS les templates coté rails. Lui filer une version statique du html, un diff suffira à voir les changements qui gagneront à être limités. En début de conception il va lui falloir régulièrement du temps avec vous pour échanger sur les wireframes et/ou psd. Il ne vous connait pas, ne connait ni le projet, ni l'utilisateur, ni le besoin et fait 3 autres trucs en même temps. Bien se mettre d'accord sur ce que vous attendez de lui, diviser les intérations en page et feature et éviter de tout lui dire d'un coup sinon il va tout oublier. L'avantage dans votre cas c'est qu'il y a un existant, c'est plus facile pour lui de comprendre de quoi on parle et ce que vous faîtes. C'est globalement plus compliqué "out of the blue". # Pour le travail collaboratif avec un designer remote dans un environnement mac j'apprécie particulièrement comme outil: - http://www.getcloudapp.com pour les itérations live, ca permet d'échanger directement un snapshot de photoshop ou un screenshot, vraiment super. En moins cher et un peu plus cheap il y a http://idzr.org. En cours de discussion via skype ou par mail c'est INDISPENSABLE, ca remplace le doigt sur l'écran et ca évite de nous faire ouvrir les psd. - Dropbox pour les livrables type psd, images, wireframe, images ... Au niveau de l'intégration le mieux c'est le site en live en html pure car recevoir des versions d'intégration est rapidement l'horreur, ca marche bien dans Dropbox avec le rep public. Versionnement de l'intégration ? Si le designer connait sinon ca sert à rien car de toute facon le projet aura un autre repo au final. - Un photoshop bien rangé par section. Indispensable car on a pas l'occaz de tapé sur l'épaule du gars pour lui demander ou est l'icone truc. Si c'est pas assez bien rangé, une claque, écouter les développeurs s'ils se plaignent. Un designer qui bosse en remote a en général de bonne habitudes à ce niveau. - Une todo liste claire pour le designer sur la prochaine itération. Rien de compliqué, perso j'utilise juste le mail, mais y a trois zillions de système de todo/GTD/project mngt avec différentes approches. Il faut lui faciliter les changements de contexte et la todo permet très précisement de savoir ce qu'il y a a faire et ou on en est et très rapidement. - Skype: Franchement on a toujours pas fait mieux que la conversion vocale. Ok avec les décalages horaires c'est parfois compliqué mais je travaille actuellement avec un gars à Nouméa (GMT +11) donc c'est possible. Pas besoin de faire long mais régulièrement surtout dans la phase conception c'est indispensable et bien plus efficace que le mail. Pratique aussi pour les standup meeting sur une itération car le coté asynchrone du mail fait perdre du temps quand on est dans la même time zone. Associé à Clouapp dans le skype chat et ca permet des échanges très efficace ou le designer fait des changements en live sur le petit truc qui accroche et a un feedback immédiat comme si vous étiez derrière son épaule. Webcam, et shared screen inutile. - Les outils de feedback type http://www.notableapp.com/,http://www.proofhq.com/. Preview et http://skitch.com/ marche bien aussi. Je préfère quand même TODO mail + skype + cloudapp pour les retours mais ca a l'avantage de cumuler la TODO avec le feedback et d'être asynchrone. Pratique en période d'intégration quand il faut expliquer que la couleur est pas la bonne ou qu'il y a une outer-shadow blanc à très faible opacité dans le psd qui a disparu à l'intégration. Le problème de ces outils est le suivi de commentaire et/ou de correction. - Une app de règle/color picker genre Screen Ruler ou Rulers. C'est dommage mais tous les add-on Chrome sont soit mauvais soit imprécis. Or c'est toujours quelque part entre le designer et les développeurs que la perte de qualité est la plus importante. En remote le designer ne se sent pas particulièrement responsable du destin de ce qu'il fait donc il faut lui demander un feedback sur l'intégration et/ou valider vous-même. # Et rails dans tout ca ? - Installer la stack à l'intégrateur ? Perso j'ai jamais osé, car il n'y a pas vraiment de solution parfaite ici même si homebrew, pow et bundler offre des stacks assez simple à installer. Vagrant est ici le grand gagnant car il propose des stacks plug&play avec tout installé. A tester pour ceux qui aiment les défis. - Si vous voulez faire rentrer le designer dans la stack rails alors HAML, SASS/compass, localization, jammit sont vos ennemis ici car ils augmentent la distance entre le travail de l'intégrateur et le code. ERB, css pure et texte dans les templates sont clairement plus simple (même si certains ici ne vont pas manquer de jurer le contraire...). Par exemple avec Compass (que j'adore) la css est très chargée (à cause des hacks) surtout si on fait du css3 car les dev tools de chrome affiche mêmes les règles non webkit ce qui rend le truc opaque au non spécialiste qui veut juste tripoter pour voir. De plus ca favorise la duplication (via les mixins) dans la css plutôt que la réutilisation des règles ce qui rend la css finale assez touffue et modifier via la version texte risque de ne changer qu'un endroit et pas l'autre. - Git je vais contredire mes camarades mais j'ai travaillé depuis le debut de git (où gitgui était le seul outil) avec des designers et même quand il n'y avait pas d'UI ca n'a jamais été un problème. Tant que c'est utilisé à la svn à savoir: git pull --rebase, git add, git commit, git push. C'est tout ce qu'il y a à connaitre. Le jour où il y a un conflit c'est une autre histoire, il vaut mieux avoir une bonne répartition des taches. Ceci dit maintenant il y a au moins 10 GUI pour gérer cela. Le mieux pour un designer IMHO est l'intégration avec le système plutôt que le third party app, donc je regarderai l'approche tortoise en premier. # Globalement dans ton cas: En remote la clé c'est un partage de tache clair pour le freelance et de lui offrir un interlocuteur présent et disponible. Cette interlocuteur doit avoir un vrai pouvoir de décisions sur le projet afin de pouvoir décider en live sur la plupart des cas (bouton ou lien, wizard ou formulaire, ...) afin de minimiser les aller-retour et les phases de validation qui font rendre ce coté remote très pénible. Il maintient également les TODO de chacun et agit comme intermédiaire sur tous les feedbacks, validation et et garantie que les besoins de chacun dans l'équipe sont satisfait et que chacun délivre. Il est pratique de toujours avoir quelques taches d'avance, comme ca le freelance passe à la tache suivante quand sa tache en cours attend validation/feedback. Je préfère l'approche divide & conquer : Ne pas espérer que le designer va faire du rails et deployer ou que les Raileurs vont gérer le designer et/ou regarder les psd. Chacun fait son job dans son coin et le chef de projet est au centre pour passer au voisin. Dans ton cas le designer fait l'UI, le design et l'intégration et tes équipes "motorisent". Le découpage standard d'un travail de design est traditionnellement waterfall wireframing > look&feel > design > integration surtout si vous le payer en forfait. Ca marche tout aussi bien en itération par pages / feature. Attention comme avec les développeurs les méthodes agiles à base d'itération sont source de tension/mauvaise volonté si le designer n'est pas en facturation variable et que trop de changement sont demandés. Une méthode efficace quand le projet le permet est "l'intégration continue". A savoir l'itération designer suivi immédiatement par l'itération développeur et mise en ligne. Cela permet une correction immédiate, retouche au niveau du fonctionnement, le designer voit son boulot en réalité et l'équipe a toute de suite conscience des problèmes (psd pourri, intégration moisie, truc infaisable ou trop compliqué ...). Le problème de bosser avec des freelances c'est l'aspect mercenaire de la relation, donc pas très adapté à des cycles long où le travail du designer n'est utilisé que des semaines après quand le designer est déjà très loin et c'est souvent compliqué de retoucher. My 2 cent, désolé pour la logorrhée :) -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
