Barebones UI evolving to custom app UI

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):

  1. 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.
  2. 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.
  3. 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.
  4. 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…

1 Like

It sounds like the following may/would be helpful for you:

  1. Creating Document Tours - to create a tutorial explaining various parts of a document to non-developer users.
  2. Adding metadata such as descriptions/comments to tables/columns. This has been requested in Add comments in table and Would you say those requests partly match what you want?
  3. If you add ?style=light to the end of the URL, much of the interface is hidden, including the right panel. This feature needs documenting and polishing.

As to Creating Document Tours, not really:

  1. it’s not robust
  2. It seems only to run the first time the page is opened. Where is the persistence?
  3. It has no UI to access the tour comments that pertain to specifick page elements.

The overall appearance is OK: floating text boxes.
Needs a more robust way to to access the little hints.
A starting point…

Putting some help in a column is really not viable. If for some reason the row containing the info is deleted then the helpful text is gone. To put the same text in every row of the “help” column–well, you can see the weakpoint.

You have a really robust implementation of relational data and permissions and as good start on layout/pages. Like I’ve said in many posts, it’s really time to focus on usability and appearance.

AirTable is weaker functionally but leagues ahead in UI.

There’s a “Tour of this Document” button in the left panel to show it again.

Any comments on those links?

I see AirTable allows adding descriptions to tables/columns that are shown when hovering over a little ‘i’ icon. Is that exactly what you’d like, or is there anything about the AirTable method that you think needs improving?

How do you get ?style=light to persist in the URL for a page? I can see no way to access the (hopefully, persistent) URLs for pages.

I don’t understand what either of your questions mean. But as I said, this is an undocumented, unpolished feature. Do you think you would use it if it was more polished? What do you think it lacks most?