PwrDev to expensive?

[Edwin Knoppert]

In Januari i had this pricedrop and was well-received.
In February i experianced less sellings and even a few mails for selling me PwrDev for the lower price.

While i find $149 is really not that much (~100 EURO) i have the feeling it is for some to expensive.

Therefore this poll

[Chris Boss]

Edwin,

Setting a price is a matter of a number of factors.

From my own experience, you have to gauge whether you can sell a lot for a low price (lower than what you value the product) or whether it is better to sell closer to a products true value, but obviously sell less.

Take for example my EZGUI software.

Version 1.0 sold for $99
Version 2.0 sold for $159
Version 3.0 sold for $199
Version 4.0 sells for $249 and likely I won't go higher in the future

I found with each price increase (new version) I got less customers, but yet because of the higher price I made just as much as the previous version did. Right now EZGUI is about at its maximum price level possible for its value.

Your PwrDev has a lot of features in it and it has a high value to it, IMO.

If you want to tap into the low price market, it may be better to make a "lite" version of it, taking out some of its more advanced features and then selling it at a lower price.

This is the choice I have made. For example my new "Personal version" of EZGUI which sells for $49 has done reasonably well.

Also with my DDT line of Designers, this is the path I will follow. My current release of the Utility Dialog Designer for $29 is actually just about its actual worth. While still quite powerful, all the high end stuff (ie. common controls, layers, etc.) have been removed. I will release later a higher end tool (called "Dialog Studio Designer") which will sell for a lot more.

Personally I think it best to not undervalue your software. Its easy to periodically offer a "sale" on a high priced product to build up sales, than it is to increase the price of a product. I was only able to increase prices with new versions. It would not have been possible (or reasonable) to do so with an existing product. Since a new version had signficant new features, customers didn't overly complain about the higher price. Customers though would not think to highly if you sold a product today for $99 (regular price) and then a month later increased it to $149.

They though do appreciate and understand when a higher priced product is offered on sale.

If you do a comparison of GUI tools, Pwrdev is currently in about the right price range (actually slightly undervalued IMO).

A lot complain about the price of good programming tools (I see this a lot with other compilers which target hobby programmers, like EBasic and Purebasic). Users want everything cheap.

Me personally, I have been programming professionally for over 15 years and I am use to a higher price for tools. I bought VB 5.0 pro for $450 (not cheap). VB'ers are used to high prices addons too. They could spend thousands of dollars on addons like ActiveX controls. Powerbasic is a more professional level tool IMO, so addons should command a reasonable price.

[Jim Padgett]

Price Point

It's not just the cost!! Tools are tools and you have to have a need to buy them. If I have already purchased a designer, then as long as that designer is working well for me, then why buy another?

Each tool has it's strengths and weaknesses.

As far a selling a designer goes.. in order to really determine which one is best for you it is necessary to try it out or in the case where there is no trial period, you have to depend on reviews and comments.

You will always sell more product if you lower the price... that's why they call them sales.

[John Strasser]

Edwin,

When I was enrolled in a sales training course years ago, one of the first things they taught me was (duh!) that "not everyone's you're prospect"

If 100 EURO is too much for some people they don't need what you offer.

For example - in my role as a therapist/coach/trainer I have a range of products (actually services) with a rate $250/hour on the low end to $2,000/hour on the high end. Obviously the clients I'm targetting with the 250 are different from the 2000. Very different prospects.

So when evaluating programming tools, if your tool saves me an hour (especially if I'm using a fixed price contract -very common for me when I wrote software as a consultant) every hour saved was money in my pocket. And even in "the old days" I valued my time as worth more than $150/hour.

And since a product like yours would save me time on *every* project it's surely worth 1 "hour" of my time.

It's why we buy tools like SQL Tools - Using a DLL beats me having to write my own ODBC drivers (especially since I don't want to learn ODBC).

While I'm on the soapbox one more rule - people will always try to beat down your price and turn you into a commodity. Your IDE is different from EZGUI which is different from FireFly, which is different from Jellyfish, which is different from UltraEdit which is ...(you get the idea). Each has different strengths and appeals to different users (or the same users with different types of projects).

So my advice is stick to your guns.

John, Hypnotherapist Extraordinaire, NLP Trainer,
and Full Time Grad Student in Clinical Psychology
---------------------------------------------------
John Strasser
Phone: 480 - 344 - 7713

