Well, the coding/planning part of the work is over, and now I'm onto the big cycle of documentation.
It took a couple of weeks to really get going on the project: the first week was spent doing research into the capabilities of the Creative Suite, and the next was spent exploring the variety of ideas I'd had. Most of them, sadly, ended up being junked as being a bit too complicated for non-technical folks to follow (the designs really did have to be idiot-proof: we'd previously sent PDF proofs to people who still had trouble signing into Windows!), but finally I had a set of ideas that (a) worked, (b) saved a lot of time and (c) don't crash unless the user is really, really trying. So I'm happy.
Sadly, there wasn't enough time to be able to set up an proper intranet for them, which I still think would have been quite handy; I'm doing the documentation as a small model of an intranet though, just to demonstrate the ideas behind it. You never know: I might get a call-back!
My plan is try to make the documentation sufficiently interlinked that it's never too hard to find the walkthrough that you're looking for: to write lots of small chapters, with plenty of links between them, and to reuse the same chapter structure wherever possible. (Lazy - or consistent? A bit of both, perhaps.)
It was a great couple of weeks spent in London, though, and a great little bit of work to be getting on with to get me back into the swing of things. I didn't manage to write any Java that week, but at least the old grey matter was getting a bit of exercise nonetheless.
Next up: finish this darned documentation, and then start writing my applets!
Thursday, 22 July 2010
Friday, 9 July 2010
Messy Acrobats
We all hate losing work on a computer. And yet it continues to happen, through crashes, momentary incompetence, or glitches. Which is why a lot of software companies do their level best to ensure that this happens a little as possible, or that files can be recovered when they fall apart.
Which is why I'm a little worried about some behaviour I've been finding in Acrobat 9. One of the big draws of the latest couple of versions of Adobe's PDF creating software is the ability to do a shared review, where - by uploading the file to a central server - a bunch of users can write and reply to comments on the document to get it ready for final production. It's a fantastic idea, and far better than the old approach of emailing everyone a copy of the file, and trying to hold further discussions over email, compiling all the comments and finally working out what to do.
But here's the problem: with Acrobat 9.x, you must have a copy of Reader 9.x to get this feature to work. If you're working in Reader 8.x, a dialogue box pops up when you open the file to tell you this.
And then it goes away, and the commenting and online review tools all appear, exactly as you'd expect.
Great, you think. Maybe it will work after all, and the problem was exaggerated. So you blithely go through, add a few comments, ask for a margin to be reduced or a graphic sharpened. And you hit the "Publish Comments" button. Nothing much seems to happen, but hey - all the comments are there, right?
Except that the guy who sent out the review can't see them. He calls you up, asking you to upgrade to Reader 9 - which you do. You open up the file again, and suddenly BAM! - all the comments are gone. Reader 9, it seems, opens the file, talks to the server, and - seeing there are no comments - syncs your file to the file on the server.
It does beg the question: if you'll lose all the annotations you've made when you upgrade to the correct version of the software, why does it even allow users to make them? Why not just have a flag in the file that says: if opened in Reader 8 or below, disable commenting features?
I'm quite surprised that this hasn't been noticed yet, or fixed - perhaps it's not such a bad problem as I thought, and the other comments are recoverable. But software shouldn't give you such a heart attack moment, I'm sure.
Anyway, I'm going to go back to trying to find a more elegant solution!
Which is why I'm a little worried about some behaviour I've been finding in Acrobat 9. One of the big draws of the latest couple of versions of Adobe's PDF creating software is the ability to do a shared review, where - by uploading the file to a central server - a bunch of users can write and reply to comments on the document to get it ready for final production. It's a fantastic idea, and far better than the old approach of emailing everyone a copy of the file, and trying to hold further discussions over email, compiling all the comments and finally working out what to do.
But here's the problem: with Acrobat 9.x, you must have a copy of Reader 9.x to get this feature to work. If you're working in Reader 8.x, a dialogue box pops up when you open the file to tell you this.
And then it goes away, and the commenting and online review tools all appear, exactly as you'd expect.
Great, you think. Maybe it will work after all, and the problem was exaggerated. So you blithely go through, add a few comments, ask for a margin to be reduced or a graphic sharpened. And you hit the "Publish Comments" button. Nothing much seems to happen, but hey - all the comments are there, right?
Except that the guy who sent out the review can't see them. He calls you up, asking you to upgrade to Reader 9 - which you do. You open up the file again, and suddenly BAM! - all the comments are gone. Reader 9, it seems, opens the file, talks to the server, and - seeing there are no comments - syncs your file to the file on the server.
It does beg the question: if you'll lose all the annotations you've made when you upgrade to the correct version of the software, why does it even allow users to make them? Why not just have a flag in the file that says: if opened in Reader 8 or below, disable commenting features?
I'm quite surprised that this hasn't been noticed yet, or fixed - perhaps it's not such a bad problem as I thought, and the other comments are recoverable. But software shouldn't give you such a heart attack moment, I'm sure.
Anyway, I'm going to go back to trying to find a more elegant solution!
Wednesday, 7 July 2010
Science: It Works.
With a little help from some very nice people over on the Adobe Forums, some of yesterday's problems are now (mostly) solved.
Yes, there are issues with importing Word files into InDesign; both packages have suffered from feature creep over the last couple of versions, so the integration of file types only gets harder and harder.
But what really solved the issue was the appliance of old-style scientific trial and error. Going through the processes that InDesign automates by hand, and working out which one of them was causing the error. As it turns out, ID isn't keen on long footnotes which split across three or four pages (you know what? I'm not keen on them, either!) and as soon as that was taken out, everything worked perfectly.
Once again, the principle of working through a process and breaking it down into the most basic steps you can find to figure out what's going wrong gives results. Excellent. Now I can get back to what I was supposed to be doing, and automating as much of the typesetting as I can.
Yes, there are issues with importing Word files into InDesign; both packages have suffered from feature creep over the last couple of versions, so the integration of file types only gets harder and harder.
But what really solved the issue was the appliance of old-style scientific trial and error. Going through the processes that InDesign automates by hand, and working out which one of them was causing the error. As it turns out, ID isn't keen on long footnotes which split across three or four pages (you know what? I'm not keen on them, either!) and as soon as that was taken out, everything worked perfectly.
Once again, the principle of working through a process and breaking it down into the most basic steps you can find to figure out what's going wrong gives results. Excellent. Now I can get back to what I was supposed to be doing, and automating as much of the typesetting as I can.
Tuesday, 6 July 2010
Interoperability; or Play nicely, boys
I'm back at work for a while now, trying to convince two very separate applications to play nicely with each other.
In the red corner (as it were) is Microsoft Word, the very commonly used word processor & text editor. In the blue corner is Adobe InDesign, the heavyweight page layout software.
Despite the similarities of the two, there are some really fundamental differences between them, going right down to the basic level of what the software is designed to do.
Word is designed to make it very easy to type simple documents, apply some rough page and type formatting, and print it out or email it. Apart from a few character and paragraph styles, the formatting and layout options are pretty limited.
What Word excels at, though, is the process of writing the document. Find & replace is very good, with a useful selection of wildcards. A variety of forms of annotation are available, all relatively easily.
InDesign, on the other hand, is designed to create very high quality printed output, with as much typographic and graphical integration as possible, and it excels at this. It's fabulously easy to create inventive page spreads with precise positioning of all the elements. It's a doddle to combine multiple documents as a single book, and link between them all seamlessly in whatever output you want to create.
At some point in the publishing process, though, you'll need to take input from the authors (usually in Word or one of the alternatives) and put it into InDesign. This is where the problems begin to show.
InDesign doesn't handle the same number of annotation options, and anything that doesn't fit is just dumped out at the end of the document.
Word doesn't allow cross-references between documents, so unless you combine everything into one big lump, you can't end up with anything saying "See page xx", unless you want to manually update them all in InDesign later.
Luckily, InDesign has a great scripting toolkit. You can write bits of JavaScript that do practically anything you like with the document, which is what we're doing now. The trick I'm finding at the moment is that you have to work out exactly what you want from the workflow before starting the scripts (which is a good first step for any project) and then build them up very slowly.
These packages may not want to play well with each other, but with a little thought and effort, you can certainly paper around a lot of the cracks.
In the red corner (as it were) is Microsoft Word, the very commonly used word processor & text editor. In the blue corner is Adobe InDesign, the heavyweight page layout software.
Despite the similarities of the two, there are some really fundamental differences between them, going right down to the basic level of what the software is designed to do.
Word
Word is designed to make it very easy to type simple documents, apply some rough page and type formatting, and print it out or email it. Apart from a few character and paragraph styles, the formatting and layout options are pretty limited.
What Word excels at, though, is the process of writing the document. Find & replace is very good, with a useful selection of wildcards. A variety of forms of annotation are available, all relatively easily.
InDesign
InDesign, on the other hand, is designed to create very high quality printed output, with as much typographic and graphical integration as possible, and it excels at this. It's fabulously easy to create inventive page spreads with precise positioning of all the elements. It's a doddle to combine multiple documents as a single book, and link between them all seamlessly in whatever output you want to create.
The drawbacks
At some point in the publishing process, though, you'll need to take input from the authors (usually in Word or one of the alternatives) and put it into InDesign. This is where the problems begin to show.
InDesign doesn't handle the same number of annotation options, and anything that doesn't fit is just dumped out at the end of the document.
Word doesn't allow cross-references between documents, so unless you combine everything into one big lump, you can't end up with anything saying "See page xx", unless you want to manually update them all in InDesign later.
The solution?
Luckily, InDesign has a great scripting toolkit. You can write bits of JavaScript that do practically anything you like with the document, which is what we're doing now. The trick I'm finding at the moment is that you have to work out exactly what you want from the workflow before starting the scripts (which is a good first step for any project) and then build them up very slowly.
These packages may not want to play well with each other, but with a little thought and effort, you can certainly paper around a lot of the cracks.
Subscribe to:
Posts (Atom)