Email
Like
Liked ×
Save
Contact Me
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
+
Loading

+ Follow

Responsive Web Design: One Size No Longer Fits All

by Perficient, Inc.

2,150 views

Designing to allow an ever-increasing number of devices to access your website or web application is a game you can never win. There is arguably little business benefit to targeting less-widely used devices, yet web-accessible smartphones that aren't iPhones constitute a large group of users that is costly to ignore.

Responsive Web Design is a new approach to the design and execution of websites and web applications that offers a way to cater to a much wider array of users and devices than would be possible otherwise. Through the use of modern web standards and a thorough execution plan it is possible to create attractive, brand-aware user experiences that work across a wide range of devices - feature phones, smartphones, tablets, netbooks, laptops and desktop computers - without requiring expensive device-centric development.
This slideshow covers:
• Costs and benefits of Responsive Web Design
• Examples of large-scale responsive websites currently deployed
• When to consider a responsive approach to your project
• The skills your team should have, and the techniques they should be using, when designing responsively

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

5 Embeds 507

http://www.perficient.com	500
http://perficientauth	4
http://us-w1.rockmelt.com	1
http://www.twylah.com	1
http://perficientauth.perficient.com	1

Statistics

Likes: 1
Downloads: 29
Comments: 0
Embed Views: 507
Views on SlideShare: 1,643
Total Views: 2,150

