UIKit admin reflow and FOUC

[Mikie]

Hey just bringing up as a point for discussion. I find in various areas of the admin there is quite a lot of reflowing of content and flash of unstyled content (FOUC). Examples are:

• the pages listing animation pushes the footer down the page every time, and this can also be seen on various pages where content doesn't load immediately (footer will fly down the page)
• basic pages with no fields – sit there and refresh a basic page a few times, you will see a flash of all content before tabs are created
• pages with lots of fields – progressive loading and rendering of different fields and groups causes lots of reflow, particularly loading wysiwyg and image fields
• modules eg lister-pro  – loads the add new button initially on the left then it jumps to the top right as the lister loads, then columns reflow and resize as content loads in and classes are applied

Whilst pw is very fast to render admin page html, to me the above makes it feel quite jarring and heavy. Generally speaking you want to aim for no reflow or FOUC whatsoever for a good user experience. I know there is a lot going on here and it is not a simple thing to manage an admin like this, but does anyone notice the same thing and have any ideas about how this can be optimised? Below are some relevant links. Minimising animations is the best place to start, although before anyone suggests it just using AdminOnSteroids to disable animations doesn't fix a lot of what I am talking about. 

https://developers.google.com/speed/docs/insights/browser-reflow
https://gist.github.com/paulirish/5d52fb081b3570c81e3a

 

[Soma]

Yeah good point. The way to do it is simple. If javascript is deferred, add the classes like uk-grid etc and not just the data attribute. https://getuikit.com/docs/grid#usage

[adrian]

