Category: Designer

Adaptive Content – Think differently about your content

This article from Webdesigner Depot makes some very good points regarding how content is handled in a responsive, mobile-first web design. One of the key ideas are that websites no longer consist of “pages,” but instead consist of a series of object that are assembled into a page. The article is primarily focused on WordPress, but the concept is transferable to most any CMS you want to use.

http://www.webdesignerdepot.com/2013/04/adaptive-content-with-wordpress/

Role of a designer in Responsive web design

The mobile era is here to stay and the role of the designer in responsive web design workflow is even more important. As a designer, our role is to aid in the direction of the content, provide the vision for the design and present the content in the most effective manner at each potential screen size using a responsive site.

Everything’s changing

For a (frequently hilarious) gallery of mobile fail, the appropriately-named WTF Mobile Web site is a good way to waste an hour (and maybe learn from someone else’s mistakes at the same time). Mostly it’s a simple blog of screenshots from websites or apps that just don’t handle mobile devices very well. Check it out.

However, buried in the “About” page for this little blog is a very perceptive summary of the challenges that mobile devices create for web designers:

The problem isn?t any one person. The problem is that we?ve all been doing this thing called Making a Website for a long time in a particular way. And now everything is changing. Sure some developers are resistant to learning new things, but most developers are interested, excited and willing. But this isn?t a problem that you can fix by just switching out which bit of code to use. It?s bigger than that. Content strategy, design, business all have to change. The fundamental way in which people work together to plan and coordinate the creation of a website has to change. It?s not easy to go into work one day and say to a big team, ?Hey, uh, we need to restructure our design process and completely change what we are doing with our mobile web strategy. Uh, why? Yeah, just because.?

From the What’s Up With This Site? page on WTF Mobile Web.

Shame on you…for creating all of those hacks!

Hello everyone. ?My name is Xavier and I sometimes … add hacks to my CSS. I thought I should be the first to admit this. You don’t do this? Are you sure? Well, if you have ever used !important or overflow:hidden to “fix” a quick problem to get the site out of the door, then yes, you hacked your CSS instead of figuring out the problem.

I found this article?by Harry Roberts and thought it quite funny, and convicting and true at the same time. He suggests separating our quick, dirty and tacky CSS into a new file named “shame.css” instead of keeping it in our well-defined CSS. ?He states:

By putting your bodges, hacks and quick-fixes in their own file you do a few things:

  1. You make them stick out like a sore thumb.
  2. You keep your ?main? codebase clean.
  3. You make developers aware that their hacks are made very visible.
  4. You make them easier to isolate and fix.
  5. $ git blame shame.css.

I think I will do this on my next project.

Source:?http://csswizardry.com/2013/04/shame-css/

If it doesn?t work on mobile, it doesn?t work.

A developer on the NPR apps team posted a great article about building a fast, stable news webpage on a tight budget. While the article itself is really interesting and worth a read for it’s own sake, one part in particular jumped out at me:

If it doesn?t work on mobile, it doesn?t work.?Most of our work averages 10 to 20 percent mobile traffic. But for our?elections app, 50 percent of users visited our?Big Board?on their phone. (And it wasn?t even responsive!) Moral of the stats: A good mobile experience is absolutely necessary.

From the NPR News Apps blog.

If it doesn’t work on mobile, it doesn’t work.

A developer on the NPR apps team posted a great article about building a fast, stable news webpage on a tight budget. While the article itself is really interesting and worth a read for it’s own sake, one part in particular jumped out at me:

If it doesn’t work on mobile, it doesn’t work. Most of our work averages 10 to 20 percent mobile traffic. But for our elections app, 50 percent of users visited our Big Board on their phone. (And it wasn’t even responsive!) Moral of the stats: A good mobile experience is absolutely necessary.

From the NPR News Apps blog.

Why Page Weight Matters

Here is a fascinating story about a web developer at YouTube, and their quest (code named “Feather”) to reduce the overall download sizes of their video pages. What seems at first to be a fairly straightforward exercise in bandwidth reduction took a surprising turn, and ends up having a surprising lesson regarding mobile first design:

After a week of data collection, the numbers came back? and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.

I won’t spoil the ending for you, because what they found is rather surprising. I’m sure you’ll be able to draw the implications regarding mobile design.

Responsive Web Development Resources

Beginning responsive web design can appear to be a daunting task but, that is not necessarily true. With the right direction and inspiration, creating a responsive website is easier than you think. We have compiled a list of our favorite articles and resources that have assisted us in exploring how to get started, develop, and explain the responsive design process and?methodology.

Feature Detection

In the early days of the Web, sites had small icons indicating the web browser they were specifically built to serve, such as “Works Best in Internet Explorer” or “Built for Netscape Navigator.” Because of the relatively low number of browsers, building unique versions of a site for each individual browser was possible without worrying about unknown devices or operating systems.

Today, the Internet is accessible from a countless list of devices and computers with an vast combination of operating systems, browser and hardware capabilities. Rather than write snippets of code that detect specific browser/system combinations (e.g., iPhone running Safari, Windows running Firefox), the preferred method of enabling more complex features is through feature detection: small scripts that detect whether a browser or device is able to use a certain feature, regardless of its specific setup.