one large project vs global project linking

This forum is for Single-Sourcing your Flare content to multiple outputs.

one large project vs global project linking

Postby Lynn_policy_writer on Thu Apr 11, 2019 11:05 am

Hi - I should start by saying that my team and I are complete Flare and Central newbies so please bare with me... My team (of 6 writers) and I are working on a single project that is very large and will only continue to grow exponentially (to over 2000+ topics). We are trying to decide if this is something that can remain a single project, or if we should split the project up and use global project linking. We are just not sure on what makes the most sense moving forward, and would love some help weighing out the general pros and cons of keeping it as a single project vs splitting it up into 3-4 smaller projects and using GPL. Not sure if more information is needed to answer a question like this? But..hopefully someone can give us some input! :)
Lynn_policy_writer
Jr. Propeller Head
 
Posts: 5
Joined: Tue Feb 07, 2017 4:09 pm

Re: one large project vs global project linking

Postby Dave Lee on Thu Apr 11, 2019 11:39 pm

I'd always recommend keeping it in a single project.

Using multiple projects and project imports (GPL) is much more limiting and restrictive than using a single project - they should not be considered equal.

Generally speaking, a single project is the best option if all the content is all related and connected; e.g. the topics are linked together, or you have shared content (snippets, etc.). Flare can easily handle projects with over 2000 topics, multiple targets, etc.

I can't think of many good reasons to use multiple projects and project imports, if the intention is to combine the projects anyway. If you use multiple projects, then the content needs to be genuinely separate; e.g. you have no links from topics in one project to another project, and the projects don't have shared content. So unless the content in these projects is largely separate and just going to be bundled together, it's probably not going to be suitable.

Also bear in mind that if you use a project import (GPL), that will essentially just copy all the files from the child projects into the parent project. So that means the parent project will be exactly the same size as using a single project, so there is no difference/advantage if the project size was a concern.
Dave Lee
Master Propellus Maximus
 
Posts: 5657
Joined: Mon Mar 05, 2007 8:33 am
Location: UK

Re: one large project vs global project linking

Postby Psider on Fri Apr 12, 2019 4:05 am

@Dave Lee
Would having different people work on different sections be a case for splitting the project? Or, what problems could you encounter if you have multiple people working on one project at the same time?
Psider
Propellus Maximus
 
Posts: 596
Joined: Wed Jul 06, 2011 1:32 am

Re: one large project vs global project linking

Postby Dave Lee on Fri Apr 12, 2019 5:47 am

Psider wrote:@Dave Lee
Would having different people work on different sections be a case for splitting the project? Or, what problems could you encounter if you have multiple people working on one project at the same time?


If you have multiple people working on it, you'd use source control to manage that.
I'd suggest using source control anyway, even if you're a sole author.
Dave Lee
Master Propellus Maximus
 
Posts: 5657
Joined: Mon Mar 05, 2007 8:33 am
Location: UK

Re: one large project vs global project linking

Postby Nita Beck on Fri Apr 12, 2019 5:58 am

I agree with Dave's advice and all of his reasoning.

That said, I do use global project linking for some clients' work, specifically for those who have many products whose documentation needs are truly segregated. In that case, we have a global project that holds all the "high level" corporate assets -- logos, trademark notices and other legal disclaimers, page layouts, "base" stylesheet, even some global condition tag sets and variable sets. These assets are imported into the product projects (they have upwards of 40); if a particular product's documentation requires any customized CSS, we create a product-level stylesheet that first imports all of the styles from the global stylesheet and then defines the differences.

Regarding source control, whether one is a lone author or working on a team, I *always* *always* *always* advocate the use of source control.
Nita
Image
Content Strategist / Information Architect / Flare Consultant: http://beck-communications.com
Manager, Rochester Flare User Group: http://www.facebook.com/RochesterFlareUserGroup
Nita Beck
Senior Propellus Maximus
 
Posts: 3290
Joined: Thu Feb 02, 2006 9:57 am
Location: Pittsford, NY

Re: one large project vs global project linking

Postby ChoccieMuffin on Fri Apr 12, 2019 8:02 am

Weighing in with Nita's approach here.

Our company uses GPL pretty heavily, and it works well for us to have a sensible structure.

