Any best practices for project file management?

[keuler]

Hi. I'm wondering if anyone can offer best practices for file management, that is, the directory layout, of project. For example: Is it best to put all Images, Snippets, PageLayouts, etc, in the respective default Resources subdirectories? Should the directory structure beneath these Resources subdirectories be flat?

Also, has anyone had issues with Content Explorer not updating links and cross-references in the expected way when you drag project files to different directories (under the same project, of course) or rename files? My initial sense is that referencial integrety might have been broken in several places during some of my recent file management activity. Are there file management actions one should avoid, or should take care to do in a certain way?

Much obliged.

-Kurt

[ChoccieMuffin]

Firstly, only EVER move files from within Flare. The instant you start moving things in Windows Explorer the project falls to bits. Even when moving files from within Flare, take great care to READ the dialog box that pops up inviting you to update or not. And take it slowly. It does seem to take Flare a bit of time to catch up, particularly if I'm moving lots of files around.

As for where you want to put things, it depends on the structure and size of your project. One of my projects is massive, uses global product linking from about 10 other projects and has been a nightmare. To help me to identify what file comes from where, all the source projects that are called with GPL have topics in a sub-folder of their Content folder with the project name (e.g. \Content\DV and \Content\DV Images) so that when I import the topics and images (the only things I need from those projects) the sit happily in the massive project in their own sub-folder. For the big project itself I have also separated the chapters or sections into their own folder. This means that the Flare project opens up loads quicker, and I also have a chance of finding where a topic is.

But I don't do this splitting the stuff by chapters for my other, smaller, projects because that would be overkill for me.

Is that any use to you?

[keuler]

Thanks ChoccieMuffin. Your comments are useful indeed.

I just counted about 2,500 files (htm, images, etc) in my main project (probably a small count compared to yours).I'll see what makes sense for me. Main issue is to be able to find files by browsing.

And yes, I definitely understand that I need to use Flare to manipulated its Project files.

Thanks!

-Kurt

[RamonS]

Main issue is to be able to find files by browsing.

For that craft a rather flat folder structure and establish a naming convention for topics and images. Numerical prefixes keep the file names short, but they are not that intuitive to use. It depends on how many different areas you need to cover.
Example: an app to design coffee cups might have these areas
- main page
- add/edit/delete design
- add/edit/delete cup shape
- add/edit/delete cup and design combo

Prefixes for the topics and images would be "Main", "DesignAdd", "DesignEdit", "DesignDel" and so forth. You may want to set a rule that each component is not allowed to be longer than 5 characters. That way everything that belongs to one area is clustered together and files should be much easier to find.

[ffeathers]

Hi All

I'd like some insight as to how people have set up their Content Explorer for managing their topics please.

I started out with a folder structure under Content where I kept topics dependant on user level. This didn't work out well, so I then ended up moving everything into a flatter structure, and have topics in one folder. However, as my project has developed, I'm finding that for some key parts where there is overlap between the user levels, that I have to snippet quite a bit.

Would it be sensible to move these topics that have now been labelled with their user level into a folder to manage them and make them easier to find? e.g. welcome-userA, Welcome-userB, Welcome-userC all together by topic content OR everything together that is by user type -userA in a folder of its own, -userB in a folder of its own, etc... (It was the latter that I tried before and it didn't work).

I also have conditions in my topics but most of them are quite granular. Most of my conditions are set at paragraph level, in the TOC and Targets.

[RamonS]

It all depends. Unless customer complaints came in I would not even bother differentiating between user levels. So the data entry user can see all the awesome stuff an admin can do, where is the problem? If anything, it will make them understand the app as a whole much better. Could craft multiple sections in the ToC based on user level to add some guidance. The only drawback I could see is when searching. When a dozen top results are irrelevant to my user level search becomes a bit useless.

As far as the structure goes, I'd sort by DITA type (task, reference, concept) and then by functional area / feature. There is no one size fits all approach.

[ffeathers]

Hi Thanks RamonS. Unfortunately, none of the users are allowed to see what higher spec users can see, and that's been specified in the settings also.

I've applied HTML Classes for topic types where possible for now. No decision has been made about DITA but I thought the best approach was stick to the spirit as much as possible.

Ffeathers