New devices with varying dimensions are released relatively frequently and in theory should just need to be validated with our responsive approach with the potential for relatively minor tweaks. In this way, we don’t need to know a specific measure for a given device (though at a bug-fix or minor improvement level this can be handy), we have a working assumption from whatever we define as a narrow viewport to the widest our designs should support, it should work well no matter what you use. You might often hear people speak critically of resizing the browser window when working responsively as that not being a behavior your users would do…but that test gives us confidence that whatever viewport they’re using, our layout should be appropriate. With snap mode on Windows and multitasking on iPadOS we have a great real-world example of how the width of viewport doesn’t correlate to a specific device type or interaction model. Because this is the web and not a native app, having a narrow viewport does not mean it is a mobile device, just that it may be as being wider doesn’t mean we’re targeting tablets or desktop devices, just that the viewport is wider. One of the main issues is that our design tools don’t work in the same way as the canvas we code for: the browser. This is where I’ve always had an issue with device-based breakpoints – they’re circumstantial at best and don’t allow us to get the most out of the space we have for whatever device you use. Without real-world constraints, we can say a space of 320px wide is ‘mobile’ and most people would understand the implications of a device like that. In our design tools, we need some measures to work with some size of artboard or frame to design on. For example, assuming that it’s possible a user may have touch capabilities and so having larger hit areas will work for everyone, attempting to make a change based on whether it appears the user’s device has touch interaction may be unnecessary overhead and not actually be good for the user. Device detection itself isn’t a great tool either – the question we need to ask ourselves is if the user’s browser or device is capable of X, how would that change our design? Much of the time making these things our default can make a site or app better for everyone. Likewise, we can’t make assumptions about input types whether something is touch-based or not purely by viewport width alone. You change the orientation of your phone and going by viewport width it would be reported potentially as being in a ‘tablet-type’ size unless we also check for orientation. What is important to note is that it’s no more than circumstantial, a viewport of a given width tends to be found on this kind of device but not exclusively. Because of this, the language we use becomes a bit flaky going by viewport width alone means being narrow means it might be a mobile, being wider might be a tablet and being wider still might mean it’s a desktop. These breakpoints (values we use with media queries) that we code with can themselves be divisive: while they are capable of doing many things these days, we typically refer to the width of the viewport…the part of your browser that renders a website. In CSS we use media queries to describe when we want to step in and design a change. This difference between design tools and the browser we’re designing for can lead to a few problems, the first being deciding on how we describe change in our layouts. Challenges with creating responsive interfaces It’s this space where as great as design tools are, we don’t have parity with the abilities of the platform we’re designing for so there is still an element of translation. All these years later we still have a difference that can make working in this responsive way difficult: the web is innately fluid but design tools are not.Īs great as componentization (the grouping of UI elements in a discrete package) is in some tools, along with some great layout options that allow for flexibility now, we still have a mismatch between the static artboards or frames we design with and the more fluid and dynamic nature of a web browser. CSS itself has brought forth flexbox and grid which means we can do away with elaborate hacks and have a real sense of control over sometimes quite complex layouts in a way that we never have before. Luke Wroblewski’s ‘mobile first’ became common parlance for starting with a smaller implementation and scaling up for larger screens.įrom that, fluid typography, the element, and all kinds of more flexible ways of presenting our work have evolved. Ethan Marcotte’s simple recipe of fluid grids, fluid images, and media queries (from way back in 2010 and the following book) spurred us as creators of the web to really consider how we use space across many device types. For the uninitiated, responsive web design is the way that we enable a single layout to work for anything that can use the web.
0 Comments
Leave a Reply. |