Introduction
XMPie is a company that produces cross-media and personalization products. However, everyone uses
the company name to refer to the product. So for this review, I'm using "XMPie" to refer,
interchangeably, to both the PersonalEffect™ product as well as the company.
The XMPie PersonalEffect product consists of several modules. "uPlan" manages the data, "uCreate"
manages the design template, and "uProduce" puts them together. There are other modules which
can be optionally purchased (uChart, uStore, etc.) but this review focuses strictly on
personalized print production.
uPlan
uPlan is the data-mapping module, and is a stand-alone Windows program written in Java.
Its purpose is to abstract a schema from your data-sources. Then, any data-source that uses the same
schema can be attached to a production job. Think of this in terms of using a "model" Excel spreasheet in
uPlan. Customers would provide data each month in a "copy" of this spreadsheet. As long as the spreadsheet
structure is the same, it will work. uPlan is even robust enough to work with similar schemas. If your
customer adds a column to the spreadsheet, it won't break the workflow. It's a great concept, and the
application is well thought-out, though there is a steep learning curve.
As you attach various data sources, which can be single flat files, Excel spreadsheets, or a complete
Access Database with multiple tables, you use the QLingo™ language to construct queries,
functions, and variables. QLingo is an XMPie proprietary superset of SQL. You can also use
JavaScript and/or VBScript in building your expressions and variables.
This allows you some very powerful data-filtering capabilities. However, it does take an experienced,
data-savvy programmer to use. Most graphic designers, I think, would really struggle trying to use
uPlan (just as most programmers would really struggle to design a nice graphic layout).
The purpose of all this data mapping and filtering is to create objects, which XMPie calls "ADORs".
Those objects are used by the next module, uCreate.
Say you were creating a piece that had, as a variable item, a person's full-name, but only if that
person is over 21. In your database, you might have AGE, FNAME, and LNAME as fields. You use uPlan to
create a "Full-Name" ADOR, behind which are the appropriate SQL queries and string-building functions
to select ONLY those records where AGE is greater than 21, and for those records,
concatenate FNAME, a space, and LNAME.
Overall, uPlan works very well. There are a few minor inconveniences that will no doubt be ironed out
in subsequent releases, but no show-stoppers.
uCreate
uCreate is an Adobe InDesign plug-in. All uCreate operations are performed with an
XMPie palette within InDesign. The basic concept is simple: replace any text or image elements
in the InDesign document with the ADORs you created with uPlan. The uCreate palette is well-organized
and easy to use. It really is as simple as highlighting some text, then dragging an ADOR onto that text.
Entire layers or pages can be toggled on or off by use of a special "visibility" ADOR. The methodology
then becomes to create a many-layered InDesign file chock-full of ADORs that pull in variable
text and/or graphics, and selectively output (or suppress) layers during print production.
The drawback here isn't the uCreate program itself. Rather, it can take a lot of planning to design
a completely variable, complex job in uCreate/InDesign. You'll need someone highly skilled in InDesign,
who also has the ability to "meta-design", that is, to incorporate all possible variable designs, images,
styles, and overall layouts into a single InDesign template, with properly inserted ADORs. You're not
just designing a document. You're designing all possible documents, at once! This person will also need
the ability to accurately describe to the programmer the precise type of ADORs they'll need.
uProduce
Finally, the uProduce server brings the data, filtered through the uPlan file, into the ADORs inside
InDesign. InDesign then outputs a variable document per record (or, per record you actually selected
in the uPlan phase) in the database. I didn't spend much time working with uProduce, but it obviously
does the job.
Some Drawbacks
In my opinion, the Achilles' heal of the XMPie workflow is InDesign. uProduce itself doesn't produce
the print-stream, it uses InDesign to do so. In essence, InDesign is being used as if it were a
"document server".
What's wrong with that? For one, speed. To use an analogy, many web designers use
FrontPage or Dreamweaver to produce web page files. However, those files are eventually hosted on a
Web Server. No one would try to use FrontPage as a Web Server. Yet InDesign, a page layout program,
is being used as a Document Server - something it was never meant to be. It's a desktop,
single-user application trying to be a server-based document composition engine.
Another negative is that XMPie can only do what InDesign can do. Specifically, it can only
import graphics and text files from the file system. Do you store your images in a Database?
Too bad. InDesign Tagged Text files? Put them all on the file system. The idea of having all
variable data inside a database file isn't possible with XMPie, because InDesign can't import
images or tagged text from anywhere but the file system.
(I have created and used dynamic imaging websites. Wouldn't it be nice to tell XMPie to go get a
graphic using a parameterized URL? Think of a Street Direction MAP or a financial chart! Sorry, as
nice as that would be, InDesign requires a file on a hard drive.)
Another drawback is Adobe the company. Adobe has a long history of producing wonderful,
innovative products and then progressively ruining them through oddball marketing strategies and
dead-end development. Think of PostScript, a great language, the language that created Desktop Publishing
and literally drives the printing industry, that has not been updated in many years, and is not
likely to be, ever again. Or Acrobat/PDF - a great concept now burdened with a confusing and fragmented
product offering and intentionally crippled feature sets. PageMaker, anyone?
XMPie is allowing their entire workflow and product strategy to be at the mercy of
whatever Adobe decides to do (or NOT do) next.
Lastly, the price: XMPie is outrageously expensive. If you thought you could have a team of developers
and a "team" of designers working to create personalized campaigns, think again.
Outfitting just one developer and one designer is a six-figure proposition.
Conclusion
In summary, XMPie has produced some well-thought out, easy-to-use, and very powerful products.
However, they have left the most critical aspect of any print job, producing something to print,
up to someone else, and attached a truly massive price tag.
Would you like to discuss, correct, or debate this article? Join the
T.Greer PrintForum.
About the Author
Thomas D. Greer has years of experience in the printing business.
He held the position of Director of Development for Consolidated Graphics, where he wrote the COIN eCommerce platform.
Prior to that he was Vice-President of Technology of a large printing company acquired by Consolidated Graphics,
where he was responsible for the development of a completely custom-written plant management system still in use.
Today Thomas provides consulting, development, implementation, and training services to commercial printers.
He can be reached on the web at www.tgreer.com.
