Potential launch blocker - frontend/design
Kriti Godey
Sean Colsen
Some thoughts on this:
-
This seems a little tricky to me, design-wise.
-
From the front end’s perspective, here’s one limitation to keep in mind… the front end won’t have any way to know what may have changed after the reflection. There could be a new schema, a renamed table, a deleted column, yada yada. Without knowing what changed, the front end will need to re-build all its stores. A quick and dirty way to do this would be to refresh the whole page, but it’s kind of slow. If we wanted to spend more time (multiple days, realistically) then could build a mechanism to reliably refresh all the stores without reloading the page, but I don’t think we want to do that right now.
-
Let’s examine a simplistic idea that would sort of work… Put a refresh button somewhere in the nav header. On click, it requests reflection. When the request succeeds, the front end reloads the whole page, rebuilding all the stores.
But I don’t really like this.
-
For one thing, where would the button go? We could put it in the “Shortcuts” menu, but that’s not very prominent. We could put it alongside the shortcuts menu, but the nav header is already getting pretty squeezed horizontally.
-
With this design, the button seems to behave just like the browser refresh button. So “why is it there?” a user might wonder. We’ll, “it has a subtle difference from the browser refresh button under some circumstances” we could say. This feels messy. A user might conclude the buttons have the same function and then become confused when the browser refresh button does not perform reflection.
-
How can we communicate to the user that our refresh button is different from the browser refresh button? That’s the design challenge. It’s a challenge because the reason the buttons are different is an implementation detail that users should ideally never need to concern themselves with.
-
-
Ok, maybe we put some different kind of refresh buttons in some other places. Atop the list of schemas we could have a refresh button. Atop the list of tables a similar button and so on.
I don’t really like this either
-
For one thing it’s a bit of work, both for design and implementation. We need to refresh schemas, tables, columns, constraints.
-
We have a refresh button at the button right of the sheet. Should we make that perform reflection too? If so, what other operations do we want to perform reflection? It becomes a slippery slope.
-
-
The best thing I can think of is to put a refresh button on the Database Page, probably above the list of databases. But I’m not quite sure how to communicate what the button does. I don’t think a simple “Refresh” button is accurate. Maybe it could have a help popover with some more text that explains how it works. This design would require users to navigate to the database page (an uncommon page) to push the button. But that seems better than anything else I can think of.
Ghislaine Guerin
Sean Colsen
Ghislaine, the “Refresh Reflection“ button (that Kriti is suggesting we add) is different from the browser refresh because it would perform reflection. Any schema changes made outside Mathesar would only be visible after pressing the “Refresh Reflection“ button (and would not be visible after refreshing via the browser’s refresh). Your question is exactly the question I don’t want users to have. But it's tricky because 99% of the time the buttons would appear to do the same thing since schema changes outside Mathesar are likely to be rare (I’d guess).