How to manage Targets, TOCs? Folders in Project Organizer?

[beagley]

Hi,
I'm going to have over a hundred targets and TOCs when our transition project is complete... one for every discrete PDF manual that we distribute.

That's going to make the "Targets" folder and the "TOCs" folder in the Project very difficult to use, since the Project Organizer doesn't have a new-folder feature. I'll be scrolling like crazy, trying to find the Target or TOC I need to tweak...

And I imagine the "Build Primary" pull down menu that I use to build items is also going to become useless.

Any Suggestions?

Anyway to make subfolders of the Targets/TOCs folder?

-Douglas

[Alice]

Well, as for me you seem to be in ttrouble.
I tried to create subfolders in Project folder with the help of file managing programme? but Flare doesn't seem to "see" them.
Perhaps project Organizer has extremely strict structure.
Try to submit a feature request.
Good luck

[jmenning]

Wow. That's a lot of targets. Presents some interesting problems

As far as I can tell, there's no built-in way to handle such a large number of targets (submit a feature request!).

You can use naming conventions to organize the list, so that related targets stay together alphabetically. Doesn't help with the scrolling, though.

Creating sub-folders in Windows Explorer and moving targets to the new folder just hides the targets that are in the sub-folder. But you could maybe use that to show/hide groups of targets, so that you're only working with 10 or so at a time. Depending on your release schedule, that might or might not be worth the effort to mess with.

Depending on how your project is organized, and how much overlapping content there is between targets, you might consider breaking up the project into multiple projects. If you have shared snippets and styles, but not a lot of shared topics, you could use a synchronization tool to keep all the snippets, styles, etc. the same for all the projects, so when it's updated one place it gets updated everywhere.

[LTinker68]

If you have shared snippets and styles, but not a lot of shared topics, you could use a synchronization tool to keep all the snippets, styles, etc. the same for all the projects, so when it's updated one place it gets updated everywhere.

Flare v4 can do that with project linking.

[beagley]

Thanks for your thoughts. Naming conventions had vaguely occurred to me as a solution... maybe I can figure out a good system.

Yes, I know, if I were a good boy I'd submit a feature request. It's just that once again (as with publishing locations for PDFs) the way the product performs these tasks really needs to be re-conceptualized. This problem is at the core of Flare's weird "Project Organizer" and "Content Explorer" artificial dichotomy (I still haven't figured out why some items are stored in one or the other) and the bizarre (and inconsistent) relationship that the structure has with the file system that underpins it. So I wouldn't know what exactly to request, and I really doubt I'd be able to convince MadCap's software designers to change their whole file management philosophy. I love this product and think they are all geniuses, but when it comes to things like this... I just think they must be crazy.

Follow-Up Question: Does it strike people as unusual that I have to have so many Targets and TOCs? I mean, along with traditional manuals, I need a downloadable/printable PDF for every 5-page "How To" handout that my company produces. And of course I want to have all those handouts and manuals in the same project (for our WebHelp output). So OF COURSE I'm going to have over a hundred targets in a single project. Give me a few years and I might have a thousand!

My question, in other words: Why doesn't EVERY Flare user have this problem, with every major product suite? I feel like I must be doing something wrong... maybe *I* need to reconceptualize...

-Douglas

[RamonS]

Yes, I know, if I were a good boy I'd submit a feature request. It's just that once again (as with publishing locations for PDFs) the way the product performs these tasks really needs to be re-conceptualized. This problem is at the core of Flare's weird "Project Organizer" and "Content Explorer" artificial dichotomy (I still haven't figured out why some items are stored in one or the other) and the bizarre (and inconsistent) relationship that the structure has with the file system that underpins it. So I wouldn't know what exactly to request, and I really doubt I'd be able to convince MadCap's software designers to change their whole file management philosophy. I love this product and think they are all geniuses, but when it comes to things like this... I just think they must be crazy.

Developers are only as smart as those people who tell them what they goofed up (which is QA and the customers). I find it quite easy to determine why things are where once one understands what is considered content or a resource and what is not. Typically, anything you will find as such in the output will most likely be in the Content Explorer, for example style sheets.

The Project Organizer and other areas in Flare read from files as well, such as project files and target definition files, which all are created from templates. Flare needs to know where to find these files and for that a rigid structure was chosen. The alternative is to tell Flare every stinkin' thing, such as where to find the custom templates, where to find the skins, where to find the target definitions and and and. Sure, that's an option, but it will annoy every Flare user rather than just a few who may think that this approach is not flexible enough.

Follow-Up Question: Does it strike people as unusual that I have to have so many Targets and TOCs? I mean, along with traditional manuals, I need a downloadable/printable PDF for every 5-page "How To" handout that my company produces. And of course I want to have all those handouts and manuals in the same project (for our WebHelp output). So OF COURSE I'm going to have over a hundred targets in a single project. Give me a few years and I might have a thousand!

