Beta 2: Notes on multi-document editing (Slow tab switching)

[Misho]

I love the idea of tabs in Cornerstone, but if things remain as they are now, I will still continue to switch between browser tabs to achieve the same, but significantly quicker.

For example, If I am editing the Homepage of the website and jump to the header, getting back to the Homepage tab lasts “forever”. Benefits of native tabs are lost, with browser tabs still being the fast alternative.

I was expecting that, for example a change inside a component without saving in one tab would reflect on a page that has that component in other tab. Then it would make sense to wait sometimes more than 10 seconds for the page tab to load, plus additional time for effects to kick in, etc.

I understand that this is probably due to performance reasons, but I’d prefer to get the chance to decide on my own. The only solution that I see to this is a right click context menu on a tab, with an option “Keep loaded”, or something along those lines. This way, if we are in the situation that we need to go back and forth between tabs, we could still do it instantly like we are doing it with Browser tabs.

Thanks!

[kory]

Hey, @Misho…thanks for writing in. The presence of tabs in Cornerstone does not preclude you from using native browser tabs if you wish. One of the main reasons for the inclusion of the tabs was to eliminate the feeling of context switching so much as you jump from a page to a header to a layout to a footer, et cetera. Yes, switching tabs does take a little bit of time as it triggers a refresh to reflect potential changes made on other tabs, and also for performance reasons, we can’t have dozens of “open” tabs operating and listening to on another all within the interface, as that has other implications. The load times experienced moving between tabs are not just part of the tool, but also a reflection of the builds / environment things are operating in. We have tested this new interface with some very extensive builds (dozens and dozens of lengthy pages with multi-dimensional Component nesting, et cetera) and yes, there is a tiny refresh moving between pages, but this is expected as you’re refreshing moving between pages (not the whole app mind you, just that instance, so this is quicker than having to refresh a browser tab). I am not sure on the feasibility of “locking” a tab open as you’re mentioning here, but I’ve noted it.

Thanks!

[Misho]

All right! I guess I have to test more. What I experienced was not tiny. It took more than 10 seconds for the homepage to load when switching tabs. The page has two loopers being fed by two different CPTs, and six lists getting their data from JSON loopers. Nothing special.

The difference is massive on the initial page-load as well. The homepage on Pro 5.1.5 is loading under 3 seconds while in Beta 2 it loading time is consistently double or more. Perhaps you still have some optimization to dial in?

Additionally, I went to the Homepage to click on a button and quickly fire up the Dev toolkit so I can copy it. Even though the page loaded (After 10 seconds), I had to wait for additional 6 seconds for the Tools > Elements part of the Dev toolkit to show up. With old Pro, this was instantaneous.

For me, the backend speed is one of the biggest Pro’s strengths. When professionally working in a tool, any extra lag adds up quickly, affecting productivity and costing money. Over the years, Pro was continuously getting faster and more streamlined. This is the first time it seems like slowing down. At least during the Beta.

[Misho]

Here’s another thing:

I was testing building a components set. I had that opened in a separate tab inside Cornerstone. I opened a page in another tab and tried some stuff. When I finished testing, I reloaded the page to get everything back, completely forgetting that this will erase everything I was doing in the components tab. Surely enough, all my buttons built by that point were gone.

We must get into new habits of tabs within the tabs but I see how losing work due to this will happen from time to time to lot of people. I am not sure if a better warning system could be made, especially when reloading the browser tab.

There is the standard warning about losing potential unsaved work, but we are used to it and often that’s what we want, for the active tab. This message is not reminding us that even if we want to lose the unsaved work, there might be another tab where we don’t want that.

Thanks!

[kory]

Thanks, @Misho. We hear you on all of this and have noted things down to look into. We definitely take performance into consideration with all we do and want things to feel like a step forwards, not backwards. This will of course all be looked into as much as we can.

