Build Better Back Buttons

By Jennifer Neighbors, Senior Consultant


Traditionally the BACK button on a form takes users to the most recently viewed screen. In Ninox, however, screens tend to layer on top of one another instead of forming a linear direction. Recently I’ve been working on a large project with lots of modules and tables where the user can easily get lost in the stack. Users of my database won’t be familiar with Ninox and won’t have any training in how to click on the “X” in the corner of the screen to close it. I decided to help the user go back – not to the previously viewed screen – but instead to where I think they are likely to want to go. And I wanted to use a button to do it, so novice users won’t be confused.
To do that, I needed to sort out Ninox’s methods of closing forms and navigating to others. Closing forms can be confusing because behavior of the same function can be different depending on how many screens are stacked underneath. Let’s take a look.

This function closes a screen and, when used with a button, allows the user to press a button and return to the screen underneath the current screen. But what if there are no open screens under the current screen or what if
there are more than more than one? It doesn’t offer any real control over what the user sees when it is executed. All it does is close the top-most form and it provides a great alternative to the “X” close screen icon.

I wasn’t satisfied with this solution. In my large database, the user often has three levels of interaction. For example I have an Events Management dashboard at the Events module level where the user may search records and add new ones, an Events table that allows the user to create a detailed record about an Event, and nine more child tables from that which allow the user to define other things such as Attendees, Entertainment and Vendors.

In short, I have a grandparent table, a child table, and several grandchild tables. How would I allow the user to close any of these and navigate back up the stack?


This function is very like the closeRecord() function, except that it closes each and every underlying record. It still doesn’t offer much control over where the user eventually lands, but it is very effective at closing all records that the user has left open while working. So far, so good. What about opening the screen the user wants to go to? There are a couple of options for that and when they are combined with the closeAllRecords() function, they provide a great solution.

					let xEventNum := number(EVENT);

This code in a button’s on click function not only closes all the underlying open records, it also takes the user to a specific record in a specific table. In this case it opens the Events form for the event that the user is currently working with. The button’s name is EVENTS, so the user can easily see that to go “back” to their main form, which is Events, they simply have to press that button.

I have another button named “HOME”. You can guess what that button does, right? It takes the user to the grandparent level – the dashboard for the events module where they began when they searched for or added a new Event. Here’s the code for the HOME button:

openTable("Event Management", "Events")				

I use the openTable method here because I’m navigating to a dashboard. It doesn’t need to open a specific record in the table. It merely has to go to the table and expose the view I want the user to see.

My grandchild table forms all have EVENTS and HOME buttons allowing the user to close up and go back to a central location they have been to before. My Events table form only needs the HOME button so users can go up the stack to the dashboard. That’s it. Once I sorted these few functions, I gained a better sense of how to help my users go “BACK” and my novice users now have a good sense of direction and control.

Jennifer welcomes feedback and can be reached at