 |
| The Fly (you know, caught in the web...? Aw, forget it) |
</whine>
OK, so enough whining about the options out there; it's time to actually try my hand at some responsive web design (RWD)!But where to start?
Planning, of course!
First of all, I decided that rather than diving straight into trying to redesign my own site - you know, with all that actual content and stuff - it would be better if I did some proof of concept pages to get my hands dirty and get solidly back into code. That's where we're starting.
To this end, I didn't go into great depth with content cataloging, sketching, wire framing, etc., simply because I'm not planning to use real content for this demo. Of course, I am fully aware that the demo might just roll right into the real deal, so I want to try and do things pretty well from the start… but let's start small.
I did do something of a mini "content catalog" and "wireframes" to have some idea what I'd be dealing with. Basically, I knew I'd need the following:
- A header, which would consist of a nav bar with 5-6 items and a logo
- A main content area which would consist of various sections, articles, etc. to be determined later
- A sidebar area that could have several elements
- Another, rogue, floating sidebar element that I could play with
- A footer
That's about all I need to get started, as far as elements. But thinking about actual content and the priority of different content elements is very important in responsive design. Since the idea is for your user to be able to consume your content in any context, you need to know what elements will be most important to them in each context, and how to make your page reconfigure to display that content best on different devices.
The discussion around whether or not to specifically tailor your site and content to a specific device context is a lively one, but if you observe the most basic best practice - know your user and business goals - you can probably figure out how to approach this.
For now, my user is me, and I don't want to hide any content from anyone, so everything needs to reconfigure itself nicely. This first project will kind of be a content prototype, but without any real content.
Based on the "content" that I identified above, I did a quick "wireframe" to see how these pieces would fall in a regular desktop format, and in a narrower one (we'll just do one breakpoint for now):
 |
| Ooooh, fancy! |
I know from many years of video experience that there's no point in making your own storyboard templates when there are dozens out there on the web - enough that it's probably quicker to Google it than to even fire up Illustrator. I did a quick search and, sure enough, found some great, simple RWD layout planning templates by Jeremy Alford, which are the thin, straight lines you see around my scrawls up there.
So now it's time to code.
I am assuming that, if you are here, you already know some HTML and CSS and are interested in getting down and dirty with some RWD yourself. If you are new to web coding, I would strongly suggest you get up to speed before going much further. There are countless ways to do this; Treehouse and Lynda.com are two excellent paid resources, but there are some great free ones out there as well; check out the html.net and Tuts+ sites to get started.
I decided that for these first steps not to use any frameworks, boilerplates, grids or anything - just see if I can throw together a nice, simple demo that would give me a good, semantic framework upon which to build, and to get used to using SASS and Compass.
Or more accurately, SCSS, since I am not using much of the special SASS syntax right now. I'm mostly taking advantage of the nesting and variables made possible with SCSS, maybe a few mixins from Compass, and letting Codekit take care of all the compiling and organization in the background for me. To see a bit more about how I have used SCSS variables in my code, take a look at the CSS code - there are some comments in there for you.
Did I already gush about Codekit? Time for another gusher. If you are a Mac developer and you aren't using Codekit, RUN, don't walk, and get this thing (sorry, Win-folk, there's no version for you yet, and apparently no alternatives... but it's coming). If you are using any preprocessors for HTML, JS or CSS, or if you want to save a crap-load of time setting up fancy schmancy CSS effects and transitions, this little application will save you a lot of effort and interaction with the Terminal (don't be afraid of the terminal, but still get Codekit). Anyway, it is SO worth the $25. And tech support is quick and first-hand, let me tell you.
Behind the mask
First of all, though, what we need is a nice, simple semantic framework. To that end, join me on a zany, madcap adventure to the wonderful world of completely unstyled HTML:
Yes, that's what our page looks like with no styles at all, just the most cursory <h> and <p> tags. Ugly as sin, but clear enough - if you can get to this page, you can figure out what's going on and where to go. This principle is beautifully demonstrated by the now age-old CSS Zen Garden. This site shows wonderful examples of the separation of structure and style; do yourself a favor and play around there for a while.
Now, while I am not going to use any templates, I am most definitely going to use a CSS reset to kick things off. A CSS reset is almost always a good idea - at their simplest, they reset some browser defaults to 0 to give your site a standardized playing field to work on across browsers. Some of them also fix known issues with certain browsers, optimize things for HTML5 or fluid grids, etc. But there are two accepted guidelines: You should use a CSS reset, and whichever you use, only use it as a starting point; they are meant to be customized by each developer for his or her unique situation.
Now based on past experiences, I figured I'd start with the Eric Meyer reset (now in v2.0) and do some tweaking. I also used some bits from Normalize, as well as a brilliant box-model fix by the equally brilliant Chris Coyier (known for CSS-Tricks.net and the incredibly addictive Codepen) which allows us to use margins and padding without messing up our fluid layout. You can read a lot more about that piece here. For a closer look at a variety of popular reset starting points, you can visit CSSReset.com.
Before I go too much further into the discussion of the code, how about a little peekskie at the properly styled test page?
Now, while I am not going to use any templates, I am most definitely going to use a CSS reset to kick things off. A CSS reset is almost always a good idea - at their simplest, they reset some browser defaults to 0 to give your site a standardized playing field to work on across browsers. Some of them also fix known issues with certain browsers, optimize things for HTML5 or fluid grids, etc. But there are two accepted guidelines: You should use a CSS reset, and whichever you use, only use it as a starting point; they are meant to be customized by each developer for his or her unique situation.
CSScapades - now we're stylin'!
Now hold on just a cotton-pickin' minute here!
What's that you say? "I looked at your test page on my iPhone and it isn't responsive! That darn site just showed up as a two-column site zoomed way out. You're cheating!" Ok, guilty as charged, but there's a reason for this (you knew there would be, didn't you?), and it's called the <viewport> tag... but we'll go into that next time. Promise. |
| Web Fu |
The one concession I made towards improving the visuals was to use a couple of web fonts rather than leave things to chance. To that end, I used Google Webfonts, and am using Signika Negative for the headers and Cardo for the copy. The font is added with a simple <link> in the <head>, and then you can use it in your CSS - bang. Web fonts can be embedded in other ways, of course, and as always there are benefits and drawbacks.
But now go ahead... play around with the browser window for the styled test page. You'll notice that the major areas are fluid, which is one of the cornerposts of RWD. Wherever possible I am using % and ems to define sizes rather than px.
Originally, back in the stone age (2008?) when browsers didn't all scale things very consistently, elements defined with specific pixel values would not always re-size properly, breaking all kinds of layout stuff. Which is, of course, bad. Using variable values such as ems and percentages helped fix that.
These days most browsers are smart enough to zoom things right, so the best reason to keep it relative is more for your own sanity: if you keep things as fluid and relative as possible, you don't need to calculate and code every column width and font size for each breakpoint. But don't take my word for it.
Breakin' 2: Electric Boogaloo
Tastier yet - speaking of breakpoints, we now have our first media query! When the page re-sizes horizontally below 48em (in my SCSS this is a variable called $smallDeskWidth, which you can see below), it goes from being a 2-column layout to a 1-column layout. The sidebars snap below the main content area and all elements become full-width. This is accomplished with one very simple media query (stripped down here to the critical bits):
This is placed at the very bottom of my SCSS/CSS document so that things cascade properly; stuff you define later in the document overrides stuff that you define earlier in the document, assuming the conditions are right. So if that browser width gets narrower than $smallDeskWidth, the styles override the ones set higher up. Simple!
When triggered, both the #sideBar and the #mainContent areas become 100% wide (within the max-width of 94% set by the #wrapper) and get stacked on top of each other. The reason the sidebars snap below the main content is that this is where they live in the actual HTML flow (refer either to the source code or the first, unstyled test). When they were floated right, they stacked atop each other on the right hand side and the #mainContent "flowed" around them. When that float is cleared, they suddenly lose their special privileges and hop back in line with the rest of the HTML.
The issue of content choreography - or where various chunks of content go when things re-size - is non-trivial, and there are many ways to handle it, none of them quite perfect. We'll look at this more going forward, but for now suffice it to say that a content strategy (or at least some kind of hierarchy) is very important when you might be dealing with very limited viewing areas.
You've probably noticed by now that the new single column will not re-size BELOW 29em (as you can see from the code, that is on purpose, defined by a min-width). This is because I know the layout as it stands will break if I size it down much more, and I want to add another breakpoint in there to handle it (why do you think they call 'em breakpoints?). Having your nav crash into your logo is very bad form. But that's for next time.
You'll also notice the footer, which is fixed at the bottom of the page and remains perpetually 6em from the edges of the browser window no matter how much you flail that mouse around. As it stands, it is at the bottom of the page, just where you'd expect to find it given its position in the HTML document. The cool thing is that, because I have defined its position as fixed in relation to the bottom and sides of the browser, you could put the <footer> code anywhere in the HTML and it would still show up right there at the bottom.
For now, this just proves a point - defining something as position:fixed in a layout is a powerful tool that we can use for all kinds of interesting things. But as the footer is now, I kind of hate it, the way the left edge stays static and the right moves around, and it can be either wider or narrower than the main layout depending on your window width... yuck. To be fixed later.
Until next time, please let me know if you have any questions about anything (I can be very responsive!) and stay flexible.
@media only screen and (max-width: $smallDeskWidth) {
#wrapper {
width: $smallDeskWidth;
max-width:94%;
min-width: 29em;
}
#sideBar {
float: none;
clear: both;
width: 100%;
min-height: 100px;
}
#mainContent {
width: 100%;
}
}
When triggered, both the #sideBar and the #mainContent areas become 100% wide (within the max-width of 94% set by the #wrapper) and get stacked on top of each other. The reason the sidebars snap below the main content is that this is where they live in the actual HTML flow (refer either to the source code or the first, unstyled test). When they were floated right, they stacked atop each other on the right hand side and the #mainContent "flowed" around them. When that float is cleared, they suddenly lose their special privileges and hop back in line with the rest of the HTML.
The issue of content choreography - or where various chunks of content go when things re-size - is non-trivial, and there are many ways to handle it, none of them quite perfect. We'll look at this more going forward, but for now suffice it to say that a content strategy (or at least some kind of hierarchy) is very important when you might be dealing with very limited viewing areas.
You've probably noticed by now that the new single column will not re-size BELOW 29em (as you can see from the code, that is on purpose, defined by a min-width). This is because I know the layout as it stands will break if I size it down much more, and I want to add another breakpoint in there to handle it (why do you think they call 'em breakpoints?). Having your nav crash into your logo is very bad form. But that's for next time.
You'll also notice the footer, which is fixed at the bottom of the page and remains perpetually 6em from the edges of the browser window no matter how much you flail that mouse around. As it stands, it is at the bottom of the page, just where you'd expect to find it given its position in the HTML document. The cool thing is that, because I have defined its position as fixed in relation to the bottom and sides of the browser, you could put the <footer> code anywhere in the HTML and it would still show up right there at the bottom.
For now, this just proves a point - defining something as position:fixed in a layout is a powerful tool that we can use for all kinds of interesting things. But as the footer is now, I kind of hate it, the way the left edge stays static and the right moves around, and it can be either wider or narrower than the main layout depending on your window width... yuck. To be fixed later.
Are we having fun yet?
So, my goals for the next iteration are pretty clear: Set a second breakpoint below 29em; figure out if that accordion thingy is going to be an accordion thingy (and make it work); add enough content to make it need to scroll, which will afford some new opportunities; fix the hideous footer; find a way to use a little JS in there; and maybe improve the visuals a bit. Oh, and we'll address that <viewport> issue as well and start making things look good in mobile contexts.Until next time, please let me know if you have any questions about anything (I can be very responsive!) and stay flexible.
No comments:
Post a Comment