The architecture of InDesign's Document-object Model handling has always perplexed me. What should be a simple, straight-forward hierarchy of parent-to-child cascading style control is instead a haphazard peer-to-peer asynchronous spaghettibowl—a wonderful tribute to Pastafarians worldwide, yes, but hardly a good-working model for production of publications.
I understand that when InDesign was being developed, Adobe did not yet hold a marketplace stronghold against competitors like Quark Xpress, and a seamless user experience between applications was key to get people to switch from one to the other. But it seems by doing so, Adobe shot itself in the developmental foot. Either that or there was simply no master plan for an overall framework for document object modelling.
It's because of this that I really propose Adobe come up with a new structure. But how to do it without bricking the many tens of thousands of *.indd files out there? How to transition without destroying what's already been built? It's much like the 710 freeway in South Pasadena: finishing a simple gap of highway that would enable the entire system to flow better would essentially have to destroy an entire community of homes established over 50 years. Yet without it, things are a mess. InDesign 5 files are already incompatible with previous files, so I don't see too much harm in bricking them again.
To illustrate my point, and the urgency, let me bring up the issue of Master Text Frames. Anyone who's been using InDesign since the turn of the century has always seen the 'Master Text Frame' option on the 'New Document' window, hanging there pointlessly like a coccyx. The reason for its existance has been the subject of much debate by several critiques ranging from independent design journalists to Lynda tutorial videos. Even though you can perform the same function by simply creating a text autoflow on a master page, it's still there as an option. And, as far as I know, it's an option impossible to toggle it any other menu-based means once the document has been created. This demonstrates that the feature's original purpose (as well-intended as it might have been originally) has been deprecated in the scheme of a bigger picture that's developed since then. We now have book files, template files, multiple masters, XML support, etc, etc... InDesign's original concept was all laid out during a period in history where we were transitioning out of the "Windows 98" peer-to-peer mindset of the 90's before returning to the time-tested server-client system. It's just better than peer-to-peer for not only internal networking but design structure.
If that doesn't convince you, let me ask a question: Suppose I wanted to apply a template file (or better yet, elements of one) into an existing InDesign document? Sounds crazy I know, but we do this all the time in the web design world. So imagine if instead of master pages being embedded within documents, they were actually external template files like *.css, with stylesheets and scripts built into them? And like web structures, imagine that they controlled things from a top-down hierarchy to all the styles in all child documents of all book files?
indt > indb > indd.
Master object/paragraph/character styles and libraries (and any other attribute you can think of) would be defined in the master document templates. From there. In book file, you would choose which template masters you wish to be associated with that book, and this selection of templates would carry down to the connected child documents. Finally, the child documents would inheirit these styles or could have their own embedded styles which would override the master styles, if desired.
Now that I think of it, with this structure, indd files themselves would not even need to be touched for those people who don't want/need whole books. So mabye bricking things is unecessary.
Compared to the peer-to-peer chicken-or-the-egg manual syncroninzation scheme in the indb pallete, it would be a simple automatic system ensuring uniformity among all involved documents in the book! And these template files, since external, could be used for many book files, automatically updating all of them. And we would never have to deal with the dreaded "UGH! Why is this style folder resyncing itself in a different order, and why did that style reappear when I just erased it!?" syndrome forevermore.
InCopy could really become a truly useful application if done this way rather than a cheaper watered-down version of InDesign for editors. You could have a good chain of command between designer, editor, and typesetter. And it would be one step closer to seamless integration between print and web. If a better DOM manages to be produced, I have a feeling InCopy is going to go by the wayside, much like ImageReady.
So yes, I urge that a serious redesigning and redevelopment of InDesign's style / object hierarchy be looked at, for the sake of humanity! I'm sure I'm not the first one who has thought of this. It just takes an executive decision somewhere in San Jose. Here's hoping. Cheers.
Here, hopefully this will better illustrate what I'm thinking of.
And now that I think of it, this would also handle conflicting/duplicate styles. When selecting the templates for your book, let's say that two templates have two styles that are either identical in attributes and/or names.. It would alert you of this conflict, and the user could choose to block or impliment any one of those styles. And just like Links, a pallete could be made that shows active styles in a document file, and if you click on the info for that style, it tells you which template it's linked to.
On the far right, we see another situation where I choose not to have a book file at all, so the template is linked directly to the document. That same template can be also linked to a book file since it's external.
For documents that are linked to a book file, templates would not be permitted to be linked.
I think you misunderstand what a Book (.indb) file is. It's a collection of documents. It's not based on any template and it has no attributes to speak of other than a list of pointers to the component documents and a record of pagination (maybe). The component documents need not be based ont he the same template, nor any tempalte, nor even have the same page sizes or shapes, and a document may be contained in as many different books as you choose. Styles, swatches, master pages and pagination can be synchronized across the book, or not, as you decide. Your proposal, if I understand it, would completely destroy this flexibility.
I think you misunderstand what a Book (.indb) file is. It's a collection of documents. It's not based on any template and it has no attributes to speak of other than a list of pointers to the component documents and a record of pagination (maybe).
Yes, I noted that.. the indb books wouldn't hold the styles within them. It would only pass them from template to document collections.
Styles, swatches, master pages and pagination can be synchronized across the book, or not, as you decide.
Yes. That wouldn't be interfered with. You can still embed styles within documents, or have them passed down from templates. Like I said, what I'm proposing is only a way to feed styles top-down from templates. The way things work now, a template disconnects from the document the moment you load it. I'm saying it should retain its connection as a master page.
What I'm really proposing is the disengaging of embedded master pages and allow links for external master pages. Might as well make those the templates since we already have them.
Right now, when you have a book, you select one of the documents in that book to be the one with the styles that are passed onto each of the other documents.
When you sync up, it copies and embeds those styles into each *.indd file.
I'm telling Adobe, stop that! Stop embedding styles in each *.indd. Instead, select a master/parent template(s) to put the styles in, and pass those styles down as links to the slave/child documents. The *indt files would work perfectly for this.
If styles could be linked rather than embedded, it would rid us of the rickety nature of the current syncing system. It would be cascading, which would work tons better.
We have a "Links" pallete for images. What we need is a Style Links pallete.
When combining documents from different sources where ther is a common style name, but the text is clearly not intended to be styled the same. It's not a common occurrence, I suspect, but it does happen (in fact it has happened to me). All things being otherwise equal, it's faster not to synch styles than to define new ones and rename/reassign in many cases. Remember, too, that documents can be in more than one book.
You are mnissing the point. I don't want to synch the styles at all, not resolve a conflict. I want the smae name, but different defintions applied just as they are. Your linear proposal is way too rigid.
I don't know if you realize it, but you're speaking in this forum to other InDesign users. Peter and others of us here are expert InDesign users but we are not Adobe employees. We have no ability to make changes in the way InDesign is structured. If you have suggestions you need to make it through a feature request to Adobe: Adobe - Feature Request/Bug Report Form
Oh, I know, but rather than acting like George Zimmerman and reporting everything to the authorities every 5 minutes I thought I'd pass my ideas around the community first to see what people thought about it.