We updated the server the past two days, you should see some speed performance of our site.

Jump to content
  • Our picks

    • The FileMaker Script Debugger is powerful. Its features are often overlooked. In this post we examine the buttons that control stepping through a script.
      The post Like a Boss: Using the Script Debugger to its Full Potential appeared first on Geist Interactive.
      • 0 replies
    • The fmp7://, fmp7script://, and fmp:// URL protocols offer FileMaker developers awesome possibilities. They can be used to control FileMaker solutions from outside or from inside. Examples include: from a web page, another application, or a FileMaker Web Viewer.

      http://www.twdesigns.com/fmp_url_protocol/
      • 0 replies
    • FileMaker 16 Card Windows

      A Card Window is a new type of window (FM16) that is modal (only to its parent window), allowing users to open a “context independent” sub-window (showing a layout in the same file or an external file) without leaving the parent window

      http://www.twdesigns.com/filemaker-16-card-windows/
      • 0 replies
    • Part 2: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer?

      Hiring a developer is about creating a working relationship. You want someone who gets your business and gets you. Having a good working relationship often determines the success or failure of a development project. Hire someone you are comfortable with who also has the skills necessary to make your project successful. Beyond the quality of the working relationship, there are several questions to ask that will help you determine if you have chosen the right developer.

      View the full article
      • 0 replies
    • This SQL code generator will generate ExecuteSQL() code for FileMaker allowing you to use unsafe field names and make changes to database schema after making the code. If you have feedback of any kind such as bugs or feature requests please visit the support topic for this file.
        • Like
  • Topics

  • Blog Entries

    • By Todd Geist in Geist Interactive
         0
      The FileMaker Script Debugger is powerful. Its features are often overlooked. In this post we examine the buttons that control stepping through a script.
      The post Like a Boss: Using the Script Debugger to its Full Potential appeared first on Geist Interactive.

      View the full article
    • By FileMaker Magazine in FileMaker Magazine
         0
      If you're the type of person who's into Math, then you probably know when you need to use Factorial() versus Exp() versus Div(). Inevitably, you're a better mathematician than I. My use of the Number functions extends to how useful they can be when you're creating your FileMaker user interface and solving workflow related problems.
      When it comes to FileMaker's Number functions, there are number of tricks I've picked up over the years from those who are much smarter at the "math part" than I am. For the most part, the functions are there when you need them and are obviously useful when your required solution deals with math.
      In this video, I go through the Number functions and talk about when and how I've used them. Which ones I've used the most and what you can do with them.
      Click the title or link to this article to view the video.

      View the full article
    • By eXcelisys in eXcelisys' Blog
         0
      Part 3: Quotes, Estimates and Change Orders, Oh My! — Understanding Pricing & Billing Models

      Creating the perfect vision of your business and even how a software solution enhances that vision is the fun part of dreaming about growing a business. Brainstorming ideas and building a mental picture of how business could be done more efficiently, or eXpanded, really gets the juices flowing. Creativity is unleashed. Evaluating the costs associated with business development, however, tends to kill the creativity. This is particularly true of software development because it often feels like a luxury item rather than an integral part of the dream, even though it is one of the elements of success.
      The first question is whether custom development and the associated costs are worth it. Without understanding the time and effort required to build an application, custom development prices may seem high compared to commercial application options. And frankly, they are. An off-the-shelf application has been developed with a general business model in mind so it doesn’t fit anyone eXactly, but is close enough for many. The creators of the application make back their investment through repeat sales so the cost per sale can potentially be fairly low. Customization may or may not be an option after the sale, so eXpect to adapt at least some business processes to match the features and workflow of a commercial application. That is the trade-off for a lower price tag.
      Custom software is designed specifically for your business model and workflow. You are the only one with that product and all of the time and effort spent to create it is done on your behalf. The value of custom is that it handles all of the work requirements you decide should be included and is designed to make your business much more efficient. As the business grows, the custom app can be tweaked to accommodate that growth. That means less time doing manual procedures or using workarounds to meet your work requirements for years. The trade-off here is that it costs more up front to build the perfect app and it will take more time to get it up and running. The return on investment, however, can potentially be huge in reducing operating costs while allowing for business eXpansion as employees refocus their efforts in more productive directions. Because any licensing costs are usually dramatically less than with most commercial solutions, surprisingly, it can often be less eXpensive than a commercial option in just a few years.
      Pricing
      Before deciding which is the right direction for you, it is helpful to understand the pricing structures developers use and how they use them to try to charge a fair price for their services. Hopefully, by gaining a little insight about the different billing models the evaluation process will become clearer.
      Most developers use one of three pricing scenarios — a fixed bid (quote), a fixed bid with change orders, or an estimate. All of these methods are based on developer estimates. None of them can guarantee how long the actual work will take and no developer can calculate the eXact amount of time a project will require. Therefore, all methods are formulated from a “best estimate” based on the known elements of the project.
      A note about developer accuracy in estimating. If the price seems too good to be true, it probably is. A novice developer will generally underestimate the amount of time needed to complete the project and will offer an estimate or quote based on the eXact amount of work that’s projected to be done (with no allowances for the unknowns). A seasoned developer will do a better job of estimating the necessary time, both in hours and in calendar days. Their estimate may be higher but that’s because their eXperience allows them to anticipate, and account for, roadblocks that could pop up and cause additional development time and money.
      Once the project is under way, the developer who underestimates the required time may walk away when they get to the point of diminishing returns — especially if they hit a development snag and realize they can’t turn a profit finishing the project with all of the requirements. That usually translates to cutting corners and omitting things that would make the finished product perfect. Some will stand by their word and take a financial hit to finish the work. The eXperienced developer, however, knows that a successful project always takes a bit longer than anticipated and has considered this when compiling the estimate.


      Quotes, Bids and Estimates
      Quote: A quote is usually a fixed price that the developer gives to the client after going through a discovery phase to determine as many of the details of the project as possible. Generally, this employs a very rigid requirements document and a well-defined scope of work. Whether the development time required is more or less than the amount of time that price represents, it is what the client pays. Period. Developers who use quotes without change orders have to make a best guess about how much additional time will be required for the unknowns and inevitable changes and add that to the quote. You pay for that time, whether it is actually used or not. Fixed bid with change orders: Most often a quote comes with allowances for “change orders.” In this model, the same process is used to arrive at the initial bid as with a quote. However, if the project scope changes and new functionality is added after the scope document is approved by the client, the developer adds an up-charge for each change. In this model, it is possible for the initial quoted project price to be reasonably low and the final price to be many times higher. Keep in mind it is rare for a project scope to remain the same from start to finish so cost eXpectations should be adjusted accordingly. The changes and additions are commonly called “feature creep.” They happen because in the process of reviewing your workflow to create an app that accurately reflects it, you will re-evaluate and modify some processes along the way and you’ll want the completed application to incorporate these changes. Estimates: With this model, the developer and client go through a reasonable amount of discovery, which may be a little or a lot depending on the complexity of the project and the amount of known information. Based on the scope of the project determined in the discovery phase, the developer or project manager makes an accounting of the number and complexity of the features and gives a range of the eXpected hours it will take to build. This is not a hard and fast price but a best guess based on eXperience. The client is then billed for the actual amount of work time required. Many people are uncomfortable with what they view as an open-ended price, but they are generally presupposing that the project will go beyond the high end of the estimate. This is not necessarily the case, especially in the hands of a seasoned developer. With an estimate, the client pays for the actual amount of development time. The final cost may actually come in lower than the estimate. Feature Creep
      The danger in all billing methods is the previously mentioned feature creep. One of the great advantages of custom software development is that you often recognize potential improvements to your workflow as a result of defining it in detail for the developer. Being able to modify the application while it is in development can improve your overall business efficiency. You want to take advantage of that as long as the feature creep doesn’t overwhelm the development process. If left unchecked, it can easily cause the project scope to get out of control and/or eXceed the budget.
      This is why an “open-ended” estimate feels like a black hole and a quote feels like a tidy box. Time management all depends on how modifications are handled. A strategy for dealing with modifications should be determined at the outset so that it is a benefit and not a hindrance. Feature creep can be easily controlled by focusing on the priorities first and saving bonus items for later in the development process. A good developer will help you identify and manage feature creep, ensuring that core priorities don’t fall to the wayside in favor of more eXciting new features. Your developer should categorize features in terms of needs vs. wants and tackle the needs right out of the gate to ensure they get done.
      Rates
      Two concepts are worth mentioning here. The first is the rates developers charge. Software development may feel like the Wild West but developers by and large tend to charge what they feel their skill is worth. Low-priced developers are often young (in the sense of time in developing their skill), inexperienced (with the technologies) or slow (haven’t mastered the techniques efficiently). The price seems right, but the work may be subpar or a lot of hours end up being billed because of slow development. More eXperienced and skilled developers are more thorough, quick to resolve development challenges and faster to produce the final product. They charge more per hour but bill fewer hours. The overall cost often works out about the same but can come with a noticeable difference in quality.
      The second concept is the three intertwined factors of any service: good, fast and cheap. The rule of thumb is that you can choose two of the three, but you can’t have all three. If the product is good and done fast it will be eXpensive. If it’s done fast and cheap it will not meet eXpectations. If it is good and cheap the developer has to spend time on other paying work to afford the time to make it good at a low price, which requires eXtra calendar time. You choose which two are the most important factors.
      Billing
      Fixed: The quote proposal defines both the scope of work and the final price, as well as the billing increments. Commonly, the agreement will be for some form of half down and half on delivery or payment in thirds with 100% paid before the finished app is delivered. Payment before delivery protects the developer from disgruntled clients refusing to pay for time and effort on their behalf. Hourly: This usually means some method of hourly pricing based on the actual hours worked. This could be billed at a straight hourly rate or even by the day, week or month. It can be handled as a pre-pay retainer or invoiced at regular intervals during development. In this scenario, the developer may deliver several intermediate builds and a finished product when the work is complete. Because this is a pay-as-you-go arrangement, developers tend to feel more free to share the work as it unfolds because they have been compensated for their time along the way. Now that we’ve established how to approach the prospect of custom software development with the right mind-set and eXpectations, it’s time to dig into proper planning. In the next installment, we will discuss the planning and organization of development, including how to define the scope of the project, gather the necessary information for your developer, and delegate responsibilities.
      If you missed Part 2, find it here: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer?
      Read Part 4 of 7: Coming soon — Making the Plan for Planning Your Plan of the Project Plan
      To read more about eXcelisys’ software design, development and consulting services, click here.
      The post Survival Guide: Find, Hire and Work with a Software Developer, Successfully! (Part 3 of 7) appeared first on eXcelisys.

      View the full article
    • By Todd Geist in Geist Interactive
         0
      In this new series "Learn FileMaker Like a BOSS!" we explore techniques and concepts and tools that will help developers become better at what they do. It is our goal to remind people of all that is out there and to bring those new to FileMaker up into more advanced development faster.
      The post Learn FileMaker Like a Boss appeared first on Geist Interactive.

      View the full article
    • By Todd Geist in Geist Interactive
         0
      DamageDetectoR is a free macOS-only tool that identifies the issues that can cause an XML DDR to fail to import into FMPerception or other analysis tool. It identifies specific issues and the location of each issue in your FileMaker file.
      The post Introducing DamageDetectoR appeared first on Geist Interactive.

      View the full article
×

Important Information

By using this site, you agree to our Terms of Use.