10 Replies Latest reply on Mar 20, 2016 4:08 AM by jrenfrew

    New developer UI behaviors

    dburnham

      I wonder why the Data Viewer's "Edit Expression" dialog uses the traditional calculation dialog box while the new one appears everywhere else.  Was this just overlooked, or is there a good reason?

       

      The rule has always been that double-clicking an item (such as a function) inserts it into the calculation expression.  The same was also true for operators, but now, the operators are inserted with only a single click.  It's confusing and I have found several times that when defining a button to use a single step, if I don't make sure that I double click, my selected button behavior remains "Do Nothing".

       

      Also, if you choose to define a button with a Single Step, you get a dialog that allows the selection of functions, but there are no operators available until you specify a calculation, perhaps because Single Script Step doesn't allow inline editing?


      And the tiny icon that displays platform compatibility is remarkably similar to the icon that opened the Data Viewer in FM-13, but when you are writing an expression in a calculation dialog or when you are working in the new Script Workspace, there is no icon to open the data viewer.   Hard to believe that there was not enough room for an extra icon .... approx. 16-20 pixels?

        • 1. Re: New developer UI behaviors
          CarstenLevin

          From what I have heard FM Inc is very well aware of issues like

          I wonder why the Data Viewer's "Edit Expression" dialog uses the traditional calculation dialog box while the new one appears everywhere else.  Was this just overlooked, or is there a good reason?

          And they are in cue to be fixed. We can also se very different layouts of Field Picker, Inspector and just as an example the File Options. But since it is only developers who see this it is really not an issue. But of course FileMaker will have to focus on aligning all dev. UI's to one design.

          Will it then be the field pickers or will it be like the Inspector?

           

          Best regards

           

          Carsten

          threedifferent.png

          • 2. Re: New developer UI behaviors
            dburnham

            We're now using v.2 for a while and these behaviors remain the same.  Another one worth noting in the new calculation dialog box is that inserting an operator requires only one click, whereas in other places such as the Edit Expression in the Data Viewer, it still requires 2 clicks.

             

            In the Script Workspace, some of the script step options do not appear until they are re-opened for a second time.  For example, if you insert a step to Go to Next Record, you are not presented with the checkbox for "Exit after Last" unless you remember that you did not see it and you re-open the option dialog (click the gear) and then you can select the option.

             

            Failure to exit after last can cause runaway scripts which, for users of FileMaker Pro who don't have a debugger can be very risky and/or dangerous.

            • 3. Re: New developer UI behaviors
              Malcolm

              dburnham wrote:

              In the Script Workspace, some of the script step options do not appear until they are re-opened for a second time.  For example, if you insert a step to Go to Next Record, you are not presented with the checkbox for "Exit after Last" unless you remember that you did not see it and you re-open the option dialog (click the gear) and then you can select the option.

               

              Failure to exit after last can cause runaway scripts which, for users of FileMaker Pro who don't have a debugger can be very risky and/or dangerous.

               

              I'm always annoyed by that too. I'm trying to think of the times that I use Go to Record [next] without wanting to exit after last. They are so few but I think that in almost every one of those cases, the "exit" switch could be on and it would not affect the script behaviour.

              • 4. Re: New developer UI behaviors
                mrwatson-gbs

                Hi dburnham,

                 

                I wonder why the Data Viewer's "Edit Expression" dialog uses the traditional calculation dialog box while the new one appears everywhere else.  Was this just overlooked, or is there a good reason?

                 

                I’m pretty sure that the answer to your question is simply: "Work in progress"

                 

                The minor releases are mainly for bug-correction, and the inconsistency of the UI is a niggler but not a bug, that is why wee have not seen this ‘fixed’.

                 

                Look to the future - I’m sure it is rosy!

                • 5. Re: New developer UI behaviors
                  dburnham

                  Work in progress implies that there is progress.  We are now at the 4th rev and I don't see it yet.

                  • 6. Re: New developer UI behaviors
                    mrwatson-gbs

                    And I don't think we will necessarily see progress in this area in any minor revision, because it is not a BUG but an inconsistency.

                     

                    I would much rather that such progress be focussed on fm15 - where it only needs to be programmed once (twice if we count Mac+Win) - while the minor releases focus on correcting broken functionality (which is more time consuming, because it needs to be fixed in the minor release AND in all major development branches that are being concurrently developed).

                     

                    I bet we see progress in fm15!

                    • 7. Re: New developer UI behaviors
                      dburnham

                      I won't bet against you.  It's likely this will be fixed.  But I can't agree that an inconsistency is different than a bug.  However, I would say that if a bug is a species there are several kinds of bugs, of which this is one.  As I see it, all bugs need to be squashed, regardless of their size or severity.

                      • 8. Re: New developer UI behaviors
                        CarstenLevin

                        Hi everybody here: Discrepancy or bug ...

                         

                        While this will of course need to be solved, one day, it is not causing any errors. We do of course look forward to using the new calculation interface for all calculations. But it is a minor problem, and not a bug = everything behave as expected and does not cause errors.

                         

                        So when FileMaker Inc find that the time is there for ironing out less problematic inconsistencies .... but probably not before.

                         

                        Personally I also find it a little bit strange with the very different L&F of the field picker.

                        Not so much whether I like it or not, more that I find it strange with one single element looking so much different than all other elements, one point though: The inspector and the field picker are both very compact = in my opinion space efficient. I like that aspect when we are talking about a development interface.

                         

                        Best regards


                        Carsten

                        • 9. Re: New developer UI behaviors
                          dburnham

                          I know I am going out on a limb here, but I admit I am fearless on this subject.   Did you watch the most recent Republican debates?  This stuff about bug v. discrepancy reminds me of the way the debate devolved into three candidates for president quarreling about who repeats phrases and who sweats more on stage. 

                           

                          In our case it demonstrates how the need to make changes/improvements/repairs/enhancements has devolved to the point where they've got us quarreling over how to categorize the things we all agree need to be done.

                           

                          I come from a background of being a business owner in the days before software was an off-the-shelf product.  If I wanted something to look or behave differently, I called a meeting to make sure others shared the same desire, then paid the programmers to do what was wanted and needed.  Some things were done instantly, others took a few days or weeks.  There was none of this nonsense about whether to call it a "bug" or a "feature request."

                           

                          I get that it's now 2016 and we're working with a sophisticated product.  But that's not an excuse for the failure to provide a more sensible, organized, and interactive approach to this issue that also respects that fact that as developers, we need this information to operate our businesses. Planning ahead is not an esoteric concept.

                          • 10. Re: New developer UI behaviors
                            jrenfrew

                            Hmm

                            This bit of code over here is not quite as 'pretty' as that new bit we implemented here, but will take time and money to change and QA - but it is an irritant to some people. This problem to address is for something that is 'actually' broken- -and is an actual problem for users.

                             

                            Which one gets the resources, and on which timescale??

                            Not a trick question by the way, it's one we face every day. How and where to apportion our not finite resources.