3 ms·
This is a good example of how important it is to work with actual data, representative dummy data, or at least to try and simulate these things. When pagination
by mercer 11y ago
This is a good example of how important it is to work with actual data, representative dummy data, or at least to try and simulate these things. When pagination is built, the fixed-width page number links are often based on a single integer, which of course breaks down once you get more content.
A huge amount of 'bugs' I run into as a front-ender are of this kind. For example, someone designs a nice three-column layout with title, subtitle, and text underneath each other. Each of these columns is fixed-height as well (usually a bad idea in general, but it looks very ugly otherwise).
This works fine in the design phase, where titles are written to fit the element, but once you start working with real data, you run into a problem: one title might be three lines high, while another is only a single line high. Since you want the 'columns' to be fixed height, you now have to add a lot of whitespace underneath the one-line title, so that everything lines up with the three-line title element.
Then you realize that you have the same problem with the subtitle and content, so now you end up with ridiculous amounts of whitespace between title, subtitle and body, depending on the length of the text within.
I've often tried to preemptively address these issues as a front-ender, but aside from this not really being my job (that's where the value of a UX designer comes in, I guess? Or at least a web-skilled designer), I can't always predict these kinds of things either.
So the best solution I've found is to always try to work with real data, or create enough 'random' fake data to fix these kinds of issues.