How do you store Help content?

Hi all,

I’m curious to know what people use to distribute help content to their team/s, whether you only need to provide help for in-house users or you need to distribute to many companies / outsources.

Do you use one or more of the following?:

[ul]
[li]Chm[/li][li]Wiki (Media Wiki, Other Wiki Engines)[/li][li]Share Point[/li][li]Custom Web page[/li][li]Custom Software[/li][li]Text files[/li][li]etc…[/li][/ul]

And is it embedded into your tools?:

[ul]
[li]Web page in your DCC[/li][li]Custom display[/li][li]Tool tips[/li][li]Hyperlink out[/li][/ul]

~B)

This is maybe a stupid reply but I have been using Google Docs for this.
It was for student and personal projects.

This way they always had the up to date file and some could work on the same file.

Not at all I know, Rob.G has been talking about that on Chat, I’m sure he can give us an update on how that is going for him.

~B)

We use Media Wiki for both our internal docs and for the external facing content aimed at supporting our end users. This solution has been far more flexible and accessible than the standard web docs that were previously in place. That said, some of the more obscure tools that I’ve written have only received the bare bones readme file treatment. :D:

All our docs are on an internal wiki.

I have been meaning to add links from the tools to the relevant wiki pages, just haven’t gotten around to it yet.

You asked: http://www.robg3d.com/?p=132

For non-code related documentation, we rely heavily on our internal mediawiki.

For code, we generate CHM via Doc-o-matic. (which is both a nice tool and lots of headaches in one package - it’s not built for multi-user editing)

We have discussed transitioning to an Database-driven, doxygen-derived code documentation system, but it’s on the backburner for now. Rarely we’ve had to share documentation with external studios - 98% of the time, our documentation remains internal-only.

Great write-up, Rob. Agreed on all points.

We use MediaWiki for the majority of our game project documentation, splitting off to Word where necessary. I found myself tackling the MediaWiki beast after my last big project and it was generally easy going. I kept the layout to one page as I was covering the entire character art pipeline from modelling considerations, skinning and tools used. Although it took me a few days, it was easy as I was involved in a centralised team so tackled pretty much all aspects of the process. The one page layout helped greatly when other teams chose to use our character customiser framework, though it was used more as a starting point because they weren’t producing a like-for-like game.

Being in a centralised team I tend to think of all the users in my studio as outsourcers and they’re a real tricky bunch! I prefer to write generalised tools for maximum re-use though project specific are unavoidable. I’ve had senior artists who say they never read tool documentaion so I’ve have to include it in the UI itself! Of course, this becomes impractical if the tool covers a lot of functions.

If it’s any consolation to anyone here, documentation is hard but having worked with Sony’s Home briefly it’s comforting to know even their character set-up documentation (provided as a series of overlapping PDFs) leaves a lot to be desired!

We have an internal system called Insight Pages that allows us to easily keep up with documentation. ReelFX used to work off a wiki page, but since the creation of this system, the wiki has been taken down.

Thanks for the responses guys and the write up Rob. It looks like I’ll keep going with media wiki changes I have scheduled for the time being.

~B)

We also use an internal wiki here, with a Rough Guides section to pretty much all our art-related stuff.
I’m tending to lean towards embedding unlisted youtube videos I’ve uploaded into my more recent guide stuff just because it’s a lot quicker to do, and people I find are much more inclined to sit and watch a 10 minute video explaining how to use something, rather than read through a page of complicated text.

Nice idea, our videos are hosted locally and we use wikiflv, mind you to get it to work we have to set up the network path as a web address otherwise the flv player could not see it.

~B)

We have an internal wiki here as well that people can and do make some documentation. Then we have a tool that makes documentation and puts it on the wiki. The generated documentation formatting is basic to make it fast to make. Alot of time is spent on formatting documentation. Our tool takes care of all of that its not fancy but it is better than nothing.

All of our tools are in a second menu bar in Maya. Our documentation tool goes through all of the menus and makes a documentation page that I later upload. With out the tech artist doing anything the tool uses the annotation and the command for the documentation. A first pass that starts on the road to documentation. In addition to we set up a folder structure in our source with extra documentation (How to’s, What for’s, This tool is going to…, pictures, and links). That structure is a folder for each tool and each folder contains txt’s and jpeg’s. The tool will see this extra info and generate it into the wiki along with the basic info.

The basic idea is I may not have time to make detailed documentation, but I can tell you what it is and give some pictures of what its all about. I have to for the email I send out to the team any way so with this I just save it on our source.

This is our first pass so there are issues. The option-menu box makes it accessible, but gives double-meaning to the icon. So we are working on getting a small question mark. The documentation lives on our internal-wiki and the tool that loads it up to the wiki is a bit slow and is only one-way. So there are flaws, but having even limited easily accessible documentation is really nice. I find myself using it to look up tools I’ve written a long time ago.

Article I just found about googledocs.

Wiki + epydoc / doxygen everywhere I worked so far.