Another FMP 11 Disappointment

[Søren Dyhr]

Well, then the mentioning of the bare existence of a runtime builder should be entirely omitted ... since explosive expectations are likely.

But a developer is still able to build the foundations with whatever version, and then migrate it RunRev and then add all the bells and whistles he/she could think of provided having what it takes to get there ... making the produce ready for wheeling and dealing, like any other commodity.

I have only used the runtimes to demo what I had in mind, never sold any solution as foilwrapped. Since I know of expirience that both the runtime builder as well as IWP isn't where the tool really shines.

The tool is much better suited to perform something live in group, just like:

http://www.joelonsoftware.com/items/2009/09/23.html

...a way of having a tool which can morph to the circumstances, not being overly complicated to get things done with.

An perhaps Ryan Rosenbergs vanity plays a little trick with him here? But I can easily see that the bare efford of explaining these limitations, they are way beyond the "no battery included..." - because the real problem could be this:

Indulging in too much self-congratulation and individualism has resulted in the loss of the capacity for self-examination. Most dangerous is the American tendency to solve problems by looking for scapegoats and quick fixes without considering the consequences.

Stumbled over by googling this:

http://findarticles.com/p/articles/mi_qn4188/is_20070507/ai_n19062972/

...and yes the larger your operation is the less are you likely to be sensitive to being made a scapegoat ... by some "fools on the hill" - all large companies might even operate with some sort of mosquito bite tolerance, in their operations. Simply because if the above quotation has any bearing, what is the cure against it?

The customer is always right, is the saying ... but it doesn't imply that everybody is right without conditions? What would you do with customers explosive expectations? Let's imagine you're the next in Rosenbergs seat?

The tool is apparently selling in buket loads despite... if it ain't broke don't fix it - would i suggest. Because if the measures you're likely take on behalf of the so called consumers, are going to make the sales stall ... are you not going to have the bolster in the seat replaced in your time in it!

It's as if it have been said "one single tools gets you there..." but can you mention just one single tool that actually does that?

But what you suggest is that even though filemaker is making money on this, should "as is"'es be sprinkled all over their marketing stuff ... but how many features would then remain, universally harmless to mankind?

--sd

[comment]

Well, then the mentioning of the bare existence of a runtime builder should be entirely omitted

Why? It's a feature of the product - and quite an attractive one for some. I have a couple of runtimes deployed at clients and they serve their purpose quite well without requiring yet another tool.

[Søren Dyhr]

So you think it should be included in the promotion, but with a disclaimer attached ... next in line ought then to be IWP'ing when we are at it - you can possibly think up a whole handfull of matters with questionable behaviour.

I would gladly know what your first move would be, after depriving Rosenberg his throne? Whit out making the product start plummeting?

--sd

[comment]

I have never had the pleasure of meeting Mr. Rosenberg. I think the problems at FMI run much deeper than what could be solved by replacing this person or another. But to the current issue, I agree with Alex: there should be an asterisk pointing to a disclaimer.

[Søren Dyhr]

what could be solved by replacing this person or another

A point I raised as well earlier, but what could then be done since it's hardly the only place in need of an asterix then ... steepening the learningcurve to dissuade the Pareto cowboys from attempting or raising the overall price on the packet could perhaps animate to a more thoroughly worked purchase decision.

I have absolutely no idea of how much the p/b relation could be squeezed upward without affecting the bottom line. Btw isn't the caveat emptor not fully eradicated from todays law, as you claimed in your post to Bruce and here is the condtion still:

The only exception was if the seller actively concealed latent defects or otherwise made material misrepresentations amounting to fraud.

Where is this active concealment done here? To me is the crippling not the same as a defect, limited versatility is something different - there are still something usefull in the runtime builder, we do both recognize that.

--sd

[Zcast]

I completely agree with Comment on this one. And besides, if we have to "migrate" everything we do to RunRev as Soren suggests (quite often, I might add), why not use RunRev instead of Filemaker to begin with? When you buy a new car with four tires, is it not common sense to expect them to be filled with air? I guess, from reading through all the statements in this discussion, the best bet is to flood Filemaker with thousands of emails requesting info the next time a release is made. And as for "explosive expectations will be expected". Not true. We simply would like the features in the program to work with everything in the program. I'm not expecting my runtime solution to predict the lottery, just use some very basic graphs. I mean, after all, scripts and calculations work on all layouts, not just one. Shouldn't all the features work, even in a runtime? As for "licensing", someone stated that a royalty would have to be paid for each runtime that every developer puts out with graphs in it, if they actually did work in a runtime. Why? Who said? Filemaker could get a "developers" license for their chart add-in, the same as we do with the plugins readily available to us, charge a little more for FM to cover that license, then everyone is happy! Could you imagine buying 4 rolls of toilet paper, then having to pay to use each roll? Paying "extra" seems to be the norm for EVERYTHING that is related to filemaker these days.

[Søren Dyhr]

When you buy a new car with four tires, is it not common sense to expect them to be filled with air?

But is there actually established a sort of common sense, on the expectation side of RDBMS, there are really a lot of unique takes upon what should be in the package ... an awfully lot expect spreadsheet'ish virtues which isn't really made provisions for except in filemaker - where is it put in writing that MySQL isn't a spreadsheet?

why not use RunRev instead of Filemaker to begin with?

You started out expecting shortcuts! If some of the legwork could vanish ... instead of learning something, particular usefull

--sd

[Zcast]

I do agree with you on that Soren, that many different users have many different expectations with what FM can do, or what they would like it to do. But, why put a "feature" in, if it doesn't work with everything? I am very happy without the charts in a runtime, but I easily see where this seems to be an issue that should be disclosed with a little more effort on Filemaker's part.

[Zcast]

I do own RunRev as well, by the way.

[comment]

Btw isn't the caveat emptor not fully eradicated from todays law, as you claimed in your post to Bruce and here is the condtion still:

As I said, I am not about to get into a legal debate. But I will make this note: caveat emptor is completely irrelevant here. As your quote suggests, the doctrine deals with defects in the product - for example, you purchased milk, and it turned out to be spoiled. There is no doubt here about what "milk" is - the only question is who should bear the responsibility for not discovering the defect in the product beforehand.

The question here is an entirely different one: what exactly are you buying when you buy FMPA? There is no suggestion of a defect in the product: everyone who bought FMPA gets exactly the same thing, so you cannot say your copy is defective - and there is no other standard against which one can judge what a non-defective FMPA is. There is, however, the seller's description of the product - and if the description is inaccurate or misleading, then it's the seller's fault.