I've suddenly found my team grow from one to three and it's clear
that a centralized file system is needed, especially as the team
I'd love to hear how other teams are working, managing their
documentation for both the UX/IxD/VD phases for projects.
My aim is to have a central file repository that manages versions and
is easily accessed on/off location.
I appreciate any insights into this.
Great question, would love to hear what others are using for version
What about an SVN repository? I've heard from various front-end
developers, visual designers, and UX-ers that using a code repo
works. I haven't personally tried it, but it sounds doable to me.
Experience Design & Implementation
jason at jasonrobb.com
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
I reached out to the guys at EightShapes and Nathan Curtis responded
with a link to a post on their blog that speaks to this (Thanks
Link to the article:
Headlines on the file management aspect:
Use Subversion Beanstalk
If version control problems are likely to cause serial heart attacks,
then I prefer Visual SourceSafe, even though it can be a pain.
In a recent project involving several parties we used Basecamp to
share docs and had no problems (http://basecamphq.com).
Linked In: www.linkedin.com/in/uxexperts
Try Dropbox -- for small groups, their folder sharing works pretty well.
Automatically syncs, accessible over the web, keeps historical versions.
On Tue, Sep 1, 2009 at 3:42 AM, Tom Daly <tomcdaly at gmail.com> wrote:
> I've suddenly found my team grow from one to three and it's clear
> that a centralized file system is needed, especially as the team
> I'd love to hear how other teams are working, managing their
> documentation for both the UX/IxD/VD phases for projects.
> My aim is to have a central file repository that manages versions and
> is easily accessed on/off location.
> I appreciate any insights into this.
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
Subversion is pretty much the de facto standard as far as centralized
version control goes. It is a fantasic piece of software and there
are loads of tools round for easily integrating it into your
Alternatively you may also be interested in looking into distributed
version control systems such as Git (http://git-scm.com/) and Bazaar
Kim already mentioned Git, a de-centralised/distributed solution for version control that many consider more powerful than centralised systems such as Subversion or CVS.
If you have any budget available you may want to look into GitHub that offers a cool web-based interface to your Git repositories under a software as a service model: http://github.com/ . It's very nicely set up and extremely active especially for open source projects.
Jussi Pasanen, Volkside http://www.volkside.com/contact/ Interaction and Information Design, User Experience and Usability
Git and svn are comparable but git is better in some respects , for
e.g. handling branches (i.e. if you are production version of the
code , and then you also are working on 1 or more new features. You
can keep one production branch and have another branch for other
features. This way if a hot fix is to be done to production then any
incomplete feature code does not come in the way.
Hosting wise , you could have these installed anywhere. I use github
and like it. It has nice integration into other apps also, and then
it hosts a lot of open source code which is useful.
But these are more useful for code related files. for documentation I
had a media wiki locally installed and that worked very well for me.
On 1 Sep 2009, at 21:31, Alok Jain wrote:
> Git and svn are comparable but git is better in some respects , for
> e.g. handling branches (i.e. if you are production version of the
> code , and then you also are working on 1 or more new features. You
> can keep one production branch and have another branch for other
> features. This way if a hot fix is to be done to production then any
> incomplete feature code does not come in the way.
And git is worse in others (poor support on Windows boxes, lack of GUI
apps for those who like GUI apps, more complex command line UI, etc.)
[and you can also do branches with Subversion - but the tool support
for managing branches is better in git]
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
I've used SVN for document assets once, but the downside is that the
front-end tools are primitive (like Tortoise SVN)and some folks would
rather not be bothered w/ having to understand all the SVN lingo. To
be honest, almost all the projects I've worked on we have a
commercial CMS like Stellant or Sharepoint. Recently, I started
looking into Jive (http://www.jivesoftware.com/), which we are
beginning to set up at my work and it does a good job of version
management and other things, but it is pricey.
We currently use Jungledisk Workgroup to manage multiple versions of
comps, icon libraries, interactive prototypes, etc. A new web view
just launched in beta which makes easy access to your files from any
I like this solution because it scales seamlessly and also works
across Windows, Mac and Linux.
I recommend you take a look at getdropbox.com. It's a great online
backup tool and shared folder with version control that lets you sync
files across different computers %u2013 Windows, Mac and Linux.
Basically you sign up for an account, install their software and
assign a folder in your computer as a shared resource. Dropbox will
automatically backup your files and track the changes from a
specified folder. In addition, you may share the contents of the
folder with your team to keep everyone up-to-date.
Dropbox has a free account which comes with 2GB of space you and your
team can use for as long as you like.
I've been using it for almost a year and am very happy with it. Hope
On 1 Sep 2009, at 18:36, Duane Taylor wrote:
> I've used SVN for document assets once, but the downside is that the
> front-end tools are primitive (like Tortoise SVN)and some folks would
> rather not be bothered w/ having to understand all the SVN lingo. To
> be honest, almost all the projects I've worked on we have a
> commercial CMS like Stellant or Sharepoint. Recently, I started
> looking into Jive (http://www.jivesoftware.com/), which we are
> beginning to set up at my work and it does a good job of version
> management and other things, but it is pricey.
One _really_ big advantage of using Subversion in my experiences is
that it's easier to communicate with the rest of the development team
if everybody is storing things in the same way/place.
It's much easier to for a developer to miss a design change (or vice
versa) if they have to remember to go look somewhere different from
where they spend most of their time.
It reinforces that everybody involved is working on the "same thing".
 Or whatever source control system is being used by your dev team
 If they're not using one get a better dev team :-)
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
Thanks for the input everyone, there's a lot to digest here! Will
follow up with a summary and the approach we choose.
We are just getting started using SubVersion and have hit some snags.
We think there is a file size limit of about 21MB which is causing
some problems for us.
Also the repro browser and the working copy obliterate the file type
icon with a big ugly status icon which we find very difficult to work
Karen, the issue you are describing with the icons is a client side
issue. If you are windows based you may be interested in looking into
TortoiseSVN. It's a fantastic client that integrates very nicely with
the windows explorer. Rather than 'blowing away' the file icons is
uses small overlays so that you can quickly identify the filetype and
its current svn status.
Also, subversion itself does not have any inherent file size limits
(apart from those of the operating system the server is running on).
The problem you are describing is likely to be the result of your
pre-commit hook script implimenting a size limit.
We have worked with subversion and and seems like a decent solution to
al our needs. File size never really is a bottleneck and sharing
becomes a real fun.
Ashish UI Redeisgn
I have used git and svn before, but they are just a little too complex
for our needs. They are great in a coding environment, but for our
graphics and documentation environment we use Gridiron Flow. Its a
new piece of software and its incredible.
Versioning, mapping, everything is just awesome. Size is not
important, I have several versions and 'maps' of 300meg files. I
love looking at an InDesign file and seeing the location of all the
assets that I put into it. It also alerts you if the original placed
file is missing, etc. I use that in conjunction with a shared network
folder that has backups as well.
It has a 30 day free trial. Try it and you'll never go back.
Another vote for subversion and tortoise. Online subversion hosting
is pretty cheap. I would only go with an alternate solution if it
is better integratd w/ the developers workflow (ie if they are using
cvs then use cvs).
Also check out Wuala, "the social online storage"
You get 1 GB storage free, and can buy additonal storage if needed.
There is file versioning too, although I haven't used that feature
Hopefully this isn't too far of a branch in the conversation, but
what have you all found to be successful for distributed storage and
sharing of icon files and other "non-changing" assets between team
members or other parts of the organization?
Do any of the above-listed options offer asset management as well as
version control? (and don't cost more my yearly UX budget!)
Just to clarify some points that Ron George made (Thanks for the
* Flow's versioning function was designed to be insanely easy - in
short, when you save a file in any supported app, Flow creates a
"version" (list can be found here
though a few are missing such as the Mac Finder) The number of
versions can be controlled in preferences as well as the type of
files versioned. You can dedicate, say, 5% of your hard drive
(internal, external, or server) to versions.
* Flow has a mechanism for sharing data about a project over a local
network via Share Maps. As such, everyone working on the same project
sees the same changes in the map and has access to the same files and
all previous versions thereof.
* We don't, in version 1.0, do any kind of "clouding" (Is that a
word yet?) making the assets and map visible across the internet.
I've taken copious notes from the other responses in this list,
however, and will be making a few feature requests for the next
Any questions, feel free to email me directly.