ワイヤーフレーム/プロトタイプのアセットをどのようにバージョン管理しますか？
ワイヤーフレーム/プロトタイプのアセットをどのようにバージョン管理しますか？私は主にインタラクティブなHTMLプロトタイプを使用しており、反復を繰り返すうちに、バージョン管理、変更のロギング、バージョンの比較のプロセスが非常に不足していることがわかりました。誰か提案がありますか？ SVNを使用しますか？
SVNは学習曲線が高く、主に開発者によって使用されるため、すばらしいとは言えません。それで問題がなければ、先に進んでそれ（またはgit、hgなど）を使用しますが、もっと良い方法があると思います。
Handcraft （私が作成したもの）は、この問題を念頭に置いて設計されました。バージョン管理を使用する代わりに、アカウントに異なるプロトタイプがあります。実際には、代替設計を作成する必要がある場合、いくつかのオプションがあることがわかります。
- いくつかのCSSを再利用し、他の部分を上書きするプロトタイプ内に新しいページを作成します
- プロトタイプを複製して、そこから作業を続けます
インタラクティブなプロトタイプを操作するためだけにバージョン管理を学ぶようデザイナーに依頼することは少し「開発者志向」だと感じたので、これらのアクションはどちらもHandcraftで非常に簡単に実行できます。インタラクションデザイナーやフロントエンドエンジニア向けに特化したツールを用意して、プロトタイピング中に不要なものをすべて取り除く必要があります。それがハンドクラフトです。
たとえば、現在、Handcraftのプロモーションサイトで 代替ホームページのデザイン をテストしています。確信が持てず、さまざまなことを試しているという意味では、これはプロトタイプです。私がしたことは、ホームページのHTMLをコピーして、状況を変え始めたことです。それでも元のCSSを参照していますが、このページでのみ例外、変更、オーバーライドに使用する新しいスタイルシートを作成しました。それはかなりうまくいきます。まったく異なる方法でホームページにアクセスすることを計画している場合は、ゼロから始めるか、これに基づいて2番目のプロトタイプを作成して、実際に掘り下げることができます。
ご参考までに、Handcraftは基本的なバージョンのバックアップをサポートしているため、履歴の変更が失われることはありません。しかし、プロトタイピングの性質は実験に向けられていることに気付きました。そのため、念のためバージョンが用意されています。小さな変更ごとにスナップショットを作成するのではなく、できるだけ多くを探索し、できるだけ迅速に反復することを検討する必要があります。異なるアプローチを比較したい場合は、上で概説したものが非常にうまく機能します。
編集：私が考えたばかりの何か-私は現在クライアントのプロトタイプに取り組んでおり、後で参照するために特定のバージョンを保存したいと思っていました。そこで、Handcraftからプロトタイプをエクスポートしました。これにより、一連のHTMLファイルとすべての付属メディアが得られます。次に、これを最終的なアプリの開発トランクにチェックインしました。プロジェクトの進行に合わせて、将来のスナップショットでこれを行う予定です。
（明らかな免責事項：私はHandcraftを作成しました）。
Subversion（別名SVN）
HTML、CSS、JavaScriptなどのテキストベースのソースの場合は、完璧であり、強くお勧めします。
バイナリファイルとメディアファイルに関しては、SVNは理想的なソリューションではありません。 IMHEそれはdoes動作しますが、私はSVNが何かを台無しにしないことを保証できません。技術的には、SVNは各バージョン間のテキストの違いを保存するため、これが危険であると想像できます。自分で使っていますが、問題は一度もありません。
更新：バイナリの問題について間違っていました。これを指摘してくれてありがとう、クリス。
Subversion（aka SVN）doesサポートバイナリ： http://Subversion.Apache.org/faq.html#binary-files 。
ただし、SVNclientがバイナリ機能もサポートしているかどうかを確認する必要があります。
ファイル共有
別の解決策は、履歴を自動的にバックアップするある種のファイル共有システムです。 Dropbox 私がよく使用する1つのソリューション。本当に使いやすく、他の人とフォルダを共有するのはとても簡単です。 IIRC、Dropboxは履歴を保存するので、前のバージョンのファイルを取得（= /// =）できますが、もちろんこれはDropboxの主な機能ではありません。
SVNのバイナリに関するさらなる議論
StackOverflow.comで検索 を実行することを検討してください。私はこのトピックがそこで議論されたことを知っています。たぶん programmers.stackexchange.com で何かを見つけるでしょう...
私はGitの機能を基本的に理解しており、忠実度の高いプロトタイピングのコンテキストでは非常に便利だと思いますが、コマンドラインインターフェイスのチョップをあまり持たない非プログラマーとしてはheckuvaの学習曲線があります。
すべてにファイルのバージョン管理を使用する必要があります。ワイヤーフレームや同様のドキュメントは、SharePoint内でバージョン管理されることがよくあります（SharePointは悪質で恐ろしいですが、1つの問題がなく、ドキュメントを共有してバージョン管理していることを認めます）。
とは言っても、悪魔の支持者を演じている場合、ワイヤーフレームを頻繁に編集していることに気付いたら、それは時間の無駄だと私は主張します。ワイヤーフレームは、プロセスを順調に進めることを目的としていますが、IMHOは、更新が必要な永続的なドキュメントの一部として機能することを意図していません。私はワイヤーフレームをチームの内部に保ち、構築プロセスが始まったらそれらを捨てるのが好きです。
これは完璧な答えではありませんが、開発チームがSubversionを使用している場合、 PixelNovel Timeline はSVNをCreative Suiteに統合するので、ソース管理に証明を簡単にコミットできます。
Dropboxはグラフィックコンプを更新する仕事をします。ワイヤーフレームデザインなど。組み込みのsvnがあり、非常に使いやすいです。はい、コラボレーションも素晴らしいです。
また、DropBoxを使用しています。これは主に自動バックアップとバージョン管理に使用しますが、共有にも使用します。私はOS Xを使用しているので、Time Machineも実行しています。これにより、以前のバージョンにバージョン管理できます（Dropboxには制限があります）。
DropBoxとTime Machineはどちらも、必要に応じてリビジョンを保存する癖がありますが、通常、私がそれを適切だと考える場合には、これは一致しません。 DropBoxはすべての保存イベントでバージョンを保存します（保存することなく3時間の作業を行った後ではありません）。一方、Time Machineは1時間ごとのスケジュールで実行されます。 （これはSVNらが適切な場所です）。
どちらも私にとっては十分ではありません-私のワイヤーフレームは設計とコミュニケーションのドキュメントであり、印刷され、電子メールで送信され、スニーカーネットを介して送信され、USBスティックにコピーされ、壁にポストされ、紡がれ、折りたたまれ、ピートモスに埋め込まれ、リサイクルされます火のライター。すべての変更を通じてファイルのファイル名が同じである場合、古いバージョンを参照していると、混乱を解消するために多くの時間を浪費することになります。誰かが必然的になります。
したがって、私はまた、私のドキュメントがどのエディションであるかを反映するファイル名を持っていることを確認します。私にとってうまく機能することがわかったスキーマは<thing-name>-v<requirements-version>-<yyyy-mm-dd>.<extension>。エディションの差別化要因として日付を使用すると、抽象的な番号をインクリメントするよりも便利であることがわかりました。私自身と他のユーザーは、バージョンを見て、プロジェクトイベントの前後に生成されたかどうかを確認できます（たとえば、一連のユーザビリティテスト）。 。日付形式は、今日ファイルの名前を変更したことを思い出したかどうかを一目で知らせます... v1.7.18のようなものを見ると、これはまったくわかりません。
私は確かにOSファイルの変更日付に依存していません（実際に、単にファイルを開いて表示したときに日付に触れるアプリがいくつかあります）。
@plainclothesに同意します。 jQueryモバイルアプリに使用しています
GitのSourcetree。リポジトリにリンクできるユーザーフレンドリーなアプリケーションです。すべてのコードと画像のバージョンを追跡します。
こちらからダウンロードできます： https://www.sourcetreeapp.com/
OS Xを使用している場合は、次の2つのオプションのいずれかを強くお勧めします。
- Cornerstone （または Versions ）によるSVN
- SourceTree によるGit
簡単に言えば：
SVN =一元化
Git =分散型
私はその違いにかなり基づいて両方を使用します。
私はSCMのバージョン管理を使用しています。
Balsamiqは素晴らしいですし、XMLを使用しています。これは、diffツールがうまく機能し、非常にコンパクトです。
画像ベースのモックアップの場合、より多くのスペースを消費しますが、可能な場合は引き続きバージョン管理を使用します。ただし、高解像度の出力をレンダリングするときは、後で見つけやすくするために、それらを別の名前付きバージョンとして保存する傾向があります。私はSCMラベルを使用するはずですが、インターフェースはこれを嗅ぎ分けることができません。
1つの落とし穴：サイト全体を一度にバージョン管理するようにしてください。これには、すべてのページとスクリプト、および使用している外部ライブラリ（jQueryなど）が含まれます。そうしないと、古い状態を再現できなくなります。
たくさんのツールと問題に対処する方法があるので、この質問に対する正しい答えはありません。個人的には、インタラクティブなプロトタイプにはGithubを、PDFにはgoogle Docsを使用しています。これは、それらを簡単に共有できるためですが、githubを事実上すべてで使用できると思います！