Few "simple" feature-requests

Grist Feedback
1

Hello
Few ideas in bulk :
Formulas :

  • Is it possible to include a toggle switch widget to lock formulas columns (even for admin) to prevent erasing those formulas

Layout

  • Can the scrollbar be narrower (think about vscode like…) to win place in the layout (of course being able to scroll the page would be a plus)
  • In the formatting options :is it possible to affect the whole row instead of just the cell ?
  • Is it possible to customize a little more the title of the widget (size at least) ?

:slight_smile:

6 Likes
2

Dears,

I’m just coming to this topic and especially this :

I’m using a standard form with different tables (8D claim management in industry …)
I need two more tables so scrallolable layout is a must if I want do go on this way.
I’m about to split in different documents my structure but : it breaks the logic of this way of use

=> So if there is a short term plan for this then I’ve better wait a little :slight_smile:

2 Likes
3

Thanks for this feedback and the screenshot! It certainly helps. Layout space is something we’ve discussed and we have a design idea. Dmitry shared it on Github a couple months ago: [Feature Request] · Issue #174 · gristlabs/grist-core · GitHub

What do you think?

4

Hello Anais,

Thanks for your suggestion, I’m happy to see this an open topic:

Ability to move a page widget (like a table, card, chart) into a top bar, where it will show up collapsed, as a button (or tab).

Ability to expand a widget to a full-screen (lightbox) view, either by clicking the button, or a new “expand” icon available on every widget.
It will be possible to rearrange the buttons in the bar, or to drag those collapsed widgets back into the page layout.

For complex data, e.g. with many tables of data linking to a customer, it would make it possible to have all the linked data accessible at one click, without having to fit it all on one page.

=> I think that for a lot of users these improvement are quite good, BUT :

  • Is there a real ergonomic gain in using the tab rather than going to another page of the same document with a hypertext link? To be tested…
  • If there are a lot of tabs, won’t that be confusing too?

For example in web design you have the same problem:

  • Either you use tabs in a menu
  • Either you put it in a long verticall scrollable layout (the modern way)

With tabs you have a better data structure, but having the possibility of going back and forth with a few turns of the mouse wheel is for me more efficient and more ergonomic.
In addition, it allows you to keep a visual structure of the document which helps you to find your way around, which brings you closer to your work.

To be weighed in the balance or perhaps to have both possibilities ?

5

Just started to reorgaize my page leaving the mother list away (maybe future tab)

image
image1862×881 28 KB

I think some place coud be optimized :
Hideable colun number ? + column ‘+’ (add column)-> Not necessary with right click option…

6

im just about to share a grist document with my work colleagues and i could see this being a problem as well.

a workaround for now is to switch to using a trigger formula which means when someone clicks on a cell they wont see the formula pop up, and then set which columns you want to be updated when there are changes, including the column that the formula is on.

the worst that will happen will be that someone tries to add something into that column but it will be removed once they press enter and the formula runs, and they should hopefully notice and remember that they are supposed to be inputting the information into another column. this works in my use case anyway, maybe not all

7

Hi @dave-b ,

Thanks! That’s a nice workaround, though we are loosing the “=” icon data are preserved.
Works on my side.

8

@dave-b and @Sylvain_Page You could also add team members as editors and then deny editors schema edits in the access rules page. The default rules would be edited like this:

image
image1209×298 18.5 KB

The S represents schema edits which are 1) edits to the structure of the document (creating or deleting tables and columns, for example), 2) edits to the layout (pages and widgets), and 3) formulas. By denying editors schema edits, they cannot edit formulas, but they can update data within the document you created (e.g. data entry and exploring data within your structure).

The risk of using trigger formulas as a workaround is that values that should be calculated when other fields are updated won’t be calculated unless the trigger formulas’ specific triggers are met. The values may not be what you expected, depending on what the formulas and triggers are.

1 Like
9

Hello @anais-grist ,

Thanks for your feedback.
Currently I’m running Grist-Core as self hosted version with electron app (no authorization for external storage for long term use) → So I cannot deploy your solution.

We are a company of 35 people mostly in cold forging providing
I’ve just deployed it on a single PC running as server internally.
We are just 2 working with it and 4 people who can have access to Grist but honestlt speaking most of the job is done by 2 people so finally this is not a real concern for me.