These days, I have to use the term “app bulders” instead of “front-end developers” because most front-end developers aren’t working on the front-end anymore.
One result is that I’m not part of any dev community. These days, I stay with the following communities:
UX
Information Architecture (IA) or
Accessibility
because they have something of value that I can use across any tech stack.
The thing I worry about is that developers like me are a) being pushed to non-coding/programming roles or b) pushed out of tech altogether.
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
Experience
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.
In finally starting to write about responsive design, I realize that there’s a trap. I’ve known about RWD since 2010 with An List Apart’s article Responsive Web Design. So by now, it’s something that should be commonplace and a regular process.
Then again, if that was true, I wouldn’t have written the blog post that this new lecture is based on.
The only true wisdom is in knowing you know nothing. – Socrates
In the next couple of months, I will know more about RWD than I did before as a front-end developer. And from that, more questions about it. But it’s an interesting trip just to see what else can be found along the way :-).
That said, a couple of months ago, I was looking a PBS/American Masters biography on architect Eero Saarinen. I followed up with a few lectures on him and his work on YouTube. There was a quote that stood out:
Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan. – Eero Saarinen
Sounds like a way to think about responsive design.
Well, while making the first steps in writing my next lecture about responsive design, I came upon a Tweeter discussion last week. Ethan Marcotte, author/mastermind behind RWD, talked about container queries and his support for them. Very interesting read.
I’ve heard about container queries before during the last year or two. But I decided to read this article with much more intent because of topic relevance.
To describe container queries, you need to think about web apps/sites as a system. Changes via media queries are macro, that is, applied to the whole system. It’s what we been doing for years. We build the base (preferable mobile first but any sort of initial state we want) and apply changes at certain breakpoints. So when we write the following media queries:
@media (global conditions/breakpoints #1) {
… some changes here...
}
@media (global conditions/breakpoints #2) {
… some changes here...
}
etc..
what we are doing is
Even though these changes are to certain areas such as footer/header/etc.., these are applied as if the whole app is one big container.
But with container queries, we are applying changes at the micro level. Instead of the previous example, we are applying changes to local containers. The queries will be influenced by the container conditions, not by the overall viewport. So now instead of the previous model, we have the following:
and with each part
we are applying changes on the local level/containers. These media queries are not global and [could] be different from other containers. You could have a combination of global and local conditions in this system as well (don’t know if this would happen but you never know):
As for the talk/lecture, nothing had really changed. The main focus of the talk is the “why’s” of what we do in terms of RWD. However, it is obviously something to think about further.
About a year ago, I wrote a blog post about responsive design. But instead of the usual techniques, I decided to describe it with three terms – Constraints, Content, and Context.
A year later, these three terms are more relevant than ever, especially Context. I am thinking about re-editing the post for brevity but the main points will remain.
Over the past few years, many of you have heard of the term responsive design. Basically, it’s an approach where we build web apps and websites to be usable across a wide range of devices, from mobile phones to laptops.
But instead of tricks, techniques, and more code (there are plenty of basic responsive design tutorial out there), I want to go in a different direction. Instead of asking ’how do we do this?’, I want to ask ’why do we do this?’.
Here at Innate, we recently designed our Accessibility Services website with responsive principles. Instead of answering basic questions, we want to delve into the types of problems we encountered that influenced how the design developed, as these are common problems for all responsive sites. It doesn’t matter if it was one person or a company like Innate; when we all build a responsive site, we are solving these problems at every step of the way.
So, let’s start solving some of these problems.
The Three ’C’s
Responsive design is like solving a puzzle. When someone asks me to describe it, I tell them the following three words: constraints, context, and content.
For brevity, I like to call them the three ’C’s. If I were to give them descriptions:
Constraints –the conditions, restrictions, and parameters for the given problem
Context – the situations or circumstances in which you have to work on the problem
Content – the way in which information is displayed for the given problem
These three ‘C’s are needed in varying amounts when building a responsive site – sometimes, some more than others. But together these are necessary to solve responsive problems. The better the mix of each piece, the better the product. Each part contributes to the whole product.
Referring to the above graphic, think of Content as water. Constraints as a container. Depending on the amount of content, you will choose the appropriate constraints to display this content. If you have a long article, the viewing on a phone will require more scrolling than that of a wide screen monitor.
With Context, referring back to the water analogy, our problem can change depending on circumstances or environment. At room temperature, water is liquid. But change the temperature and we get either ice or steam. With design, that means adjusting our design to meet these changes.
Constraints
Like all problems, we need constraints to get the best solutions and designs. Finding constraints allow us to make good assumptions about how to solve a problem. Let’s start by making a few right now.
The most obvious problem in responsive design is conforming to the screen sizes of numerous devices. How do we get a website or app to fit in the screen width of a phone, tablet, and laptop? When we consider the number of devices on the market, we see there is a large range of screen sizes. But by finding constraints, you narrow down the problem, making it manageable.
What is our minimum screen size? Right now we’re not thinking about smart watches (at least not for the purpose of this demonstration), so let’s stop at mobile phones. Apple has pretty consistent design parameters and the classic iPhone has a minimum of 320 px, which is under the range of recent larger models. This is the stopping point on the small end of our constraints scale.
On the large end, we are not considering TVs (at least not for the purpose of this demonstration), so we need an upper bounds for desktop monitors or laptops. Right now, 1400 px is a nice place to put an upper-limit constraint.
Why these numbers? Global stats are a start but the best statistics are a combination of site logs and Google Analytics.
In addition to the extremes, we have a few other number to consider, such as ones for laptops (1024 px) and iPads (786 px). These aren’t necessarily standard, but they are starting points. During the course of building, you will find out the other two parameters – context and content – will affect the constraints. For example, the footer may not look right somewhere between 320 px and 768 px; if this is the case, a new constraint will need to be added. You can really have as many constraints as you want, but the best motto (and the one with less headaches) is the fewer constraints, the better.
Constraints are like conditions, though. They don’t need to be screen size; there are others as well, such as orientations (vertical or horizontal), resolution and pixel density, etc. Other constraints could come from areas beyond your own work (product requirements, project specifications, etc.).
No matter which constraints you are dealing with, they can be influenced by context and content. Let’s look at how this works.
Learn how to adapt to different screen sizes from this informative Intel tutorial:
Context
As you’ve seen, constraints can help define a problem and lead to a solution, but context informs these constraints. Oxford Dictionary defines ‘content’ as:
The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.
For example, taking one device (a tablet), we can drill down in the Analytics data to discover Insights that drive content in learning lessons such as : 1) when users read tablets depends on the time of day at home or work, 2) tablet users are using their device in landscape instead of portrait mode or 3) whether the devices used for certain tasks are Android or Apple, and screen size/viewport.
But more than just statistics, it comes down to research and observation. Taking a device (there are device labs you can check out) and learning about how it handles and comparing with other devices. The experience gained influences how we design/build responsive sites and apps.
Why does this matter? By using context, we can refine our solution and design to better fit a solution to the problem we need to solve. As a consequence, context will define each of our constraints to accommodate user behavior.
Yes, it feels time-consuming, but it’s worth it to create a great user experience. There is still a third element that must be considered, though: content.
Content
At its simplest, content it the stuff that’s on the page. However, with the ever-changing layouts from responsive design, content must become more sophisticated.
In thinking about content, we have to remind ourselves that the core concept of the Web is information.
With the advent of responsive design, we now have a process where we can create websites and apps that can carry the nearly same information without device constraints. However, constraints and context shapes how we view content. It’s not a matter of just hiding or showing words. It becomes a matter of determining what content has the highest priority.
With changes in layout and the concept of the fold largely negated, we needed to rethink how we place content on a screen. Or I should say, we need to reconsider old ideas about placing content on a screen.
For example, the non-responsive NASPGHAN site has complex, deep navigation. Mentally, you would think that the code for this would come at the beginning of the page. However, because the navigation is so large, it would take a vast amount of space before the content the user wants to read. In this case, code for the navigation is written at the bottom with its position displayed via CSS at the top. If you were to use a screen reader/non-visual tool, you could get to the content readily but still get to the navigation via skip/anchor links.
When creating content, keep a mobile-first mantra. Design for the mobile site first and let the constraints of a small environment help select the most important content. Then, as the user gains more real estate or features, give them the extra content. Essentially, just let your constraint and context will be a guide in your content selection.
Prioritizing content creates a flow of information along the screen which aids in how layouts are structured. This, in turn, allows you to adjust content for better solutions to constraints. When creating content for responsive design, the best practices are:
Prioritization – determining what content gets the highest importance
Distribution – determining which content is important enough to cause readers to scroll down.
A Collaborative Art
The most important thing that I hope to stress is that responsive design is not a singular effort. As in the jigsaw puzzle at the beginning of this blog post, each project is a combination of the three ‘C’s. A little more content in this project, a little more context in the other. Responsive design is a process that involves many processes and, in some cases, many people to bring it together.
(Originally published on CDG Interactive/Innate blog)
It’s back-to-school time, so here’s a pop quiz on today’s new buzz word: HTML5.
What is it?
Should I care?
Should I worry?
Answers: 1) see below, 2) yes, 3) not yet but soon enough
So, now that you’ve taken the quiz, may I suggest a textbook? Specifically, HTML5 for Web Designers by Jeremy Keith.
Now, I’ve known about HTML5 for a while (and some of the preliminary work around it). But when I heard about this book, I was curious how much more information could I gleam from its pages about HTML5. Judging by the title, I thought that it would be just an introductory text for web designers (not necessarily for experienced web developers).
But, I took a chance. I ordered a copy and waited. And the package arrived.
And when I first opened the box and held the book, the first thing that popped into my head was “Wow, this is a pamphlet!”
OK, not a pamphlet but a brief, concise book (under 100 pages).
However, from the very first page, it was evident that conciseness is the intent of the author. What Jeremy Keith does, with good effect, is to give the reader a brief synposis about HTML5, bypassing W3C language. (Alert: W3C documents are so precise, they could turn a cake recipe into a DVD instruction manual.)
Of course, he starts off by answering what HTML5 is and is not–not a new version, but a much-needed upgrade for building future web applications. This means it not only adds/removes features, but also adds more semantic meanings attached to the current set of tags (important for Internet devices like mobile phone or screen readers.)
For the remainder of the book, Keith highlights some important features and gives bits of advice for the newly introduced. The best thing is that he engages the reader enough to encourage further study in HTML5, which is not easy. This book could have easily become just another five pound dictionary. Of course, he remarks that there are others more experienced with this and points to some online resources. (As I am writing this, a number of new HTML5 books have popped up in the stores.)
In the end, the author does what he planned out to do – give a nice gentle push in the right direction towards HTML5.
Now, if you don’t mind. I have a list of HTML5 books to read.