Some expanded information about the decision making that took place here:

Before

• Nearly all of the UI used a 14px font size.

• At a smaller browser window width, the buttons and inputs would ballon to be 44px tall. Font sizes did not change. In several cases, this broke FOLIO's pane layouts.

The idea with the button/input size changing was that Apple gives the guideline that the size of clickable targets on touch devices should be at least 44px X 44px. Other mobile OS makers like Google and Microsoft recommend even larger touch target sizes.

The problems with this approach:

• It makes the assumption that a narrow browser width means the device is touch-enabled, which is not true in cases where a mouse-based user just shrinks the browser window.

• It ignores that touch-enabled devices can also be much larger.

• When focusing on an input to type in it in iOS, if the font size of the input is less than 16px, the browser will zoom in on the input. This broke FOLIO's pane layouts.

• FOLIO does not officially state any support for iOS, Android, or any touch device, but as a browser-based app it's a sure bet a user will try it out. FOLIO should be at least reasonably functional on those devices, even if it's not optimized for a touch-enabled experience or small screens.

After

• The base font size of the UI is 16px, but some elements of the UI remain about 14px.

• The form controls stay a consistent height no matter what the screen width or device capabilities are.

The compromise with this approach:

• Long lists (like search filter checkboxes and search results themselves) will show 15% fewer items on the screen at any given time. I deemed it a good compromise to lose 15% of the density in the interest of FOLIO instantly becoming more functional on more devices.

• Detecting whether a user is on a touch screen is technically possible, but technologies like the Microsoft Surface, which can be used with either a mouse or touch, throw all assumptions out the window. At best, we can only guess if the user wants to use their finger.

Industry examples

When designing browser apps, compromises have to be made to accommodate a wide spectrum of browser widths and input devices. Although phone OS makers recommend certain touch target sizes, it's important to note the browser-based solutions these projects arrived at with billions of dollars of R&D available:

Slack

Looking at the list of channels and DMs, each item in the list is 26px tall in the browser (or on desktop), and 36px tall in the iOS app. It doesn't appear that they're even following iOS touch target guidelines - they know they have a list that would be difficult to parse when spaced out that much, so they compromise.

Material Design

Google's design system.

https://material-components.github.io/material-components-web-catalog/#/component/button
Buttons are 36px tall in the browser

Bootstrap

Created at Twitter; variant of it used by GitHub.

http://getbootstrap.com/docs/4.1/components/buttons/
Buttons are 38px tall, larger sizes available for some layouts

None of these projects choose to differentiate font or form control sizes in the browser based on whether a user is on a touch screen, because they arrived at the same strategies I applied here:

• Make sure elements are large enough to be reasonably clickable on a touch screen.

• Don't go so big that mouse-based users with big monitors have an awkward experience.

• Making all clickable elements on touch devices at least 44px tall is an unrealistic expectation for a browser-based app that relies on density.

Conclusions

After switching inputs to have a 16px font size, I made these adjustments to the set of components to match:

• Increased the body base font size to 16px, the browser default.

• Added a full spectrum of font-size variables, from xx-small to xx-large.

• Everything in stripes-components now uses one of those font-size variables.

• Increased padding of buttons so they have the same height as inputs.

• Decreased size of label and label-like elements to use the "small" font size variable, which rounds to 14px.

We now have a middle ground where the design system works for more devices, while only giving up a fraction of the density the system previously provided. We relied on industry-standard best practices to get there.

Merged https://github.com/folio-org/stripes-components/pull/611

Per 9/27 (Filip + Jeffrey) will proceed with this user story. And will address issues reported by Filip, Rasmus, and others.