The future of BYU web design

Editor's Notes

1. \n
2. We’ve brought things up to current technical standards, such as...\n
3. HTML5\n
4. CSS3\n
5. and jQuery, but...\n
6. Our layout approach still reflects the thinking of 4 or 5 years ago.\n
7. 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
8. 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
9. A mobile browser that wasn’t terrible. (Thank you, Steve)\n
10. Your TV became a browser.\n
11. Another mobile browser that didn’t stink. (Now everybody’s got one.)\n
12. Tablet computers finally took off.\n
13. Google’s in the TV business.\n
14. Amazon’s in the browser business.\n
15. There are even cars with web browsers in them.\n
16. \n
17. \n
18. \n
19. \n
20. \n
21. \n
22. \n
23. So how do we get current on our design?\n
24. We don’t. We need to think further ahead than that.\n
25. This is not the future.\n(Horizontal scrolling. Ugh.)\n
26. Please, don’t let this be the future either.\n(Pinch-and-zoom viewing. Double ugh.)\n
27. (For the Win!)\n
28. 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
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 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
30. 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
31. 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
32. Here’s a sweet example: http://bostonglobe.com\n
33. Here’s how I’ve approached the visual design\n
34. Mobile first, of course.\n
35. 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
36. 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
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?\n
38. 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
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.\n
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.\n
41. 600px. A good snapshot between the 480px view and the 768px view.\n
42. And here’s another way we’re handling the menu based on the 600px screen width.\n
43. 768px wide\n
44. 1024px.\n
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.)\n
46. And now we get to the technical stuff. It’s really cool.\n
47. Here’s what’s driving it all. Additionally, some well-planned javascript can help immensely as you adapt your layouts to various sizes.\n
48. 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
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.\n
50. INSIDE my stylesheet, it looks like this.\n
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.\n
52. The flexible grid is pretty easy to set up. \n
53. 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
54. 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
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.\n
56. 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
57. 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
58. 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
59. Here’s some of the other stuff Modernizr lets you do, to account for browsers that don’t handle things quite right.\n
60. 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
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), 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
62. 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
63. 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