http://www.inthespiritmarketing.com

http://www.lifetranscendent.com

[Chris Boss]

Edwin,

Let's examine your product and look at its real value.
I am taking these points directly off your web site.

You provide 20 custom controls, some of them very nice interface controls.

Let's say you sold each control separately at the amazingly low price of $10 each, then all 20 controls would be worth $200 (already more than what you charge for the entire product).

Besides generating EXE's it can generate code for:

- Console apps
- CGI apps
- NT Services
- Dll's
- Controlpanel applets
- Excel Addins
- Create your own custom controls (if I read it right)

That is definitely worth something !

You also provide support for accessing .NET , something no other tool does that I know of.

That is definitely worth something!

Then add to that your Visual Designer environment, which even supports ActiveX !

That is definitely worth something!

The point is that the feature set is quite rich!

Another important consideration is future development. If you can't make it worth your while to develop your software (make a fair profit), then you won't be around in the future to develop new versions. That effects your customers who depend upon your software for their work.

[Joe Byrne]

I purchased v1.0 when you had a "sale" (actually, I believe you were thinking of leaving the PB business and wanted to "liquidate" ) I don't remember what the actual price was, but I bought it based solely on the feature set (and your reputation of being a great PB developer!).

To be honest, I haven't really used it. It's too "VB" like for me, but that's not really the issue. I tend to agree with Chris that your product is well worth the current asking price. The comments from some of your customers tend to make me think it might be under priced in fact.

