Time Investment to Learn InDesign Scripting

[freshmurry]

I'm looking to learn InDesign scripting (preferably JavaScript) to automate tedious and time consuming layout work. We have over 500 InDesign files that all need to transition into a new layout format. What is the time investment in getting up to speed to be able to really dig in and proficient enough to create scripts to complete overwhelming tasks? Should this be something learn on the job or outside of work at home in the evenings?

[Jongware]

Years and years

Personally, I already was a pretty proficient programmer before I ever looked at JavaScript, about 15 years of earlier experience with extremely various programming languages.¹ That counts for a lot – at that point, learning the syntax of JavaScript was no problem. (Well, and memorizing all of its weird little bugs features that makes it so dear to us all.) If you know how to program, you can dive in at once with a basic JS course or web site. Beware that InDesign's implementation of JS is not updated over the years, and so you'd typically rather look at old tutorials than the very latest!

Then again, if you don't know how to program and cannot tell a global from a for loop, you'll need to learn how to first, before you can do more than very elemental cargo cult programming. You might as well know right off the bat that, when asking for help, cargo cult programmers are prone to drive "real" programmers insane, because their questions are usually ... well, the wrong kind of questions.²

Apart from that, learning how to address InDesign's Object Model properly is an exercise in itself! The relations between the different objects are not always clear (or, come to that, logical). And there are lots of objects. And there are lots of properties per each object. And there are lots of functions per object. Even those that should be aware of a few handy websites to look up the data you want, find it easier to just drop their questions in here rather than browse through – wait, let me check – 1,101 pages, for ID CS6, because it's faster if you have no clue what to look for.³

You mention "transition into a new layout format" without further specification, and depending on these, it could be a piece of cake (for a relatively experienced ID scripter) or a task that a paid software developer would shirk back from. For the former, think stuff like "all paragraph styles should be unified", for the latter "the page size of these heavily formatted documents, including all images and tables, need changing".

Notes

¹ From various dialects of Basic via machine code of different processors up to more serious languages such as C and Pascal.

² The "wrong kind" is hard to explain, but the symptoms usually are that the answerer starts to stutter, flinches back, does a double-take, and tries to explain in simpler terms. And the questioner doesn't understand that either.

³ Actually, "what to look for" is usually (but not always) the exact name of that function in the UI ...

[Vamitul]

Short answer: if you are thinking of learning scripting just to deal with those 500 files, it will take longer to learn that just fix them up by hand. If you don't want to do them by hand, find a scripter, pay him and have it done.

Long answer:

