Automatically sort grist tables for ease of use

[fire]

Grist version

getgrist.com

System information

Firefox on windows 11

Issue description

I have 2 screens of table names. It is difficult to use the tables since they are not sorted, can they be sorted?

So I have two table names that are almost the same name, but are on the first page and the second page.

Sorting probably needs to use unicode rules.

Steps to reproduce

1. Create a database on https://getgrist.com
2. Generate 50 table names in sentence case without punctuation and in snake_case
3. Notice the order of the tables is random which makes it hard to use

Idea graveyard

1. allowing the user to sort the table list is a worse idea
2. the metadata needs to be saved
3. customization for not much gain

[fire]

To be clear it means that these examples should be sorted close together and not with table creation order.

1. abce
2. abc
3. ab_cd

[fire]

Example of the inability to sort.

[Vinschni]

You can drag and reorder Pages with the mouse and even create hierarchies:

Be aware that in grist the concept of a table is something diffrent than a Page. A page can show widgets with multiple tables. Your aim seems to be to sort Pages, which in your case only consist of one widget showing a table.

[fire]

It was not obvious I can drag from https://github.com/gristlabs/grist-core/issues/485#issuecomment-1501172677 and the only way I could find out is because you used a yellow circle to indicate which is a usability problem.

Is there a specific reason why dragging is disabled until hover?

[paulfitz]

I agree this isn't very discoverable @fire. There is documentation at https://support.getgrist.com/page-widgets/#pages - but we can think about ways to make the feature more obvious.

[Vinschni]

Personal opinion of me as a user: I like the design decision to hide the drag surface as it is. But adding reorder pages to the tutorial tour could be something to think of with low priority.

[fire]

Well, I'll try looking for other software then, since I have a lot of pages and tables and this is considered low priority meaning probably never done. A tutorial is the same as not fixing the problem.

The problem it's pretty painful to scroll through the overview with 50 elements to use and edit. A flat list was veto'd earlier in this discussion because the element is pages which has widgets. A table is only one widget so it cannot be sorted as the container is the page.

[paulfitz]

(Just to clarify that @Vinschni is a user of Grist helpfully sharing their knowledge, and not currently a contributor to the codebase or roadmap)

[Vinschni]

Dear @fire my post was a personal opinion. I'm not associated with grist or their development / roadmap decisions.

[Vinschni]

@fire If you have over 50 tables i imagine there are other ways to fulfill your requirement. In my eyes using pages may be just one how for what you aim for. Could you use one table and represent the attribute you encode in the page name as an additional column? This would improve usability for you a lot, including filtering and sorting.

[dsagal]

Since I don't see it mentioned in this discussion, let me point you to Grist's Raw Data feature, which lists all tables in a document in alphabetical order. This is the best place to find all data in a document.

Compared to Raw Data, the user-configurable "Pages" are intended as application-like views: you may configure what each page shows (often more than one table, with data linked together), and how the pages are arranged. Note that rearranging pages allows also grouping them into a nested list. Note also that page names default to the table name, but may be renamed (e.g. for a more functionally meaningful name when the page contains several linked widgets).

In a document with as many as 50 different tables (with different structures), such tables are often helper tables, many of which are either rarely touched, or which represent subordinate data, best viewed as part of another page. Another situation where Grist users sometimes find themselves with many tables is when the tables share structure: e.g. one table per physical store, but each table has the same columns as other tables. For this situation, it is indeed recommended to unify the data into a single table, like @Vinschni suggests. This is described in a bit more detail in this Community post.