Hi folks! I’m Martin Ridgway, a Lead User Experience Consultant for Perficient, in our Experience Design Practice, or Perficient XD as we’re more snappily known. I’ve been with Perficient since November 2011, and have been in the web design world in various capacities including user experience designer, front-end web developer, and interactive manager for more than 10 years.
So today I’m going to spend a little while talking to you guys, and here’s what we’re going to discuss:First of all, we’ll look at the state of the Web today, and where it’s headed in the next few years.Then, we’ll talk about what we can do, and where Responsive Web Design fits into that. We’ll also talk about what Responsive Web Design actually is.Next, I’ll walk you through a few examples.Then we’ll talk about a couple of drawbacks and criticisms to the technique.Following right on from that I’ll give you the best business case there is for using Responsive Web Design.Finally, we’ll get into some of the nitty gritty – the three elements that make up Responsive Web Design, and how they all come together to create a seamless experience across the board.And as a bonus, you might get to see a few more of these kind of images along the way. We’ve got a lot to cover, so let’s begin!
There’s a change coming, and it’s a big one…in fact, the change has already begun…
Day by day, the number of devices, platforms and browsers that need to work with your site grows – Jeffrey VeenVeen is a founding partner of Adaptive Path. He’s worked for Google, and is the founder of Typekit, an easy solution to use real fonts on the Web.Which is a long way of saying, this guy’s been around the block a few times, and he knows whereof he speaks.
There was a time – believe it or not - when the only device a website was accessed upon was a browser on a desktop computer. Life was simple.
Today the web development landscape today looks a little something like this. But with more devices. And probably a table or two to hold them up.And each of those devices interacting with your website does so in a slightly different way. Maybe it’s a different resolution, maybe it’s a different touch interface, with different gestures. Maybe the device is running an older version of an operating system because it can’t be upgraded easily by the average consumer. Whatever the reason, users now access websites from anywhere, on every device imaginable. And most of us – even the least technologically savvy amongst us in the Western world - have at least two of them!
As of February 2012:There are 1.2 billion mobile Web users worldwide, based on the latest stats for active mobile-broadband subscriptions worldwide; Asia is the top regionMobile devices account for 8.49 percent of global Website hits.Many mobile Web users are mobile-only. In other words they don’t use (or very rarely use) a desktop or a laptop to access the Web. Even in the US, 25 percent of mobile Web users are mobile-only.And, perhaps more importantly, the landscape is continuing to shift towards the mobile space. By 2015, paying by mobile (what’s known as m-payments) will be worth over 1 trillion dollars. Purchasing digital goods is the largest segment in that market.Mobile commerce will reach 119 billion dollars worldwide, with US mobile commerce worth 31 billion dollars.
I’m sure you’ve browsed many websites on your smartphones. You go to a site that isn’t “optimized for mobile”, and you spend a few seconds pinch-zooming to make the text even remotely readable. And then, if you’re unlucky, you navigate to another page on the same site and the text resets to the unreadably small again! How frustrating!There has to be a better way. And there is!
We could do this.
Except that would be silly and expensive.
So, what can we do instead?
Remember this quote? I was disingenuous before, because I only showed you half of it.“Day by day, the number of devices, platforms and browsers that need to work with your site grows. Responsive Web Design represents a fundamental shift in how we’ll build websites for the decade to come.”Yeah, decade. That’s a loooooong time in Web terms. A decade ago Internet Explorer 6 was the most popular browser in the world, and Facebook hadn’t been invented. So if we’re talking about a technique that can change the way we build websites for a whole decade, that’s gotta be some pretty serious technology, right?
Which leads us to…
Responsive Web Design.This graphic represents one website on three screens – assume a desktop computer, an iPad and an iPhone.The grey blocks are different content types – perhaps a logo in the top left, search in the top right. A couple of paragraphs of information, and then call to action blocks.Notice how the widths of the grey blocks are adapting to the device? It’s especially noticeable for the darker call to action blocks. They shrink, the margin between them contracts (but remains proportional), and when the screen width is simply too small to comfortably show three, the website adapts and shows the first two. Maybe the third is hidden, or moved down the page. We can’t infer that from this graphic. But what we can infer is that whatever decision was made with regard to that third call to action block was made collaboratively with the client.
Here’s another example. One website, many screens.The laptop shows a usage we often ignore – those of us who don’t maximize our browsers to 100% of the screen width. I know I don’t. And I’m hardly alone. It irritates me no end when I have to stretch my browser window to get rid of the horizontal scrollbar. Why can’t the site adapt to my slightly different display resolution? Because – in those cases - it wasn’t designed responsively!
So, why do this?One solution to rule them all – Let’s face it. A single version of a website that works on every screen width; on every device? That’s pretty awesome right there. Do we really need more reasons than that? Oh, we do…fine. Let’s talk maintainability, then. One website means one set of code to maintain moving forward. No more worrying about your iPhone site, and your Android site, and your fallback site, etc etc. One set of code, one set of rules, one website.One codebase means one set of metrics for all users – Collecting and collating metrics is hard enough. No-one wants to do it multiple times over to achieve an overall picture. With a single website designed responsively there’s one set of metrics, broken down by device, or screen size, or whatever else your metrics package measures. Easy to plot, easy to collate, and easy to follow through.Finally, a responsive design allows for greater consistency of your brand across all experiences – No-one wants a brand to break down. Ever. Making sure all possible devices access a branded experience that’s tailored to them- and to the millions of other potential users using devices that are very similar to their own - is vital to engender greater brand trust and loyalty.Now, how to go about this. First of all, be pragmatic in your approach. You can be as gung-ho as you like about responsive web design – and believe me, I encourage your gungedness, and indeed your ho-ing – but if your traffic logs are showing that everybody accessing your website on a tablet device is doing so on an iPad? Well, target one of your responsive breakpoints (and we’ll get to what that means shortly) to the iPad!Test your CURRENT site on those devices you’ve determined are important TO YOUR SITE and determine where the experience breaks down. And THEN create an action plan to address the common issues. It may be that your action plan is timed to coincide with a website redesign (that would be very handy!), but it doesn’t have to. Responsive elements CAN be added in after the fact.But, what are a few examples of those common issues? Well, on your test device take note of things like:Content that is only accessible when a user hovers over something (remember, there’s no such thing as hover on a touch device)Controls that are too small to manipulate on touch screensPopup (or modal) windows that are unusable on small screensA lot of heavy graphics and mediaAnd then repeat those steps as often as necessary on the devices you’ve determined are important to you.
So, you want to see this new hotness. OK. I’ve got 4 great examples of responsive design to show you. In order to make the screenshots as clear as possible, I’ve deliberately left out the mobile view – it’s just a little too small in a presentation setting to be able to see clearly - and instead I’ve focused on the desktop and tablet experiences. In every case in the next 4 slides, the tablet view is to the left, and the desktop view is on the right.
The Boston Globe is the current poster-child for responsive web design. The site launched late last year to a huge fanfare in the web community. The development team successfully integrated techniques likeresponsive images (an image that shrinks to accommodate the content), andincorporating advertising blocks within the different layouts. Columns shift, type changes size slightly, and navigation adapts to accommodate the smaller screen size. But note that the site is fundamentally the same on both platforms. The layout has simply been adapted.
One of the earliest examples of responsive web design, St Paul’s School’s website started life as a desktop-only fixed-width site. It was then retro-fitted to be responsive at a later date. This approach can be problematic in some cases, but in this case it was a successful retro-fit, and the responsive elements (such as the learn more box on the right hand side of the desktop layout, and the latest news section) adapt nicely on smaller screens.As as aside, I really do recommend taking the opposite approach to St. Paul’s School wherever possible. Where they started with the desktop view and moved downwards to mobile, it’s really a much better idea – when possible – to start with the mobile view and move up. We’ll get into the specifics of why that’s the case a little later.
The new version of ASU’s website launched in late 2011. Notice the navigation flowing seamlessly to two rows, and the event calendar and far right column dropping below the content. Also, the three education news posts that were a column at desktop resolution, are now in a row at tablet resolution.
So we’ve talked about the problem. We’ve looked at what Responsive Web Design is, and we’ve checked out a few examples. Now, let’s see if there are any drawbacks to this approach.
That was a quick section, right?Well, ok. There are a few issues. Nothing comes for free, and a new technique like this is bound to have its share of potential problems. Many of them can be mitigated with careful planning, but be aware: Not every website is a candidate for responsive web design. The fact is, many times the objectives of the desktop version of a website just aren’t the same as those of the mobile version.
Think about Yelp.com for example. If I’m on the go, I use Yelp to look for nearby restaurants, bars, etc. I’m not looking to leave a review (in all likelihood), and I’m probably looking in my local area. So the mobile version of the site gives me a stripped down view, it uses location services to know where I am, and it presents that information to me quickly and cleanly. If I want to view the full site from my mobile device I can – the option to do so is as the bottom of the screen – but 9 times out of 10 the mobile version suits me just fine.Contrast that with the desktop version of the site. Much more emphasis on leaving reviews, of browsing, and of choosing the metropolitan area I want to focus on. Two different experiences, and dissimilar enough that responsive design wouldn’t do it justice.Oh, and by the way, if you’re ever in Houston, go to Lankford Grocery. Best hamburgers in town. And the Thursday lunch special is chicken fried steak. To die for.Now, Yelp’s an extreme example. I happen to believe the vast majority of websites would benefit from a responsive design approach. But, let’s look at some problems that approach faces…
There are 3 popular reasons given not to choose responsive web design. I categorize these as slightly different to the Yelp example, because whereas I believe that is a justifiable reason to develop a different solution based on the needs of the user, the criticisms on this page are – by and large – not a reason NOT to design responsively.Load time – A popular misconception of responsive web design is this: “When I load a responsive site, I’m essentially loading the desktop version of the website, and then hiding or resizing items that I either don’t want to see, or deem to be less important than on the desktop version.” Though technically true, this is one of those “drawbacks” that isn’t a drawback at all, as the industry has already moved on. What we’re doing now is something called “mobile first” – a subset of responsive design that builds up from the mobile version, as opposed to building the desktop version and scaling down. So what does that mean for load times? Well, now a mobile device will only ever download what it needs and will ignore (most) everything else, meaning the website is snappy and loads quickly. A desktop browser accessing the site will download what it needs, so it’s also snappy. Everyone’s happy!Integration with 3rd party apps – This could be a sticking point. Let’s take advertising blocks as an example. There are standard ad sizes, set in pixels, that are universally understood on the Web. But a responsive web design recommends a designer to think outside of the context of pixels. So what to do? The ads can be shrunk, just like any responsive image, but what about when there’s a block of 4 ads in a grid on a desktop site? How does that translate to the mobile view of the site? Do we linearize the ads? If so, are the advertisers who are paying for the spots aware that their ads are now further away from the top of the page (still a concern for advertisers)? Communication is vital in these kinds of scenarios.Then there’s the biggest obstacle of all…I’m not going to lie to you guys. It takes more effort, more time, and more money to design a site responsively than to build just a fixed-width, standard desktop website, because building a responsive website is a slightly more complex endeavor than not.
But here’s the thing…
It’s much cheaper to design and build a responsive website than it is to design and build separate websites for desktop, iPad and iPhone. And we’re only talking about targeting 3 devices in total here! What about all those other devices that are out there? Start factoring those in, and suddenly responsive web design becomes a very attractive option.
Now, just like with every new technique, there are going to be detractors. And responsive web design has gained one very big detractor indeed…
On April 10, 2012 Jakob Nielsen – one of the pioneers of web usability, and a leading figure in the field of Experience Design – published an article about mobile vs desktop sites. In it, he issued a proclamation that was wrong in almost every way. He said:
“Good mobile user experience requires a different design than what's needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”His article goes on to say that what we should be doing is providing not just separate websites, but cut-down content for mobile users, and – worse still! – auto-directs to mobile sites. When I say auto-directs, I mean when you visit a site on your mobile device, you are automatically taken to the mobile version of that site. Whether you want to go there or not. Now, to give Nielsen credit, he does say there should always be a link back to the desktop version, but this all seems a bit clunky to me.However, here’s my overarching problem with Nielsen’s advice: “The notion that you should create a separate, stripped-down version for 'the mobile use case' might be appropriate if a clean mobile use case existed, but it doesn't.”Nielsen’s article assumes the myth of the mobile user: A distracted, on-the-go user who ingests information in seconds-long bite-size chunks. That’s not the whole story, not by a long shot. Nielsen is confusing device context with user intent. All we know about mobile users is they’re on a small screen. We cannot divine their intent from that. I know I sit for hours on my phone or tablet when I’m waiting at the airport. I’m browsing. Leisurely. I’m anything-but “on-the-go”! Stripping a website back simply because I happen to be browsing from a smaller device is akin to a book author stripping out chapters from the paperback version of her latest bestseller because it happens to be a smaller form-factor than the hardback version!
A couple of responses to Nielsen’s article, one serious, one hilarious.McGrane goes on to say, “Jakob's recommendation that mobile sites should cut content and features relegates these users to second-class citizens. He suggests that the mobile-only user should get sites optimized for 'the mobile use case', which doesn't exist if your mobile browser is your only browser. We should strive to make the web accessible for all users.”If this issue interests you, I encourage you to read both Nielsen’s original article, and some of the response articles, of which the link in this slide is but one.
With good communication, all the obstacles I talked about can be overcome.But these conclusions should be in the forefront of your minds when talking about responsive web design…1. Does a responsive approach align to our site’s objectives?2. Do our users expect a similar version of the website on their phone as they do on their computer?3. Do we have the time, the resources (and most importantly) the money to do it?I’d assume that point 2 will pretty-much always be true, but it’s worth keeping in the back of your mind if you intend to become the next Yelp. However, if all these points line up, we’re a go for a responsive approach.
So you’ve made the decision to actually get down and dirty with responsive web design. Now what? Do you have to throw out all your old ways of working? Is Photoshop just a remnant of a bygone age? No! Of course not! You can try out new methodologies if you like, and we’ll talk about a few of them in this section, but if you’re comfortable with the way you work now, keep doing it! Visual designers, if you want to produce 2 or 3 static comps showing the site at its different resolutions, go right ahead! Just be prepared for a few more questions from your developers about the transitions, the break-points, etc. However, keep your mind open to new ideas, and new ways of working. I have one possibility that I’m actually trying out right now that I’ll share with you guys in a few minutes. So, this is where we start to get a little more technical. We’re going to dive into what all this actually means for you as project managers, as designers, as developers, and as website owners.
I’m not responsible for any elongation of the ears that might occur.
Responsive Web Design is a term coined by Ethan Marcotte in his seminal A List Apart article, the link is on this slide. In it, he laid out the three principles for Responsive Web Design: A flexible (or fluid if you prefer) grid; flexible images, or images that work in a flexible context; and media queries to bring the whole shebang together. Read that article. It’s 2 years old now, but the principles laid out have paved the way for an entirely new way of looking at web design and development.
The following slides contain math. Consider yourselves duly warned.
This is a wireframe of a basic web page. Our wrapper is 960px wide, and inside that we have a centered element called main that is 900px wide. For the sake of simplicity in this first example, we’re going to assume that’s it. Nothing else exists on this page.Now, normally in our CSS we would specify the widths of those two elements, wrap and main in pixels. But this is a responsive design, and we want to be flexible. So what we do instead is use the following little equation to determine our widths.
Target, divided by context equals result. This little equation is going to form the basis of our flexible grid system. But what does it actually mean? Let’s go back to our simplistic grid…
For the purposes of this example, we’re going to assume that our target is main. Our context is wrap. So target (900) divided by context (960) equals 0.9375. Multiply that by 100 to give us our percentage width for main, which is 93.75. So, main will always be 93.75% the width of wrap, no matter how much we shrink or expand our screen size.
Expressing that in our CSS is simple…The important line is in black. The rest of the CSS is to give that line some context. So we’ve set wrap to be 95% of its context’s width (in this case, the context for wrap is the browser window, because nothing else surrounds it). And we’ve centered both wrap and main horizontally with the margin statement.The main block has our width specified as a percentage, so it will always be 93.75% of the width of wrap. If wrap is 960px wide, that means main will be 900px wide. When I’m writing CSS for a responsive design, I like to put the calculation in a comment right next to the relevant line of CSS. It makes coming back to the code later a whole lot easier.Now, that’s kind of a simple example. Not many websites these days are one-column like that. So, let’s make this a bit more real-world in our next example.
Remember, Target divided by Context equals Result. So in the case of the block called “pri” (short for primary), it’s 660px in our comp, and its context is its immediate surrounding container, ie “main”.Sec (short for secondary) is 220px wide in our comp, and its context is again its immediate surrounding container, which is also main. So we divide target by context to get our results.
Our CSS for those two blocks is pretty straightforward, as it turns out. Don’t be put off by the large number of decimal places. Division like this tends to lead to a lot of long numbers.In order to get the two blocks to float next to one another I’ve added a float left to the primary column, and a float right to the secondary content.As an aside, naming your content sections becomes even more important when designing responsively. In the previous slide, I could have called the two columns “leftcol” and “rightcol”. But what happens when you shrink the screen down, and leftcol is now stacked above rightcol? Your naming convention makes no sense.So, now we’ve seen what can be done in laying out the largest elements of your page. But the concept of flexible grids doesn’t just apply to those big content areas. We can apply the technique to just about anything that we place on our page. After all, everything on the Web is a block.
The small squares could be thumbnails in a gallery. So in this case, our calculation would be thumb as the target, pri as the context. So 180 divided by 660, which equals 0.27 etc, multiplied by 100 to give us our percentage width for each thumbnail. But what about the margin between the thumbnails? Well, that can be expressed as a percentage too. And how would all that come together in our CSS?
Again, we’re floating each of our thumbnails left, and expressing the width of them as a percentage of their context, ie, the element on the page that contains them. And as you can see, we can also express the margin in the same way.
I like to apply the same rules of flexibility and the same calculation: target divided by context equals result – to typography on responsive websites. This ensures that all the elements are responsive, and nothing is defined in fixed pixel widths. If you prefer, you CAN use pixels for typography, but it is fundamentally less flexible than defining type size using proportional sizing.So, in our example above we initially set our body copy size to be 100% of the browser default. That equates to 16px. So now we have our context. Our targets here are the h1, h2, and paragraph elements. From the comp undoubtedly provided by our kind and loving visual designer, we’ll know what size we want to use for our copy. In the case of the h1, we want to set the size to 24px, so we divide target by context to get our result of 1.5. This we set in ems – a relative unit of measurement, originally named because one em was equal to the width of a capital “M” in the typeface being used.Our h2 is set at 1.25ems – 20 pixels divided by 16 pixels equals 1.25. And finally, our paragraph element is set at 0.75ems, which is a comfortable 12px.When you set font sizes in ems you are doing a good thing for the overall accessibility of the Web. People can increase and decrease the font size easily in their browser of choice, without having to zoom in on the whole page, which makes your images look pixellated and nasty. In combination with a responsive design, ems are even more powerful. Now when a user resizes their text to be larger than the default, the em font size units will work in combination with the flexible grids to stretch and adapt the layout. And, because of what we’re about to discuss, your images won’t ever look pixellated.
OK, a previous example used elements called thumb to illustrate our responsive grid. Thing is, those thumb elements probably contain images, and we all know images are a set number of pixels wide and pixels high. There’s not a whole lot we can do to change that, right? So our images will be a fixed width within our flexible thumb container. They’ll overflow the container as the screen size gets smaller, and our beautiful page will break, right?Wrong.This bit’s so easy, I’m going to give you a bit of background first…We were taught for years that in order to give our users the fastest possible experience, we should include widths and heights in our img element declarations. There’s a lot of technical information as to why, but basically it boiled down to making sure the browser only has to do one pass when it renders the page, meaning the page loads as fast as possible, If we didn’t include the widths and heights, the browser had to do a second pass to finalize how the page looks when it loads the images in. That’s much less of a problem now than it was a few years ago as browser technology has improved significantly.So, to go back to what we should do for our images to make them responsive?Step 1: Strip out those width and height attributes. Leave the alt attribute though. It’s important for accessibility reasons, even if it’s empty!Step 2: Add this little snippet of CSS. img max width 100%.Step 3: Profit!And that’s it. You’ve just made all your images responsive! When you resize a page, your images will shrink down and maintain their aspect ratio properly, and when you expand back up, they’ll grow, but only to 100% of their size, so you won’t end up with horribly pixellated images. Told you this bit was easy!
To apply the same flexibility to other types of media as we have to images, all we do is extend our previous CSS declaration to the other media types. And make sure we don’t specify any of their widths or heights in our HTML either!Now we have a truly flexible page, which is great, and is the foundation of responsive design. But our final piece brings it all together.
CSS is phenomenally powerful. Using just CSS we can apply unique styles to different screen sizes, all with one statement.The text in black is our media query. We have to begin by saying this media query applies only when we’re talking about styles for the screen (as opposed to print styles, which would be in a separate media query starting with “at media print”). Then we use a CSS declaration, min-width (we could also use max-width…or to set an explicit range we can use both: styles should be applies where min-width is 480px and max-width is 768px, for example. But here, we’re keeping things simple. We’re saying that the styles contained within this media query should only be applied when we’re on a screen, and the minimum-width of that screen is 960px.
We can chain multiple conditions together in order to more selectively apply styles. Here we’re targeting screens with a minimum width of 768px and are oriented to landscape view. By its very nature, this limits this particular media query to probably only target tablet devices in landscape mode.
Browser support for all this stuff is fantastic. All current versions of every major browser support media queries. Yes, even the venerably Internet Explorer, long the butt of web design jokes, has really stepped it up with IE9. And IE10 looks like it’s going to be a phenomenal browser!But what about older versions of browsers? Well, excluding IE for a moment, every other browser has supported media queries for about 5 years now. So it’s safe to use.A lot of people still use older versions of IE, and you may be thinking, “Sure, all this sounds awesome, but we’re still on IE7. What use is all this to us?” To which I answer, yes, but 1. Your customers probably aren’t. And 2. for anyone that is still on an older browser, why not just serve them up a version of the site without all the media queries?Oh what’s that? You can already? Awesome. Here’s how.
Just specify all your default styles, and the stuff you’d like to override later, in your CSS file BEFORE any of the media queries. Browsers ignore that which they don’t understand, so older versions of IE will read and understand everything down to the first media query, then ignore the rest. That way, you can safely use all of this new technology in every single browser available today.
Like I said earlier, if you’re happy with the way you’re doing things right now, don’t throw that out. But if you’re up for a little experimentation, then here’s something I’m trying out.
We start with our sitemap. From that, we sketch out a set of very low-fidelity wireframes to give an idea of major content areas, and what happens to those at various screen sizes.Then here’s where we make a sharp turn from the usual process. Creating a fully-responsive HTML prototype is a great way to illustrate exactly how things will work, because it’s the HTML and CSS we’ll be using in the final delivered product! It really allows everyone, from the client, to the visual designer, to the interaction designer, to see exactly how the site works at all the relevant screen sizes. This prototype can be polished as you like, but I like to leave it grayscale, so a visual designer can easily apply their creative touch to the elements.Next comes the visual design. If you as a visual designer are more comfortable staying in Photoshop, then do so! But if you want to try something new, then maybe designing in the browser would be a good step. It requires either knowing your fair share of CSS, or working very closely with a front-end developer who does, but it’s a great way of getting to solutions collaboratively, and gaining immediate feedback from the team on what works and what doesn’t, without having to go through the step of creating what is essentially, a picture of a website.Finally, we have either integrating the HTML and CSS with the design applied into a Content Management System, or just building the site out with the content. But because we produced production-level HTML and CSS early on in the process, this is actually a relatively painless step (at least for those of us working on the front-end of a website).This process is just one possibility. As our industry gets more and more familiar and comfortable with responsive web design, new and better workflows will start to appear. Just like with responsive web design itself, the process of getting to a finished product requires us as designers, developers and site owners to be flexible.
If there’s one thing you take away from this presentation, let it be this quote. Stay committed to your decisions, but stay flexible in your approach. That to me encapsulates the essence of responsive web design, and how we use it in our projects.I hope you guys have gained something from this webinar. Whether that’s a new technique, or gaining an insight into just why responsive web design is such a good business case. Or maybe you’ve learned that any PowerPoint slide, no matter how dull, can be livened up with the addition of a funny image downloaded from the Internet.Whatever the case, it’s been a pleasure to present today. In the time we have left, I’ll be happy to take any questions you may have.

1 Like

Chris Schmechel, User Experience Architect at Olympic College 2 months ago