From: jeffo@ux1.cso.uiuc.edu (J.B. Nicholson-Owens)
Subject: Re: Open letter to NextDevelopers (long)(Flamebait)
Reply-To: jeffo@uiuc.edu
Organization: University of Illinois at Urbana
Date: Wed, 22 Jul 1992 03:35:03 GMT

I've got a few questions about this post.

sherwood@fenris.space.ualberta.ca (Sherwood Botsford) writes:
>Sorry, I should have been clearer. I'm speaking somewhat hyperbolically.  The 3  
>minutes refers to the initial look at an app to see if it may meet my users  
>needs.

Ah.  That explains some things.

>I have 140 MB in /Untested currently.  At 3 minutes per megabyte it  
>would take a full day to go through this.

What I want to know is where do you get all these demos of things?  Or
does this include things that might not be demos, but you need to
attend to anyways?

>	1.  Have the application check its own directory for writeability.  It  
>writes to a location in its own executable once a minute.  When the total is 1  
>hour, it deletes itself.  This would mean that people would have to reinstall  
>it all the time if they wanted to keep using it, but an hour would enough time  
>to really get to know the package.

Somehow, I think that more people would complain about that than not.
If the executable is run by someone without permission to write in the
demo directory, how can it write in itself to keep this tab?  Also,
since you are suggesting an hour, it might be better to just have the
program tick away 1 hour like programs tick away two minutes now.

>	2.  Have the program check its own date on startup.  It will run for a  
>week after that date.

This sounds fair to me, so long as within those two weeks anyone can
run the demo for as long as they want and as many times as they want.
And I'd also apply the demo rule of no saving, cutting or copying
anything from any window but the Info panel.  I think that it's
readily obvious that programs will work together if they save
compatible files (like exchanging pictures in the TIFF format, text
and word processor files in RTF [yeah, not the best format in the
world, but it works in a lot of places], that kind of thing).

>	3.  Periodically post demo versions that are good until the first of  
>next month.

Why not just say that it's good for 6 months from install date?  That
way someone would have to either change the clock on their machine
(not too many people are willing to do that, from what I informally
gather), or go somewhere else to install the program again.

>	4.  Set up the demo version so that it only runs on Wednesday, but that  
>it's full functioned on that day.  (I like this idea)

To me, this is definately in the danger zone.  I think the demo should
never be 100% operative for any amount of time, that's why it's a demo
and that's why you should pay for the program.  I don't think
unreasonable restrictions are the answer; I think unlimited time,
unlimited booting, any number of simultaneous users, no saving, no
exporting clipboard data outside the demo application is sufficent to
demo the program for as long as the user wants, but still get the user
to pay for it should they want to take their data to another app.

This method sounds too risky though: what's to stop people from doing
all their work with this app on Wednesdays?  Or to make some hack so
that this app always thinks it's Wednesday?

>	5.  With a purchased version provide a palette of equation templates, a  
>font set of extra symbols (the symbol set is limited...) a filter that allowed  
>you to slurp up Mathematica from the notebook, and format it to your own  
>style... 

