Comment contrôlez-vous la version de vos actifs filaires / prototypes?
Comment contrôlez-vous la version de vos actifs filaires/prototypes? J'ai largement travaillé avec des prototypes HTML interactifs et au fur et à mesure que j'exécute itération après itération, je trouve que mon processus de versionnage, de journalisation des modifications et de comparaison des versions est tout à fait manquant. Quelqu'un a des suggestions? Utiliser SVN?
SVN n'est pas génial car il a une courbe d'apprentissage élevée et est principalement utilisé par les développeurs. Si vous n'avez pas de problème avec ça, allez-y et utilisez-le (ou git, ou hg, ou autre), mais je pense qu'il y a une meilleure façon.
Handcraft (que je construis) a été conçu avec ce problème à l'esprit. Au lieu d'utiliser le contrôle de version, vous disposez de prototypes distincts dans votre compte. Dans la pratique, je trouve que si j'ai besoin de créer une conception alternative, il existe plusieurs options:
- Créez de nouvelles pages dans un prototype qui réutilisent du CSS et écrasent d'autres parties
- Clonez le prototype et continuez à travailler à partir de là
Ces deux actions sont très faciles à faire avec Handcraft car nous pensions que demander aux concepteurs d'apprendre le contrôle de version juste pour travailler avec des prototypes interactifs est un peu "orienté développeur". Il devrait y avoir un outil spécialement conçu pour les concepteurs d'interaction et les ingénieurs front-end qui supprime tout ce que vous ne voulez pas lors du prototypage. Voilà ce qu'est l'artisanat.
Par exemple, nous testons actuellement ne autre conception de page d'accueil pour le site promotionnel de Handcraft. C'est un prototype dans le sens où nous n'en sommes pas sûrs et essayons différentes choses. Ce que j'ai fait, c'est copier le code HTML de la page d'accueil et commencer à changer les choses. Il fait toujours référence au CSS d'origine, mais j'ai créé une nouvelle feuille de style que seule cette page utilise pour les exceptions, les modifications et les remplacements. Cela fonctionne plutôt bien. Si j'avais l'intention d'approcher la page d'accueil d'une manière complètement différente, je pourrais recommencer à zéro ou créer un deuxième prototype basé sur celui-ci afin que je puisse vraiment creuser.
Au cas où vous vous poseriez la question, Handcraft prend en charge les sauvegardes de version rudimentaires afin que vous ne perdiez pas vos modifications historiques. Mais nous avons remarqué que le prototypage par nature est orienté vers l'expérimentation. Donc, la version est en place au cas où. Vous devriez vraiment chercher à explorer autant que possible et à répéter le plus rapidement possible au lieu d'essayer de prendre un instantané de chaque petit changement. Si vous souhaitez comparer différentes approches, ce que j'ai décrit ci-dessus fonctionne très bien.
Edit: autre chose que je viens de penser - je travaille actuellement sur un prototype pour un client et je voulais enregistrer une version spécifique comme référence pour plus tard. J'ai donc exporté le prototype de Handcraft, ce qui me donne un tas de fichiers HTML et tous les médias inclus. J'ai ensuite vérifié cela dans notre tronc de développement pour l'application finale et je prévois de le faire avec de futurs instantanés à mesure que le projet progresse.
(Clause de non-responsabilité évidente: j'ai créé Handcraft).
Subversion (alias SVN)
Pour les sources textuelles, comme HTML, CSS, JavaScript, etc., c'est parfait et fortement recommandé.
En ce qui concerne les fichiers binaires et les fichiers multimédias, SVN n'est pas la solution idéale. IMHE it does fonctionne bien, mais je ne peux pas garantir que SVN ne gâcherait pas quelque chose. Techniquement, SVN enregistre les différences textuelles entre chaque version, vous pouvez donc imaginer que cela pourrait être risqué. Je l'utilise moi-même, cependant, et je n'ai jamais rencontré de problème.
Mise à jour: J'avais tort sur le problème binaire. Merci d'avoir signalé cela, Chris.
Subversion (alias SVN) le fait supporte les binaires: http://Subversion.Apache.org/faq.html#binary-files .
Vous devez cependant vérifier si vous SVN client supportez également la fonction binaire.
Partage de fichiers
Une autre solution est une sorte de système de partage de fichiers qui sauvegarde automatiquement l'historique. Dropbox une solution que j'utilise beaucoup. Vraiment simple à utiliser et très facile à partager des dossiers avec d'autres personnes. IIRC, Dropbox enregistre l'historique, donc vous pouvez revenir en arrière et obtenir une ancienne version d'un fichier, mais ce n'est pas la caractéristique principale de Dropbox, bien sûr.
Discussion supplémentaire sur les binaires dans SVN
Vous pourriez envisager de faire un peu recherche sur StackOverflow.com . Je sais que ce sujet a été discuté là-bas. Vous trouverez peut-être quelque chose sur programmers.stackexchange.com ainsi ...
Je comprends fondamentalement ce que fait Git et je pense que ce serait vraiment pratique dans le contexte du prototypage haute fidélité, mais en tant que non-programmeur sans beaucoup d'interface de ligne de commande, il a une courbe d'apprentissage heckuva.
La version des fichiers doit être utilisée pour tout. Les wireframes et la documentation similaire sont souvent versionnés dans SharePoint (SharePoint est mauvais et horrible, mais je vous l'accorde que cela fait une chose OK et c'est de partager des documents et de les versionner).
Cela dit, en jouant l'avocat du diable, si vous vous retrouvez à éditer beaucoup de wireframes, je dirais que c'est une perte de temps. Les wireframes sont destinés à faire avancer le processus mais, à mon humble avis, ne sont pas destinés à agir comme un document permanent qui doit être mis à jour. Je suis un fan de garder Wireframes interne à l'équipe et de les jeter de côté une fois que le processus de construction commence.
Ce n'est pas une réponse parfaite, mais si votre équipe de développement utilise Subversion, PixelNovel Timeline intègre SVN dans Creative Suite afin que vous puissiez facilement valider des épreuves pour le contrôle de code source.
Dropbox fait le travail de mise à jour de la maquette graphique. tels que la conception de wireframes etc. Il a un svn intégré et très facile à utiliser. Et oui pour la collaboration, c'est super aussi!
J'utilise également DropBox, principalement pour la sauvegarde automatique et le versioning, mais aussi pour le partage. Comme je suis sur OS X, j'ai également Time Machine en marche, ce qui me donne encore plus de recul dans le temps (Dropbox a des limites).
DropBox et Time Machine ont l'habitude d'enregistrer les révisions quand ils le souhaitent, ce qui ne correspond généralement pas lorsque je le considère pertinent. DropBox enregistre une version à chaque événement de sauvegarde (ce qui pour moi est très souvent, pas après avoir fait 3 heures de travail sans enregistrer), tandis que Time Machine fonctionne sur un horaire. (C'est là que SVN et al seraient appropriés).
Les deux ne sont donc pas suffisants pour moi - mes wireframes sont des documents de conception et de communication, et en tant que tels, ils sont imprimés, envoyés par courrier électronique, transmis via sneakernet, copiés sur des clés USB, affichés sur les murs, fusés, pliés, enfouis dans de la mousse de tourbe et recyclés comme briquets. Si le fichier a le même nom de fichier dans toutes mes modifications, je perds beaucoup de temps à trier les confusions si elles recherchent une ancienne version. Quel sera inévitablement quelqu'un.
Ainsi, je m'assure également que mes documents ont un nom de fichier reflétant de quelle édition il s'agit. Le schéma que j'ai trouvé qui fonctionne bien pour moi est <thing-name>-v<requirements-version>-<yyyy-mm-dd>.<extension>. J'ai trouvé que l'utilisation d'une date comme différenciateur d'édition était plus utile que l'incrémentation d'un certain nombre abstrait: moi-même et d'autres pouvons ainsi regarder une version et savoir si elle a été produite avant ou après un événement de projet (par exemple, une série de tests d'utilisabilité) . Le format de date me permet également de savoir en un coup d'œil si je me suis souvenu de renommer le fichier aujourd'hui ou non ... ce qui n'est pas du tout évident quand je regarde quelque chose comme v1.7.18.
Je ne me fie certainement pas à la date de modification du fichier du système d'exploitation (il existe en fait certaines applications qui touchent la date lorsque vous ouvrez simplement le fichier pour le visualiser).
D'accord avec @plainclothes. J'utilise pour mon application mobile jQuery
Sourcetree pour Git. Il s'agit d'une application conviviale que vous pouvez lier à votre référentiel. Il suivra les versions de tous vos codes et images.
Vous pouvez télécharger ici: https://www.sourcetreeapp.com/
Si vous êtes sous OS X, je recommande fortement l'une de ces deux options:
- SVN via Pierre angulaire (ou Versions )
- Git via SourceTree
En termes simples:
SVN = centralisé
Git = décentralisé
J'utilise les deux en fonction de cette différence.
J'utilise le contrôle de version de notre SCM.
Balsamiq est Nice et utilise XML, sur lequel les outils diff fonctionnent très bien et qui est très compact.
Pour les maquettes basées sur des images, cela consomme plus d'espace, mais j'utilise toujours le contrôle de version lorsque je le peux. Cependant, lorsque je restitue des sorties haute résolution, j'ai tendance à les enregistrer en tant que version nommée distincte, juste pour la rendre plus facile à trouver plus tard. I devrait utiliser des étiquettes SCM, mais l'interface n'est pas à la hauteur pour cela.
Un écueil: assurez-vous de contrôler la version de l'ensemble du site à la fois. Cela inclut toutes les pages et les scripts, et quelles que soient les bibliothèques externes que vous utilisez (jQuery, etc.). Sinon, vous ne pourrez pas reproduire l'ancien état.
Il n'y a pas de bonne réponse à ces questions car il y a des CHARGES d'outils et un moyen de faire face au problème. Personnellement, j'utilise Github pour mes prototypes interactifs et google Docs pour PDF, simplement parce qu'il est plus facile de les partager, mais je pense que vous pouvez utiliser github avec pratiquement tout!