Feature request: Multi-page boards / Multi-grid navigation

[rgabo74]

I sometimes came across a problem when I have more elements on a grid of a certain size, that can fit on a single grid, so I would need multiple pages of the same type of elements. I could of course do a second grid of the same type, but it is somewhat cumbersome do define paging buttons every time when I would need multiple pages, so I rather don't do this.

Proposed Solution #1 (more effort)

Each grid may have multiple, numbered pages that are editable separately. They have minimum one page, which is the current state.
Users could add paging action buttons (next page, prev page, first page, last page) to the global grid or to a grid which are allowing changing pages if the grid is a multi-page grid. The buttons are enabled/inhibited according to the availability of pages on the board and according to the current selected one. This way each existing grid can be easily extended with further pages if needed.

Additionally Navigate to a Grid action may be extended with a round-robin paging option. When a navigation element is placed to the global grid and the round-robin option is enabled on the navigate action then repeated touching of the navigation element could automatically switch to the next page and then from the last page to the first page.

Proposed Solution #2 (less effort)

Multi-grid navigation action among element actions. The multi-grid navigation action configuration allowing to define one or more grids in a defined order. When an element with this action is placed on the Global Grid, repeated tapping of this button is navigating through the defined list of grids, then navigating to the first one after the last one.

[klues]

Thanks for your ideas!

I think the first proposal would add too much complexity. It will be difficult to explain to users the difference between different grids and multiple pages within one grid and it will be confusing when to use what.

The second options sounds better, maybe add a new navigation type here:

The type could be something like Navigate between selected grids. But still some things not clear to me how to do it:

• how to select the grids which should be included in the "group"?
• we would need some additional input to select if we want to navigate forward or backward
• do we need a way to order to grids which are selected?
• how to prevent that we need to define the same groups multiple times, e.g. for creating a forward and backward button?

[ms-mialingvo]

But still some things not clear to me how to do it:

This sounds like it could get quite complex to set up and it would end up being easier to just not add that category to the global grid and connect the grids of that category in a loop manually?

[rgabo74]

What about defining a new entity, grid-groups. A grid-group can have a name and list of grids with defined order. Add/remove/change order operation would be useful.

Having grid-groups in place would simplify the new navigation mode setup. Just select one grid-group and select the direction of paging.

I am wondering if there are other good use-cases that would make grid groups beneficial.

[arasaac-dga]

But still some things not clear to me how to do it:

This sounds like it could get quite complex to set up and it would end up being easier to just not add that category to the global grid and connect the grids of that category in a loop manually?

Agree. More complexity. A manually loop like now is enought.

[klues]

What about defining a new entity, grid-groups.

Also shortly thought about it. But I agree with @arasaac-dga and @ms-mialingvo - probably the best is just to create manual loops. I think it's also not that difficult, you can create a Next -> element, copy it and then set the navigation to it (right click -> set navigation) - paste the element to the next grid, again set the navigation etc.

Of course with the groups it maybe would get a littlebit faster - but only if you know the feature well. On the other hand much more people will get somehow lost in the application, because they are overwhelmed by the settings and features.

[rgabo74]

I understand manually defined paging navigation tiles could work on the pages itself. I did it earlier myself.

Where this idea came from is the new capability of dynamic grid placeholder. This would allow to create a collection of category tiles on the left, on the global grid like things, people, animals, etc. And a dynamic part on the right which is changing by the category selected. This structure would be useful if repeated tapping on the same category could change pages on the right. Otherwise I will end up having Animal1 Animal2 in the category and running out of space quickly.
A solution could be to open a sub-category grid on the right with Wild Animals and Household Animals and the open the final grid... But this would add an extra tap to the flow.

Anyways, I understand the concerns and complexities...

[ms-mialingvo]

I'm not sure you have understood what we mean by looping manually. Here is a grid where animals and food is looped.
https://we.tl/t-IVBr5dz6JH

[klues]

I'm not sure you have understood what we mean by looping manually. Here is a grid where animals and food is looped.

the problem using this technique is that it's not possible to have the category button in the global grid.

An idea: we could add a new type of navigation here:

Something like Navigate through defined grids (like proposed solution 2 from @rgabo74 ) - but just providing a field like name selector which defines which grids should be used. For example using Animals as selector would select all grids named like Animals-1, Animals-2 etc.
When using this navigation action, each action will simply navigate to the next grid where the name matches the selector.

