Nine to Five Reports and Rev

[Richard Gaskin]

Dan Shafer wrote:

> I agree with the analysis that it would be easier to create reports
> directly in Transcript than to try to mangle an external that would do
> so. However, if someone came up with a stack/app in Rev that handled
> most or all reporting functionality sufficiently generically and
> extensibly, I think it would be a world-beater of an app. I'd buy one
> for sure!

Here's the deciding question:  How _much_ would you pay?

I've been looking into this for years, and since I once made my living
selling parts to xTalkers I've been trying to find a viable business
opportunity with this.  Thus far dense clouds, no rain.

It seems printing needs for most Rev folks could be categorized like this:

- Large blocks of text,
  which can be done with revPrintField

- Labels and other grid-based layouts,
  which can be handled with Rev 2.0's Report Generator

- Single-page forms,
  which can be handled by just laying it out and printing the card

- Things not handled by the first three,
  which are often too weird to be easily generalized, if at all

And that's just layouts.  The real power of Reports was in the layout tools
and queries.  Layout tools are easy enough  -- it's really just the pointer
tool with a palette to bind fields to data.

It's the latter that's hard in Rev if one attempted to write The Ultimate
Printing Tool:  where is the data coming from and how is it structured?
With custom props, SQL, Valentina, etc., we're not just talking about
walking through background fields anymore.

In most cases, if you can handle the other aspects of app development you
can probably lay out some fields and issue a print command.

The tricky stuff is like the example from last year when the topic came up,
an interestingly complex case but not likely to be of general use any more
than some of the more complex reports in HyperRESEARCH (another MC-based
app).

If we left data gathering up to the user, how many folks would need a tool
that does just formatting?  And again, how much would they pay?

So one challenge from a business perspective is that it must be priced low
enough to make it worth buying instead making a custom solution that does
exactly what you need, but it must be flexible enough to appeal to as many
different developers as possible, with the foreknowledge that some unique
types of reports could not be generalized affordably -- those potential
customers with the most complex printing needs may still need to roll their
own for the hard ones, and those with the simplest needs already have three
types of printing solutions available.

And that's before we start exploring support costs.  Sure, in the mind of an
experienced person like you the dividing lines between The Ultimate Print
Tool, Rev, the MC engine, and the printer driver are probably pretty clear,
or at least you could follow a set of guidelines issued with your license
for The Ultimate Print Tool. But as Rev's audience grows, one could expect
new developers to call everytime their customers report a printing-related
issue. Just the cost of referring people to the appropriate party could eat
up a prohibitive amount of time (there are some pretty sloppy drivers out
there, and very, very few end-users who report having the latest driver have
actually even checked the vendor's site).

If I can find a way to do this profitably I'd be a fool to turn down the
cash.  But thus far the level of effort to generalize and support a
universal printing tool seems likely to cost far more than the aggregate of
writing print routines for the task at hand, many of which use the
preexisting solutions listed above.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc