8 Replies Latest reply on Dec 13, 2013 1:05 AM by ChrisVanBuren

    A short simple wishlist.


      I have no desire to tell FileMaker what to do and I respect their basic business model decisions. That said, I see a few, small simple things that would help:


      Commercial Points:

      -Offer an annual or monthly cost for one license on up. So "AVLA" for one license. This would really help win small projects where FM sticker shock is a problem. I lost a small project this way a couple of days ago. They needed perhaps 1 day of my time but 3 FM licenses. The FM licenses doubled the cost so they are now using Access and the lady's husband is having a go at writing it.

      -A much more meaningful price break for larger numbers of licenses all purchased at the same time (say 50%). FileMaker gives away basically nothing for 20 licenses or more. This kills many larger projects dead. The only ones that live are ones that started on FileMaker when they were small (so they have no choice). This will not cause great erosion of revenue from larger existing projects as they will generally buy additional licenses one at a time. Yes it might impact larger upgrades but most of them are getting the upgrade price anyway so are already paying less. It may also be revenue positive as it will encourage buying more licenses than are actually needed. It will also encourage older upgrades (past the upgrade window) to actually happen. There are many projects who basically avoid upgrading for as long as possible just on cost grounds.


      Technical Points - Have a release (13.5) that just does a pile of small stupid things. The list below has already been done to death but here is my list:

      -HTML email - Load of plugins have this! How hard can it be? Just give us the basics. We don't need everything the plugins offer.

      -Multiple attachments per email

      -Two more custom dialogs - "list dialog" using a value list and "large dialog" that can display a warning message or similar (could be same Show Custom Dialog - just let us specify size and position on screen). Yes you can do this with a layout but it looks bad on Windows as you lose your maximization and also custom dialogs are so much faster to write. Also more buttons and more fields on custom dialogs. Also mixture on the fields (some edit, some drop down)

      -A "cut out" that shows a different layout. This way you can make your "standard stuff" (top level tabs that change between layouts) in one place so much easier for maintainence.

      -The whole Windows thing on Windows. You more or less have to run maximized to make it look good which is a pain.

      -Native progress bar. Troi dialog had this 10 years ago.

      -Better access to file system. Loads plugins have this. How hard can it be.

      -Dynamic portal sorting without hacks.

      -Programmaticly control what is on the Status Toolbar. Just a simple thing "Add/remove Status Bar element" and then you just choose one element. You string together a pile of these statements to build up the Status Toolbar you want. Also needed will be a command "Clear Status Bar" which gives a clean fresh start.

      -Drag and drop without hacks. This is a bigger one but every other development environment has had this for years and years.

      -Tick box on Install Menu Set - make default for file. This is so annoying. I just want to say "I am developing now, please give me full menus until I say otherwise"

      -Charting that respects calendar days. Right now the charting is limited because if I have a data set with a date of 1/1/2013 and another data point 2/2/2013 and a final one of 31 December 2013 then the 3 points will just appear equidistant giving a totally false impression. This is crap. xmChart doesn't do this. This is a obvious and important defect.


      Just small simple stuff. I am sure others can add to this list.



      Most of this ought to take a good developer a few days. Heck, FileMaker can get a jumpstart on half of it by hiring the plugin guys as consultants to help them. Of course, the plugin guys will worry about FM taking their business away but that is going to happen anyway so I am sure they could find folks who would help or provide source code at a reasonable cost. How can this be so hard when plugin developers who are typically one guy working part time can make most of these things?


        • 1. Re: A short simple wishlist.

          All good points.  I especially would like to be able to have my own Customizable status bar.  


          The dialogs really need some added functionality, especially now that we have Webdirect.  Going to new Windows is very costly in WebDirect and FMGO, and multiple windows are not really possible. 


          The other stuff would be good, but they are not show stoppers as there are ways to work around.  But in the scope of things, I would guess you are right in that they should be relatively trivial.   We should not have to use Plugins for some of these basic things.




          • 2. Re: A short simple wishlist.

            Is it too early to ask for 13.5 and 14 features? I don't think so.


            How 'bout conditional buttons? If the calc is false then the cursor doesn't change and one can't click (and therefore no change to the pressed event look).


            How 'bout conditional formatting on the event changes? Then we can determine the look of each pressed/hovered/etc event based on a calc.

            • 3. Re: A short simple wishlist.



              and for me the most important thing: improving of the Import-Dialog!


              Sorting, searching in the source area, moving many fields ... (we need a lot of time for the import in every project).


              Regards, Willi

              • 4. Re: A short simple wishlist.



                +++++!1  on that!  The Import mechansim is really showing its age!

                • 5. Re: A short simple wishlist.

                  How 'bout conditional buttons? If the calc is false then the cursor doesn't change and one can't click (and therefore no change to the pressed event look).


                  You already have that using Hide. A hidden button does not trigger the cursor. The hide formula can be as simple or complex as you like. If you want the ghosted image of the button to remain, place a dead button which is formatted appropriately beneath the real one so that it is visible when the true button is hidden.



                  • 6. Re: A short simple wishlist.

                    Yes, but a disabled state (in the list with 'hover', 'pressed', 'active') and a calculation to determine when it is disabled is far better. You only have one object and the disabled formatting will be stored in the style and in the theme.

                    • 7. Re: A short simple wishlist.

                      Yes, they are outdated and nearly none of our customers are able to handle it without long documentation and help.


                      there should be:


                      - instant search for fields (when there are many many fields)

                      - ability to see the data format, to sort by that and to reduce the list of fields only to date fields for example

                      - ability to prevent for example import of text in number fields

                      - formula fields should be hidden, because you can´t import into them

                      - ability to define hidden fields for import dialog

                      - alias names in field definition to give us the ability to show localized or different names in import, export and sort dialogues and table headers

                      - free definition of text format with delimiters, with fixed length, text type (UTF or what), look at Excel. Same applies to export definition by the way.

                      - no limitation of import of text data to certain file extensions - txt could be everything, nobody knows .ser

                      - more and new import formats, for example vcal und vcard data

                      - perhaps even the ability to scan a file like PDF or Excel for database compatible data and import only that. Often people don´t think, that an importable Excel file has to be formatted as a data list file and cannot have for example a heading row and an footer row. Why couldn´t the import of such file more intelligent by defining the import like "Import B2::D28" ?


                      Getting data into a database is the MOST IMPORTANT task of a database and that should be always the Number 1 point for updates. Popovers are nice, import is more important.



                      - more obvious graphics wether a field is really matched and fits to the target field

                      - optional "show only still unmatched fields"

                      - preflight of import with more information about what goes wrong regarding input validation

                      - option to have the automatic input options controlled for specific fields

                      • 8. Re: A short simple wishlist.

                        All good points about import dialog.  Here's how I get around the limitations now:


                        -I make a data import table with say 100 text fields starting at 100 (so sorts neatly).  Text fields are just called "Text Field 100", "Text Field 101" etc.

                        -I then import which is a cinch.  I import all fields and they just go in order. 

                        -I then run a looping script to move that data to where it should go.  You can usually tell what fields are what from looking at them or referring back to the original Excel file.

                        -This strategy is more work but has some big advantages:


                        i) Easy to incrementally improve the process - you just delete the imported records and run them again (without leaving FM)

                        ii)  Easy to fix data problems (like convert US dates to UK dates) or put Proper on names.

                        iii) Easy to separate out things that belong in different tables

                        iv) Data import table then becomes an archive in case a problem is detected down the road.

                        v) Also easy to add identifying data "Imported from xyz on such and such date"

                        vi) Easy to populate fields that need adding but which are not in the data (like flag fields).


                        You can do all this by replace but you have to remember what you did and if you make a mistake you have to do it all over again.  I find this much better.