Don't Be a Tech Support Nightmare

Synopsis: even if you're under stress, try to communicate clearly with the people in tech support. There's a little checklist at the end of this post.

In this blog post, I want to share some issues people in tech support are facing, and raise some awareness of the difficulties anyone in tech support has to contend with.

It all comes down to communication, or a breakdown thereof.

I am sure a lot of other small software companies are facing the same issues - so please, takes this plea to heart next time you're dealing with software created by a small company.

It might come as a surprise, but in small companies like Rorohiko, tech support is being run by real, live people. We don't have a complex automated response system - if you e-mail support@rorohiko.com, you'll be answered by a real person. We go to great efforts to run a tidy, responsive tech support department. We provide world-class support on our software - whether it is free or not. We respond quickly to e-mails, most of the time within hours.

Yet we still run into the occasional tech support nightmare.

The problems we're facing are manyfold.

1) Not Enough Info

First of all, people often don't give tech support people any information at all, or way too little. You'd be surprised how many times we get an email that simply states:

"Dear support,
It does not work. Please fix ASAP!
Bye,
John"

This is sometimes prefaced with some upset diatribe about things being urgent.

We then need to guess what 'it' is? More than once the 'it' that did not work turned out to be a software from a different company all together.

(So - no, we don't do electronic PCB design. Nor knitting patterns. And no, we're not Adobe. We make task tools to help do things faster with InDesign - plug-ins, extensions, little applications. We don't make InDesign).

As we're servicing both people on Macintosh and Windows, we also need to figure out whether this person is using a Mac or Windows, and what the version is of their OS - XP, Vista, OS X 10.5, OS X 10.6? Then we also often need to know what version of InDesign they are using.

We sometimes use little tricks like looking at the raw e-mail headers of their e-mail - that might give us a clue whether they're Mac or Windows users, and sometimes even what version of the OS they're using. So if their hidden e-mail header says their e-mail program is Outlook, that's a give-away that they're on Windows.

2) We Cannot Reach The Person In Need

Our e-mails get thrashed by their spam-killer.

Or their e-mail server rejects our e-mails because it deems them suspicious - so we get our e-mails back after a few days with 'Undelivered e-mail returned to sender'.

Or our e-mails don't get through because their e-mail inbox is full.

So the scenario is like this: we get a question, and we reply, typically within a few hours. Our reply does not reach its destination.

We get an upset follow-up. We try to use a different 'sending' e-mail address, most of the time to no avail. We get an even more upset follow up,... and so on.

Sometimes people also post messages on forums saying things like 'Rorohiko does not answer e-mails'.

Luckily, most people have an e-mail signature, and such e-mail signature is a really Good Thing as it often contains a phone number. If we notice e-mails being bounced and we have a phone number, we give them a call - problem fixed.

But all too often there is no phone number - all we have is a first name and some email address @gmail.com or @hotmail.com. What's a tech support person to do?

3) Not Enough Answers

The third problem is that people often are unable to answer the questions we ask - they're often under stress, and have trouble concentrating on what we ask them. A dialog could go like this:

>>>

It does not work. Please fix ASAP!

<<<

Hi,... So sorry to hear that. 


Could you let us know the name of the software you're having trouble with? 


Also, we need to know whether you are on a Mac or on Windows. 


Furthermore, let us know what version of the OS you're using: is it XP, Vista, Windows 7? Or OS X 10.4, 10.5 or 10.6? 


And if InDesign is involved, please give us the version number - CS, CS2,... CS5? 


Thanks so much!


Rorohiko Support

>>>

I am on CS4. I need to get this out by tomorrow. Please FIX ASAP! IT IS URGENT

<<<

Thanks so much for that information! That helps a bit - but we need more. What is the name of the software you're having trouble with? We have many products available, so it could be any one of them.


Rorohiko Support

>>>

The product is called Adobe InDesign. And MS Word. HELP ME!

(ok - here we can kind of guess the issue might be with our TextExporter - that's the tool we most commonly see being used together with InDesign and MS Word).

and the e-mail ping-pong drags on...

4) Don't Contact support@rorohiko.com - Post It On a Forum Instead


This is one of the biggest issue we're facing. Instead of asking us for help, some people simply assume they are on their own, and look for help with our software on public forums.

That's OK - the people on those forums are often very knowledgeable, and very helpful, and you might get a solution, or they will point you to support@rorohiko.com.

The problem is that we're kept out of the loop - i.e. if there's a problem with any of our software, we'd love to hear about it.