My question, in other words: Why doesn't EVERY Flare user have this problem, with every major product suite? I feel like I must be doing something wrong... maybe *I* need to reconceptualize...

I think (and that is really just my opinion, nothing else) the request to have that many How To handouts as PDF is quite excessive. From my experience users tend to be interested in mastering a particular section of the application. So what I would do is consolidate the How Tos into logical blocks and make those to be PDFs for download. So you'd end up with a 50 page PDF including 10 How Tos about the general feature ABC. Or you can groom the print output from WebHelp and have each How To be one topic which then can be printed at will.
You really should evaluate the needs. Do users really need to have all How Tos as 5 page PDFs? Maybe there are How Tos that are so trivial that handouts are not needed or some are never used (look at the access log of the web server). I think the consolidation will be a good compromise....unless your end users all have dial-up and the complain about the bigger files to download.

[beagley]

On the first issue... I am SURE there is a logical split in the form or functionality of Content Explorer vs. Project Organizer in the Flare developer's mind... I just disagree with it. If it were really Content vs. Project, then (in my mind) "Content" would be Topics and Images, and Project would be everything else. Why is a Master Page Content and a TOC part of the Project? I can imagine a conceptual reason, but it falls apart in my head. The end result is that when I want to edit a Target (for example) I have no idea if I'm going to find Targets in the "Resources" folder or in the Project Organizer. I guess wrong almost every time.

I actually really LIKE the association with the file system, I just wish it were consistent and behaved more like a file system... MORE rigid, not less. I can't seem to alphabetize (I've just discovered), I can't view file information easily (like last modified dates), and I can't always create subfolders (sometimes legal, sometimes not?). It SORTA works like a file system... but without many of the advantages that an integrated file browser would otherwise convey.

I'm sure the designers had good reasons for all these decisions! I don't want to seem like a whiny Carl! But my fiction-writing mind feels like these problems are all treasured paragraphs written early on that the author can't bring himself to cut, even though the story would stand better on their own if they pulled out the red pen and cleaned things up.

Thank you for your thoughts on output production management. The reason I steer away from conglomerate PDFs (the 50-page multi-how to model) is that we do get a lot of requests for PRINTED (sigh) instructions for simple tasks... like adding a provider to our system, configuring a new insurance policy, etc. etc. If I stuffed them all together, then our support team and our clients would regularly be printing 50-page manuals, many of which would be out-of-date annually as we update our features.

Unfortunately, it will be at least another 20 years before our "non-digital-age" customers retire.

For now, I'll probably set up 25 printable PDF targets... and create more on a demand-basis only. It doesn't take me more than 30 minutes or so to whip together a PDF target based on a subset of topics, really.

For the record: how ARE items in folders in the Project Organizer sorted? It isn't alphabetical... and obviously it isn't custom... as I can't click and drag items or rearrange them. I'm sure the designer has some clever idea for this but I can't figure it.
-Douglas

[jmenning]

If you use the same settings for all the targets, could you set up one PDF output target, then just flip the TOC and enter a new filename? That's essentially what I do for my sort-of-monthly release notes - every release I create a new TOC, then in the target select the TOC and type the new filename for this release.

My items in the Project Manager are alphabetical, but it doesn't re-sort them until I close and re-open the project, so new items are at the bottom of the list for a while, and renamed items are stuck in order based on their old names.

[beagley]

"My items in the Project Manager are alphabetical..."

That would be very useful!

Did you turn on some setting or something? I don't seem to have that feature.

-d

[jmenning]

"My items in the Project Manager are alphabetical..."

That would be very useful!

Did you turn on some setting or something? I don't seem to have that feature.

Hmm... not that I know of. Maybe it's just magic

I cannot come up with a plausible reason why it wouldn't sort alphabetically when you close and reopen Flare. (I could probably make up some implausible ones, though!)

[beagley]

"I cannot come up with a plausible reason why it wouldn't sort alphabetically when you close and reopen Flare. (I could probably make up some implausible ones, though!)"

My suspicion is that there IS a secret way to custom-order items... but I've tried clicking around on all the Flare interface menus and I can't find it yet. I've tried ctrl-shift-option-alt-drag, too.

The Truth is Out There!

[LTinker68]

Flare sorts topic names, image names, etc., based on how you have Windows Explorer set up to display the same information. So if you open a folder in Windows Explorer and it's listing the contents alphabetically, then Flare should list items the same way.

[NorthEast]

Just as a side note, did you see the topic on the command line batch file?
http://forums.madcapsoftware.com/viewto ... =12&t=1599

If you need to build batches of your targets, it might make life a bit easier.

[RamonS]

