best practice for Publication size / amount of pages
do you any experience to share when it comes to larger publication objects ?
We plan to set up a publication (for PowerPoint output) which may have up to 80 - 100 (!) pages (containing a lot of pages with pure text and various discover chart objects - lets say 50/50 ratio).
Should we expect performance issues or any other problems? Whats the best practice for such a setup?
Thank you very much,
It is impossible for me to know whether what I am about to describe had to do with my company's configuration/server "horsepower" or the software.
I had a report that was about 30 pages. Mostly tables, some charts, no dynamic text -- just some labels and footnotes here and there (fixed text). That ran well.
I then had to update the report (which was focused on the first calendar quarter) to add a Year to Date version of all the same reports, as well as the current quarter. So it doubled in size (plus a few new ideas got included). That did not work. What's worse is the whole publication became unstable/unusable, so I had to start over.
For clarity, this publication was many many underlying discovery objects, not a handful of discovery objects iterated over multiple members of a dimension, so it may not related to what you are doing. I have done other simple publications that then iterate and never run into trouble there.
We've built numerous publications (PDF, Word and PowerPoint) and all have worked. Out largest template is 70 pages long - with every type of content item imaginable.
What you need to be aware of is this:
- A large report does take longer to render. It should: 2-3 queries per template page over 70 pages is like running almost 200 queries per run. If you ran that for 50 slices, you would be executing 10,000 queries per batch! Personally, I would break up the package and do smaller reports - and it won't kill your data source. (I also think very long PowerPoint decks are a little unstable themselves when you open them in PowerPoint itself.)
- The editing process is best done using 'prototyping'. That means building out a small example of the entire package and getting it right before expanding it out completely. This includes layout, formatting etc. It is much better than creating the entire report and then changing the design and layout over and over again. [One technical comment: Publish shares common queries if used multiple times. If you copy-paste items be aware that they are not 2 independent items, but rather conjoined elements. We found this effect after much trial and error. It turns out its not a bug, its by design for performance. We submitted a feature request to provide the alternative and I believe its on the near term road map].
- Keep the formatting of content tight and almost exclusively in Discover or Illustrate. Doing adjustments in Publish is slower and can create inconsistencies. (Try and avoid the 'unlinking' option for discoveries).
We have built several successful publications.
My biggest suggestion is to write all the required text in notepad, text editor or Word and then copy paste into the publication. The browser based text editor is a little temperamental.
Second recommendation is to put all the content into the template and then do the slicer wire up at the end.
Last thing, is that we totally underestimated the server resources needed. We were trying to render 500 reports a night on a small server (I think it was 8 core / 16Gb memory) that also hosted the data source (MS cube).
thanks for replying and sharing your experience!
You named some important topics I already was wondering about!
Our report setting is more like an "annual report" which will be rendered from time to time for draft versions and the final document - so I think facing longer rendering times might not be our main concern. However, dividing it into smaller chapters (multiple publication objects) might be a good approach.
I already had some "wrangling" with the "temperamental" text editor NPANS mentioned and hope it would be sufficient enough to only have "raw" text inside the publication and do the necessary fine-tuning via PowerPoint later on.
samuel alma : are you recommending not to use the UNLINK-function? (It was the one I would have heavily relied on...).
This is because we optimally will start building the report with just a handful of discoveries - each page is showing content (graph, dynamic text and editorial text...) for a single element from our main dimension (lets call it "dimension 1").
My current approach is to set up a few template-pages that I can duplicate (especially for keeping format, position etc.), then unlink the chart from the duplicated page and select the next element from "dimension 1" within the underlying discovery
(...however, I don´t have a handy solution for the dynamic text by now ;)).
Here is a simple draft of the concept:
Example for templates 1-n (usable for most of the pages)
Duplicated Templates - each page is set up with one specific element from the main dimension
(What I am used to working with other BI tools is some kind of "page selection" I found hard to reproduce here)
I would appreciate your thoughts on this!
Thank you very much, best regards
The "unlink" function is focused on either creating a one-off analysis or for allowing the visual to be formatted in the publication uniquely, separately from its original design in Discover (effectively, the same reason). I don't think its primary purpose is to facilitate copy/paste.
I would build the variations in Discover (stick them in a folder), and simply add each one. It will give you more flexibility in the future and better content management options.
To keep formatting tight, use the rulers, snap to grid, master pages and the "guides". This is a better proposition rather than copy/paste of pages etc.
I don't understand you last comment on "page selection". Perhaps you can explain it.
Thanks again for your contributions!
samuel alma I think the main problem for me is getting used to the thought of having such a lot of single discoveries (for my concept likeley 40+ objects for this publication)...plus having them all saved (spammed :P) into the CMS, plus dragging and dropping each object into the publication...
Then I fear the moment someone wants "the text font to be +1 point taller" or switching "the dark blue bar into a light blue" ...forcing me to touch each and every discover object again (however, the UNLINK function doesn´t solve this problem either ;))...
What I mean by "page selection" is that I was hoping to be able to stick with a few discover objects, duplicate my page templates as needed and then select for each page by which element of my dimension the content should be shown.
In Present, I realized a similiar szenario by simply adding a new slicer for each page which has a "handpicked" set of elements via the advanced settings
ATM I don´t see a way to achieve this in publish (slicer option here is meant to be used in another way...).