I think it’s sort of polite to refer to the UI of Grist as “bare bones”. Another complimentary description would be “streamlined”. Normally, both are good.
Let’s suppose we are trying to create an app for non-developers to use. The users don’t know how the app was created and don’t normally use Grist. They are just doing scheduling (for example…).
So, we want to leave them some hints in the UI of our app.
It’s not possible. Try using a custom widget, but there is no widget for displaying static text. And, widgets are really meant for things that display data: grids, cards, charts, etc. These can be big. But, it’s downright silly to put a single button in a widget. There’s this tiny little button floating in this huge white space.
This gives rise to a series of suggestions (if you care about getting beyond a ‘developer as user’ audience):
- a button bar (toolbar in other products) for the page; a button bar per widget. This is where buttons live. Each button has a code window, rather than relying on content that comes from the cell of a table. This code is saved in the code view as a Python function per button.
- A static text “widget” that allows formatting and can be sized arbitrarily, or perhaps can float over another widget with a designated x:y anchor point for its top left corner. The text could be saved as a property of the widget, accessible in the right hand side properties pane, which is how custom widgets already work.
- Custom help widgets. These should be a little ? in a circle that can be floated over the page, a widget, or appear in a specific place, one per page and one per widget. The help button is associated with text authored by the app developer. Where does this text live? Well, certainly not in a row of a hidden column. It probably gets a simple human intelligible guid name (help_text_ and help_text_<page_name>, or worst case–simply numbered). These are Python document level variables that appear in the code view. Hallelujah. Now there is an easy way to edit them! Or, use the property pane to display/edit the help text. Probably cleaner.
- Local links to parts of the current document or possibly to other documents (maybe later). These appear as link text in the floating static text widget above. Click on the link and something gets displayed. Could be some help text. Could be some interesting data or chart widget that is relevant. This is a beginning to the popup widgets idea that is on the roadmap.
The basic UI approach of Grist has suitable mechanisms. But, the property panes need to be inaccessible to non-developer users. This is one of the problems with the spreadsheet “metaphor” for app builder features of Grist. All of what a spreadsheet does is visible to users of the spreadsheet. But, database apps aren’t spreadsheets even if a grid is a nice widget for viewing data. The “app” has a lot more complexity. Property panes are reasonable for developers but need to be hidden from users that are just scheduling…