So, our plea: if you have any issues with our software, let us know!


5) Web Sites Do Go Down

We are using an ISP located in the USA, and we're pretty happy with them (http://www.arvixe.com if you need to know).

But every so often, just like everyone else's, our web site goes down for 10, 20, 50... minutes. It might be DNS failure, a hardware replacement,... Sometimes there's some other internet issue.

If you try to reach http://www.rorohiko.com and you cannot reach the web site here's what you should do:

1) E-mail support@rorohiko.com to let us know that our web site is down - we're not continuously monitoring it, so we're always happy if someone helps us out by letting us know.
2) Sit tight, and try again in a few hours.

Here's what you should not do:

1) Assume that because our web site is down, something must be horribly wrong
2) Put posts on public forums asking whether Rorohiko has gone out of business because their web site is down

6) We're In a Different Time Zone

Rorohiko is based in New Zealand. That means we're in a different time zone - so you might not always get an immediate response to your e-mail. We're almost a day ahead of the USA - so what is Friday in the USA is already Saturday here in New Zealand. If you e-mail us on Friday, we might already be out fishin'.

Most of the time we do keep our support department active over the weekend, but occasionally, e-mails won't be answered until after the weekend.

7) Be Impolite And Demanding On Forums

This is not an issue that affects us in tech support, but we do see it happen a lot, and I wanted to address it here, because it is also a communication issue.

Various forums like http://forums.adobe.com are run by volunteers - people willing to sacrifice their own time and knowledge for the greater good.

All too often, someone under stress busts in on these forums, and starts demanding a solution for a problem, preferably in ALL CAPS, and they NEED IT NOW.

Please, don't do that - keep in mind that software forums are like tech support run by volunteers. If a forum post does not get answered: that's how it goes. You cannot force volunteers to help you fix your problem.

Being polite helps. Being complete and concise helps too. Building goodwill by helping others in need helps too - so if you can help someone else, do it. By doing that, you increase your chances of being helped when the time comes you need it.

But don't expect help if you go bustin' in yelling you need help NOW.

Conclusion

So - if you are ever in the position of needing tech support - please think of the recipient at the other end, and help them help you.

Provide ample information from the first e-mail or post you send:

