SwatchWatch – A Case Study
SwatchWatch is a free script for Adobe InDesign CS5 and higher. It will append a printable grid of swatch samples to any document.
The look-and-feel of the grid is customizable.
We’ll be using this script as a case study.
You can download and use this script for free. The download links are somewhere further in the article.
The free script is actually a bit of ‘click-bait’, and we really want to entice you to read this article.
Read this article, and get a useful script in return; that’s a good deal, no? We cannot force you, of course. Any which way, we hope you enjoy the script!
The main idea is to allow prospective customers to get a ‘feel’ for what custom software development with Rorohiko might cost, and what the potential return on investment might be.
Our approach is ‘no cure, no pay’: you can try out our custom software ‘for real’, in your own workflow, and make sure it performs as desired without up-front costs. If you were to find it does not work for you, we would not charge.
The initial phase of any software development with us will be to define a scope for the project.
We need to find a balance between two conflicting elements: your available budget and the capabilities of the software.
If you don’t know what the budget is, you first need to work out an estimate of how much money the envisioned software development might be saving you.
The estimate does not need to be accurate, but you need at least to know the order an magnitude: $1,000? $10,000? $100,000? …
If the potential savings are below $1,000 the project is probably not worth the effort.
One way to go about it is to take the average cost of an employee-hour. This figure is higher than just the wages: it should account for all costs – taxes, premises, consumables… Then make an estimate of how much time the custom software might save over some period of time. Multiply both figures and you have a rough estimate.
No Fixed Price Quotes
We don’t provide fixed price quotes. In the creative sphere, the finished product nearly always ends up quite different from the original request.
In order to provide what is needed (instead of what is asked) we work with an iterative process.
Requirements will often only become clear after the prospective users of the software have had a chance to play with a prototype.
Users need to find out first hand whether the software fits the purpose. We cannot predict how long this process will take, so we cannot make up a fixed price quote.
What we will do instead: provide non-binding estimates of the cost, based on what we’ve learned from similar projects that we have done in the past.
The final cost also depends on how well you communicate back to us.
On one hand, if we get detailed reports, sample documents, screenshots, we can normally make adjustments very quickly, and we will need very few iterations.
On the other hand, if we have to figure out what to do from terse messages like ‘it does not work’, the process will become very drawn-out and expensive.
Our approach is to provide you with a working prototype as soon as possible.
The prototypes we deliver are not limited in any way (e.g. no artificial timeouts or limitations). We expect you to test them in your real-life workflow and provide us feedback as soon as possible, i.e. within two, at most three working days.
Before you start a project with us, you must commit sufficient manpower and resources to test the prototypes we’ll be sending in a timely manner.
Based on the feedback we receive from you, we then provide you with an adjusted prototype. We play a bit of ‘ping-pong’ this way. Typically, we will have two or three iterations before the final deliverable.
Once we send you the final version you are faced with a choice: either you sign off on the project, or you reject the deliverable.
If you reject the deliverable, there is no cost to you, but you must destroy all copies of the software. You are not allowed to use the software after you reject it.
If you sign off on the project, we will send you an invoice. Once the invoice is paid, the software becomes properly licensed, and you’re allowed to use it in your workflow.
We expect invoices to be paid upon receipt. If that is not possible, you must let us know beforehand, as there is an additional cost for longer payment terms.
Once the invoice is paid, you have a perpetual license to use the custom software. You are also allowed to re-distribute it and make as many copies as you like.
If desired, you can also purchase the source code to the project. However, this is subject to a separate negotiation. We don’t provide the source code by default.
In order to be efficient at custom software development, we make use of our proprietary library of source code templates and pre-written software. This proprietary library represents a large investment of time and effort on our part.
Purchasing a custom software development from us does not automatically entitle you to access to the source code for our proprietary library. If you want the source code to your project, you will also need to purchase a license to the source code for our proprietary library.
How to get started? First of all, make sure you have a figure for the budget.
Then collect as many sample documents as possible. If the goal of the project is to automate some document transformation, you should also provide us with manually built sample ‘before’ and ‘after’ documents.
Send the sample documents, and an extensive description of the goal you want to achieve to [email protected].
We’ll get back as soon as possible (typically within the week) after we’ve had a chance to review the material.
If you’re in a rush to get your script developed, we might need to disappoint you: we’re quite busy most of the time, so our turn-around times will often be at the very least a few weeks.
Custom Development vs. Off-the-Shelf Development
One way to reduce the overall cost of a custom bit of software is to reduce the amount of user-interface code we need to build.
In practice, we often find that the users of our software are quite computer-savvy, or they have good I.T. support in their company.
As a result, if the budget is limited, we often create ‘user-interface-less’ solutions. They don’t sport a nice user-interface, but the value of such nice user-interface is often minimal in the given environment.
Instead of developing a user-interface, such custom tools are most commonly configured by means of a human-readable settings file.
To (re)configure the software, you open the configuration file with a text editor, and tweak the settings.
As an example, we’ve built a small project, called SwatchWatch. SwatchWatch is a script for InDesign CS5 and above.
This is only a sample project; we provide custom automation in many other environments, including the Creative Cloud apps, not just InDesign.
This small sample project is based on real user-requirements, and it is currently being used in a real workflow.
SwatchWatch will automatically add swatch samples to the end of a document, creating new spreads as needed.
You can re-run the script as many times as you like: it will remove the old swatch samples, and re-create them.
There is a configuration file, called SwatchWatchConfig.ini, which needs to reside next to the SwatchWatch.jsxbin script.
Install the .jsxbin script and the SwatchWatchConfig.ini file in your Scripts panel. If you don’t know how to do that, pay a visit to the InDesignSecrets web site:
You can also add a third file, the optional SwatchWatchStyleTemplates.indd template file.
The script relies on six paragraph styles and six object styles to format the swatch samples. If these styles don’t exist they are automatically added to the document.
If the styles need to be added the script will attempt to load them from a document called SwatchWatchStyleTemplates.indd. If no such document resides next to the SwatchWatch.jsxbin file, the script will fall back to building some styles from scratch.
Once the styles have been created or added to the document, they won’t be modified by the script any further. From there on it’s up to the user to change them in the document, to achieve the desired look and feel.
More info can be found in the ReadMe.txt file that accompanies the script. You can download the script here:
The cost for this script does not only include the actual coding, but also the preliminary work on the scope, the architecture of the script and the design of the workflow.
Going from the initial request for automation to a properly working, efficient solution is not as easy as it might seem, and that’s part of the service we offer.
If done as a custom project, this particular script would have costed about US$1,500 to develop.
The advantages over manually creating the swatch samples are:
– avoiding human error
If you would need this script for a one-off, it would certainly be too expensive to be worthwhile.
But as soon as you need to do this for a number of documents, and repeat it again and again over time, US$1,500 might not be all that much, and the script would pay back for itself in a short time.
I hope this sample gives you a bit of a ‘feel’ for the magnitudes in custom software development!