• Like
The future of BYU web design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

The future of BYU web design

  • 760 views
Published

Mobile first and responsive web design at BYU. Presentation given nov 17, 2011

Mobile first and responsive web design at BYU. Presentation given nov 17, 2011

Published in Design , Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
760
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n
  • We’ve brought things up to current technical standards, such as...\n
  • HTML5\n
  • CSS3\n
  • and jQuery, but...\n
  • Our layout approach still reflects the thinking of 4 or 5 years ago.\n
  • Here’s why. Back in 2007, we decided that “most” browsers were 1024x768. And if they weren’t, they should be--our layouts didn’t support anything else.\n
  • I’ve got a lot of screenshots in the following slides. I’ve left the browser chrome in so that attributions remain intact and so you can go there if you so desire.\n
  • A mobile browser that wasn’t terrible. (Thank you, Steve)\n
  • Your TV became a browser.\n
  • Another mobile browser that didn’t stink. (Now everybody’s got one.)\n
  • Tablet computers finally took off.\n
  • Google’s in the TV business.\n
  • Amazon’s in the browser business.\n
  • There are even cars with web browsers in them.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • So how do we get current on our design?\n
  • We don’t. We need to think further ahead than that.\n
  • This is not the future.\n(Horizontal scrolling. Ugh.)\n
  • Please, don’t let this be the future either.\n(Pinch-and-zoom viewing. Double ugh.)\n
  • (For the Win!)\n
  • When designing a site, 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 focus on those, 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.\n
  • 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 could lose all the stuff you didn’t care about and focus in on what really matters to you: posting your own status and looking at everybody else’s status. \n
  • 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 on ethernet or a super-slow phone network. It loads one small stylesheet, one small javascript file, and one image aside from the HTML.\n
  • So once you’ve started with mobile, you expand from there. Make your design adapt to WHATEVER size a user’s screen may be.\n
  • Here’s a sweet example: http://bostonglobe.com\n
  • Here’s how I’ve approached the visual design\n
  • Mobile first, of course.\n
  • 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!)\n
  • BUT, 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?\n
  • 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?\n
  • Here’s step one. 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 as well, say 300 to 450px wide. (But that will depend on what makes sense for your specific layout)\n
  • 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.\n
  • 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.\n
  • 600px. A good snapshot between the 480px view and the 768px view.\n
  • And here’s another way we’re handling the menu based on the 600px screen width.\n
  • 768px wide\n
  • 1024px.\n
  • 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.)\n
  • And now we get to the technical stuff. It’s really cool.\n
  • Here’s what’s driving it all. Additionally, some well-planned javascript can help immensely as you adapt your layouts to various sizes.\n
  • 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.\n
  • 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.\n
  • INSIDE my stylesheet, it looks like this.\n
  • 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.\n
  • The flexible grid is pretty easy to set up. \n
  • Simply 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.\n
  • 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.\n
  • 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.\n
  • Here’s where the mobile first starts. Only serve up the very basics at first, and add stuff in later for more capable browsers.\n
  • Modernizr should be loaded for just about 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 even help some less than capable browsers (I’m looking right at you, IE) get up to speed.\n
  • 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. This is a simple declaration that will load these two scripts in parallel (faster) BUT execute them in order. (w00t!)\n
  • Here’s some of the other stuff Modernizr lets you do, to account for browsers that don’t handle things quite right.\n
  • 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.\n
  • 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), 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.\n
  • 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)\n
  • 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.\n

Transcript

  • 1. The Future BYU Website ProjectSlide notes will appear here.
  • 2. Redesign byu.edu • Markup, style, and scripting have been updatedWe’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 2007Our 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 2007I’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 biggerBrowsers are bigger
  • 18. and smaller than ever.and smaller than ever.
  • 19. Connections are fasterConnections are faster
  • 20. and slower than ever.and slower than ever.
  • 21. Browsers are more capableBrowsers are more capable
  • 22. and more rudimentary than ever.and more rudimentary than ever.
  • 23. Bringing the design to 2011So how do we get current on our design?
  • 24. Designing for the future Bringing the design to 2011We don’t. We need to think further ahead than that.
  • 25. FAILThis is not the future. (Horizontal scrolling. Ugh.)
  • 26. FAILPlease, 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 outthe 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 winfor 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 itcould 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 reallymatters: 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 gotdown 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 everyoneSo 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. DesignHere’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 theevolutionary 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 areclose: 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, andnot 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 animportant 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 aview to consider, or even bigger.)
  • 46. TechniquesAnd now we get to the technical stuff. It’s really cool.
  • 47. Techniques • Media queries • Flexible grids and uid images • Progressive enhancement • Poly lls & fallbacksHere’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 cellphone) doesn’t understand media queries, it won’t load the stylesheet. This is important, because it means that even browsers from the ageof 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 understandsmedia 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 putthe smaller widths first and move up, I only have to define the CHANGES, which can keep your stylesheets still pretty small. This one is under20K, minified.
  • 52. Flexible Grids • Liquid layout • Percentages de ne widths • Proportion-perfect, not pixel- perfectThe 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 handlerounding 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 upabove 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 thenusing 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 browsersHere’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 todetect 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 toconditionally 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 loadingHere’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 fillin 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 yourcss 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 totest for, as well as include an HTML5 shim, the yepnope script loader (Modernizr.load; with more documentation at yepnopejs.com), mediaquery fallback for IE, and so on. It lets you use partially-supported features RIGHT NOW, by allowing you to gracefully fall back if the browserisn’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 (andstyles 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.