What screens want

Great read if you haven’t yet read it yet:
Frank Chimero : What screens want : http://frankchimero.com/what-screens-want/

web and interaction design are just as much children of filmmaking as they are of graphic design. Maybe even more so. After all, we both work on screens, and manage time, movement, and most importantly, change.

So what does all of this mean? I think the grain of screens has been there since the beginning. It’s not tied to an aesthetic. Screens don’t care what the horses look like. They just want them to move. They want the horses to change.

Designing for screens is managing that change. To put a finer head on it, the grain of screens is something I call flux—

and more

Movement, change, and animation are a lot more than ways to delight users: they are a functional method for design.

These examples are essentially animated wireframes, but extra detail isn’t needed. Designing how things change and move is enough for us to understand what they are and the relationships between them. You don’t need the heavy-handed metaphor, because the information is baked into the element’s behavior, not its aesthetics.

A designer’s work is not only about how the things look, but also their behaviors in response to interaction, and the adjustments they make between their fixed states. In fact, designing the way elements adapt and morph in the in-between moments is half of your work as a designer. You’re crafting the interstitials.

We’ve been more aware of this interstitial work in the past few years because of responsive design’s popularity and its resistance to fixed states. It’s a step in the right direction, but it has made work crazy frustrating.

Please read the full article: http://frankchimero.com/what-screens-want/

On Going Responsive (responding to Where to Start)

trent-walton-thumbI needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.

Longer On-Ramps Have Benefits

I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.

Design

It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.

Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.

CSS

All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.

Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.

Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.

Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.

I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.

Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.

When making the transition to building responsive websites, the hardest part can be getting started.

I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

via Where to Start | Trent Walton.

Style Tiles

Style Tiles are about designing a system or guide to style a website rather than full comps and mockups. They really come in handy when talking about Responsive Web Design since it frees the designer from having to think about different layouts (as much, it should already be addressed in the wireframe stage). The designer can then focus on thinking about styling the elements and setting rules for a system that will be followed throughout the rest of the site. I really like the thought that style tiles are for when mood boards are too vague and design comps are too precise. Though, It really makes me think about designing a style guide rather than designing a webpage. Then the developers building the website can follow the guide dictated by these style tiles and make simple future-friendly/object oriented/SMACSS/modular css (or sass/less if you prefer). This also leans towards the late trend of moving more of the web design process into the browser.

Ethan Marcotte refers to static comps during the responsive design process as a “catalog of assumptions” Style Tiles are the perfect complement to that catalog, whether it be in place of comps or to reinforce visual themes. Style Tiles don’t imply dimensions nor device; only that the design will be digital.

In addition to Style Tiles, “Component Style Guides” can help with carrying a particular style through specific functionality without designing full web “pages.” These guides are very helpful for responsive designs across a wide number of devices and for implementing design systems for a CMS platform.

Develop a design system rather than designing fixed-width pages.

via Style Tiles.

I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what process are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets shook up and flipped on it’s head.

How do you see style tiles benefiting your process? Have you used style tiles in a project?

Adding Viewport Meta Tag via WordPress Theme Functions

Add the viewport meta tag with a WordPress hook via your theme’s functions file to allow responsive web design and mobile-friendly themes

meta-viewport-thumbWith all the responsive web design activity over the past few years, I hope that any theme or site we work on we’re able to make responsive to some extent. An important part of making a web site responsive is adding a viewport meta tag to your html. Without explicitly stating our viewport, the mobile browsers will scale down the website to fit into their ‘viewport’. This is a good thing, since if it was a full website and the browser didn’t scale it down, you’d only see the top left corner, or some small section of the site. This viewport was introduced by apple for iOS and has spread to most mobile devices since. There are viewport properties or parameters we can set with this meta tag such as width and scale and can even use some device aware variables (like ‘device-width’) to set these values.

A WordPress Meta Viewport Hook

I usually end up using the following hook to add a viewport meta tag to my head in wordpress. I set the viewport width to match the width of the device. Then I set the initial scale to 1. Some go and set the maximum-scale to 1 as well. This would prevent users from zooming in on your site. I advocate that we should allow users to zoom if they wish since it is a gesture they may be used to and may still need (no matter how nice your RWD is, they may need/want to see it bigger). RWD is about giving the user a better layout for whatever device they are on, not restricting how they view it.

