use-revolution digest, Vol 1 #1398 - 14 msgs

[Dan Shafer]

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.

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

> - Labels and other grid-based layouts,
>   which can be handled with Rev 2.0's Report Generator
>
Haven't looked too closely at this, so I can't comment but I'll take 
your word for it.

> - 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
>
Not sure I agree with the last part of your observation. (More below)

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

> <<Snip>>

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

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

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.

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

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

> -- 
>  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
>
================================================
Dan Shafer, Author, Consultant, Product Development Expert
http://www.shafermedia.com
You are nearly 3 times more likely to need a lawyer than a hospital:
http://www.prepaidlegal.com/info/danshafer