- Who are you? Make sure to leave enough info so you can be contacted. Provide an alternate e-mail address. Provide a phone number.
- What is it about? Make sure you explain what the name of the software or tool is you're having trouble with.
- What is the problem? Describe in detail what steps you are taking and where it goes wrong (e.g. something like "I then try to select the File - Open... menu but it is greyed out")
- Which platform are you on: Mac/Windows? What version of the OS? XP, Server 2008, Vista, Vista 64, Win7, Win7 64, OS X 10.4.x, OS X 10.5.x,...
- What version of the creative suite are you using: CS, CS2, CS3, CS4, CS5?
- Do you know how to create a system profile on Mac? (Go to the 'Apple - About this Mac' menu then click 'More Info...' and use 'File - Save As...' to save a system profile. Attach it to your e-mail).
- What version of InDesign are you using? CS4 has a whole range: 6.0, 6.0.1,... 6.0.5?
- Can you make one or more screenshots of the problem? If so, please do
- Can you provide a sample document? If you can, please do (but don't send a 1GB sample - try to make it as small as possible)
- Did something crash? If so, can you get the crash logs and e-mail them? If you don't know what those are, can you find someone to help you with that?

Finally, answer all questions you get in return to the best of your capacity.

Just sayin'

Cheers,

Kris

Kill The Caps Lock!

Here's a little tidbit that has made my life a little bit easier: kill the Caps Lock on your Mac.

I don't think I've ever used the Caps Lock key - all it's ever done for me is cause pain and grief and wrong passwords or inadvertent 'shouting' in e-mails. It's a fossil from days gone by.

Go into System Preferences, select the 'Keyboard and Mouse' or 'Keyboard' panel, click 'Modified keys...'
and set the Caps Lock key to 'No Action'.

Takes all of 10 seconds!

I don't know about you, but I love it.

Cheers,

Kris

BBEdit and ExtendScript

Quick tidbit for my fellow ExtendScripters. I am using BBEdit as my main text editor on Mac OS X, and I've set it so .jsx files are seen as JavaScript files. That adds lot of nice features that are also handy when working on an ExtendScript.

But when I am working on an ExtendScript, there is this little annoying thing: each time I started typing

  try

followed by a return, BBEdit's auto-completion would kick in and convert it to something like


  Try.these( 
function() { ... },
foo.bar.bind(),
this.bat.bind()
    )

Gaah! I didn't want that!

One of these minor annoyances - not enough to spend time on, got code to write, right?

But eventually, I got annoyed enough so I did the Right Thing and looked into it.

It's simple enough to clear up:

In the Finder, go to your home folder

Go into Library, then Application Support, then BBEdit, then Clippings, then JavaScript.js, then Prototype, then get rid of the file called Try.these


Oh bliss! It's like removing a pesky pebble from your shoe!

Some time later, I'll look into creating a proper 'try - catch' autocompletion that matches my ExtendScript behavior, but for now, just getting rid of this is just great!

InDesign Scripters and Plug-In Developers: How To Avoid Confusing File Duplications

In short: how to avoid copying or shuffling scripts and plug-ins during development on Mac or Windows.

When it comes to scripts or plug-ins, Mac alias files can be used as if they are 'the real thing' - InDesign will treat an alias file as if it is the script or plug-in it is referring to. I'll explain how you can use that feature to your advantage.

Sadly enough, a Windows shortcut file is not treated with the same respect by InDesign - a Windows shortcut file is simply ignored, so shortcuts are out.

Luckily, Windows has a 'hard-linking' feature that can be used in the same way as Mac alias files - I'll explain that too.

The basic idea is to avoid 'scattering' copies of your script or plug-in around your hard disk. As soon as you start copying stuff around, it becomes easy to lose track of which is which, and in the heat of the moment, you might get older and newer versions mixed up.

A typical scenario would be: you're creating a script that needs to work both on InDesign CS3 and InDesign CS4. You're testing and debugging - and each time you want to swap between CS3 and CS4, you need to copy the script in progress from one Scripts folder to the other.

And then the phone rings, and you're caught in mid-swap. After the phone call, you forgot: did you complete the copy or not? So, where is the most recent version - in the CS3 folder or in the CS4 folder? Frustrating, isn't it?

To avoid doing 'the shuffle', you can instead store a single 'master copy' of your plug-in or script somewhere on your hard disk.

If you are using a source code control system like SVN or CVS, the master copy would probably reside somewhere in a folder structure managed with the source code control system.

Then, instead of copying the script or plug-in to it's 'active location' (e.g. one of the InDesign plug-ins folder, or one of the InDesign scripts folders), you instead create a 'stand-in' which always refers back to the master copy of the file.

On Mac, you can use an alias file for that - pretty easy. Create an alias of the script or plug-in and plunk the alias into the proper InDesign subfolder - and everything will work as if the 'real thing' was there.

On Windows, you might be tempted to try shortcut files - but that does not work. Instead, you need to use a hard link, which you can create from a command-line window with the following command:

fsutil hardlink create [destination] [original]

where [destination] is the path of the hard link to be created and [original] is the path of the original file. Depending on your setup and Windows OS version, you might need to launch the command-line window as user 'Administrator', so you have enough privileges.

You can use this command to create hard links to folders as well as files - but I recommend you only use it for hard links to files.

Also keep in mind that this command only works on NTFS volumes (so FAT volumes are out), and both original and destination need to be on the same volume - but in most cases that's all you need.

Hard links are a low-level NTFS feature, and hard links to folders are not well supported in Explorer - and as a result, they're very dangerous things - they don't behave like Windows shortcuts, and that is where the danger lies.

Suppose you had created a hard link from a folder, and then you attempt to delete the hard link later on. Doing that in Explorer would actually also delete all the items that reside in the original folder - not what you'd expect. Explorer treats the hard link as the real thing, and when you delete a folder, it simple-mindedly will empty the folder first - blissfully unaware that the folder is still being used via the original directory entry.

Once a hard link to a folder is created, it's not easy to get rid of without also losing the contents of the folder.

In short: avoid issues - only create hard links to files on Windows; that's much safer.

There's another caveat with regards to hard links on Windows. If you use a hard link to a script file, you must make sure that the text editor program you use does not create backup files because that tends to mess up the hard link - typically, the text editor will simply rename the original file 'test.jsx' to 'test.jsx.bak' or so - taking the hard link along, so it now refers to the .bak file instead of the modified .jsx file.

Turn the backup feature off, and all will be well. I've tried it with Notepad and ExtendScript toolkit, and things seem to work well: if I edit the script via its hard link, the original script is updated as well. I also use UEStudio as a text editor - and at first I ran into problems because this editor makes .bak files by default. Once I switched that off, things worked well.

With regards to maintaining hard links to plug-ins generated from Visual Studio: make sure to use Build, not Rebuild - Rebuild will destroy the original and break the link.

So, that's it for now - hope this makes your life a bit easier!

Display Workflow-Related Meta-Info For Your Users From An InDesign Script

When developing workflow software around Adobe® InDesign® or Adobe® InDesign Server®, as a scripter, you often find yourself attaching 'meta-info' or metadata in some form or shape to various page elements in an InDesign document.

In this blog post, the samples should work with InDesign CS and above on Mac as well as on PC, and I'll use ExtendScript for InDesign for the scripts.

But the information presented here can be applied just as well in AppleScript or VBScript. The syntax is slightly different, but it works equally well.

Meta-info would be any info that is not directly related to the page layout per se, but that needs to be associated with elements of the page layout.

Examples of meta-info you might like to attach to a page item would be things like invoice data, prices, product codes, file names, script labels, XML tags, user names, document history information, destinations, job ticket data...

In many cases, this meta-info can remain hidden from the end-user and not be displayed on the page layout at all - the data is typically picked up by various automated components of your workflow (scripts, applications, plug-ins...) and used to control processes and routing of info and documents.

One of the most popular methods to attach meta-info to InDesign page items is to use the extractLabel and insertLabel methods. These two essentially allow you to 'attach' any number of arbitrary strings to any page item, where you identify each of the strings you want to stash away with a key string.

For example, try the following script.

Open or create a document, select a page item and run the following script. (Be careful: the script has no error checking whatsoever, so it is not user-friendly. You need to select exactly one page item, and with the item selected, you need to run the script via the Scripts Palette).

// Script1.js

var theItem = app.selection[0];

theItem.insertLabel("com.rorohiko.statusquo","Whatever you want tada tada whatever you need tada tada");

Nothing apparent will seem to happen - that's OK. Now run the second script, while keeping the same page item selected:

// Script2.js

var theItem = app.selection[0];

var theData = theItem.extractLabel("com.rorohiko.statusquo");

alert(theData);

This shows how you can attach a string to a page item. I do recommend that you use a globally unique string for the keys, for example, like I did, based on my reversed domain name. That helps ascertain that you don't accidentally use the same key as another scripter.

For example, if your domain name is yourcompany.be, and you want to store, say, a user name, you should write something like:

theItem.insertLabel("be.yourcompany.username","John");

instead of

theItem.insertLabel("username","John");

The latter will also work, of course, but you always run the risk that your end user might try to run two scripts from two different developers.

Imagine she tries to use a script created by yourcompany.be and also another script created by rorohiko.com, and both scripts would use the same key username for slightly different purposes. Lots of weirdness would result.

Better be safe than sorry - so if you use be.yourcompany.username, and I use com.rorohiko.username as the key to insertLabel / extractLabel, there will never be a conflict - are we cool on that?

The string you store in the keyed location can be pretty much anything - I often store a very looong string, for example, with carriage returns separating individual records, and tabs separating individual columns, and then use .split to convert the string in to a table.

const kMyDataKey = "com.rorohiko.keyforimportantdata";

//... more code ...

// Little table of data with columns separated by tabs

// and lines separated by carriage returns

// 12 13 Kris

// 15 17 John

var myImportantData = "12\t13\tKris\r15\t17\tJohn\r";

theItem.insertLabel(kMyDataKey,myImportantData);

//... more code ...

var theData = theItem.extractLabel(kMyDataKey);

theData = theData.split("\r");

for (var recordIdx = 0; recordIdx <>

{

theData[recordIdx] = theData[recordIdx].split("\t");

}

//... more code ...

Or you could encode the data you want to stash into a big XML formatted string - that works really well too - something like:

const kMyDataKey = "com.rorohiko.thecoolKeyForXMLData";

//... more code ...

var myImportantData = "";

myImportantData += "<data>"

myImportantData += "<record>"

myImportantData += "<x>12</x><y>13</y><name>Kris</name>";

myImportantData += "</record>"

myImportantData += "<record>"

myImportantData += "<x>15</x><y>17</y><name>John</name>";

myImportantData += "</record>"

myImportantData += "</data>"

theItem.insertLabel(kMyDataKey,myImportantData);

//... more code ...

var theData = theItem.extractLabel(kMyDataKey);

// Use the built-in XML parser to parse the XML data back into its components

//... more code ...

Or any other scheme you can come up with to convert the data you want to store into a string- you can do things like ASCIIEncode or ASCII85 the data if you want to store binary info in a pure ASCII string - your imagination is the limit.

Now, what if you wanted some of this data to be visible to the end-user?

For example, the end-user could use one of your scripts to tag individual page items, maybe to let your automated workflow 'see' where it needs to insert a header and where it needs to put an image, and so on.

Wouldn't it be great if you could give the user some visual feedback in this regard?

That's where our APID ToolAssistant comes in. APID ToolAssistant was conceived as a 'scripters toolkit' and it offers a whole range of functionality that could help the serious scripter.

You might have heard about APID ToolAssistant, because it offers a very 'fine grained' event model that allows scripts to be triggered by user interaction with the document - but APID ToolAssistant has a lot more to offer than just some event-driven facilities.

One of the coolest features in the APID ToolAssistant toolkit is that it offers the scripter a way to display any 'meta-info' next to a page item. To display this meta-info, APID ToolAssistant can add little, non-printing 'labels' (also known as adornments) to any page item, and in those labels, you can display anything you like: some text, or a PNG image like a logo or an icon, all under the control of your script.

These adornments are not page items - they are instead very similar in nature to the selection handles and the overset text indicator on page item frames. They are nothing more than visual cues for the user, and they are not visible in the printed end-result.

The way APID ToolAssistant works its magic is by adding some new methods and attributes to the InDesign object model. There is a pair of methods called setDataStore / getDataStore which behave very similar in many respects to how the built-in insertLabel / extractLabel work - i.e. you store data identified by a unique key.

But there's a twist - some of the unique keys have a special meaning - they are 'magical'.

If a key starts with $ADORNMENT_ and ends with $, it tells APID ToolAssistant the stored data is something that has to be interpreted as content for a little info-label.

Install APID ToolAssistant 1.0.47 or higher (you can download it from http://www.rorohiko.com/apidtoolassistant ), and enter the following script:

// Script3.js

var theItem = app.selection[0];

theItem.setDataStore("$ADORNMENT_com.rorohiko.sample$","Hello World");

Just like with the first sample scripts you need to select a single page item, and then run the script.

Is that cool or what? (If your APID ToolAssistant has been installed for a while, it might have reverted to unlicensed mode, in which case you'd see 'DEMO: Hello World' in the little info-label).

Now, this is only a simple example - instead of a simple string "Hello World" you can actually provide an array with data to setDataStore, and through various parameter values ask APID ToolAssistant to display the label on the left, right or bottom sides of the frame.

Or you can ask it to change the background color. Or for really fancy stuff, you can display a PNG image instead of text. The possibilities are endless.

To get some ideas about what you could do with this functionality, have a look at what I've done with our FrameReporter tool at http://www.rorohiko.com/framereporter . FrameReporter is really not much more than a very thin layer of code on top of APID ToolAssistant.

For more detailed info, you need to look at the information provided in the Active Page Items Developer toolkit - http://www.rorohiko.com/activepageitemsdeveloper .

The necessary documentation is included in the free demo download - you don't need to purchase the toolkit if all you want to do is use this 'meta-info-label' feature. Check the reference manual to find out about all the variations of the adornment features.

So, keep in mind - if you want to show meta-info to an end-user, all you need is a US$25 license for APID ToolAssistant (to get rid of those 'DEMO:' prefixes added by the unlicensed version), and you can script away!

More info can also be found here:

http://www.rorohiko.com/wordpress/2008/10/15/how-to-add-indesign-page-item-adornments-using-scripting/

Apple Mail and the Drafts folder

I use Apple Mail, and generally, it does work well. However, there's one thing that annoys me: if you don't have any 'pending' draft e-mails, the Drafts mail folder is invisible and cannot be seen in the mail window.

That seems like a non-issue, but I like to use the Drafts folder for 'repetitive' e-mail. I sometimes send out a similar e-mail to two or three people, and I like to option-drag previously sent e-mail from the Sent mail folder back to the Drafts folder to make a modifiable copy.

What I used to do in previous versions of Apple Mail was the following:

1) Type in an e-mail. Hit 'Send'.

2) Open the 'Sent' folder in Apple Mail and Option-Drag the e-mail I just sent to the Drafts folder. That makes a copy of the e-mail, and makes it available as a draft.

3) Double-click the draft in the Drafts folder, and adjust it to suit the next addressee; hit 'Send'.

4) Go back to step 2 as needed.