[cc lang=”php”]
/////////////////////////////////////////////////////////////////////////////////
// Add viewport meta tag to head
//
function viewport_meta() {
?>

Web vs Mobile – For The User

I agree with this idea from Ryan that the web has big advantages. I am constantly hearing stats and projections that Mobile is taking over. And sure, I agree that I use my phone to browse more sites, but when it comes down to it I’m just casually browsing – not working. I love the post he’s links in the first line: Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first.

Vibhu details that he’s done the mobile startup thing and has learned from the complications. He explains that most of these have been solved in the desktop browser already and a lot of it relates to usability.

Another big point is that mobile apps must be installed (actually they must be found, installed, opened and setup), whereas a web app can be as simple as a link- click, and then the user is already using it. Adoption is much easier on the web.

And even another point is updates and testing and whatnot. YOu can do various tests and even update the whole app relatively fast on the web. There is the one version to support – the live one. While with apps, you can’t do much in the arena of testing and updating is sluggish plus it relies on the user to update (some don’t know how to update and even less care).

I think a web app that is mobile friendly wins. You can give mobile users access, but they aren’t stuck on mobile. They can use it anywhere. While so many are talking about responsive design and produce sites that are device agnostic mobile apps are very device centric.

I’m a fan/advocate of future friendly at least, and strive for future proof (although I understand that’s near impossible). I also hold that there is ONE web and mobile myths.

Web versus Native Economics and User Adoption | Ryan Stewart – Mountaineer Coding.

Responsive Image Dispute and Tourists – Analogy

Jason explains the root of the problem and why no one has been able to devise a solution that makes everyone happy yet. The browsers (in their awesome drive to make browsing faster) are prefetching images and developers want to only use one image based on criteria the browser doesn't know until the layout is calculated.

Echoing some other thoughts and comments I’ve read, but writing it out so I can grasp the details.

What about the updated image format that by default only loads the smallest embedded size. Then once the browser finishes layout and knows what size the image is rendered at (and also resolution) it can update the request for an image that’s embedded in the file that best fits or matches the requirements. This by default would load the smaller part of the file and display something for the prefetching browsers and “enhance” the image as it can. I can see photo editing software like photoshop (if that’s your poison of choice) to have extra settings for creating this new image type – resolutions to include, breakpoints to be set, etc. The we aren’t managing multiple images – it’d be one file that included all the desired sizes. Very much like progressive images and old gifs. Mobile browsers and old fallback browsers would display the smallest (or first) specified img (although this could also be determined in the meta data of the file – which subimg would be the default). This may end up in users with high BW/large screens to download two subimages rather than only the high res image, but remember that the first one would be much smaller in size and if they can handle it the big one the big and smallest together shouldn’t be too heavy. The page would also load very fast as the first image to load would be much faster than loading the large image initially whatever the bandwidth. Then browsers and image compression engineers can get together and figure out a communication method between the browsers and images via metadata and requests while developers/designers can just choose the proper settings as they save the files (or software can have standard-best-practice defaults) and focus on creating websites rather than having to understand how all browsers and devices will load and present content.

Also – Amen to @Brian Gallagher: “Who are we to make the distinction between what the users NEEDS to see, and what the user WANTS to see?”

Embedded Link

» The real conflict behind and @srcset Cloud Four Blog
Some people do a lot of research before they travel. They read guidebooks. They like to know what they are going to do before they get there. Others want to experience the new place and let the serend…

Img Set?

Great article at a list apart discusing the state of the industry regarding responsive images. This picks apart the set attribute of the img element from a surprisingly objective view coming from someone so close to the picture element. Insightful discussion about the principle behind the proposals than the actual solution too. If the working group wants the community to be involved and then ignores it in favor of "their own" biased unproven/untested ideas.

Embedded Link

A List Apart: Articles: Responsive Images and Web Standards at the Turning Point
The goal of a “responsive images” solution is to deliver images optimized for the end user's context, rather than serving the largest potentially necessary image to everyone. Unfortunately, this h…

Google Embracing Responsive Web Design

Google showcases a few of their own sites that have become responsive here in their google webmaster blog post. They explain the need they had from watching their analytics and walkthrough some other decision made in going responsive!

Embedded Link

Responsive design – harnessing the power of media queries
Webmaster Level: Intermediate / Advanced

We love data, and spend a lot of time monitoring the analytics on our websites. Any web developer doing the same will have noticed the increase in traffic from mobile devices of late. Over the past year we’ve seen many key sites garner a significant percentage of pageviews from smartphones and tablets. These represent large numbers of visitors, with sophisticated browsers which support the latest HTML, CSS, and JavaScript, but which also have limited …

Boston Globe Responsive Process Interview w Scott Jehl

Some good insight into the thought process behind the "famous" responsive web (re)design for the Boston Globe. I think the discussions about the fallbacks and technical challenges very important. Sites should be optimized to have a low overhead and build with the worst oldest devices in mind as well as the latest and best.

Embedded Link

Scott Jehl on the responsive Boston Globe site | Interview | .net magazine
Opera’s Bruce Lawson talks to Scott Jehl of The Filament Group about developing the highly-regarded and responsive website for The Boston Globe