I think if you're that needy for web-deployed performance, then maybe you should invest in a CWP solution, which would only commit/request/refresh on demand and not in realtime like WebDirect.
Maybe years from now, there will be an option. WebDirect is still under a half year old, and the developers community hasn't even had time to really dig in and compile best practices or discover performance tips.
For now though, it's definitely a case of "you can't have your cake and eat it to" with WebDirect. The ease of use and deployment is a trade off for decreased performance under load. But if you look close enough, the new FM13 model fills the gaps in a lot of SaaS and mobile app niches. Places where fast deployment, ease of use, low-cost and good-looking all fall under the requirements.
Todd Geist has hosted a data binding session at devcon a few years now, and when you realize what can go wrong when you have a request/submit rather than realtime binding model, then you're thankful that FileMaker does a lot of the heavy lifting for you.
Thanks Mike for your thoughts - any others?
Cheers - Nick
For now I'm sorta with Mike on this.
FMI will make WebD better and faster, I don't doubt that. But the whole premise is that it WILL behave pretty much like a FMP client does. Including and especially the under-the-hood notification scheme.
If you don't want that then CWP is a better option, then you have full control over everything.
I mentioned this in that other thread...but I throw it in here to.
Users may expect/tolerate the manual refresh of data...but it's not really what they want. Google has show it is possible to update, nearly live, and have performance be awesome. While Google Wave was not adopted, what it did was show the possibility of real-time updating. Which is really what consumers want. Look at the progression of data push as an example.
From a developer perspective, we can say no we shouldn't need to do that...but from a user perspective, it is what they expect from desktop software. And the advances in browser technology and in code in general has already started to show them its possible. There is a blurred line now between a desktop app and a web app. And most users don't see why there should be a difference. Plus to perform an action, you need to retrieve the current data in order to proceed anyway.
Ads on website update dynamically. Their gmail automatically fetches and displays new emails, reminders, etc. Website tickers update weather automagically. Phones are designed to have data pushed to them as fast as possible ( text, email, updates, etc). We are in a world of technology-based instant gratification. And the demand is to build applications that are platform agnostic, automatic updating of key data, and nice to look at and use.
I do think WD will get there. WD is like IWP the same way new Hybrid Cars are like Fred Flintstone's car. It's a new code, a new approach, with new challenges to overcome. And the first one will always be performance and speed. The Model T had a top speed of 65 mph, got 25-30 mpg, and cost $800. But no one is clamouring for their return. Technology progresses, and I don't think suppressing the auto-update of data is the path to the future.
Thanks Wim and Joshua - it looks like I am in a minority here - which is interesting - perhaps the holy cow is good but just needs to become a little less active?
I have no interest in CWP - but I am interested in pushing the envelope with FileMaker Platform Apps - an d speed over WAN is pretty much everything - other than data integrity - and reducing the holy cow's volume and frequency will go a significant way to helping in that area I would think.
Cheers - Nick
Well, I agree that the performance hit right now is high. But that is a matter of optimizing the communication between server and host, not one of abandoning a feature. If they are trying to use the same model that the desktop uses, a cache file that constantly communicates back and forth, it won't work on mobile devices, ever.
But pushing the data that is relevant to the current context should be doable, and should be able to be optimized to the point that is changes how they handle it in the client version also.
Nick, I don't think what you propose is quit as simple as you might think. WD is an entirely diffferent paradigm than traditional web pages that click to submit. This is a Rich Internet App with lots of moving parts...AJAX, push, and so on.
If you noticed the new script step to refresh an object, in web direct that translates to telling one part of the web page to refresh it's content instead of refreshing the entire page. In that way, it greatly reduces network latency because you don't have to reload then redraw all the html that makes up the page. There's lots of moving parts behind the scenes and these go mostly unnoticed and taken for granted.
That's really the only way to include functionality like all the script steps it does support, it's really quite nice with everything that they do support. That being said, this is a version 1 release for WD, but it's got very good potential.
For example, look at facebook... visually it still resembles a basic html page, but there's a lot going on there that people just expect to work nowadays like indicators changing, chat icons lighting up, little popup windows, etc etc.... Just pointing out that is now contributing to user's expectation.
If you want a simple web page, you can certainly build your own. I don't want FMI to include a "simple" one for me, I wouldn't use it, I don't think most would.
make a feature request
I see FileMaker's problem. Each feature / option requires more coding / testing, and the engineers have just so much time
> Per Olsen recently commented "FileMaker really needs to put a lot of effort into WebDirect to get it to move faster and reduce server loads. That COULD be done by giving the developer a choice to use submit (commit) buttons instead of having the WebDirect client chat continously with the server.
Yes - I do have some limited familiarity with WebDirect and had indeed noticed that script step.
The question I posed was based on what I have observed when meeting with and talking to folk at FMI in Santa Clara over the past couple of years and noting the key role that FM WebDirect seems likely to play in the future of the FM Platform.
For it to work commercially if must be faster enough. The way you make stuff faster is, generally, by removing activity that you decide is not essential.
Hence, if you look at how WebDirect currently works with a browser under iOS you can observe much too frequent refreshing - one reason why WebDirect isn't yet recommended through that deployment.
So as it is clear that reducing network activity is a key part of how FMI have been working to improve WAN performance generally on the platform since starting work on FM12 - I thought it would be interesting seek views on whether leaving us as developers to determine when we wanted the update to occur was a desireable next step?
The general response suggests that it may be a step too far at present :-)
So it is very interesting to hear your views,
Many thanks, Nick
Thank you for a thought-provoking post.
Before considering whether or not to allow developers to control refreshing the WD UI, I think that the "next step" would be to let FMI Engineering do some optimization of the WD product without changing/adding features or concept.
I think it likely that the FMI "greater plan" for WD includes product updates with some under-the-hood optimizations which could potentially take things to another level both in terms of performance and perceived performance.
With respect to the concept that you and Mike Duncan mentioned, i.e. the ability to refresh individual page elements independently as needed:
My guess is that this first release of FM13 has set the foundations for this sort of design, but that under-the-hood it has not been fully utilized and optimized yet. I could imagine that a really well-optimized implementation of this concept (where both the server and the browser only push the minimum data needed to keep everything fresh) could play a key part in making the WD product meet and/or exceed our expectations for a "snappy" UI.
I see somewhat of an analogy with FM's use of CSS for defining layout objects:
I recall that when FM12 first came out, we were all understandably excited about the new looks that were possible, but I also recall that I was a bit stunned when I looked at the DDR output. I felt that one of the most key reasons for using CSS had not been leveraged by FM, namely, the ability to minimize the data needed to define a layout's look by having CSS definitions that apply at a layout or file level (as opposed to each layout object having its own potentially redundant CSS definition). As it turns, out, this particular optimization that I was looking for in v12 was indeed part of the greater plan, and it arrived in v13, making a good thing even better for those willing to design accordingly.
"For it to work commercially if must be faster enough."
This just isn't true. Maybe in YOUR context it has to be faster to work commercially. But depending on industry/client, WebDirect as-is may be a very viable option for the solution that they need. Especially if it's a smaller office that's been dealing with the hurdles of IWP, or the overhead of trying to create a CWP solution.
Don't forget there are hundreds of developers worldwide on the FM platform that are developing in ways that are completely different from you!
I welcome innovation more than criticism (obviously!), and am looking forward to the innovations that are soon-coming on WD. Let's not beat a dead horse anymore though. I agree WebDirect shows exponential slowness as you scale it, it definitely is something they know about and will probably be working on in future releases.
I don't really see the auto-save as a big negative, and I'm not sure that's where the performance hit is coming from. It's the OTHER refreshes that are happening that seem to agitate me the most. I would prefer we see some kind of notification system where we can trap a refresh event from the server and then selectively decide if we want our interface to ignore the redraw or process it.
Yes Lee, I agree - a little control will go a long way here I suspect,
Well I guess we may have to disagree on the speed thing Mike - folk on mobile devices do not have much patience in my experience - but as you imply its horses for courses!