First, though it's a total shame you can't officially report the problem to them. They don't want to have reports for ETS
Jumping some circles, I could report it to them extensively, providing files etc, and urging them not to release this.
We know what happenned
Moreover someone actually said he reported the slowness at Beta stage.
But it's very obvious that FMI is perfectly aware of those speed issue before they even wrote the first line of code of it. That's very obvious, when you add functions / change a rendering engine it's a given it will make a performance hit, so either you don't care (like FMI did) or you take appropriate measures to counter balance it (if they were not aware of it prior coding it, that would make them the worst devs on erath, I don't think so).
FMI didn't care beacuse FMI can shove us bad software for years without having the community if full of zealots that defend even the worste FMI blunders, so yes you can blame the filemaker community for this.
If you want to know why is it so, read my analysis here
Hi Egbert, you asked
"do i understand you correctly: you blame the developers choosen to take part in the ets for not finding/fixing the problems we are all facing now? well, that might explain some defenses made here on this board…"
No I Don't, I blame the System & Human nature.
With the "Normal" caveat of not to use Beta to develope on a Production database, small throw away DBs are created for testing. These do not really perform stress tests and they usually look at one issue only.
It is only when looking at a fairly complex system that other "issues / flaws" are manifested.
That was my meaning.
I was at a FileMaker presentation today to our local Users group. The Slow issue came up and I was assured that they take it seriously and are working on it.
One thing I have come accross many times is user acceptance testing. I have seen where this has failed simply because the users who are doing the testing are either busy with other items or fail to notice an issue. Unfortunatly the issue comes up front and center once the software is release and everyone starts to use the program and things that were not noticed by the few are suddenly a big deal to the many. I can see why specific script steps or list view slowness might not be that noticable in small data sets or a quick test, but suddenly become a hugh deal in the field.
My impression is that developers like Richard Carlton and other FBA members had 12 much earlier then Technet subscribers and in fact did an extensive amount of work and testing to update their applications or build new ones for 12. I'm also sure that if they found an issue they reported it back to FMI. As an example see the announcements from Goya about BaseElements. My guess is he has been working with 12 for quite a while to produce the update.
I could not agree with you more and that was my point to begin with. Specifically;
"One thing I have come across many times is user acceptance testing. I have seen where this has failed simply because the users who are doing the testing are either busy with other items or fail to notice an issue. Unfortunately the issue comes up front and center once the software is release and everyone starts to use the program and things that were not noticed by the few are suddenly a big deal to the many."
As I tried to indicate, at least in my ETS case, I got enrolled late in the process & the requests from FMI were to concentrate on certain issues / areas to see if the "Fix(s)" work.
I don't doubt that other Developers were enrolled much earlier in the program and did do a lot of work. And, I don't mean to denigrate their or FMI's work.
I still maintain its' the fault of the System & Human nature. And, that it is the "Third Set Of Eyes" that catch what was missed or overlooked.
The Beta Pre release is too late in the cycle. Each developer has their areas of interest and will catch all sorts of things. But there is no Official way to talk about it. And with the "Don't use on Production DB's" what do you expect ? A Look see, a few tweaks and Mums the word. Got to wait for the GM Release.
I wasn't part of ETS. But birdies tell me that the conjecture that FMI did not have the performance problem VERY strongly presented to them during ETS just is not valid.
That makes sense. I just hope they can work it through and resolve it soon!!! I'm sure they are working on it and have contributed two examples in one file that they are analyzing.
The demo I saw today showing a number of great features I want to use like internal SQL and the new layout tools.
I looked at your input a few times the previous days.
And I was not sure. But after coming back to it, I will share my first and last thought:
You are definetely angry about somethings.
And you are shooting at somebody, but I am not sure who.
So just let me tell that
You do not give a damn about:
ESS, CSS, SQL, IWP, CWP and all those other three letter "THING A MABOBS"
But they are very important to a lot of us. And they are some of those 3 or 4 letterwords that makes us choose FileMaker as the preferred tool for development of our solutions.
Then you state.
I don't want to be forced to implement all those new fantastical available 3 letter thingies.
Now, please help me. Who is trying to force you to use CWP, IWP or ESS?
And how does IWP or CWP interfere with your work if you are not using them?
A lot of us want to help.
Therefore could you please state what it is in FileMaker 12 that are breaking your FileMaker 11 solutions?
- We can all learn from the actual issues and learn how to solve them.
I am not sure what happened. But, you lost the whole point of my "opinion piece", it must have gone way over your head. I am not sure you know how to read "Tong in Cheek" comments.
I, for one, certainly do not appreciate your puffery.
It is probably because I am not a native English speaker/reader. But your attacks left me wondering.
As far as I am concerned this converstion is over.
My words were in the form of a critique not an "attack". There is a BIG difference.
I'm pretty sure many of the issues folks are frustrated about were brought up in testing. There's a great deal of work that goes into testing, and I know many folks in the testing program spend HOURs doing tests and preparing examples. They are just as interested and concerned about performance as you. Ultimately though, a product has to make it out the door, and what goes out when is often a compromise. It's just life. Sometimes it really stinks. The key is how the company responds to the concerns of their customers. I know FMI is working to remedy the serious issues of concern as quickly as possible. FM Pro is a BIG JOB. Think of all the platforms and OS variations it has to be tested on and deployed to.
While FMI no doubt wants to fix this ASAP, they have to be sure they do not introduce additional serious problems, or they will just compound the problem, and every upgrade release has a financial costs associated with it, as FMIs customer base is fairly large. Hang in there, help is on the way. I'd suggest living with FM11 until a uprade is released, but in the mean time you can start to explore and get familiar with the features in FMI. It may be slow, but for many users and databases it is usable, and with such a huge number of changes under the hood FMI had to start somewhere.
All that said, I have some nasty FM databases, and to quote a famous President, "I feel your pain." ;-)
David Rawcliffe wrote:
Incremental database enhancement has been left behind, we are now playing in the Graphic Arts arena.
This was an important move that FMP had to make at some point. The old interface capabilities didn't keep up with other related technologies. Whenever I build a new interface, I ask myself how someone would expect to do it on the web, because the web has become the core reference point for nearly everything that everyone does nowadays.
Also, Dave, how many times have you gone into a new customer where some IT or user is bagging on FMP because it is not a professional database? I think part of that is that do-it-yourselfers (and even many professionals) have been hindered by the previous lack of real interface tools. I think this was important to help change FMP's reputation.
All that said, I am disappointed that some of the interface elements seem to have been implemented to replicate a graphics program regardless of what is truly approrpiate to how database developers actually use layout mode. I also continue to be highly disappointed in how Inspector works (or rather, how it does not work). But overall, the layout tools needed an update and they STILL haven't caught up to where they need to be. I think FM12 was just an incremental update in relation to where it needs to go.
David Rawcliffe wrote:
I don't give a damn about ESS, CSS, SQL, IWP, CWP and all those other three letter "THING A MABOBS"
I know what you mean, Dave, but the world continues to evolve and that world more and more demands mobile and web apps. I farm out such work because learning to use PHP or an iPhone at this point in my life is more effort than I care to make. Nonetheless, it is incredibly important to FMP's market and continued growth.
David Rawcliffe wrote:
I would make the COMMENT that all involved in the ETS 12 program had a responsibility to say "BASTA" something is off, let's discuss / fix it.
I'm not sure where responsibility lies here, Dave. Like you were in the past, beta testers are always busy and not everything gets tested in the way they will be in the real world. My guess based on my experience in past beta programs is that testers reported a lot of things that time just didn't allow to be fixed. At some point, the product has to be released; you do your best to fix everything before deployment, but sometimes you have to temporarily overlook some issues until later. I'm sure many other things got reported by testers who were brought into the testing loop much too late for their comments to have any effect on the interface (which typically gets frozen much earlier in the process).
Take something way from a client, there is going to be a Royal Outrage, witness all these threads.
Yes, so don't take anythign away from your clients. I made it clear to my clients from the day FM12 was released that there would be absolutely no upgrades to 12 for a minimum of eight months, based on past FMP update schedules of essentially one v-rev each three months and my guess that some stability might arrive by 12v3. Make such a recommendation to your clients, Dave, and no one will be able to complain to use that something was taken away. I would love to take advantage of FM Server's new speed and stability, but not at the expense of lost efficiency in layout mode (and perhaps some on the client side, as well).