Building a better AutoMap
ePublisher includes tools to create designs (Pro), stamp them out (Express), and automate builds (AutoMap). The thing is, AutoMap, as it exists today, is not always the right fit for our users. It offers more capability than some folks will ever leverage. For them, AutoMap is simply too expensive. Others make extensive use of AutoMap’s command-line capabilities to maximize their use of the product. In their eyes, AutoMap is huge bargain.
I’d like to figure out how we can better address both types of customers in the future. Doing so might mean splitting AutoMap into distinct products. Let’s see if we can define some product offerings that better fit everyone’s needs.
I’ll start off with a list of functions AutoMap presently provides:
- Scheduled generation
- On-demand generation for scripting integration
- CMS integration capabilities
- Pre/Post generate actions (useful for source-control integration)
- Notifications (E-mail)
Our Sales team tells me they have a further need to distinguish between:
- AutoMap on a server
- AutoMap on a client
Here, the server case represents AutoMap being used as a centralized resource by a number of users. The client case represents customers looking to keep their Express projects up-to-date or integrating AutoMap into their nightly build processes. Obviously, we’d like to find a way to provide a client-side user with a reasonably priced offering.
Finally, there are always the things that AutoMap doesn’t quite do yet, such as support for job queuing. Job queuing would ensure a system could not be overwhelmed by multiple, simultaneous conversion requests.
Tell me now. If WebWorks were to build one or more products based upon the AutoMap of today, what combination of functions would you need for success in your organization?
5 Responses to “Building a better AutoMap”
Tweets that mention Scenes from the Engine Room » Building a better AutoMap -- Topsy.com - April 29th, 2010
[...] This post was mentioned on Twitter by WebWorks. WebWorks said: New Blog Post from Ben Allums – "Building a better AutoMap." – http://tinyurl.com/2cqwoyv [...]
1. AutoMap is expensive.
2. You buy it when you have complex things to automate.
3. Complex FM projects contain Boolean expressions.
4. AutoMap doesn’t let select nor you define expressions.
5. So there’s room enough to expand …
BTW: 2010.1 now has “non-GUI support for expressions” … and that’s all the help a user gets from Quadralay. Folks, tools to create documentation should be well documented themselves.
As I just posted on wwp-users, many/most/all of us are facing more tasks, and more complexity in projects (see F-JK’s note above), all in a shorter timeframe. And our developers, who we used to be able to borrow to write scripts, are in the same boat.
For Auto to work better for us (and sell more copies for you), we need a helluvalot more doco on its workings, and even more adaptible, real-world, sample scripts.
Notwithstanding the above, I do know that you are faced with the same too-few-hands-not-enough-time constraints as the rest of us. But wouldn’t it be nice …
jjj
I used AutoMap extensively for several years at my last company, and I just about choked when I started my new job earlier this year and found out how expensive it has become. No way I can justify that purchase order.
90% of Automap’s value to me was scheduled generation. I didn’t use the pre- or post-scripting capabilities until fairly late in the game, and even then it was for non-critical, nice-to-have functionality. For CMS, I wrote my own scripts which executed before Automap ever kicked off.
Same thing with e-mail — I never used the built-in feature.
All I really want is the ability to schedule overnight builds, and I’m not prepared to pay the current asking price for that.
Job queueing would have been a nice feature — it would have prevented many “train wreck” builds that I had to sort out in the morning. But I survived for years without it by carefully and manually scheduling jobs with buffer space between them. Again, I’m not sure how much extra I would pay for what seems to be a basic usability enhancement.
I know you folks need to make money selling this software — we’re all in that boat. But you’re dangerously close to a tipping point. I almost didn’t convert this place to ePub Pro & Express when I got here because of cost. Automap was out of the question.
Thanks for soliciting our feedback. Hope it’s helpful.
Bruce,
Thanks for your feedback. I’m wondering if you can elaborate further on the pricing issue.
What did you pay for AutoMap a couple of years back? We’ve move our pricing around over time and I’d like to hear from you what you used to see versus today.
I’m wondering if you purchased AutoMap as part of the old “Enterprise platform”, where it was sold and licensed per seat as opposed to now where it is licensed per server.
Thanks!
Leave a Reply