Because in more recent versions of Apple Mail, the Drafts folder becomes invisible if it is empty, I used the following clumsy workaround:

0) Create an empty, dummy e-mail and hit 'Save as Draft'. That puts something in the Drafts folder, and I can start using my previous trick (option-drag sent e-mail into Drafts to make a modifiable copy). Go to step 1) above.

...

That works OK, but the dummy e-mail is blank, and you end up with a blank e-mail in the Drafts folder - I don't really like that.

So, finally my current workaround is to create a single, non-blank e-mail in the Drafts folder, and leave it there for eternity. It's not perfect, but I can live with that.

The Drafts folder now has a permanent mail in it.

Not the greatest trick in the world, but it made my life a little bit easier, so I thought I'd share it.

Cheers,

Kris

Little Known Facts About InDesign Plug-Ins - There is More To It Than Meets The Eye

Installing a plug-in for Adobe InDesign is normally fairly straightforward.

• Quit or exit out of InDesign.
• Navigate to the folder that contains the InDesign application file.
• Find the folder called 'Plug-Ins'.
• For neatness, create a subfolder inside 'Plug-Ins' - e.g. 'Third Party Plug-Ins'. Drag the plug-in icons (and possibly any associated files) into that subfolder.
• Relaunch InDesign

That's fairly easy.