I looked at the upgrade when that went on sale, but after spending about 5 minutes searching your site, I never did find the cost, so I moved on. I'm not sure what an update cost should be percentage wise, but in any case, I seems to me that I probably would have upgraded for ~$50 to $75 even though I don't actively use the product (I like to have as many tools as possible handy since you never know when you'll need something different). However, like I said, I couldn't even find the prices on your web site so I didn't make a purchase.

Not making the sales process easy is probably more damaging to sales than missing the "sweet spot" on price by 5%-20%

[Michael Zimmer]

There are always people who want lower prices. Don't sell to those. You will have the same work as with every other who pays in full.

PowerDeveloper offers a lot, i've switched from VB and like it. Compared to VisualStudio it's tiny and fast. One thing i'am missing is the IntelliSense, but i would be ready to pay more if you add features that are useful.

[Michael Mattias]

Let's examine your product and look at its real value.
I am taking these points directly off your web site.

What the seller thinks something is "worth" is meaningless; that only thing which matters is what the buyer thinks.

Except of course in non-market economies.

MCM

[Chris Boss]

What the seller thinks something is "worth" is meaningless

To sell software properly, the seller must not only examine his investment in it (time spent developing it), but he must estimate the value of the software to the end user. All customers want to pay as little as possible and if they set the price developers would earn nothing. The tricky part of for the seller to convince customers of the value of their product.

As an example, take a look at the Linux market.

I once talked to a developer who wrote a programming tool which was multi-platform. He said he finally dropped support for Linux, because Windows programmers were willing to pay for the tool, but Linux programmers wanted everything for free (so much open source).

While I appreciate open source, at times it has a negative in that it has created an implied value of zero (nothing) for the software.

A lot of work goes into developing software and it can't be done for free. The task for the developer is to create such a good product that the value to the customer is obvious.

Value must be quantified to the customer. They must see what it will do for them and how it will benefit them. Customers often may not even realize the true value of a product before purchasing it. It is up to the seller to quantify that value.

Let me illustrate:

I use to do custom programming for local businesses for years.

I had one customer who in the early days of PC's spent $5000 on a new computer (they did cost that much back then). He didn't know what software to get for it and was looking for help. He wanted to use it in his business, but didn't know where to start.

When he went to someone he felt knew about computers, he was told "be ready to spend 5 times what you paid for the hardware, for the software".

This person, finally came across my name and called me.

This is how I handled it.

When I met the customer, I spent a little while talking to him about his needs. What did he want to do with his computer ? How would he use it in his business ?

Finally, I did something that surprised him.

I asked him to write on a piece of paper in a list all the things he thought he might want to do with his computer, like payroll, accounts, job tracking, job estimating, shipping, etc.

He wrote down a list of about 10 or so items.

Now this is where it got interesting.

I asked him to order the items in the list based on:

Payback

I explained to him, that payback is what you get back from using the software. For example, if you did your payroll and it saved you just an hour a week, then the payback would be a hours worth of work. If you had an item that got your new customers, then that has value.

The customer had never thought about this before!

So, he organized his list.

The results were interesting.

Rather than tasks like payroll and accounting being the first areas to computerize, his list indicated that the biggest payback would come from Job estimating and job tracking (he has a custom machine shop).

I explained to him, that that was where to start. The other stuff like accounting or payroll could be done later, but he should tackle the items with the biggest payback.

He was so impressed by my approach he hired me to design custom software. For few thousand dollars, I wrote a Job Tracking, Job estimating (and shipping needed to be tied in) program.

Was there a payback ?

Absolutely!

The customer told me an experience after he was using his software for awhile.

A potential customer from another state called him and requested a quote on a particular item to manufacture (his company built custom replacement parts for older machines other companies used in manufacturing). The potential customer called in the morning and asked, could you have a quote back to me by the end of the day. He said sure.

My customer, then sat down at the computer and generated a quote (not easy for his business because it requires laying out all the tasks on machines to build the custom item). It took him a few minutes and he then faxed the quote to his potential customer.

What happened next was interesting.

The potential customer called him and said (in effect) the following:

He was going to give them an order to manufacture what he needed and here is why. In all his years he never had gotten a quote back in fifteen minutes.

My customers, customer was impressed by the quick reply with a quote and he made an order.

Now of course this would be a sad tale if my customer made a rash judgement on the quote and maybe should have took longer to do it, since he could lose money, but remember that part of his software did not only job estimating and job tracking. The point is, the software was reliable and he could depend upon it to help him make good choices.

In time this customers business did so well, that he sold his previous building and then built a new $250,000 shop in the local industrial park. He was rated in the top 5% of Dun and Bradstreet (he told me) ratings because his company was so proftable. Over the years his business has continued to grow and prosper, even when the economy was bad.

He is still today using a later version of the software I designed for him. He is still using a software package which was originally developed about 15 years ago (it was upgraded twice).

You see, from this story, the customer does not always know the value of some software to themselves. It is up to the developer to explain that value and to give the software real value (because of how it works and its quality).

Price is not the most important thing in a product. It is value.
The developer creates that value by his efforts in writing software and the quality of software he writes. The hard part is marketing that value to his potential customers.

This brings up another point, which may be helpful and that is making the decision of what is your target market.

In the case of Edwins Designer, he has to determine who his market is.

If it is for professional programmers who need a tool for quality work, then they should be willing to pay a fair price for such a tool. They get a payback in many ways if the tool solves many of their problems and it makes them productive. It is worth every penny they spent on it.

If the market is hobby programmers, they get a lot less payback. Sure they may get the satisfaction of writing their own software, but how much are they willing to pay for just that ?

This is why I suggested he make a low end version of his software. You can target the hobby market with a low cost product with less features, while the high end version of the software would be only for professionals who can afford the product and who will get a payback from it.

[Michael Mattias]

If you can't identify your market BEFORE you create a product,you may as well enroll at McDonald's University to prepare for your next career.

I have seen so much crap dumped into the market by guys who created one piece of software 'on spec' and thought that doing that one job right meant they now had a re-marketable 'product.'

This crap is the source of much of the the bad press and bad professional reputation IT types have suffered since the early 1980's.

If I do one thing before I go through 'final checkout,' I will see IT personnel respected as professionals the same as doctors, lawyers and accountants, and respected thus because they have earned it.

MCM

[Scott Hauser]

In Januari i had this pricedrop and was well-received.
In February i experianced less sellings and even a few mails for selling me PwrDev for the lower price.

Edwin,

I am a little hesitant to comment on this topic because there is always a fair amount of emotional attachment to one's own creations. This is normal as a considerable amount of "blood, sweat and tears" were expended it its creation. We tend to become friends over a period of time on this forum, which I view as a good thing. I've never met any of you guys yet I like you all. That said, I feel you have been given a lot of well intentioned advice that won't increase your sales.

There has been a lot of discussion of "value" in this thread but very little involving the reason we buy tools in the first place. Most people do not want a 1/4" drill bit until they need the 1/4" hole it produces. In my case, do I really need it and if so, how badly do I need it? Following that is the price consideration which depends greatly upon how badly I need it. As MCM stated: "What the seller thinks something is "worth" is meaningless; that only thing which matters is what the buyer thinks." He is absolutely 100% correct with this comment. He merely neglected to mention need.

You are in the tough position of trying to guess how many in this forum, lurkers included, are in need of your product. How many are professional as opposed to hobby programmers. Etc., etc.... Additionally, many of the visible PB community (posters) tend to be rather self-reliant -- much like you. The down side to this is that many of them would rather roll their own than buy a third party tool.

As to pricing, you are the only person on the planet, except for perhaps your accountant, who can see the sales bottom line, before and after the temporary price reduction. Thus you are the only one capable of making the correct decision. My advice is to follow your "gut instinct" on this.

Scott

[Mike Stefanik]

Additionally, many of the visible PB community (posters) tend to be rather self-reliant -- much like you. The down side to this is that many of them would rather roll their own than buy a third party tool.

The corollary to this is "how much to you value your own time?" If deciding not to buy that $200 software development tool or component means that you spend about 40 hours working on that code instead of 5 hours, "rolling your own" means that you value your own time at about $5 per hour; that's less than minimum wage. Doing it yourself also means that you have to educate yourself on how to do it, debug it yourself and maintain it yourself.

If it's for personal education and the learning experience, then that's certainly justification enough. But for business, choosing to not use available third-party tools and components is effectively the same as lighting a stack of $100 bills and throwing it down a hole. Or put another way, the time spent "rolling your own" could be time better spent actually improving the core functionality of your product, rather than messing about with ancillary things like drawing gradient toolbars, trying to figure out how to send HTML formatted email messages or creating yet another calendar widget.

[Scott Hauser]

The corollary to this is "how much to you value your own time?" If deciding not to buy that $200 software development tool or component means that you spend about 40 hours working on that code instead of 5 hours, "rolling your own" means that you value your own time at about $5 per hour; that's less than minimum wage. Doing it yourself also means that you have to educate yourself on how to do it, debug it yourself and maintain it yourself.

Actually I am in perfect agreement with your entire post Mike, to say nothing of the necessary learning curve with a new tool. Nor was I attempting in any way to suggest this is an ideal mindset. It is a recurring mindset I have witnessed many times in various posts over the last several years.

I believe that Edwin has an excellent development tool and I think he will succeed with whatever pricing and marketing decision he chooses. I also feel that his support for .NOT will make his toolbox very desirable as more PowerBasic programers move into that arena.

Edwin's product is competing with three other, likewise excellent products, all catering to PowerBasic users. The market elasticity for Edwin, Chris, Paul and Dominic will be only X/4 percentage of PowerBasic's market elasticity, where X is the number of users who will buy a RAD tool. The Devil is solving for X. Whether or not we cheer Edwin on, and I do cheer him on, his thumb is on the pulse of his products sales performance and only he can determine the best course of action to continue or improve his market share.

[Kev Peel]

The corollary to this is "how much to you value your own time?" If deciding not to buy that $200 software development tool or component means that you spend about 40 hours working on that code instead of 5 hours, "rolling your own" means that you value your own time at about $5 per hour; that's less than minimum wage. Doing it yourself also means that you have to educate yourself on how to do it, debug it yourself and maintain it yourself.

That's correct, unless you can sell it

What I don't understand is that several third party vendors here only develop products that support PB. Now there is nothing wrong with that in principle, as a host of PB-exclusive tools bolster the PowerBASIC name (just like Windows-only apps promote Windows), but you are limiting yourself to a very small percentage of the overall development tools market.

I write multilanguage libraries (Slam, PrpT), which has many non-PB users, which I would not have had if I just targeted PB and provided PB-only headers and samples. It wasn't much work to add the extra language support, except with VB6, which had a few hoops to jump through.

Perhaps it would be better for Edwin to focus on developing his set of custom controls and "mass market" those separately as an alternative to bloated 500kb OCXs. What would also be nice is to use a "Built with PowerBASIC logo" to highlight this. The approach would also draw users attention to his site and IDE, for which the price is right in my opinion.

[Joe Byrne]

Now that we have this nifty new forum software, I'd run a poll to try and gage how many people develop commercially and how many just "for fun". There are also those that develop for business need but don't necessarily sell they end product. If you're paid by the hour, it might be more difficult to justify not "rolling your own".

Somehow I think I recall that a poll like this might have been conducted in the past. If so, and it didn't provide the necessary data to make a reasonable business decision on, then I'd start thinking of more creative ways to find this information. As much as I appreciate the 3rd party makers here, I'd be real hesitant myself to try and build a business around it if I didn't know who my primary market was.

I would think, there is a unique opportunity for 3rd party developers to gather together and come up with some creative way to find out what percentage of those who frequent this board (ie, have the opportunity to see your product marketing) are using PB to make money, vs those who do it for fun, vs other uses. There are a lot of in-betweens here too. Personally, I could envision some form of contest, perhaps as simple as a random drawing from participants for a "3rd party product license of your choice", or something to that effect.

What does marketing and sales cost? For me, its 40% of my budget....and I'm cheap

[Michael Mattias]

I'd run a poll to try and gage how many people develop commercially and how many just "for fun

I think I did that poll about six months ago.

I remember I got some comments like, "I am more than one of the available choices" which were something like "full-time professional", "moonlighter" and "hobbyist"

Try searches on 'moonlight' and/or "hobbyist'

MCM

[Chris Boss]

Interesting discussion!

Scott touched on an important point and that is need.

My comments about the developers own value of a products value still are valid though.

Why ?

The end user only has a vague idea of his actual need. Often it is generalized. ie. I need an easy to use Visual Tool which will make me more productive!. The problem is that if the end user had a complete picture of his needs, he would immediately know which product would satisfy those needs.

The reason for this, when it comes to programming tools, is that such tools supply things the end user can't do themselves (or at least not quickly enough). If the end user could accomplish everything the tool does, they wouldn't need the tool.

This means the end user may not realize all that is involved in reaching their final goal (to develop such and such software).

This is where the third party developer has the advantage!

To be able to develop such tools, the developer must be more experienced with the task at hand (otherwise they wouldn't be able to develop the tool). It is their experience which makes the tool unique.

Now the developer must examine why his/her tool is important and what problems it solves. He must set a value on his tool and know why it will benefit the end user.

The end user will not purchase a product unless they see not only a need, but how a tool fills that need (or even fills needs they may not have considered). It is up to the developer to market the product in a way that helps the end users see the value of a tool to them.

For example with my own customer base, I have found most users only use possibly 5% of the features in the product (maybe even less). Often users use a small portion of the feature set for some time and as they become more experienced they start experimenting with other features. Quite often they will find that a feature they never thought of using, it quite useful and they will add it to their software.

So the point is the end user does not know all that they could benefit from. They simply make a judgement based on immediate need and the obvious needs. They have no idea what they will need in the future as they become more experienced with a tool.

Part of my own development strategy has been to use my own programming experience (I have written a lot of custom software for businesses over the years) as a guide of possible future needs for my customers. True I can't guarantee I will always get it right, but there has to be an overall plan. I have to try to foresee what my customers might want to do, after they become more experienced with the product.

Many new customers often say "I just need to do this and that" which is usually quite minimal. I see this in those who make the jump straight from DOS to Windows. What they may not realize, but I do, is that once they find that they can do "this and that" easily enough, they will often see, "well, how about trying to do this and that and more". They keep pushing the envelope, so to speak. Some of they programmers eventually start pushing the limits of their software far beyond what they may have envisioned.

The third party developer needs to see the future possibilities for their end users or at least give them tools so they can go far beyond even what the third party developer may envision.

For example look at some apps written by some of my customers:

http://cwsof.com/apps.htm

In particular the "Fathom Systems" I find interesting. I never envisioned such software being developed with my tools. Not that I didn't think it possible. I simply gave them tools which I thought could accomplish most anything they put their mind to. I could only hope that some would push the envelope with their software.

You might say, I knew at lot was possible, but had no idea what customers would do with it.

The point is, that part of marketing is to see the possibilities, even if potential customers don't. You want then to see the immediate benefits to them, but also see the future possibilities there.

There is an old marketing phrase, that you have to "sell the sizzle with the steak", meaning you have to highlight value now and in the future.

Now back to Edwins Designer:

Edwins Designer goes far beyond the simple "visual design" aspect of programming. His feature set is quite extensive and it does things that many programmers may not currently envision themselves doing. Edwin more than anyone else, knows what his designer can do. Even his most experienced customers are likely only using a small percentage of the entire feature set. That said, Edwin is in the best position to know the real value of his tool. He knows what it can accomplish. The trick is to market those benefits to potential end users.

If I were to make an honest appraisal of the web sites of all of us third party developers, we don't spend enough time on our web sites to give more details about the product. I know I need to do this more.

Now some will say, all I need is a downloadable demo.

Thats not going to tell the customer all they need to know. It may tell them whether they can get an immediately benefit from the tool and whether they like the interface, but it won't tell them all the possible future benefits of the tool.

Why ?

Because it takes time to learn any tool well enough to appreciate the advanced features. My actual customers don't fully appreciate what the tool can tool (they only use a subset of its features), how could a potential customer (even with a demo) fully appreciate what can be done with a tool.

The developer has to try to help potential customers visualize what is possible with the tools, not just its immediate benefits. They need to help potential customers grasp the possibilities.

Only the developer can do this!

Only the developer knows what can be done with the tool (its full potential)!

This is where marketing comes in. It is a very difficult thing to market software. It is an art. While most of us developers are good programmers, that does not make use good marketers. I know I have a lot to learn.

So Edwin, rather than dumb down your product (and lower its price) just to get more customers, spend a little time first trying to demonstrate its real value.

This is good point for some PwrDev users to speak up!

Why do you use PwrDev ?

What features did you find really useful, that you didn't even think about when you first purchased product ?

Now that you have used it for some time, do you think it has more value now, that you have used it for some time ?

I find satisified users are the best advertising.

Let's hear from some PwrDev users !

[Joe Byrne]

Thats not going to tell the customer all they need to know. It may tell them whether they can get an immediately benefit from the tool and whether they like the interface, but it won't tell them all the possible future benefits of the tool.

Chris,

I understand the thrust of your point, and I agree mostly. However, you originally stated:

The end user will not purchase a product unless they see not only a need, but how a tool fills that need (or even fills needs they may not have considered).

This is right on the money. This however, is where the demo does come into play and far more importantly that I believe you understand.

When I have a problem, I first look at what I have already available to solve it. If I come up short, or even think that a better solution exists, I start searching for it. What I'm looking for at this point is a tool to solve my immediate problem. I moreorless take for granted that any tool I look at has the potential to do more, but I'm considering a purchase now to solve an immediate problem.

Assuming that more than one tool exists that claims to address my need, I'll first look at those tools that offer a demo. The reason is simple, I want to know that it does what the author claims it does, and I want to know that I can make it work the way I need it to in order to solve my immediate problem.

If I find something that does the trick, that's probably as far as I go. If not, then, and only then, will I start to consider other 'non-demo-able' products. This is far less comfortable since I am now in the position of trusting the author to know as much as he claims to know. Sure, he/she might know more than me, but the only way I can prove that is by taking his/her word for it, or risking my cash to prove they are right.

Personal testimonies go a long way to help ease that discomfort of "sight unseen", but I am still at the mercy of what other people think. For all I know, they may be far more advanced than I so what is 'easy' to them may still be too difficult for me even using the same tool.

The author of the software is basically asking me to trust them with my money and the hope that if they weren't honest with me, that they'll be honest enough to refund my money. However, there is still the problem that I can't (or won't) normally make a purchase of all the potential products out there with the idea of returning what didn't work. I usually have to make a choice on one before doing anything else.

IMO, this works against the author that does not supply a demo for a number of reasons.

1. If I find something during the initial search (based on a demo that I used, tested, and proved myself) and it comes "close enough", then that's the sale that will be made and I'll likely never even look at the others. However, before making that decision, I will download all of the available demos and test drive each one first.
2. Since my decision will be based on trust, even one reasonably sounding negative remark will likely play more heavy on my decision than all the good ones. I don't want to be that one person that gets stuck, especially if the tool is $100 or more.
3. In my research, I'll look at the person's web site. If I find that difficult to get answers from, I'll move on. You are now betting that your web talents equal or exceed your programming skills for the product. Not a good idea in my book.
4. If I read some of the problems and solutions posted on the vendor's forum, I'm not likely to know the ability level of the person asking for help. You probably know well enough that this person understands a lot of the basic features of the product so your reply will take that into account. However, as someone who has not used your tool, your reply may seem overy complex to me, leading me to the conclusion that your tool is too complex for me as well.
5. In this day of demos all over the place (even for software in the multiple tens of thousands of dollars) I have to ask myself what you are afraid of by not providing one. Its kind of like the "innocent until proved guilty". Sure, I have the right of presumed innocence if I plead the 5th, but most people will assume you are guilty if you do that. If there is no demo, then I'll most likely assume your product isn't near as good as you say it is. If it were, then you'd want people to try it for themselves.

When I first purchased EZGUI (v2?) there really wasn't much else out there. I don't recall if PBForms existed, I don't believe it did yet, but even after I got it, I wasn't all that comfortable with it. It still left me wondering how to make the jump from DOS to Windows. Had Firefly existed then, I probably (likely) would have downloaded the demo and then worked with Paul as much as he'd allow to do what I could to make that tool work for me. Fortunately, there really wasn't much else that appeared to help me with the problem I faced right at that moment so I made the purchase of EZGUI. I didn't know you then and I had no idea if you were any good at programming or not. Clearly you had to be better than I since I hadn't done a single Windows program at that point, but just being better than a beginner didn't make you a good Windows programmer in my eyes. (I have since come to learn just how good you are though!)

So from a customer perspective, I see the lack of a demo for any software as a red flag. Even PB. Had I not already known Bob and what PBDOS was, I don't think I'd have stayed with it for the windows world. More than likely I would have looked at more "mainstream" languages. However, I knew Bob did high quality work and was willing to invest my time learning Windows programming with PB over VC, VB, or any of the other languages out there.

Of course, EZGUI is your baby and you are free to market as you wish. However, I'm willing to bet that Paul doesn't regret offer his demo of Firefly (or any of his products) and I'm equally certain that everyone who looks at visual designers for PB has at least downloaded Firefly and taken it for a test drive. At least Paul has gotten his software into lots of hands and let the product 'speak for itself' so to say.

[Edwin Knoppert]

A lot has been said and i like the discussion, however, i am trying to stay out a little and see where this goes, just for fun and ideas maybe.



Chris seems to like some of the PwrDev's features (as noted by a few other threads) and i thank him for being so modest.

What i want to see about the demo, even I think a demo has good value.
But PwrDev lacks the more obvious functionalities like imagelists icw toolbar design.
These parts can be found in a tool like VB and makes it easier to create the finishing touch for any experianced as inexperianced user.

These kind of parts not being available.. i think they are the drawback of this tool, it's simply not that finished.
I think to compensate that with functionality called 'Extra Code'.
It's just a tree where you can select desired functionality to be compiled along with your own code.
I believe it isn't enough and visual design tools need to be extended with the obvious parts.
This is one of the reasons not having a demo.
Personally i never cared for that level of visual design, two simple copy and paste code fragments fill my need maybe even faster as with some kind of visual design mode.

The above is just one of these obvious things people may encounter, also note that this lack isn't mentioned much on the HB forum over the years.
Seems the projecttemplates help people so far, don't know.

Biased mode:
Overall i find PwrDev a supurb tool for rapid development, for both try-outs as serious applications.

As Chris said, "Edwin more than anyone else, knows what his designer can do.".
I think that's true and sometimes i wished for more in-depth questions to challenge the internals of PwrDev (solutions).

Back to listening mode:

[Marco Pontello]

I think that one things that authors of complex software (and that obviously include visual designers) can do, to help people have a glimps of what the software can do, and how things are done, is provide various screencasts, each dedicated to show some (peculiar, special, not so obvious) feature.

Screenshots, code samples & written descriptions are one things, but seeing some work doen by someone expert with a software can be much, much better. In some ways (but not all, off course), it could be a "surrogate" of a demo version.

Something like: "Here's how to build a basic windowed app that open an Access DB and do a simple query". That will show the basics of how the user operate the visual designer, how coding is done, what instruments / wizards / dialogs can assist the developing process, etc. etc.
That can be enough for a programmer to see if the tools suite his personal way of doing things / thinking, or maybe could raise some questioning to authors about some specific details, and so on.

There a tons of (even free) screens / sessions recording tools, with or without audio comments, window tips, etc., and for someone expert with the software it could be a reasonably fast process to produce some interesting Flash that can complements the screenshots and descriptions on a website.

Just a tought.

Bye!