Communicating Of Patterns

Bridging The Gap

Creating scripts to automate graphics-orientated programs like InDesign, Illustrator... is not quite the same as general software development.

In general software development, most times the people viewing software source code are software developers or engineers.

They share a large amount of background knowledge that does not need to be communicated.

Properly written source code written by one engineer can be read and understood by another engineer. They understand the basic rules of software development, and there is no need to re-iterate what is common knowledge between them.

It's not a simple situation. There are many often mutually conflicting schools of thought around 'proper' software development, and two software engineers disagree on what is 'best practice'. But they'll understand what the other rules are, even if they don't necessarily agree with them. One engineer might prefer indentation with spaces, the other might prefer tabs (an eternal debate that will never be settled).

When it comes to writing scripts for graphic workflows, the situation is even more complex. Often a software developer is involved, but at the same time, a non-software developer will be involved too. For example, a graphics designer might want to tweak some existing script to better match their workflow.

In that case the different actors do not necessarily share an understanding of what rules there might be.

When a non-developer reads a script written by a software developer, a lot of detail will escape being noticed.

This web site is an attempt to bridge that gap.

It allows a software engineer to clearly communicate to a 'consumer' of the software what they need to pay attention to, and to highlight important aspects in a standardized way.

It allows a graphics-orientated person to understand important details about a script without needing to get a degree in computer science.

Metapatterns

Metapatterns are remedies and approaches for specific issues surrounding scripting and programming in general.

In most programming literature, these are commonly referred to as ‘patterns’, but I’m referring to them as metapatterns, for two reasons:

- I managed to register the domain name metapattern.info to house the online metapattern info web site - The word ‘pattern’ is an overloaded word with other meanings. By referring to 'patterns' in the realm of software development as 'metapatterns' it avoids possible confusion with, say Illustrator fill patterns.

How to use metapatterns

For the sake of argument, I will pretend that the people who will benefit from the use of metapatterns fall into two distinct groups.

Of course, the reality is much more messy and many people will be firmly footed into both groups.

Software Developer

As a software developer, you will know many of these patterns. Some might be new, and might be useful to you.

You can choose to follow one or more of these metapatterns when you create scripts.

If and when you do, you will add some standardized comments to your script to clearly communicate which metapatterns you used when building the software.

Of course, these metapatterns are merely suggestions. You can make up your own mind how rigorously or how loosely you want to apply any of them, if at all.

Also, a lot of these metapatterns will seem incredibly obvious, to a software developer. It is important to keep in mind that they are not that obvious to a non-developer.

Non-developer

As a non-developer (e.g. a graphics designer, a layout artist...) you might find a script that almost does what you want, but not quite.

The first thing you would do is to open the script in a text editor and identify the metapattern names.

You would then use this web site to look up each pattern to understand what it is about.

If the original creator of the script followed any of these patterns, you’d be able to adjust the script to some extent, hopefully right up to the point where it does what you need.