Nine to Five Reports and Rev

[Richard Gaskin]

Dan Shafer wrote:

> On Tuesday, May 27, 2003, at 08:41 PM, Richard Gaskin wrote:
>> 
>> 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?
>> 
> For the right tool? upwards of $100 depending on feature set, data
> source diversity, ease of use.

That's about the same as each of the popular HyperCard reporting tools.

Anyone know why neither of those vendors have been motivated to do a
Transcript port of their products?

...
>> 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.
>>
> I suspect that if you had one tool that would deal with SQL databases
> only, which are the most general of the data sources, you could start
> off quite handily. Over time, customer demand for other data sources
> would drive spin-off products or versions. I haven't played with
> Valentina, so I don't know how SQL-similar it is, but perhaps you could
> offer both in one product if they are similar.
> 
> Seems to me that if I could buy a great query-manager/report-generator
> and the tradeoff was I have to store the data I wanted reported on in
> an SQL database, I'd do it.

So we wouldn't be able to get away from handling queries, eh?  Drag.

What percentage of Rev developers who say they want printing tools use
MySQL?

...
>> 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?
>> 
> My guess is this would be a popular tool but of necessity priced well
> below Revolution's price point and therefore perhaps not very
> interesting from a margin perspective.

That's what I keep coming up with.  My accountant's mantra is "Be mindful of
opportunity cost". ;)
 
...
> Maybe one key is to design the tool in such a way that it provides a
> coding framework -- or a set of parameters for a parameter-driven
> environment -- in which both of those levels of need could be met.

Agreed, but it would not be simple.  Given the variety of settings for
header, footer, and body options, such an API could quickly become
cumbersome to address in code alone.

Both of the major HC reporting packages used stored settings instead of a
complex param list, but to make those settings easily (and with fewer
errors) would require a GUI.  A lot of folks would want such a GUI to be
robust enough to ship to their customers as well, and as such it should be
modifiable to allow the developer to integrate it into their app's
appearance.

What percentage of Rev users who say they want printing tools and who store
their data in SQL need to allow their customers to modify report queries and
other params? 

And given the work involved, anyone attempting this I should ask themselves:
"Will it benefit me more to build a GUI and API for the subset of Rev
developers who need complex printing, or to put those same hefty hours into
a consumer product useful to all computer users?"

...
>> And that's before we start exploring support costs.
> <<Snip>>
> 
> For sure that's an important issue. But it's not unique to this
> product; it's a software issue all software publishers have to address.
> There are lots of options here and some of them at least might make
> sense for this product.

Given that support costs killed $99 HyperCard (which is how many came to
discuss printing options in Rev), and the variety of Windows printer drivers
out there, this one may take some thought.

What support options would you propose?

>> 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.
>> 
> Maybe there's a way to aggregate these solutions into a library that
> could serve as the basis for a product that just supplies an
> ever-growing set of templates in a specialized library.

I've pondered the herding-cats world of Open Source, but it keeps coming
back to generalization.  For example, the cost of laying out a card and
pouring data through it in a repeat loop is low, but the means to allow
others to do that without the simple scripting involved is a few orders of
magnitude greater.

If I were to bypass generalization and release the sum of all the printing
code I've written to date, the resulting collection would fall into two
categories:

- simple things that would be more work to revise for use in another
application's environment than to just spend an hour or so making one
yourself

- complex things so app-specific that they could not be easily adapted for
use in another context

Thinking back about the printing I've written over the years, where I had
trouble I was able to overcome it by acquiring not tools (maybe only because
none existed at the time <g>) but merely experience.  It's almost the
difference between giving someone a can of tuna or empowering them to
acquire anything they want to eat.

Maybe more effective than sharing code is sharing the experience that
produced the code.

To make sure we keep a useful focus, let's return to the basics for a
moment:

  What do folks need to print?

  What challenges are they currently facing implementing that?

-- 
 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