(I'm going to assume a 5 to 6 hours a day for this)

Learning just basic programing, how to think a program, how to structure it, understanding some basic algorithms and data structures will take you anywhere from 8 months up to NEVER. Some people are just not cut out for it. Most designers are terrible at it because they have a much more visually orientated way of thinking. One quick test: can you write a recipe for an omelette in a way that a brain-dead dog could replicate it? If you start with something like "crack three eggs" you already lost. What happens if you are out of eggs?

Next step would be to (properly) learn JavaScript (you can begin with some JS while learning to program, but you need to focus first on learning concepts, and only then on things like syntax and particularities of this/that language). This is a good-news/bad-news situation. ExtendScript is a bit older than the dinosaurs and was last updated when T-Rex still ruled the world. So you will not have to bother with frameworks and libraries. But, because it is so old, you will not find much documentation for it, just for newer versions and with a focus on web technologies, that do not apply to InDesign. Overall, if you already have a solid foundation and are very committed, you can get to a proficiency level in JS enough to let you write functioning but horrible programs in about 3-4 months. After about one year your programs will not suck so much your code will start to become readable (if you make the effort for that) and make sense to others too. "Mastery" will take you a few years.

Last step would be to get to grips with the DOM. Besides the hurdles Jongware already explained, another problem is that by learning JS you will learn how things are/should be done for Web projects. InDesign is a different beast altogether, and you will have to actively "unlearn" some of the things you studied and became familiar before. Other things that you have learned and take for granted are just missing because of ExtendScript's age (Object.create or array methods and so on). Last thing I need to add about the DOM is that I've been doing this (scripting) for about 8 years now (4 of them as my full-time job) and i still have to check the (web-based) Object Model Viewer 4 times a day, so I'm no way near "mastery" level.

To recap, if you are really good and committed, you can get to writing functioning scripts in about a year and a half and get somewhat good at it in about 3 years. However, because you asked the question again in a different thread I have the feeling you are looking for someone to tell you that: "Hey, it's easy-peasy. You just have to read this and that book (feel free to skip the boring parts, and if you also skip the parts you don't understand it will be an easy 15-page read), then you copy and paste some code from the forum and stackoverflow and bam! You done it!" I can't tell you that because it would be a lie, but I would love to be proven wrong!

[jb_alvarado]

I think people only can answer this question by them self. To ask others looks like there is no programming knowledge at all, then I would agree with the writing from Vamitul and Jongware. But for people that a not new to scripting there is hope, to get it done faster.

For example: I'm not really a programmer, I now good shell script, I have write in the past some little js and close to js plugins for 3D programs, and I know basic web languages.

Now in 8 days I was able, with help, reading and copy example codes to write a indesign script, with that I can format a imported word document. The script cut out the header and place it, format paragraph by paragraph, it finds quotes and numeric/alphanumeric lists and special text blocks. I believe when a pro, here in this forum, will see it he would only laugh about it, but it does what it should do.

The biggest problem, in my opinion, is not javascript, it is the indesign api.

[Trevor:]

Just adding my thoughts to this one.

Yes to become a Master or Ninja takes years.

And yes remembering the whole DOM side would take years but on the other hand there's not too much point in even trying to do that as long as you are aware of the basic DOM structure then Jongware made it easy for us to find the required methods or properties so all we have to do is remember there's something out there and the "call" Jongware to look it up.

I spend most of my time scripting and writing extensions for Illustrator, I would rate my "by heart" knowledge of the Illustrator DOM as pretty pathetic but I writing some very powerful stuff and can write it pretty quick.

The first script I made was to color the selected text, that was a one liner.

The second script I wrote was a complex script for creating a document with formatted tables and graphics. That took me I think about 2 weeks to produce the I think about 2000 lines of code, that was years ago.

I still use that script regularly many years later. True it was written badly, the sort of code one would be completely embarrassed to share in a non-binary format but the fact of the matter is that within about 2 weeks of starting I have a really useful (badly written) script that I regularly benefit from.

Spending an hour a day answering questions on the scripting forum is a great way of learning. Them Adobe manuals as badly as they are written are still a valuable source.

[Loic.Aigon]

Hi all,

Entering the dance. My fellows here have pretty much said everything already. I also started writing scripts for my on purpose. I started with an already challenging one that I was never able to achieve at the time. I got chance to be helped then and I am thankful for that.

So I tried to learn well. I bought Peter kahrel's scripting guides at oreilly in combination with InDesign Scripting guides. Little by little, I have started learning more and more stuff.

Every single line would have issues that I learned to solve and on top of that foresee and anticipate the issues. Vamitul's example with eggs makes a lot of sense to me in that sense.

I don't think I am perfect today but I can achieve most of my goals and to get there it took me years. Learning Javascript (well ExtendScript to be precise) is only one side of the challenge. Knowing the DOM is also critical.

Good practices at last are also the icing on the cake.

Nothings is unachievable but it clearly requires commitment

[Vamitul]

Seeing how you guys got started makes me think that either you were very lucky or I was very unlucky (second options seems truer).

The first complex script I "wrote" (as in copy-pasted a bunch of stuff I had no real idea how it worked) had to do a lot of text manipulations on very large (500+ pages) documents. One of the things it did was to remove all spaces inside some specially-marked anchored textframes. It worked just nicely on the samples it tested it with so it went into daily production. However, it had a nasty bug: if a story only contained one of those marked anchored frames it will also remove all the spaces in the anchor's parent story. None of the samples I worked with to develop the solution had just one anchored frame, and indeed something like that vas exceedingly rare. So the script was used without any apparent problems for about two months, producing over 300 documents when the whole thing came crashing down. One document sent to the print office had no space characters in it. Going back it was discovered that about 40 documents printed in the past two months (and distributed in 20 countries around the globe, in runs ranging up to 15.000 copies) had chapters where all the space characters were missing!!!

The company I worked for then had to pay damages to the client of over 45000 Euros. Lucky my bosses where AWESOME and my colleagues where AMAZING, so not only I did not get fired, I was actually encouraged and supported to keep at it and learn scripting better (the big boss brought me a subscription to .... and said something like: "learn so next time you screw up this bad you can at least blame it on bad documentation").

I guess my point here is that a script done with 8 days of experience behind you might end up costing not only your job but someones entire business.

[jb_alvarado]

Ouch, ok that is a bad experience! When there is no control instance after making the layout, then I would not do this step to. I think by me it is a bit safer, because I only get the word documents from one person, where I can be sure that he always use the same formatting. And after my part is done there comes three rounds of reading, two times for checking the text and one time the text breaks. And we are only a little non profit organization, but of corse it would be also a bad situation, if there goes something wrong.

[Loic.Aigon]

Wow Vamitul​, thumbs up for your boss ! Of course your company had bad times but they could foresee the future benefits. That's very clever from them and I am sure they don't regret it now

But yes automation or not, small mistakes can have dramatic consequences. And it's definitively good to have Control Quality even with automated processus or at the very least an escaladed sequence of deep testing.

[Jump_Over]

So Varmi -  you were lucky, finally

You've met a very rare kind of boss

I get fired cause people in DTP became a 'lazy guys' and everything there became an 'easy cake'...

Nowadays company does not exist anymore

Jarek

[Keith_Gilbert]

This seems to be an appropriate place to put in a plug for my Lynda.com/LinkedIn Learning "InDesign Scripting Made Easy" course. The purpose of this course is to try to explain some of the concepts of scripting InDesign, for non-programmers (designers). I firmly believe that anyone can learn how to find, install, use scripts. And then, little by little, learn to make modifications to scripts and cobble together simple scripts out of pieces built by others. Then, eventually perhaps, begin to write some of their own code. See InDesign: Scripting Made Easy

[Ben-Berkadia]

This is not me, but I found Brett Elliott's InDesign Javascript videos on YouTube an excellent resource to start from.

Brett ELLIOTT - YouTube

[S Hopkins]

The course I taught through Digital Technology involved one week of intensive training with a correspondence follow-up and often another week one-on-one. Most students became quite proficient within this time frame. There is no end to the learning curve, however; as the technology and applications keep changing...and you can always find another--or better--way to accomplish the same task.

Shirley Hopkins,

author: AppleScripting Adobe InDesign and Automating Adobe InDesign CS4 with ExtendScript

[defaultd1fn4n1tf5jx]

@S Hopkins I'm in search of a class/course to begin to learn InDesign scripting. Are still teaching this course?

[Sunil Yadav]

I can be available to provide you one.

Sunil

[S Hopkins]

Hi,
You can find me on WyzAnt.com teaching InDesign and other Adobe
products as well as scripting (AppleScript and ExtendScript).
Shirley W. Hopkins