Well, the filter idea sounds good (as long as it's addable to the 3.0
filters directory or collection), but what might be of more use to a
wider audience is if the EqB app allowed input in TeX form, that way
MMA can output TeX form (it's an MMA command) and EqB can format it.
Also, people who purchase EqB and some fancy TeX deal can use this
power of EqB.  It doesn't have to be TeX form, but a shared format
that NeXT users can already generate might make the EqB app appeal to
a wider audience.

>Exactly.  And that is what does happen now.  So, in our shop EqB has to oust a  
>pre-existing package from that niche.  And so for EqB to succeed here it needs  
>to have a demoing capability that allows people to get comfortable with it,  
>work with it, without having to fight it.

Okay, sounds like you oughta write to the authors of EqB.  They sent me email
back promptly, they seem alert and responsive.

>So now the user has to write an additional application (In VAX VMS fortran)  
>that will write a shorter file so that he can tell if the emulator package  
>meets his needs?

Just get a smaller map of the world to draw, or just draw Georgia
instead of the whole USA.  Draw some bar charts or something small and
easy instead of something that takes up 10k of instructions.

>This can be used as an argument that he doesn't  
>need it that badly, if he's not willing to test it.  However, Communicae lost a  
>probable sale because of that.

Believe me, Communicae would have probably lost a sale on another
issue down the line even if the TEK emulation were unlimited.  The
interface is the most un-standard thing I've ever seen.  I would
boycott the program just for that.  I won't linger on this, but with
IB available to everyone who gets the extended NeXTSTEP package, I
can't see a single excuse for what the author(s) of Communicae did.  I
don't know if there are other platforms where Com. exists, but if this
is their idea of good programming, I disagree.

>Wrong again.  With a hundred address capacity, I would find out if I ran it all  
>the time, calling up peoples names. email addresses etc, much as I use a  
>rolodex.

Fine, if that's what you do, then that's what you do.  I think it's a
waste of effort to type in all that just to lose it on logout, but
that's another story...

>[how to make a demo useful but still good as a demo]
>Or a drawing program that will only allow three drawings in  
>any given directory.  Or a load/save panel that makes you wait a full minute  
>while it's saving.

This won't work enough to make people not buy the product.  In order
to get a lot of people (who might otherwise be content with a small
inconvience) there has to be something that forces people to give up
something for which they bought the program.

>Or a print panel that will only print half size, or prints  
>with the word Demo overprinted.

This seems more realistic.  Here, the data being printed is not what
the user put in, therefore to get WYSIWYG, one must buy the program.

>For equation builder perhaps a possibility  
>would be to have it quit on command-c.  That is, you would have to relaunch it,  
>and reenter the equation each time you wanted to use it.

What if I wanted to copy part of the equation and paste it elsewhere
in the application or in the same equation I was editing?  I don't
think this will work, but making the pasteboard not export data to
other apps (I've seen this done and it works very well) and not save
and not print (I would the printing idea above [which I believe Dots!
does] for a printing-oriented program like Dots! or somesuch) will
work fine.

>	Ideally it should be something that doesn't get in the way or is not  
>annoying for occasional use, but can get really aggravating on repetition.

Why must it be aggravating? It could just be that if you want to
integrate this with other apps (which is pretty much a requirement for
EqB), you have to buy the program.  Not printing or saving TIFF files
doesn't get in the way.  It's so easy to save a TIFF (and will become
easier in 3.0, no?) that you can rest assured that any program that
says they'll do it, will actually do it.  If they botch it up somehow,
take the program back and get all of your money back.

>	I think that in the long run having programs out there that are  
>somewhat useful in their demo version, very useful in their paid for version  
>will generate more sales for you.

I think the only utility necessary in the demo is showing off the
features of the program itself.  I think saving TIFFs and other
system-recognized formats is all the integration we have with apps now
(until 3.0 comes out) for the most part, and this I find trivial to
review with each and every app.  I'd much rather spend time with
Frame's demo discovering table of contents generation and editing, for
instance, than I would using the standard Open panel to save something
(there's nothing new or nifty about the Open panel, there is something
new and nifty about automatic TOC generationa and other Frame
features).

>	I was citing Diagram as a good example of the way a package can be  
>crippled, be useful, and in the long run generate a sale.  DiagramDemo was  
>useful enough because people could cut and paste from it and do things.  Since  
>people also wanted to re-edit instead of redoing their work, I received  
>requests to get a non-demo version.  

If NeXT gets a system-wide object-oriented pasteboard (like the Mac's
PICT can hold resizeable objects as well as bitmaps), this will lead
to people using RTF files and Edit to hold their Diagram! diagrams so
they can cut and paste things from app to app and never need the
Diagram! program.

Until that time, I can think of tons of students who would be willing
to forgo some of the power of Appsoft Draw (for example) files and
make all their resistors the same size, all their conductors the same
size, in short, all of their reusable pieces the same size to save the
money from actually having to buy Appsoft Draw.

Basically, as the NeXT's pasteboard capability increases, I think demo
makers are going to have a new problem: What to do about cutting,
copying and pasting from app to app.

Sorry, but I don't think that that many users are that trustworthy and
ready to spend money on software to give them fully workable apps,
even in they are only fully workable for a limited time.  I think that
companies who say that the NeXT isn't a good place to make profits are
seeing a bunch of educational poor-folk who would rather pirate their
app from their school's NeXT computer than band together to purchase
one copy.
-- 
-- Jeff (jeffo@uiuc.edu)
-- No NeXTmail please
Newsgroups: comp.sys.next.advocacy