Things that are truly global all live in one single project: These things include:
* stylesheets
* table stylesheets
* page layouts
* master pages
* copyright text
* globally appropriate snippets and topics (like hardware and software minimum requirements info (the same for all our products), Table of Contents topic and Index topic with proxies, Front Cover topic using variables, etc)
*
* corporate logos and images
*
* Global condition tags (e.g. PrintOnly, ScreenOnly, COMMENT and QUESTION conditions that aren't product-specific).
* Reports that could be useful for any project
* Skins
* TOCs for things like front covers, getting help, printed table of contents, index. These TOCs are used as sub-TOCs in other projects
* Global variable set (contains things like project release date, company details, release date etc)

We don't actually produce any outputs from this project, but it does mean that when working on any other projects, these bits are never changed accidentally so we keep the consistency across all our outputs.

We have a couple of "big guy" projects, and quite a few modules that fit into both of the big projects AND need their own outputs. Each of those modules live in separate projects.

Source control is ABSOLUTELY ESSENTIAL. You don't have to use integrated source control - we don't use it here and it works very well for us (as long as I remember to add new bits in Tortoise SVN!)

This is how we do it:

Globals project, everything is in source control, except Analyzer and Output folders, and folders inside the Projects folder that either don't contain anything or contain stuff we don't want to go into other projects, like the Users folder.

All projects include an import file pointing to this Globals project. This is what the import file looks like: note that I only use a relative source path, not an absolute source path. This is because the build machine doesn't have the same structure as our individual machines.

Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<CatapultProjectImport
  AutoSync="true"
  IncludeLinkedFiles="false"
  IncludePattern="*.htm;*.html;*.flcts;*.flfts;*.flmsp;*.flpgl;*.png;*.bmp;*.jpg;*.jpeg;*.tif;*.tiff;*.gif;*.mov;*.avi;*.swf;*.swd;*.emf;*.wmf;*.xaml;*.xps;*.exps;*.hdp;*.wdp;*.css;*.flvar;*.fltoc;*.flsnp;*.flskn;*.flrep"
  DeleteStale="true">
  <Files>
    <Url
      Source="../../../Globals/Globals.flprj" />
  </Files>
  </CatapultProjectImport>


Individual projects all have their own individual variable sets and condition tag sets as well as the global ones.
All individual projects contain global.flimpfl (as above, but may also contain import files pulling in stuff from other modules. If this is needed, then the condition tag set in the donor project includes a condition to identify files that need to be imported in other projects. Here's an example import file (where the donor project is called DV, and the DV.DV condition is applied only to files needed in other projects):

Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<CatapultProjectImport
  AutoSync="true"
  IncludePattern="*.htm;*.html;*.flcts;*.png;*.bmp;*.jpg;*.jpeg;*.tif;*.tiff;*.gif;*.mov;*.avi;*.swf;*.swd;*.emf;*.wmf;*.xaml;*.xps;*.exps;*.hdp;*.wdp;*.mcpic;*.mcdraw;*.flrtb;*.fltoc;*.flsnp"
  DeleteStale="true"
  ConditionTagExpression="include[DV.DV] "
  AutoExcludeNonTaggedFiles="true">
  <Files>
    <Url
      Source="../../../DV/DV.flprj" />
  </Files>
</CatapultProjectImport>


We have 40+ separate projects. All of them include globals.flimpl, and one of our big guy projects has EIGHT other import files.

Complicated, but it works for us and helps us maximise re-use.
Started as a newbie with Flare 6.1, now using Flare 2019r1.
Report bugs at http://www.madcapsoftware.com/bugs/submit.aspx.
Request features at https://www.madcapsoftware.com/feedback ... quest.aspx
ChoccieMuffin
Senior Propellus Maximus
 
Posts: 2149
Joined: Wed Apr 14, 2010 8:01 am
Location: Surrey, UK

Re: one large project vs global project linking

Postby Lynn_policy_writer on Tue Apr 16, 2019 2:12 pm

Thank you all for your feedback, this is very helpful! Thanks!
Lynn_policy_writer
Jr. Propeller Head
 
Posts: 5
Joined: Tue Feb 07, 2017 4:09 pm

Re: one large project vs global project linking

Postby Psider on Tue Apr 16, 2019 5:59 pm

Ditto from me.



:) :)
Psider
Propellus Maximus
 
Posts: 596
Joined: Wed Jul 06, 2011 1:32 am


Return to Single-Sourcing

Who is online

Users browsing this forum: No registered users and 1 guest