Each page in Snap comprises a collection of buttons and button position information for the currently selected grid size (Page Set > Grid Size setting). The page is actually an infinite, scrolling, collection of grid screens, much like a web page. As you add buttons and reach the maximum number of buttons for the selected grid size, you can create more buttons on the next grid screen down. Scroll indicators will appear on the right side of the screen to indicate how many grid screens there are on the page with visible buttons.
Since each page can be viewed in a number of grid sizes, Snap has two different approaches for how it will reposition buttons that are no longer visible in a different grid size. It will “block flow” them or it will restore a “saved state” of buttons positions for the new grid size.
“Block flow” is Snap’s default approach to repositioning buttons when transitioning between grid sizes. Snap will attempt to preserve the position of the buttons in the visible columns. Buttons in columns that are no longer visible will be moved to the to the first available empty rows. Depending on the number of buttons on the page, this might be on the next grid screens down, perhaps multiple screens down.
In the example above, Snap moved the button in columns 5 & 6 in the 6x6 grid to the second scroll screen when transitioning to a 4x4 grid. This works well in many situations, but not in all. This isn’t the best approach if the page contains content that is alphabetical or needs to maintain a defined positional structure, such as menu pages or word lists.
Snap will stop using the “block flow” approach, at least for the current grid size, once you reposition a button in the grid. Snap assumes made the positional change for a reason and you want to preserve that, so it creates a “saved state” for the current grid size. If you then transition to another grid without a “saved state,” Snap will “block flow” the buttons accordingly. If you are transitioning to a grid size where you previously repositioned a button, Snap will restore the “saved state” for that grid size and it will ignore any positional change made in the previous grid size.
“Saved States” are helpful to ensures that, across all grid sizes, button content maintains a consistent structured, i.e. function/navigation buttons are always in the same position, buttons grouped by part of speech or spoken intent. Note, there are two separate “saved states” for each grid size, one for when Navigation Buttons are not enabled (Touch access method), and the other when they are enabled (all other access methods). (See Navigation buttons will displace buttons on your pages.)
In the example above, the Main List: Colors word list page has saved stated defined for all grid sizes so the color words flow alphabetically and the position of the All Word Lists button is maintain in a consistent position. The Little Words and Word Forms buttons were removed from the 3x4 grid by design, as those are for more advanced users.
If the Colors page didn’t have a “saved state” for the 3x4 grid size, it would appear as shown above. The outlined buttons would be moved to the second screen down. The words would no longer be in order and the All Word Lists button isn’t even visible.
“Saved states” for grids solves some problems inherent with the “block flow” approach, but it is not without its own problems. If every grid size for a page has a saved state that gets restored on transitions, then changing the position of a button(s) in one grid size will NOT transition to another grid sized. You would have to move the buttons again in the new grid size. This will be the case for all of the pre-made content in Core First. In the example below, the About Me, Bedroom and Airplane topic were move to the top row in the 6x6 grid size for the Topics Menu Page. When transitioning to the 3x3, those positional changes are lost, and the original sequential position is restored. Note, currently there is no way to remove the “saved state” from a grid size and return to the “block flow” approach.
Future versions of Snap should offer a third transitional approach that allows buttons to flow sequentially and will maintain repositioning within the sequence across all grid sizes.
In Snap, up and down Navigation Button will be added in the upper and lower right corners of every page as needed if the access method is set to anything other than Touch. The navigation buttons allow you to scroll between grid screens on the current page. The button(s) that were in the positions now occupied by the Navigation Button(s) will be relocated. If Touch access is selected again, the buttons will return to the original positions.
In the example above, the Favorite things [ ] button that was at the bottom of screen 1 and the Topic Words button at the top of screen 2 were both displace to an empty button location nearest the original position. This can be the next or several screens down depending on the number buttons on the page and the current grid size. Manually repositioning any of the displace buttons will create a “saved state” for the grid size, when Navigation Buttons are enabled. This is a separate “saved state” from when they are disabled. This allows you to optimize the button layout, for the current grid size, for either screen scrolling method. (See What you NEED to understand about how Snap pages and button grids work.)
If you don’t want navigation buttons to appear on a specific page, you will need to hide all the buttons on the screens below the first screen.
In the example above, all the buttons on the second screen have been hidden. Now the Navigation Button on screen 1 also disappears. Now, one of the hidden content button can be reposition and unhidden, leaving a single accessible screen completely filled with content buttons. Note, if you ever unhide a button below the first screen, the Navigation Button will reappear and a content button will be displaced.