But when it comes to upgrading things might become a bit more complex.

In short, you might want to first remove the previous version of the plug-in, then start and immediately exit InDesign, and only then install the updated version.

In other words - perform an 'empty' start/stop of InDesign before installing the updated plug-in.

Whether this is really necessary depends on the plug-in - most plug-ins won't need this. But if you're battling a mysterious problem, this is worth a try.

Here's what might happen.

Each time you launch InDesign it will scan the Plug-Ins folder and its subfolders, looking for any new plug-ins. If it cannot find any new plug-ins, nothing special happens - we have a bog-standard, normal InDesign launch.

But when InDesign does find a new plug-in - a plug-in it has not 'seen' before, things are different, and the launch takes longer than normal.

Most people won't notice it - the difference in launch time is not very large. If you're really observant, you'll also see some extra messages flash by in the InDesign splash screen.

Behind the curtain, InDesign is analyzing the new plug-in and extracting information from it.

For example, information on how the new plug-in can be scripted, and information about the wording on the dialogs and palettes the plug-in can display.

A lot of this extracted information is then stashed away by InDesign for 'later reference' - this to avoid having to re-analyze the same plug-in on each re-start.

So, the next time InDesign launches, it again checks for new plug-ins. If no new stuff can be found, it relies on its information stash (also known as 'cache'), and it can launch faster, because it does not have to spend time analyzing any plug-ins.

This 'trick' is called 'caching' - caches are used in many situations, to avoid needless effort to re-obtain data that has been obtained before.

For example, your web browser does it too - the first time ever you access a particular web page, it will be a tad sluggish, especially when there are a lot of graphics. Navigate to that same page a little bit later, and in most cases it will come up a lot faster.

The browser has cached the page content and instead of accessing the web site far, far away, it is showing you a copy of the page it had cached in its local web file cache. The web page comes straight off your hard disk, which is a lot faster than pulling it through the internet.

So, keep in mind: to improve launch times, InDesign caches a lot of information that is normally stored inside of the plug-in files.

Now suppose you have a plug-in installed. It's working fairly well, but there are some issues.

Some time later the software developer releases an updated version of the plug-in, which should fix the issues. You download the new version, and overwrite the old version with it.

Done? Is it that easy? Not always!

The problem is that InDesign might not scan the updated plug-in: for all it knows, it 'saw' file 'xyz.pln' before, and it still sees 'xyz.pln' - InDesign might feel no urge to re-scan 'xyz.pln'.

As a result, InDesign might be relying on the outdated info from the previous version of the plug-in that it has in its information stash.

And weird things might start to happen - things mysteriously don't work well on some computers, but work fine on others, that kind of stuff.

Morale: it might be a good idea to force InDesign to re-scan the new plug-in. To achieve that, you can use the following procedure:

0) Exit out of InDesign
1) Completely remove the plug-in you're about to upgrade
2) Launch InDesign (without the plug-in installed). It will notice the plug-in is missing, and it will erase any cached data it had extracted from it.
3) Exit out of InDesign
4) Install the updated version of the plug-in
5) Launch InDesign (with the updated plug-in installed). It will see the 'new' plug-in and re-scan it - so the cached data is now up-to-date.

Keep in mind: this info is quite general, and might not apply to your situation. But if all else fails - give it a go!

Cheers,

Kris