(In response to Adam Silver’s Stop using device breakpoints)
There are two points that I like to add –
Content will always affect Constraints (i.e. breakpoints) and vice versa.
What I do is a) use the familiar set of breakpoints as initial guesses and b) treat them as assumptions that need to be tested and verified.
If you’re getting more breakpoints, maybe you need to reconsider your initial ones. Some may just need to be:
- Moved or
- Removed completely
This is probably more a developer than designer problem(?) but depends on your background. It comes down to hands-on knowledge of various devices.
- Don’t assume the device you have on hand is the one [definite] solutions. Just because you have an iPhone doesn’t mean everyone else does…sounds sensible but you’ll be surprised how many people don’t follow that advice. I have experience because most of my work involved non-American clients (more likely to see a Samsung than an iPhone).
- Comes back to testing on multiple devices – using BrowserStack (or other simulators) helps testing for both iOS/Android devices or just get a few old/borrowed devices on hand.
The idea here is to get use to the idea of breakpoints as initial guides, not fixed points.