This would make the selection/grouping easier and would not need much more UI things besides just the possibility to select the additional navigation type.

[arasaac-dga]

You know our point of view. No more complex.

[ms-mialingvo]

but just providing a field like name selector which defines which grids should be used.

...and then I already see the next person coming "but I also want to group grids with fully different names"... ;)

I mean if you want to spend time on this, something like this

(plus a delete button after 2 or more grids to delete superfluous grids aka the one at the bottom) should be a quick, understandable method, but depending on how long it takes to program I question the efficiency of time use, when there are other things with way more priority, starting with #715 and bugs in general.

[arasaac-dga]

how long it takes to program I question the efficiency of time use, when there are other things with way more priority, starting with #715 and bugs in general.

Yes and two bugs that we have reported right now #742 and #743 and some important features like PDF Export still pending or red cross pictograms...

[Fukurouonthesea]

What about defining a new entity, grid-groups. A grid-group can have a name and list of grids with defined order. Add/remove/change order operation would be useful.
Having grid-groups in place would simplify the new navigation mode setup. Just select one grid-group and select the direction of paging.
I am wondering if there are other good use-cases that would make grid groups beneficial.

OH yes please. so many. for me at least. even apart from "make a second page" (though for me that usually turns into trying to link both from the main category page and separating by topic or something else rather than frequency)
i'll often have a couple related pages and try to name them in order, e.g.PeopleFamily, PeopleWork, PeopleFriendsOnline, PeopleGen and stuff. TimeYearHoliday, TimeYearDates. Describe, DescrVisual, DescrOpinionPos, DescrDirection, DescrAmount. Honestly Social will probably be its own group with a couple sub pages per page in that group - Greetings, Repairs, whatever. Scripts-collections for different situations, that we'd still want to keep together as "scripts". a couple youtube pages. keyboard pages. (at some point I also want to make a smaller core grid with a handful of pages to use when we're overwhelmed - thatd be another category). also stuff like where you have a main verbs page, and then make a directory of all the verbs sorted into pages by alphabet to find stuff easier like the vocal flair sets do, you could group all the a-z pages into one folder.
... sorry if it's confusing. uh. yes, at least for the way I organize and create grid-based AAC grid, groups are basically the whole idea. Naming kinda works but the character limit can get tight, and it's still a big amount of grids to sort through to find one group.

(also, if you wanted to for... idk, searching among all of it, or something else specific like two gridset versions but adjusted for different culture and grammar beyond what a 1:1 translation can do - you could have more than one grid set within one user through that feature. maybe a communikate and a vocal flair, or something. Currently that's technically possible, but I tell everyone that in my opinion they're better off just making a second user to switch between - it would get so messy so fast even if you re-label all the grids to know which set they were from. And also probably lag. This wouldn't solve the lag though.)

And related to that, you could maybe export and print grid groups as that step in between "this one grid" and "all grids" to make grid management a lot easier.

so. that kind of thing would be so awesome to me - but it's fair what arasaac says it's not neccessary for asterics to function as an aac, or making it less confusing to get into. (though, again... you wouldn't have to use it. you could just ignore the whole thing and continue as now, to my understanding, like the dynamic grid got implemented).
practically... you could have "base grids" that are always shown in grid navigation, and then add as many grids to that grid-subset as you want just by specifiying which base grid they belong to. (again borrowing inspiration from Coughdrop - if it helps I'll go get screenshots? But I think maybe you would do a selection bar and not their system of "define a specific name for each grid, like a website adress, and use that as reference" or something, so I don't know if this is understandable enough.) Or some kind of straight-up folder structure, since this is relatively computer based anyway.
personally, it'd be so much more usable than alphabetical (even with name-codes) or the other options: "linked to this grid" is way too restrictive and "number of connections" jumbles everything together - and the order changes with editing, and not like... manually defined and the same even with edits and progress of the grid set.

(I read the rest and discovered it wasn't the direction you went with this, so... not sure. Maybe this is still relevant, for this discussion, or for its own "someday when the current urgent topics are done" feature suggestion (once i have the spoons to create any more issues)? Sorry if it was irrelevant and I'll move the post because it's gotten so long and I can't find anything double or stuff.)