![Prevent Support Calls [updated July 29, 2010] - Preview Image](https://24usoftware.com/cs/news/image/34)
After being silent for a while, busy preparing a new product launch, I am now back and cannot wait to tell you what you all probably guessed already. Pssst, rumors have that an all new SimpleDialog is rolling out. But before I confirm or deny the rumors, I have a story for you. You should read it especially if you don't use any dialog plug-in yet. It's a real story about a real customer. A story about how we (24U) could easily prevent a lot of support calls. If we only used our own product...
Once upon a time...
OK, here's the story. We have a customer where we did a relatively complex FileMaker solution as a replacement for their old system created in MS Access. They decided to name the application TABUDDII.
Since they need a lot of reports generated from the data they enter into TABUDDII every day, we created a script that pre-calculates most of the numbers for their reports on a daily basis. This script was called Daily Update and the customer's users were supposed to launch it every afternoon when leaving the office by clicking a special Daily Update button.
First support call
The Daily Update script was supposed to run unattended during night, so we did not care too much about how long it runs. Actually, its first version took only about half an hour to finish.
Everything was fine and the script worked as expected for some time. Until we got the first support call claiming their FileMaker froze. Without any idea that the freeze was not a real freeze but a runing Daily Update script, we suggested they force-quit FileMaker Pro and re-open the solution. Second call followed soon from a different user, reporting that Daily Update was not performed. What actually happened?
The user responsible for running the Daily Update forgot to run it the previous day. So he clicked the button in the morning right after coming to the office. While he was away from the computer where the script was running, another user came to it and tried to click on another button. It did not work so he called and reported the freeze. He was just a user, with no clue what all the different animated cursors mean...
I recalled what the Apple Human Interface Guidelines document recommends:
"For potentially lengthy operations, use a progress indicator to provide useful information about how long the operation will take."
and later in the same document:
"A good reason to provide feedback during lengthy operations is that if your application fails to respond to events for 2 seconds, the system automatically displays the spinning wait cursor for your application. Users who see this cursor without any other feedback might think that your application is frozen and quit it using the Force Quit window."
So we did exactly what Apple suggests. It took just about 30 minutes to add and the freezes were resolved. Forever.
Second support callA few weeks later we received a support call related to Daily Update again: "I cannot run the Daily Update. TABUDDII says my colleague is already running it but he is not int he office any more." What happened in this case?
Since the Daily Update script modifies a lot of records in many different tables and there are cross-relations between the data, we implemented a protection so that only one user at a time can run Daily Update. When one user starts Daily Update, all other users are presented with this error message:
This action is currently locked by user George running script Daily Update since 14/07/2010 17:01:38. Please wait for George to finish running the script. If George is no longer running the script but this error still appears, please ask all other users to log out from TABUDDII temporarily, and try it again while being the only user logged into TABUDDII.
You would assume it says everything clearly and advises what exactly the user is supposed to do, right? We assumed that, too, unfortunately. And had to answer such phone calls many times again. Until we discovered what the user actually saw on his screen.
Can you see what's wrong with it? Right! The advice what to do is completely missing. It is actually there but you have to resize the dialog to see it. But there is no way to find this out until you try it.
Once we knew this, the solution was easy again and took us only about 10 minutes to implement:
Can you imagine that we had these features in our own product for years and still hesitated to use them?
Don't hesitate to prevent support calls
Does the story sound familiar to you? Do you want to spend time answering support calls? You can save tons of time by adding just a little extra bit of comfort to your solutions. I have just shown you only 2 examples in my story but I have many more. I am preparing an instructional movie on this topic and will make it available to my blog subscribers soon. The tools are out there. Just don't hesitate to use them.
Many developers still hesitate to use plug-ins in general. Do you want to know how to use plug-ins and still stay safely independent on them? I will be covering that in my next post. Just subscribe and stay tuned.
Oh, one last thing. Now I can tell you. Yes, 24U is going to roll out a new version of SimpleDialog this week. It has been completely rewritten to run natively in FileMaker Pro 11 on Mac OS X 10.6 Snow Leopard and Windows 7. It has several new features but one is really revolutionary. And what's more - I am going to give a HUGE advantage to my blog subscribers. So if you have not subscribed yet, make sure to do it now HERE!
In the meantime I am running a poll about which dialog plug-ins people use with FileMaker Pro. I will be glad if you participate. Also if you have a minute, please leave me your comment below. Tell me what you think. Tell me your story.
