Next one from that is 960 which is larger tablets and tiny laptops. So the first one will be 640 and that covers tiny tablet devices. You set your breakpoints in multiples of 320. Short Answer: 1280 is the perfect size to design for web.Ĭoming from a visual programming/no-code perspective, the rule of thumb we use is to work in multiples that start with 320.ģ20 is the width of the smallest mobile screen on the market, although it might be completely gone in the future, there are still people viewing websites on these puny resolutions. View it at 100% size, which means the prototype will only take up half the screenīoth of these won’t be great experiences, nor will they give a realistic idea of what the final design will look like.Scale up the design to fit the 1920px wide monitor.If I design on a 1440px wide frame, but they view it on a 1920px wide monitor, there are only two options: It seems that it’s totally dependant on what frame size we design with, and what screen size they view the prototype with. The problem was that due to these scaling issues we’ve highlighted, I’m not sure of the best way to present a prototype to this client that will be the most accurate representation of how the actual, coded site would look. My client didn’t like the text sizing across their whole site, so I redesigned it with updated text sizing. Regardless of that potential feature, I’d be interested to get others’ opinions on how I could approach the original problem I had at the start of this post: Yeah I think that would be great, although I seem to remember reading somewhere that this would be extremely complex with the way the prototype viewer has been built. However when viewing Figma prototypes, it seems like the text size is dependant on the size of the screen you’re viewing it on. If I use Chrome developer tools and play around with the width of the responsive viewport, text size isn’t increasing or decreasing.
This is where the problem arises - to my knowledge, text sizes should not scale proportionally like this, right? We can either:Ī) View it at 100% of the original size (since we’re viewing this on a 1440px wide screen, we would need to scroll horizontally in order to view the entire design, so this is not ideal)ī) Scale it down to fit our screen size, which means the entire design is scaled proportionally to suit our 1440px. In contrast, let’s say we design a responsive layout on a 1920px wide frame in Figma, then view it in prototype mode on a 1440px wide screen. So when a browser window is resized, although elements will move around, it should not affect the text size. This is similar to what we do when we set our constraints in Figma.
I could be wrong, and would gladly be corrected, but from my understanding real, coded web pages should behave responsively as a browser window is resized, they should not scale up or down proportionally. Not sure if I’ve missed something here, but this is still a problem. However, if I view the prototype and play around with the size of the browser window, it doesn’t act in the same way.
In Figma, I can play around with the frame size, and it will act in a responsive way. It’d be great if, when users are viewing the prototype in the browser, the design would behave in align with the responsive design you’ve built. HOWEVER, this means I have to change the size of each frame, and if you’re working with a prototype with lots of frames, this would take forever. This solves half the problem - if a customer asks to see the design in a different desktop size, I can simple resize the frame, and it will change in a responsive way, and there won’t be any fiddling around to do. I always take responsiveness into consideration, but I rarely took the time to properly set my constraints and grids, as I rarely had to demonstrate with my prototypes how the responsiveness would work. Thanks for the response, I’ve somehwat discovered a solution to this as I went down the rabbit hole of grids and responsive design.
0 kommentar(er)
