> You're doing it wrong if you're stripping features only on small view ports.
I'm not sure how that statement addresses the point made by GP, who said, "...their websites are often terrible on a laptop, which is how I use the Internet."
If not the de facto guidance of mobile-first design, the de jure guidance steers designers toward reduced functionality. The overwhelmingly common outcome of a mobile-first redesign of an application is dramatic reduction of functionality, often spun as a simplification. I would prefer if mobile-first redesigns retained existing functionality but I acknowledge functionality may be reached in new ways that better fit the capability of the device.
The problem is not that mobile-first design strips features only on small view ports; the problem is that mobile-first design strips features full-stop.
Unfortunately, I agree that it certainly is a tendency to do that. But, again, I'd say that's just bad design. A good design with a mobile first strategy should not end with such an outcome. I'd also like to clarify that my tone was directed towards the people who mess it up, not the parent. If you start with a semi truck trailer full of stuff from your suburban mcmansion and try to cram it into a studio apartment, you're going to have a bad time. But you have to. What you don't have to do is say "We have all these widgets and need them on mobile so let's figure that out". Those aren't features. The feature is being able to get the information you need or do your task on any device. If you can't design an interface that accomplishes what you need in a small viewport, that doesn't mean cut it, it means maybe think a bit more. It's not a situation of fitting every god damn thing on the same screen and then giving up on anything that doesn't fit. When you have more screen real estate use it if you can effectively.
Again, your feature is what you can accomplish with whatever it is you're designing. If it's a database of information with tons of categories then it's an IA problem from the tightest box first and then using more space as it becomes available. If a user can't get to the same information on any device then the design ain't working. If its a piece of accounting software you'll have a bunch of crud operations happening and need to focus on designing great forms. I think most large companies basically decide to cram their mega menu into a side are menu, then expose the search bar and put their app in read only mode. Very much like slapping agile on your team to solve your efficiency problems, it won't work.
> If a user can't get to the same information on any device then the design ain't working.
Another explanation: sometimes the device really is too small for the information. Mobile devices are terrible for a lot of things. People with laptop or desktop computers shouldn't pay a price for that. "Mobile first" is okay in some cases as long as it isn't "mobile on every device".
I'll certainly concede that there may be different challenges associated with design for things like watches. Maybe. Haven't used or designed for them though.
I'm not sure how that statement addresses the point made by GP, who said, "...their websites are often terrible on a laptop, which is how I use the Internet."
If not the de facto guidance of mobile-first design, the de jure guidance steers designers toward reduced functionality. The overwhelmingly common outcome of a mobile-first redesign of an application is dramatic reduction of functionality, often spun as a simplification. I would prefer if mobile-first redesigns retained existing functionality but I acknowledge functionality may be reached in new ways that better fit the capability of the device.
The problem is not that mobile-first design strips features only on small view ports; the problem is that mobile-first design strips features full-stop.