Absolutely agreed. The article laments things like "I have no good way of knowing how big my text is going to be when I say 16pt," and my response is "why would you ever need to know that? Do your containing elements not reasonably resize when their inner content gets bigger? How are you handling internationalization where strings will certainly be longer?"
It's ok for apps to look different on different platforms. We need to stop trying to design things pixel-perfect to the mockups - I thought we could have left that trend behind in the early 2000's.
OS font rendering can even provide info about the physical dimensions of the screen and give you an "actual size" unit you can use to match your screen to real world paper. So a lot of this article, to me, reads as a misunderstanding of why fonts render the way they do.
> It's ok for apps to look different on different platforms. We need to stop trying to design things pixel-perfect to the mockups - I thought we could have left that trend behind in the early 2000's.
Thank you, Yes Yes!
The web was much better when it was annotated text: You took a primarily text document, maybe decorated with a few formatting hints, and let the User-Agent take care of the rest. Over the years, browsers have handed way too much fine-grained control over to web developers, and the result is thousands of developers treating my HyperText browser as some kind of interactive graphic design canvas. This has really been a step backwards in web usability, even though it enabled nice fancily-designed blogs and "web apps" of dubious value.
> and my response is "why would you ever need to know that?"
The author wants to know, so this is simply the wrong question. I agree with the author that it is strange that a quantity which is in principle easy to compute behaves in such an unreliable way. It makes designing stuff more an iterative instead of a first-time-right experience.
Also, if you specify X and get Y instead, then that is a way for websites to fingerprint your browser, which is another reason to make the computation more reliable.
> It's ok for apps to look different on different platforms.
We've been all in the situation where you designed something for device A and it looks off when viewed on device B. A word that wraps in the wrong place, or a button that is 1px taller than the button next to it, etc. More control over what is shown in the browser is always better. (Of course, a user should be able to override everything, but that is another matter entirely).
> We need to stop trying to design things pixel-perfect to the mockups
This is the huge war that has left CSS and much of the web a battle-scarred crater-ridden minefield.
Users want to be able to buy a range of devices with different sizes and resolutions for different use cases.
Different users want different text sizes as an accommodation for myopia and age.
Manufacturers want to be able to bring out new devices that have a different screen size and resolution from the previous ones.
Designers (and clients!) want to know exactly what something will look like when they publish it. But insisting that you can predict the "pixel" output in all cases is to fight all of those use cases. It's just that sometimes they win.
Apple are the only vendor who've really got high-DPI and DPI scaling working consistently; Windows support is there but so widely ignored or broken by apps that you can't rely on it.
A problem I had and I could not find a solution (maybe someone could help me).
I want to show a button for the user to click. I respect my user and I want my button not to be too big or small, I would like it to be equal or similar to his preferred button size he configured his OS to use. If you search for the best practices you find studies that say that on mobile the button should be maybe 10mm real size , but good luck setting a css dimension on the button that will ensure either this default size on all devices. IMO there should be a css value for preferred font size and preferred touch button size so you don't get at the same time complaints that the button is too large or too small. (I do mostly bgackend so maybe I missed something when searching, maybe there is some hidden trick to do this...and I am referring at mobile devices)
Having another unit for "touch area" would be kind of nice, I can imagine uses for that. The device/browser/user could set how large a `ta` unit is for buttons/inputs.
Wouldn't just be useful for mobile, I can imagine even on a desktop a user with Parkinson's or something might have trouble precisely using a cursor and want bigger interaction areas when they visit a website.
The most common solution I see online is to swap layouts when the page drops below a certain aspect ratio or width, which can actually be kind of annoying on desktops. It's a hacky solution.
There are also some media queries you can do to detect the presence of a mouse in some browsers, which can work, but also doesn't really hold up in a world with convertible devices that can be simultaneously mouse-drive and touch-enabled.
> The most common solution I see online is to swap layouts when the page drops below a certain aspect ratio or width, which can actually be kind of annoying on desktops. It's a hacky solution.
In many scenarios, there is no way to interpolate between the ideal layouts for large and small screens. This makes it necessary to arbitrarily select some point where the layout is rearranged as the viewport changes.
I agree that this behaviour can be annoying on desktops as the window is resized, but it’s better than the alternative - a layout that needs to work the same way for drastically different screen sizes.
The problem I have presented in the grandparent comment could be solved either with:
- let me specify the button size in real world dimensions
- let me specify that my button should be the same size as Safari/Chrome buttons in the toolbar.
Then my users can't complain that on their device the buttons are too big or too small. The page was something like a map with a toolbox on bottom, if you make the buttons too big the map area is reduced, if the buttons are too small then are hard to use.
With native toolkits like Qt you have a toolbox widgets, you don't define any dimension or colors and the user theme will handle everything.
Right, the issue here is that we don't have enough semantic control over why an element is a certain size in CSS.
One of the underlying reasons why `em`/`rem` units tend to work better in CSS for container widths is because very often semantically you want to design a column in relation to how many characters of text it should display in a row before wrapping.
But not always; case in point touch interfaces where the reason everything is getting bigger is not because anything fundamental has changed about the user's text preferences, but because bigger elements are necessary for a bigger pointer.
So it does kind of make sense to me that we could have a semantic unit that is unrelated to text size and specifically related to a user/device defined touch size. And then you could have a mix of min/max widths and heights based on different semantic units to have something that responds equally well to both narrow windows on the desktop and mobile devices.
I am all for having more sizing units that are based on user-defined attributes that are applicable to a specific category of measurement (font-size, touch-precision, screen-brightness, whatever), not on trying to guess what specific device a user has.
A 5 inch wide page on a desktop and a 5inch wide page on a mobile device have different concerns because they're controlled by different pointer devices. It's a little irritating that they both collapse to the same touch interface.
That's the case for most ui/ux at a given point for responsive design, regardless of the ppi/size reporting.
Also, I'm refering to text/font rendering, not UX breakpoints, though I do understand the issue... the problem is, short of sniffing the user agent for "phone" or "mobile" there's no way to tell for sure... touch interfaces are unreliable as many desktops also have touch support.
Note: I have used the phone/mobile sniffing to do some things slightly differently for desktop vs. mobile before. For the most part, it's not too big/bad of an issue.. I do know people that don't like certain sites/apps on desktop as this practice has changed though (namely, skype and discord) as a friend liked to use about 1/4 the screen for chat, but the ux now changes to phone ux when too small.
Assuming the ppi is setup correctly, both px (1/96") and pt (1/72") will do that... however it's up to the device mfgs to setup the ppi for the OS correctly.
If I have two monitors with two resolutions and I put the two screens together the text is a different size. When I'm reading the text I want it to be consistent as I move it across screens. With this approach will the text be the same size?
The main issue I have as I get older is that as the resolution increases the text size seems to get smaller
This is exactly the problem that I'm getting at. The reason your font is getting smaller with higher pixel densities is because the font size is being tied to the pixel density.
In a better native world, your font size would be completely unrelated from the monitor(s) you're using. It is the attempt to tie font sizes to physical attributes of your monitors like their resolution that is giving you this problem. And it is the need for scaling to be based on resolution that makes multi-resolution monitor setups break.
There's no reason why your OS couldn't size text differently on each monitor based on monitor-specific settings that you control, and there's no reason why the applications you're using couldn't implement responsive design and accommodate that setup.
As designers we would just need to embrace responsive design and stop trying to control everything.
Any kind of user customization will have the same effect. Any preference that the user can edit can be a confounding variable in an A/B test.
I don't want to live in a software world where as a user I'm forced into a one-size-fits-all approach to every interface just because it makes A/B testing easier.
I would posit that if rendering differences in font display are affecting A/B testing a workflow, the A/B testing apparatus has failed to control for confounding factors and was probably invalid anyway. If OSX is known to render differently than Windows (and it's not just fonts), why are you comparing cohort A from Windows to cohort B from OSX? That is an analysis error.
It's ok for apps to look different on different platforms. We need to stop trying to design things pixel-perfect to the mockups - I thought we could have left that trend behind in the early 2000's.
OS font rendering can even provide info about the physical dimensions of the screen and give you an "actual size" unit you can use to match your screen to real world paper. So a lot of this article, to me, reads as a misunderstanding of why fonts render the way they do.