The document discusses redesigning the BYU website to be more responsive and adaptive to different screen sizes. It notes that the current layout is outdated since it was designed in 2007 for 1024x768 screens. Modern browsers come in a variety of sizes from mobile to desktop and beyond. The document recommends a mobile-first approach using responsive web design techniques like flexible grids, fluid images, and media queries to dynamically serve optimized layouts depending on screen width. It also advocates progressive enhancement and polyfills to gracefully support older browsers.

1. The Future
BYU Website Project
Slide notes will appear here.

2. Redesign byu.edu
• Markup, style, and scripting
have been updated
We’ve brought things up to current technical standards, such as...

3. HTML5

4. CSS3

5. and jQuery, but...

6. Redesign byu.edu
• Markup, style, and scripting
have been updated
• Layout is still hovering somewhere
around 2007
Our layout approach still reflects the thinking of 4 or 5 years ago.

7. Here’s why. Back in 2007, we decided that “most” browsers were 1024x768. Our layouts didn’t support anything else.

8. Here’s what’s happened
since 2007
I’ve got a lot of screenshots in the following slides. I’ve left the browser chrome in so that the URL serves as the attribution.

9. A mobile browser that wasn’t terrible. (Thank you, Steve)

10. Your TV became a browser.

11. Another mobile browser that didn’t stink. (Now everybody can have one-- even people who don’t want an iPhone :)

12. Tablet computers finally took off. (Again, props to Steve)

13. Google’s in the TV business.

14. Amazon’s in the browser business.

15. There are even cars with web browsers in them.

16. What this means for us:
What this means for us:
Clearly 1024x768 is a thing of the past:

17. Browsers are bigger
Browsers are bigger

18. and smaller than ever.
and smaller than ever.

19. Connections are faster
Connections are faster

20. and slower than ever.
and slower than ever.

21. Browsers are more capable
Browsers are more capable

22. and more rudimentary than ever.
and more rudimentary than ever.

23. Bringing the design to 2011
So how do we get current on our design?

24. Designing for the future
Bringing the design to 2011
We don’t. We need to think further ahead than that.

25. FAIL
This is not the future. (Horizontal scrolling. Ugh.)

26. FAIL
Please, don’t let this be the future either. (Pinch-and-zoom viewing. Double ugh. Viewing a site through a keyhole is not a good experience!)

27. Mobile First &
Responsive Web Design
FTW

28. Mobile First
• Essentials only
• Speed, speed, speed
• Bene t everyone (not just mobile users)
Always, ALWAYS design for mobile first. Even if you’re never planning to have a mobile site. Really. Here’s why: 1) It forces you to figure out
the absolutely most important parts of the site, and 2) it forces you to figure out ways to make your site really, really fast. If that’s not a win
for everyone, I don’t know what is.

29. Example: Facebook started out as a desktop site. The guy who designed the first mobile FB app started working on it and realized that it
could actually be better than the desktop site. Why? because you get rid of all the stuff you didn’t care about and focus in on what really
matters: posting your own status and looking at everybody else’s status (and a few other things).

30. beta.byu.edu/m/
Here’s a test I did, trying to see how tiny I could get BYU’s site and still deliver all of the important content on the home page. The page got
down under 50K, and loads in a blink whether you’re plugged in to ethernet or on a super-slow phone network. It loads one small stylesheet,
one small javascript file, and one image (aside from the HTML).

31. Responsive Web Design
• Don’t force size, adapt to it
• Happy browsing for everyone
So once you’ve started with mobile, you expand from there. Make your design adapt to WHATEVER size a user’s screen may be.

32. Here’s a sweet example: http://bostonglobe.com

33. Design
Here’s how I’ve approached the visual design

34. Mobile first, of course.

35. vs.
Previous thinking was that you designed a desktop site AND a mobile site. You used browser sniffing or some other (questionable) technique,
and redirected mobile users to their own little space on the web. (Hey! get out of my desktop space, you little mobile browser! Not cool.)

36. The better way to approach it is to figure out how the mobile should TRANSFORM into the desktop view (and back again). What are the
evolutionary steps to get from one to the other?

37. There’s a lot of stuff here that got left out or hidden in the mobile version. Where does it all go? And when should it reappear?

38. Here’s step one (after the basic mobile). 320px wide. It covers iPhone, Android and other smartphone browsers that are actually worth using.
This is portrait orientation. HOWEVER, don’t think of this as an isolated size. This layout should be liquid (as in, resizable) for sizes that are
close: say 300 to 450px wide. (But that will depend on what makes sense for your specific layout.)

39. This is still the 320px layout. Here’s what we did with the two menus from the desktop version. In order that we can focus on CONTENT, and
not just show a screen full of navigation (really, nobody wants that), we folded all of the nav up into the two tabs. That brings up an
important point: this layout is assuming javascript capability. If there’s no js, it looks like the very first mobile layout. More on that later.

40. Here’s what happens around 480px. That’s another good width to look at, because it’s the width of smartphones in landscape orientation.
But again, you should think of it more as a range. As things start needing a little adjustment in the smaller layout, jump to the next one.
480px is just a good view to think about as you figure out where that range falls.

