More feedback on the updated topology.pages.dev

[prabau]

Follow up to the discussion #464, which is now closed.

When visiting a Property page (like https://topology.pages.dev/properties/P000013), the old interface had the tabs in the order (Theorems, Spaces, References) and the new interface has the order (Spaces, Theorems, References). But when visiting a Property page, the most important (to me at least) is to see the list of associated theorems. So I think it should follow the order (Theorems, Spaces, References) as before.

NOTE: for a Space page, the tabs were reordered to (Properties, Theorems, References) and I applaud this change. Nearly always what we want to see first for a space is the list of its properties.

[StevenClontz]

I agree, implementing as pi-base/web#113

[prabau]

Thanks for the change

[StevenClontz]

Somewhat related, what do you think of:

• https://traits-table.topology.pages.dev/spaces/S000038/properties
• https://traits-table.topology.pages.dev/properties/P000004/spaces

[StevenClontz]

The main goal I was addressing was putting the boolean value nearer to the property ID/name.

Check again; I moved the boolean to the far left so the ID/name are together. This can wait until the next meeting to merge.

[prabau]

Still not quite sure. Logically, each id/name has a value (true or false). So it's seems natural to have the value after the id/name. But we can discuss again at the next meeting.

[StevenClontz]

While it's on my mind, a counter-argument: we frequently write $\neg P$ where the value is before the property. That's why I kind of like having the value far-left. Additionally, it links to the property/space pair page, while clicking on the property or ID sends you directly to the property page. (Of course, that's configurable if we think it should always link to the property/space pair homepage, which in turn links to the property.)

[prabau]

That counter-argument makes some sense. Following that same line of reasoning, I think I liked your first attempt above better, with true/false just before the name in English, instead of separated from it by the Id column. The Id column is good to have, but the main thing is associating a name in English with a value so it's good to have them next to each other.

[StevenClontz]

Let's do some A/B testing in the next meeting to make the final decision then.

[prabau]

A possible performance problem with the new web interface.

Starting with a link to https://topology.pi-base.org/spaces/S000031/ in an email, I click on the link and my browser (Firefox) opens a tab for that page and starts displaying the page and also showing a green progress bar at the top, showing that it's doing something, presumably to compute all the generated traits. And the progress bar is going really slow.

If I then click on the Advanced button at the top right while the computation is going, it shows all the progress of the generated traits and the progress bar completes in practically no time. But then clicking on the back button to go back to the previous page and refreshing the page again shows a very slow progress bar.

Also examining a different space again shows a very slow progress bar.

The old web interface was a lot more responsive and did not seem to have these performance problems. Maybe it did some caching in a different way? @jamesdabbs and @StevenClontz any idea?

We should demo the problem at our next meeting.

[StevenClontz]

I can replicate this behavior in Chrome. I don't have enough perspective on how data is loaded to say why load times depend on which route we're at, but I imagine it's related to the issue I've found when getting 404s on routes that don't exist on main that should exist on a branch, unless I navigate to them via internal links rather than directly via URL.

[prabau]

Another good illustration: https://topology.pi-base.org/spaces?q=Cardinality+%24%3D%5Cmathfrak+c%24%2B%7EDiscrete%2BHas+an+isolated+point%2Bhau slowly fills the list to get a total of 6 spaces. Clicking Refresh in the browser afterwards again gets the list at the same rate and not any faster.

[StevenClontz]

Follow up - many of the performance issues we discussed in this thread seem to have dissolved (perhaps with @jamesdabbs upgrades to SvelteKit 2?).

But this point stands - refreshing (or opening in a new tab) pages triggers a full reload of data. It'd be nice if we cached data from previous visits (or could use cached data while a new pull is being made).

There's also some issues with some pages loading significantly slower than others (or it appears to). I made an issue here: pi-base/web#130