@Mikie - I completely agree - the PW admin interface is full of these jarring FOUCs (it's not just the UiKit theme either). I hope Ryan will give this some serious consideration going forward.

[elabx]

Does anyone have the perception the old admin is "snappier"? I'm using both and I get that feeling, could this be the reason? 

[szabesz]

5 hours ago, adrian said:

I hope Ryan will give this some serious consideration going forward.

I think it will required a complete rewrite, based on some JS "framework" magic...

2 hours ago, elabx said:

Does anyone have the perception the old admin is "snappier"? I'm using both and I get that feeling, could this be the reason? 

Sure. While adding UIkit 3 to the mix was possible, it just added another layer of complexity. The current admin is a patchwork, although a good one, but there is room for improvement as always I think.

Ryan likes proven tech, so I wish he took a closer look at JsViews by Boris Moore: https://www.jsviews.com/#samples/editable/submit 6+ years of constant development without breaking changes and reinventing the wheel, in this sense similar to ProcessWire's path, so I started using it too. It took me a while to stumble upon it by accident.

[elabx]

42 minutes ago, szabesz said:

I think it will required a complete rewrite, based on some JS "framework" magic...

3 hours ago, elabx said:

I can't imagine the amount of work it would require coding a new admin.  I'm guessing it would need a rewrite of all "major" Process modules right? 

[wbmnfktr]

I don't want to downplay anything here but... how often do you all see FOUC in PW admin?

I just started to look closer while admin pages load/reload... but to be honest... I see only some minor reflow issues here and there but nothing that annoys me.

Right now I'm working on three different systems...

1. local (Laragon)
2. Remote (webgo)
3. Remote (Dreamhost)

While Dreamhost is remote and kind of slow only reflow issues appear on bigger pages there once in a while.
No FOUC or something similar to that.
Laragon and webgo are fast and those reflow issues are gone even before I really notice them.

I don't use AOS, Tracy, Lister Pro or similar modules that may cause those... FOUC issues.

 

Nonetheless... count me in for optimizing the backend to make it even better.

Tested on: PW version 3.0.123 and 3.0.130

[Robin S]

@Mikie, you will probably need to open separate issues for each concern in the Issues or Request repos in order for Ryan to notice - he doesn't tend to participate much in the general forums these days.

In terms of which repo, I'd say that it belongs in the Issues repo if something is broken or not working as expected, and in the Request repo if it's about adding a new feature or improving something that already works. In each issue please describe exactly what the problem is and what a solution would look like. And if you are able to contribute code for a suggested fix that's great (but not essential).

I have some possible fixes for some of the things you mentioned that you'd be welcome to include in any issue report if you want...

On 4/23/2019 at 2:52 PM, Mikie said:

the pages listing animation pushes the footer down the page every time, and this can also be seen on various pages where content doesn't load immediately (footer will fly down the page)

The footer sits under whatever content makes up the page, so if new content is loaded into the page by AJAX or page elements change in height then it's expected that the footer will move. Are you suggesting that the footer should be sticky to the bottom of the viewport when the height of the page content is less than the viewport height? Personally I would prefer that, but it's perhaps a matter of opinion. Here is some CSS that could be used for a sticky footer:

/* Sticky footer */
html { height:100%; }
body:not(.modal) { display:flex; flex-direction:column;	height:100%; }
body:not(.modal) #main { flex:1 0 auto; width:100%; box-sizing:border-box; }
body:not(.modal) footer { flex-shrink:0; }

 

On 4/23/2019 at 2:52 PM, Mikie said:

basic pages with no fields – sit there and refresh a basic page a few times, you will see a flash of all content before tabs are created

This FOUC with WireTabs was much worse with the older admin themes - I hardly notice it in AdminThemeUikit but it is there. A CSS fix:

/* Prevent FOUC for WireTabs content */
.WireTabs + .Inputfields > .InputfieldWrapper { display:none; }

 

On 4/23/2019 at 2:52 PM, Mikie said:

pages with lots of fields – progressive loading and rendering of different fields and groups causes lots of reflow, particularly loading wysiwyg and image fields

The main FOUC relating to fields that bugs me is the delay in hiding inputfields with show-if conditions. I'd rather have show-if fields hidden by default and then shown when necessary. There's an open request about that, along with a roll-your-own fix for the meantime: https://github.com/processwire/processwire-requests/issues/179

I'm not sure what sort of change you want to see with regard to CKEditor fields or image fields. Some inputfields take a moment to initialise - I'd rather see the interface as soon as possible even if parts of it need to adjust slightly after loading than have the whole interface hidden until loading is complete (not sure if that's what you're suggesting).

  

On 4/23/2019 at 2:52 PM, Mikie said:

modules eg lister-pro  – loads the add new button initially on the left then it jumps to the top right as the lister loads, then columns reflow and resize as content loads in and classes are applied

Generally speaking the behaviour of non-core modules is up to the author of those modules. But in the case of the Lister Pro button you mentioned this is due to the way the admin theme wraps and clones "head" buttons. A CSS fix:

/* Hide Lister button links at bottom when results are empty */
#ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

 

Edited May 2, 2019 by Robin S
Updated CSS fix for sticky footer

[Mikie]

@Robin S was just typing a reply to say I was thinking there might be quick css fixes, maybe more complicated js ones. I was hoping someone with a bit more knowledge of the theme code might know some quick ones, and lo and behold! This is good stuff thanks. Totally get Ryan doesn't monitor the forums but just wanted to see if anyone had any more knowledge of this before attempting to do so myself. Issue / requests definitely the most proactive way to move forward.

@wbmnfktr its just little bits and pieces that I feel could be optimized. I am maybe noticing it right now because I am clicking around the admin a lot for a new site.

Generally didnt want to bring this up as a major flaw or need for a rewrite, just hoping there might be ways to optimise this stuff. Beyond Robin's suggestions my hunch is there is also probably also some weird interplay between UIKit js and jqueryui going, but I need to dig in and have a look. Thanks all for the feedback, if anyone has any other fixes maybe PM me or post back here, at some point soon I'll put these into issues / requests.

[Robin S]

@Mikie, I updated the CSS fix for the Lister button. After looking more closely I see that it only seems that the button is moving to the right. What actually happens is that initially you see the button that appears below the lister results, but this is near the top of the page because the results are empty at first. Via JS the button is cloned to the top right and the lister results are loaded, moving the original button lower down the page. So a better fix is to hide the bottom button when the lister results div is empty.

/* Hide Lister button links at bottom when results are empty */
#ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

 

[bernhard]

Are you talking about effects like the one above? I've once created a little module that shows a "loading" overlay animation until the page is fully loaded. Would that also be an option or are you talking about something else? Sorry, I'm not good at frontend stuff ? 

[tpr]

33 minutes ago, bernhard said:

shows a "loading" overlay animation until the page is fully loaded

Just a side note: imo such things just increase the percieved page load time and are an unnecessary complication unless the page is expected to load slowly. I would avoid it if possible, even that I have done it a few times in the past.

[bernhard]

Yeah, that's why I disabled it lately ? I think it also broke something else (ajax etc. getting more complicated when things are hidden at first...). But if done right, maybe it could improve the usability. Not sure ? 

[Mikie]

@bernhard yes that screencast is exactly what I am talking about. What you mention is one solution but as @tpr says it does slow down perception of load. A good analogy is a large gallery of images on the front-end. You could wait for all the images to load then show the parent div, but this would obviously take time. Or you could lazy-load (render the layout and load in images with js via src tag manipulation as you scroll), however if you don't add a placeholder file or do styling to match the aspect ratio and appearance of the final image then your gallery will jump all over the place as different images load in. 

In your screencast, if the the footer were hidden until the main tab content was loaded then the whole feeling of that page would be smoother.

[Mikie]

As mentioned I am going to try to submit some issues / pull requests for this, just super busy right now and want to take some time to fully understand how Ryan has set up the admin theme first.

[wbmnfktr]

Haven't used this in backends yet but sometimes those skeletons are pretty nice.

https://codepen.io/oslego/pen/XdvWmd

[Mikie]

@wbmnfktr I've started to see this kind of thing more, like here https://webpack.js.org

What do you think of this? To me I find it a bit weird that the skeletons don't match the content, however I get why people use it in PWAs since they are so fast to route.

[wbmnfktr]

13 hours ago, Mikie said:

a bit weird that the skeletons don't match the content

You can of course customize them. Most sites I've seen use only a few iterations for all of its content. So sometime it doesn't match but thats fine for the most part I guess. Facebook is quite good at it.

[MrSnoozles]

On 4/23/2019 at 9:02 PM, szabesz said:

Ryan likes proven tech, so I wish he took a closer look at JsViews by Boris Moore: https://www.jsviews.com/#samples/editable/submit 6+ years of constant development without breaking changes and reinventing the wheel, in this sense similar to ProcessWire's path, so I started using it too. It took me a while to stumble upon it by accident.

Please no. ?
I've been working with JsViews on a project and as the project became considerably large it became a nightmare to maintain. It's not necessarily JsViews fault though, it does a splendid job at what it does. But attaching event listeners to things based on their ID somewhere in the DOM and then reacting to it isn't really maintainable in a larger scale. In my opinion VueJS (https://vuejs.org) would be a great addition to the ProcessWire backend as they also somewhat follow the same philosophy and are a joy to work with.

[szabesz]

8 minutes ago, MrSnoozles said:

But attaching event listeners to things based on their ID somewhere in the DOM and then reacting to it isn't really maintainable in a larger scale.

Are you sure all those IDs were necessary? A lot can be done without IDs all over the markup, for example: https://www.jsviews.com/#samples/form-els/visible-binding

BTW, VueJS would be next thing I would pick if JsViews was not around but as JsViews is still being maintained I am not planning to switch to anything just yet. Also, those who seem to have experience with VueJS have issues with it too, eg.:  https://vuejsdevelopers.com/2017/09/17/vue-js-avoid-dom-templates/

Looks like nothing is perfect ? 

[MrSnoozles]

Want to add to this rather old discussion, because state of tech changed a bit:

On 5/10/2019 at 10:36 AM, szabesz said:

Are you sure all those IDs were necessary?

No - probably it could have been simplified a lot. It was my first project with Jsviews and I probably didn't use everything it has to offer.

Anyway: what caught my attention recently with regard to the ProcessWire backend is https://svelte.dev/. I haven't worked with it yet, but it seems like it could be a nice match for ProcessWire. It compiles to native Javascript, meaning even if there will be a next big thing in the future we don't have to include an outdated framework in the backend. The syntax looks really nice too and very Vue-ish which I personally like a lot.