41. 600px. A good snapshot between the 480px view and the 768px view.

42. And here’s another way we’re handling the menu based on the 600px screen width.

43. 768px wide. All of the menus are visible, and the bottom content is 2 columns.

44. 1024px

45. We’ve found that 18% of our users have browser windows above 1500px wide. So it makes sense to consider those too. (1280px might be a
view to consider, or even bigger.)

46. Techniques
And now we get to the technical stuff. It’s really cool.

47. Techniques
• Media queries
• Flexible grids and uid images
• Progressive enhancement
• Poly lls & fallbacks
Here’s what’s driving it all. Additionally, some well-planned javascript can help a lot as you adapt your layouts to various sizes.

48. Media Queries
<link rel=”stylesheet”
media=”all and (min-width:320px)”
href=”responsive.css” />
If you insert this into your HTML, the stylesheet will only load if the screen width is wider than 320px. Additionally, if a browser (say, on a cell
phone) doesn’t understand media queries, it won’t load the stylesheet. This is important, because it means that even browsers from the age
of dinosaurs (here’s looking at you, Netscape 4) will get the content and a basic stylesheet they can understand, but no more.

49. Here’s how it looks in the wild. I’m loading handheld.css in the normal way, and adding the bulk of my styles only if the browser understands
media queries (and is therefore modern enough to understand my CSS3) AND is wider than 320px. Other browsers don’t bother with it.

50. Media Queries
@media screen and (min-width:480px){
body {width:90%; margin:0 auto;}
}
INSIDE my stylesheet, it looks like this.

51. I can add as many breakpoints as needed, and the styles will only be applied if the browser meets those criteria (in this case, width). If I put
the smaller widths first and move up, I only have to define the CHANGES, which can keep your stylesheets still pretty small. This one is under
20K, minified.

52. Flexible Grids
• Liquid layout
• Percentages de ne widths
• Proportion-perfect, not pixel-
perfect
The flexible grid is pretty easy to set up.

53. Just substitute percentages for pixels. I’ve left a gutter here that’s a little bit squishy to account for the different ways browsers handle
rounding of pixels and whatnot.

54. Fluid Images
img {max-width:100%}
This one’s pretty easy too. If you apply this style to your images, they’ll scale down as their container scales down, but they won’t scale up
above their full size. Pretty nice.

55. Here’s what it looks like. (This is a great article, by the way.) I’ve also experimented with loading a small image initially (mobile first) and then
using js to replace it with a larger one as needed.

56. Progressive Enhancement
• Start with the basics: no-frills
HTML and CSS2; no Javascript
• Enhance for capable browsers
Here’s where the mobile first starts. Only serve up the very basics at first, and add stuff in later for more capable browsers.

57. Modernizr should be loaded for pretty much any site. It’s awesome. This is the one small javascript I load for mobile that will allow you to
detect a browser’s features and help some less-than-capable browsers (I’m looking right at you, IE) get up to speed.

58. Modernizr.load();
One of the most useful features is the script loader. It allows me to only load my javascript if I’m on a js-enabled browser (Nice!), AND even to
conditionally load scripts based on a browser’s capabilities. Shown here is a simple declaration that will load these two scripts in parallel
(faster) if the browser understands javascript BUT execute them in order. (w00t!)

59. Poly lls & Fallbacks
• Conditional css classes
• Conditional .js and .css loading
Here’s some of the other stuff Modernizr lets you do, to account for browsers that don’t handle things quite right.

60. body.no-js nav
{
// Fallback css goes here
}
body.no-cssgradients > header
{
// Fallback css for gradient header
}
Modernizr can add classes to your html body that tell you what capabilities it has. For example, the top declaration contains styles that will fill
in if the browser doesn’t have js turned on. The bottom is a fallback for a browser that doesn’t like gradients. These can live happily in your
css and only be deployed as needed.

61. Here’s what the production-ready build screen looks like for Modernizr. You can choose the tests to run based on the features you need to
test for, as well as include an HTML5 shim, the yepnope script loader (Modernizr.load; with more documentation at yepnopejs.com), media
query fallback for IE, and so on. It lets you use partially-supported features RIGHT NOW, by allowing you to gracefully fall back if the browser
isn’t quite mature enough to handle your awesomeness.

62. if(!Modernizr.canvas)
{
// Fallback scripting goes here
}
Modernizr.load(
{
test: Modernizr.canvas,
nope: [‘canvasfill.js’, ‘canvasfill.css’]
});
Here’s some javascript that allows you to test for a specific feature and perform some actions (top) or load external fallback scripts (and
styles too!) (bottom)

63. Essential Reading
• Multi-device Web Design: An Evolution
Luke Wroblewski, 31 Oct 2011
http://bit.ly/sKU95o
• Mobile First
Luke Wroblewski
http://www.abookapart.com/
• Responsive Web Design
Ethan Marcotte
http://www.abookapart.com/
And here’s where you go for further reading. No doubt you still have some questions; these are the creme-de-la-creme of the sources. Enjoy.