8 Replies Latest reply on Sep 19, 2012 10:56 AM by codecruncher

    The 'next' and 'previous' buttons of FileMaker Go cannot be hidden

    codecruncher

      Summary

      The 'next' and 'previous' buttons of FileMaker Go cannot be hidden

      Product

      FileMaker Go

      Version

      Go_iPad 12.0.3

      Operating system version

      iOS

      Description of the issue

      The 'next' and 'previous' buttons of FileMaker Go cannot be hidden


      There is no setting or script command to prevent the 'next' and 'previous' buttons of the bottom navigation bar to slide up and block part of the layout of a FileMaker solution. Other users have reported the issue as well and the official reason for this behavior is that FileMaker Go cannot determine wether an external keyboard is connected.

      The problem is that the navigation bar slides over the layout to block important buttons instead of adjusting the size of the layout whenever a window is maximized.

      The 'next' and 'previous' buttons even show up when the layout doesn't have a specific tab order. They are simply inactive. This is very confusing to the end user who only sees them appear on occasion to block the layout without rhyme or reason.

      To my own amusement I actually thought they were undo and redo buttons at first until I scouted the existing bug reports. I have never felt the urge to go backwards in the tab order which is why I didn't realize that the 'previous' button could be related to the tab order in the first place.

      Why is there is no global option to hide the tab keys whenever the user chooses not to use an external keyboard? The big 'next' button of the onscreen keyboard works far better than the tiny next button on top the onscreen keyboard. The iPad was designed to be used via the touchscreen and only a small percentage of users will actually purchase an external keyboard.

      I came up with a partial solution with a script that would select a specific graphic object with the ‘Go to Object’ script step and then execute a commit Record/Request script step.

      Of course the 'next' and 'previous' buttons also appear whenever you scroll through a portal. Since the portal is not actually selected there is no way to hide the buttons after scrolling.

      The buttons also appear when selecting a value list suggesting to the unsuspecting user that he can go to the 'previous' and 'next' value in the list which of course is not possible.

      A typical user might ask:

      What do the 'next' and 'previous' buttons do?
      How do I make them disappear?
      How can I access the menu item underneath?
      Am I supposed to use them to go through the ‘next’ and the ‘previous’ page of the selected portal?
      Are they there to let me select the 'next' and the 'previous' item in a list?
      Why would any buttons slide up if they do not have a function?
      Are these buttons important?
      Am I doing something wrong?
      Does the developer even know about this?
      Should I file a bug report?
      Should I simply close this buggy application and play Angry Birds?

      I can only cross my fingers that the current behavior will be changed. These buttons simply don’t make sense. Even if you have a keyboard attached to your iPad you can only use the ‘previous’ and ‘next’ buttons if the layout has a tab order. Of course the buttons will show up even when a layout doesn’t have a tab order and a user with a keyboard might ask:

      Why can’t I go to the next field?
      Is my iPad screen broken?
      Will it help if I unplug my keyboard briefly?
      Should I clean the screen with rubbing alcohol?
      Is this iPad still under warranty?
      Is this only a software bug?
      Does the developer even know about this?
      Should I file a bug report?
      Should I simply close this buggy application and play Angry Birds?

      Expected result

      There is a simply global setting to disable the 'previous' and 'next' buttons.

      Actual result

      The confused user will end up closing your application to play Angry Birds.

      Workaround

      None

        • 1. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
          codecruncher

          It was a pure joy to run my file on an iPhone today where FileMaker GO works as expected and does not show the 'previous' and 'next' buttons. This confirms that the only reason why the iPad shows the 'previous' and 'next' buttons is for the select few users with an optional keyboard attached.

          Please consider the following entry in FileMaker Go's setup screen:

          (on/off) - Make compatible with external keyboard and show 'previous' and 'next' buttons at all times 

          This option should be set to 'off' by default.

          • 2. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
            codecruncher

            Having just tested GO_iPad 12.0.4 I was encouraged by the fact that the window doesn't zoom in and out anymore whenever FileMaker changes a layout. This is a great improvement. Thank you.

            However, the behavior of the 'previous' and 'next' buttons has not changed. Is there a new script step that I am unaware of?

            • 3. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
              codecruncher

              Another user just raised the same issue. As mentioned in the other thread this is an issue that has been raised repeatedly throughout the years. I have found 2 related posts within a couple of minutes: 

               

              April 2011 - Hiding tab buttons (415 views)

              http://forums.filemaker.com/posts/85e5294cc6

               

              September 2010 - FMGO doesn't hide menus when 'show tool bar' is off (834 views)

              http://forums.filemaker.com/posts/05830edf52

               

              All posts raise valid problems this behavior causes. There is not a single post offering a rebuttal or a solution. Considering that the majority of FileMaker users actually never look in this forum and that only a small percentage of those use FileMaker Go we can assume that over 1300 views represent a very large portion of iOS users.

               

              • 4. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
                codecruncher

                Here is another example of how the inability to hide the tab buttons on the iPad can cause problems. This picture is taken from FileMaker's own homepage:

                • 5. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
                  codecruncher

                  I am not certain anymore if my motivation has grown from convincing the good folks at FileMaker to change the behavior of the tab buttons on the iPad to creating the longest thread in FileMaker's forum from a single author. I can only hope that my points are articulated in such a way that no other user is compelled to add additional feedback. Nevertheless there are some additional points that I need to get off my chest especially since the FileMaker iPhone version was updated only a few days ago but the FileMaker iPad version remains the same.

                  1) The current implementation of the sliding tab buttons breaks Apple's own app requirements. Applications that have buttons without functions are denied inclusion in Apple's iTunes store by default. A layout without a tab order will show the tab buttons nonetheless which creates an application that displays buttons without functions. The iPad version of FileMaker Go should allow developers to honor Apple's own app requirements.

                  2) It is debatable wether the 'previous' and 'next' buttons at the bottom of the screen actually improve the use of an external keyboard. The user of an external keyboard still needs to touch the next button on the iPad screen and then verify if the cursor moves to the correct field before using the keyboard again to populate the field. Isn't is just as easy and more intuitive to actually click on the desired field on the iPad screen. After all the entire screen of the iPad is touch sensitive.

                  3) The screen real estate that can be gained by hiding the status bar is smaller than the screen real estate that is lost due to the 'previous' and 'next' buttons. The battery level, time and network status indicators of the status bar are far more important on a mobile device than access to tab buttons. Giving us the option to hide the status bar without giving us the option to hide the 'previous' and 'next' buttons simply doesn't make sense.

                  • 6. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
                    codecruncher

                    4) A developer that creates a layout for the iPad with numerous entry fields that benefit from an external keyboard will very likely not utilize the tab keys. He will select the option to go to the next field whenever the 'return' key is being pressed. This would save the user from having to touch the screen at all. One could argue that well over 90 percent of all entry fields in any FileMaker solution are limited to a single line. The most obvious exception is a 'notes' field. Entering a 'notes' field with a tab button is counterproductive because the cursor will jump to the first line and will have to be repositioned manually each time additional information is added to a specific section. The tab buttons that appear in the iPad version of the FileMaker Go app at all times are neither useful for the majority of iPad users nor do they make the data entry more intuitive.

                    • 7. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
                      codecruncher

                      5) While the keyboard that appears on the iPad screen does not have a tab button the majority of external keyboards do. This can make the automatic appearance of the navigation bar even frustrating for a user with an external keyboard who might not see any value in the 'previous' and 'next' buttons since their functions can easily executed with the tab key.

                      • 8. Re: The 'next' and 'previous' buttons of FileMaker Go cannot be hidden
                        codecruncher

                              

                             I am happy to report that this issue has been fixed in FieMaker Go 12.0.5. Wonderful…thank you so much!