As for the general warning when closing out a browser…we can take some more time to look at this, but at the moment I feel the general warning is the best way forward here. There were some other discussions in this cycle about this very matter, and the idea that closing out a browser would try and give you a forced warning for every tab felt very heavy-handed. Each tab that has unsaved work will display the “Edited -” prefix before the title, and if you try and close out the browser with any tab in an “Edited” state, it will display a warning that you have unsaved work. From there, you can choose to leave and lose everything, or go back in, and double-check your work, and ensure you’ve saved what you need to. Personally, this feels the cleanest to me because rather than being forced into a potentially long line of dialogs of “Do you want to save this?” “Do you want to save this?” “Do you want to save this?” I can simply move through the tabs as I want, double-check my work, make saves where necessary, and then move on. Personally, this feels cleanest to me as it gives me one final check before leaving, and if I have something I need to save, as a user, I just need to go through and make sure everything I need kept is kept.

As always, this has been noted and we will consider if there is anything to improve here potentially. I do think that some of this also falls into getting into new habits as you mentioned as well, as this is a very big change from what we had before.

Thanks!

[Misho]

Thanks @kory!

I know that it takes away from the elegance of the builder, but I added this to be more safe:

.is-edited i {
  color:#fbce49 !important
} 

Now it looks like this:

[kory]

Awesome! If you want to make it even more “official,” this should tie into the warning color of either the light or dark theme:

.tco-document-tab .is-edited i {
  color: var(--c-text-as-warn) !important;
}

[Misho]

Amazing! Thanks @kory!

Speaking of the light theme, I turned it on (I think first time after a few years ) just to see it, and it seems that the save button has some contrast issues:

[urchindesign]

Edited - Should have read the entire thread as I see the CSS is already mentioned but I’ve left this comment here anyway just to see if we can get a class on the entire tab.

@kory

that has unsaved work will display the “Edited -” prefix before the title, and if you try and close out the browser with any tab in an “Edited” state, it will display a warning that you have unsaved work.

@kory on this one is it possible to add a class to the entire tab for pages that aren’t save? I asked about that in another post but perhaps it got missed. At the moment it is on the word “Edited” or when lots of tabs are open just a small “*”. If you can add a class to the tab then we can highlight the entire tab with UI CSS to highlight those tabs and make them more obvious.

I’ve added this CSS to mine to highlight the word “edited” to the same colour as the save button but it would be better if I could target the entire tab.

.tco-document-tab .is-primary.is-edited i {
color: var(–c-text-as-warn);
}

[kory]

@Misho, glad that’s working for you! As for your save button not having the proper contrast, perhaps you have some custom CSS going on here? I tested this and can confirm it’s the appropriate color for me:

@urchindesign, I have included an is-edited class on the tab itself for the coming release so people can style this as they wish. For now, you could test your styles (and just leave them in if you want) using the :has() selector if your browser supports it (most do now). :has() allows you to style a parent based on the presence of a particular child inside its tree. So you could do something like:

.tco-document-tab:has(.is-edited):before {
    background: var(--c-bg-warn-faded) !important;
}

.tco-document-tab:has(.is-edited) :is(button, strong, i, .is-secondary) {
    color: var(--c-text-as-warn) !important;
}

That’s just a simple way you could make it very apparent that a tab has been edited. It’s a very strong style and not for everyone, but it taps into our style APIs and you can modify as needed.

Cheers!

[JvP]

Nice, edited tabs look great that way so I’ll be using that CSS, thanks!

[urchindesign]

@kory

:has() allows you to style a parent based on the presence of a particular child inside its tree.

Thanks for this. I have not used :has before… doesn’t look like Firefox supports it out the box but perfect for development purposes.

[Misho]

@kory, I finally got time to isolate the culprit for the notoriously slow loading time and tab switching:

It is the carousel slider with logos, fed from ACF fields on CPTs.

The same slider is loading and working fine in the current Pro. In Beta 2, it has issue. This definitely looks like a solvable bug to me, unless the entire architecture was refactored for the worse, which I simply don’t believe is possible with you guys.

Additionally, the marquee slider is sometimes not playing inside Beta 2, sometimes it jumps around and gets stuck, and also sometimes it starts moving backwards? I swear I saw it moving backwards even on the front-end, but I cannot recreate it now. It also sometimes moves much faster on the front-end than it should.

Links to the the slider both in Pro 5.0.8 and Beta 2 are in the secure note (Staging websites).

[kory]

@urchindesign, no problem ! Yes, :has() is my new best friend in CSS-land, haha. I’ve been harping about how something like this has been needed for years. Very handy, indeed.

@Misho, I have noted this down and we will take a look into things. Thank you!