On the first issue... I am SURE there is a logical split in the form or functionality of Content Explorer vs. Project Organizer in the Flare developer's mind... I just disagree with it. If it were really Content vs. Project, then (in my mind) "Content" would be Topics and Images, and Project would be everything else. Why is a Master Page Content and a TOC part of the Project? I can imagine a conceptual reason, but it falls apart in my head. The end result is that when I want to edit a Target (for example) I have no idea if I'm going to find Targets in the "Resources" folder or in the Project Organizer. I guess wrong almost every time.

A Master Page contains proxies, text, or images that will be applied to topics in the output. At the time of compilation topic content is copied into the Master Page to form the output file. In that sense Master Pages are content and except for the proxies that content is almost identical between source and output.
The ToC in the project does not exist anywhere near in the same form as the ToC files in the output. Sure, in Flare it looks similar, but that is really only a definition of the ToC to be created. I do admit that the ToC is a bit closer to the border line. A target is nothing more than a collection of settings that tell Flare what to do. Nothing entered in the target definition except for the output file name will be in the output. So why would a target be content?

[KevinDAmery]

Thank you for your thoughts on output production management. The reason I steer away from conglomerate PDFs (the 50-page multi-how to model) is that we do get a lot of requests for PRINTED (sigh) instructions for simple tasks... like adding a provider to our system, configuring a new insurance policy, etc. etc. If I stuffed them all together, then our support team and our clients would regularly be printing 50-page manuals, many of which would be out-of-date annually as we update our features.

I hear ya about technology-challenged clients, but for your support staff at least you can point out to them that both Acrobat and Word support printing to a page range rather than the whole document. That should cut things down in your support department (although really, if they're in tech support they should be savvy enough to figure out how to work from a digital copy... but I digress.)

I would agree with the other suggestions that grouping the How To sections into larger documents would make your life easier, and probably would make your customer's lives easier too (on the assumption it's easier to keep track of a book or binder with 10 - 20 chapters than it is to keep track of 20+ sheafs of paper). Presumably the How To's could be grouped into logical collections (i.e. topics related to policies, topics related to providers, topics related to forms... well, you'll know the material better than me so I'll stop guessing now ) If it were me I would group them according to tasks that a particular user would likely end up doing at the same time (for example, if you're configuring a new policy odds are there's a process for delivering it to the customer that you'll probably be doing once you're done configuring it). You can probably anticipate that if the user had a question about X, their next question is likely to be about Y and put that How To immediately after it in the guide.

Leaving aside the organizational elements of managing 100+ target files, TOCs, etc. I think that making sure you update that many documents will be challenging (i.e. if you have to deliver 100+ new How To leaflets, it would be very easy to miss number 87....)

[beagley]

RamonS,
A worthy defense! But, seriously, then why would "Stylesheets" be Content? Or why would Aliases or Variables be Project? It's an endless discussion, I guess. And I'm certainly not arguing that there isn't a funny kind of logic to why certain things are located in one or the other... of course there is some logic, but the need to explain the logic sounds a lot like an author explaining why he wrote a certain chapter or left out all punctuation. Writing (and films and software interfaces) should speak for themselves as much as possible, they shouldn't need an extended commentary. I want software design that makes my job (technical writer) obsolete and unnecessary!

I also want a pony.

