Maybe it’s just me, but happens to me all the time, that I change component settings on different breakpoints without activating the blue dot… so that I always end up changing the mobile setting.
That being said, wouldn’t it be so much easier, that the little blue dot automatically gets activated when we change a component setting on a certain breakpoint?
Or do I miss something that would render that option unusable?
We did look at doing things this way early on in development, but most of the time when you change a setting, you don’t want it to apply only to a specific breakpoint; you want it to affect all breakpoints!
Here’s a video where I try to explain why this could be problematic:
Cheers @dan. Coming from another app I am used to mobile first frameworks. The way it worked for me was different.
Thanks for your explanation. It makes sense that way. Just wish the blue dot would be a wee bit more prominent and easier to click But it’s actually great to see at a first glance if there are changed settings for each breakpoint.
I’m coming from Blocs which I used for the WYSIWYG approach after I decided to move away from RW an stacks and the horrible way to design a webpage.
What I still love about Blocs is their Class Editor, which might be a bit redundant here. I too like that you can change e.g. margin and padding directly by dragging a handle on the elements / components and the way it’s visualised. Same with some other settings.
And yes, I too lean towards designing for desktop first. Just feels more natural.
I really object to the “mobile first design” implications. That’s akin to saying that there’s only one way to doing Web sites.
There are times when mobile first (and almost mobile only) is the correct approach. The Food Truck example in the Marketplace is a good example. Anyone who’d actually be a target for such an app is using a phone, they’re not at the food truck with their desktop computer ;~).
However, there are also times when desktop first is the correct approach. Generally the broader and deeper the information on a site is, the more this should be the starting point. Once designed in the space in which it’s best consumed, the site designer then has to figure out what should survive in the mobile view. And that’s the problem with mobile first: you wouldn’t create all the things that should be in the desktop design.
Thus, I don’t think site design should be thought of as an either/or approach (i.e. design mobile first, or design desktop first). You really have to be thinking about what the site visitor’s intentions/expectations would be when they’re using a phone, a tablet, or a desktop. When the iPhone came out in 2007 for a couple of years I actually had a sub-site to my main site that was just “things you’d want to know and find quickly when I’m using the phone” versus “things you want to know.” Big distinction.
Thus, I tend to design desktop first because it is the superset. Mobile is almost always a subset.
umm have yo been out in the real world??? everywhere you go whether it be pub, resteraunt shopping, on the bus everyone is on their mobile…not a desktop…when I go out with my friends everyone at one stage or another goes on the web…so thats why its mobile first..the average time spent on a webpage is 52-54 seconds…if I visit a website and its not built for mobile im gone…if you build for desktop first and dont have a decent mobile version people will just go away. I run my mates yacht club website and over a third of all visits are on a mobile.
Every website should be accessible for everyone and on every divice. Doesn’t mean the design has to start for mobile though. I prefer to design it as I want it to look on desktop. Then I start breaking it down to laptop, tablet, mobile device. I find that more natural than the other way around.
I’ve been in the real world now for 73 years. I’m not only highly observant, but also curious and statistical.
Sure, everyone has a phone and uses it. My stats show that’s it’s actually worse than 52-54 seconds “on a page,” because they’re actually doom scrolling through “chunks” of a page during that time.
I’ve been in professional media of all types for 50+ years now. I’ve watched each and every one of them get into “chunking.” Technically, Sesame Street and Laugh-In were chunks. The original USA Today was about chunking. Men’s Health was all about chunking. Instagram and TikTok are chunking. Short attention span, can-be-interrupted, one thought bits abound in chunking philosophy. But they’re also a lowest common denominator, and I don’t design just to lowest common denominator, nor do I think others should, either.
Unfortunately, unless you want the mobile view of your Web site to endlessly doomscroll, you have to simplify and pull up the most useful chunks. I actually have a question for @dan about a design issue that relates to this that I’ll eventually get around to asking.
AI is going to change Web design soon. Not in the sense I’ve seen anyone mention so far (e.g. help with design). Think of a system where content is “pulled to you” rather than you go searching for it. The design question is how you best let the user define what and how to pull to the AI. Right now all AI is using “chat,” which is nothing more than an expanded, natural language, search box. But what if it were a “control panel”? If you’ve been in the cockpit of a modern plane, pilots pull the flat panels to what they need to know, they don’t search for the panel they need. I suspect AI will let us eventually all “pilot” our Web experience. That still needs design, but instead of the designer designing what they can do, they’re designing how they do it.
I too am 70+ nearly.
started to read your reply but the 52 seconds was up so that was the end of that.
so if you ‘‘really object to mobile first’’ then surely your in the wrong place
like going into McDonalds and not liking burgers!!
you mean like it does already..ie search for something then you tube keeps giving things like you’ve just searched for hahaha or google…