Something I’m noticing: almost all the feedback in this thread is easy stuff. UI changes and etc are all pretty easy. The problem that I expect is that the dev team won’t get to the easy stuff because the hard problem of making the page load fast will take their attention.
I don’t disagree in general—certainly UI changes are easier than infrastructure changes—though there is a caveat, illustrated by the old story about the repairman who took a large repair fee to fix a complicated piece of machinery, and then gave the thing a good thwack, whereupon it worked again; to the client’s protestations that such an easy “fix” was hardly worth the hefty bill—after all, all the guy did was hit the machine once!—the technician replied “yeah, but you gotta know where to hit it…”.
So with UX: many of the changes are easy to make, it’s knowing which ones to make and how, that’s the trick of it.
Finally, implementation details (including infrastructural ones) can make it harder or easier to make changes to the UI and layout and so on. (For example, the CSS component of the LW 2.0 codebase is a , which makes it actually not very easy to make many of the sorts of changes which should be easy to make.)
We actually just cleaned up our CSS a bit, but agree that we probably want to make that part cleaner in the long run. Though I haven’t found making changes particularly difficult.
That’s good to hear, and I wish you success in your efforts to that end! Here is a very simple heuristic, which is very helpful in evaluating how clean your CSS is:
How many times does !important appear in your codebase?
The ideal number is very, very small. (There is a reasonable argument for using it on buttons, and similar utility classes with complex and very specific and universally immutable styling; doing a once-over of a typical LW 2.0 page, I see no cases that fit this profile.) “Zero” is a typical number of instances of !important in a well-maintained CSS codebase.
Currently, that number, for the CSS that goes into an ordinary LW 2.0 post, is 623.
(This is not the be-all and end-all of CSS code quality metrics! But it is, as I said, a very good heuristic.)
Ah, i agree that that is usually a good heuristic. In our case it’s a bit different though.
We are currently using the Material-UI frontend framework, which is great on a really large set of dimensions, but does all of it’s styling in the form of inline CSS (the latest version is moving away from that, but that is currently only in prerelease).
In our case, the vast majority of the !important statements are there to override one specific lowest level material-UI inline style, and are not there to override any other styles in our own CSS files. This makes the impact of those statements significantly less bad than they would usually be. Still not happy about having to use the important tags that way, and it does definitely have some cost, but overall the cost is much lower than one would naively expect.
Because that would add a whole different level of complexity to our code, where now instead of just managing CSS styles, we would need to both manage css styles in one section of our page, and JS-inline styles in another section of the page. Since the interface by which you change the material-UI inline-styles is by passing style-objects to the relevant React components.
We tried this for a bit, but this made things much harder to maintain and keep clean than having important-statements in some parts of the CSS.
In the long-run I want to move towards a styled-components approach, where all styles live in the component files, which we can do after the current @next branch of material UI reaches maturity and feature parity with the current one.
Something I’m noticing: almost all the feedback in this thread is easy stuff. UI changes and etc are all pretty easy. The problem that I expect is that the dev team won’t get to the easy stuff because the hard problem of making the page load fast will take their attention.
I don’t disagree in general—certainly UI changes are easier than infrastructure changes—though there is a caveat, illustrated by the old story about the repairman who took a large repair fee to fix a complicated piece of machinery, and then gave the thing a good thwack, whereupon it worked again; to the client’s protestations that such an easy “fix” was hardly worth the hefty bill—after all, all the guy did was hit the machine once!—the technician replied “yeah, but you gotta know where to hit it…”.
So with UX: many of the changes are easy to make, it’s knowing which ones to make and how, that’s the trick of it.
As for what to prioritize—this is something to consider: https://www.nngroup.com/articles/aesthetic-usability-effect/ (though not to try and apply unreflectively!)
Finally, implementation details (including infrastructural ones) can make it harder or easier to make changes to the UI and layout and so on. (For example, the CSS component of the LW 2.0 codebase is a , which makes it actually not very easy to make many of the sorts of changes which should be easy to make.)
We actually just cleaned up our CSS a bit, but agree that we probably want to make that part cleaner in the long run. Though I haven’t found making changes particularly difficult.
That’s good to hear, and I wish you success in your efforts to that end! Here is a very simple heuristic, which is very helpful in evaluating how clean your CSS is:
How many times does
!importantappear in your codebase?The ideal number is very, very small. (There is a reasonable argument for using it on buttons, and similar utility classes with complex and very specific and universally immutable styling; doing a once-over of a typical LW 2.0 page, I see no cases that fit this profile.) “Zero” is a typical number of instances of
!importantin a well-maintained CSS codebase.Currently, that number, for the CSS that goes into an ordinary LW 2.0 post, is 623.
(This is not the be-all and end-all of CSS code quality metrics! But it is, as I said, a very good heuristic.)
Ah, i agree that that is usually a good heuristic. In our case it’s a bit different though.
We are currently using the Material-UI frontend framework, which is great on a really large set of dimensions, but does all of it’s styling in the form of inline CSS (the latest version is moving away from that, but that is currently only in prerelease).
In our case, the vast majority of the !important statements are there to override one specific lowest level material-UI inline style, and are not there to override any other styles in our own CSS files. This makes the impact of those statements significantly less bad than they would usually be. Still not happy about having to use the important tags that way, and it does definitely have some cost, but overall the cost is much lower than one would naively expect.
Why not remove/disable that one specific style?
Because that would add a whole different level of complexity to our code, where now instead of just managing CSS styles, we would need to both manage css styles in one section of our page, and JS-inline styles in another section of the page. Since the interface by which you change the material-UI inline-styles is by passing style-objects to the relevant React components.
We tried this for a bit, but this made things much harder to maintain and keep clean than having important-statements in some parts of the CSS.
In the long-run I want to move towards a styled-components approach, where all styles live in the component files, which we can do after the current @next branch of material UI reaches maturity and feature parity with the current one.