Anyway, my vote would still be for Content to equal topic files, images, and... snippets. (It troubles me that we have Snippets at all, honestly. Topic files and snippets should be functionally the same. Or maybe they are? The whole idea makes me feel like snippets are just a feature for marketing. Unless I'm missing something?)

My other idea would be to get rid of the dichotomy all together. Have one, single file-browser instead of two. I have yet to find an advantage to having Content Explorer and Project Organizer be two different browsers... and I continue to stumble over the disadvantages. (Namely: "Where are my stylesheets? I have no idea," and "Why can't I create a folder here? Oh yeah. I'm in the Project Organizer. No folders allowed, for some reason.") Among other things, it bothers me that the root level tree structure for each one, "Content" and "Project" appears in the respective windows. A single-trunk tree does not need a trunk, it should start with the first branches.

I wonder if my annoyance is partly triggered by never knowing which one I am in. On my screen right now, the Content Explorer accordion button is highlighted in orange. The Project Organizer button is highlighted in blue. Without looking up at the items, I have no idea which one is currently selected. Now that I've looked, I've re-learned that orange is the "selected" color. But blue is the highlighted or "active" color for every other interface item on my screen, including text selection... so, for the accordion, it's reversed? Kinda bizarre.)

If anyone can help me figure out how to alphabetize items in either the Content Explorer or Project Organizer, please let me know. I've tried opening the files in Windows and sorting them all by name in a Details view and then relaunching Flare... but no luck.

I'm guessing that Flare's file-browsing interface has a cache or some kind of underlying file order that overrides the Windows browser. Or something?

-d

[RamonS]

I think you just don't see the forest for all the trees. As far as I can tell from forums posts of the past years this was never an issue of such dimension. If feel that strongly about it file a bug report here: https://www.madcapsoftware.com/bugs/submit.aspx

[Andrew]

(It troubles me that we have Snippets at all, honestly. Topic files and snippets should be functionally the same. Or maybe they are? The whole idea makes me feel like snippets are just a feature for marketing. Unless I'm missing something?)

God, I have had the same thought many times! I want to use a TOPIC as a snippet. The current method for doing so is to create a snippet, then create the shell topic for it and insert the snippet. Why do I have to do that? I think we should be able to use another topic just like a snippet.

Of course, I wouldn't be so upset about that if Flare had a reasonably sane snippet management system, but it doesn't. The snippet dialogs are wretched for any large number of snippets, and using the Content Explorer is only marginally better, since they are stored so far from the content they are related to.

I think some kind of intelligently-implemented embedded fast-search across most areas of the application would make a lot of these annoying management scaling issues fade.

[KevinDAmery]

Re: Alphabetical Order: I think this has been reported before when using network drives. It seems that the order things get displayed has something to do with the server as well as your local system, so it may not be alphabetized properly. I ran into this issue once, but it cleared up: I know that at the time that it cleared up, I was using the "Show Files" function above the content explorer, but I can't say 100% whether that's what actually fixed it or if it was a coincidence.

Re: Snippets: Snippets = topics works fine if you're making snippets that are topic sized, but it breaks down when you have ones that are smaller. In my case, I have many snippets that are paragraph sized or smaller, and sometimes I put two snippets in one paragraph. I can't see doing that with a topic.

The idea behind snippets is to contain content that will be used in multiple locations. It seems logical to me that you're more likely to have short chunks that you reuse than long ones. But ymmv....

[beagley]

I tried fiddling around in the "Show Files" split-screen thing.

Very odd feature, that. You can sorta break the interface if you click and drag things around too much or drag them between split screens...

For whatever reason, the "Show Files" split screen has headers for Name, Size, and Date Modified, and these headers are CLICKABLE, but nothing happens when you click them. It is like they tried to build a secondary "sorta filebrowser but note quite" but couldn't quite make up their minds what its capabilities should be?

Okay, I've decided my bug/feature request will be: "Please replace both the Content Explorer and the Project Organizer with a single, more capable file browser that incorporates a few more of the standard features of file browsers."

Can't hurt to ask.

In the meantime, if anyone has a clue on what's up with alphabetization, please let me know.

Cheers all!
-d

[RamonS]

Good luck with your request. I hope you added some more specifics as to what exactly you want that new gizmo to do.

[wclass]

To comment on one of your original questions about numbers of targets and TOCs, yes, I think it sounds like too many - have you tried working with condition tag sets?

One of my projects has around 800 topics and I generate 4 main output targets - one for CHM, 2 webhelp (depends on roles) and a Word file for release notes. The content is very similar and there is a lot of overlap, but they are not exactly the same. For this I have one TOC and one target for each of the outputs. I use a condition set called "outputs" to manage these ones.

However in the project I cover about 35 different functions, like mailings, meetings, payments, fees, securities, ... (you get the idea). I often want to create a print file of just one of these sections - sometimes for a How To but often just for reviewing. I have set up another condition tag set for functions, with entries for each of the 35 areas, and every topic is assigned to a function.

Then, I have only one "review" TOC with all the topics in it, and one print target to match, but when I generate I select the condition to include and exclude the rest. To make it work properly, I also have "functions" for front matter, etc, so I can include a table of contents, copyright page, or index in the output.

So I need my original 4 targets/TOCs for the main help output, but then I only need one more to get lots of different printed outputs. When generating, I need to change the selected conditions, and I usually change the output file name as well, but that is all.

This works for me. It is also easier to maintain if I add or remove topics.

[Andrew]

Re: Snippets: Snippets = topics works fine if you're making snippets that are topic sized, but it breaks down when you have ones that are smaller. In my case, I have many snippets that are paragraph sized or smaller, and sometimes I put two snippets in one paragraph. I can't see doing that with a topic.

The idea behind snippets is to contain content that will be used in multiple locations. It seems logical to me that you're more likely to have short chunks that you reuse than long ones. But ymmv....

Obviously, in an ideal world, we would have both types of snippet (or shall I say, we'd have snippets as they are now -- but with a better interface -- and then we'd also be able to insert an existing topic into another just like a snippet). I was not in any way suggesting we do away with the current style snippets. Just provide better (more scalable) management.

[Alice]

Hi Douglas
In fact I don't really understand what bothers you more: the number of targets or the inability to get files in alphabetical order.
As for the former, Why not use global project linking.
Keep running your present project and make it master project. Create child projects(choose the most appropriate base for classifying them) instead of folders in Project organizer. Thus You'll have a bearable number of targerts in each project. Configure the import file so that all needed topics are imported on building the target you need.