Friday, January 20, 2012

First Crack at Responsive Web Design

I currently have a mix of elation and frustration.  I recently joined a team of developers to redesign pages of a website with responsive web design.  First things first, we set up our project site here at Google Project Hosting.  Before you go and checkout the repository, you should know that we haven't officially started the project yet.  All we have uploaded to the repository is a test page and corresponding files needed to render it locally.  Once we get things finalized conceptually, we'll be removing that repository and replacing it with the entire site.

Okay, so after we got our test page uploaded we got to work on changing the design from a standard 960px resolution to one that would be responsive not only to resizing of the browser, but also to specific size of mobile media devices.  Initially, we were at a bit of a loss in deciphering all the HTML and CSS code.  Mainly, we had to read through and understand how the divs, or HTML body divisions, were set up.  In addition, we were looking through the CSS files to see how the page styles were organized.  This took a little while, but then we started to gain an understanding of the elements on the page and how they were controlled via the CSS files.  The Firebug add-on for Mozilla Firefox was extremely useful and made the whole process proceed quickly and with ease.

Initially, we started by looking at tips for fluid grid design.  One of the underlying techniques is to change widths of containers and elements from pixels to percentages.  This had pretty amazing effects, as it allowed objects to "float" around the page and reorganize themselves to fit within the browser after its size was reduced.  Unfortunately, the results were not perfect.  For instance the navigation bar stayed at the same height and overlapped with other elements.  That's when we decided to remove specific object heights.  Instead, we decided to provide the needed spacing between objects on the page by adding margins to the top and/or bottom as needed.

After making these changes, the site behaved better, but it was still not very attractive at certain browser sizes.  That's when we decided to do specific media queries which would load separate style-sheets based on browser size.  We decided not to query for specific media types, although that is another valid option.  At the moment, we've decided against querying specific mobile devices because we wanted the page to also adapt when people want to re-size their browser to look at other things.

We started by adding one other CSS file to override the current style-sheet when it detected a browser size that is approximate to that of a mobile phone.  We quickly learned that it was easy to implement media queries, as you simply need to create specific style-sheets for each device's approximate browsing width.  After that, you simply link to those style-sheets in your HTML file.  You can either do the media query in the HTML file, and load a corresponding CSS file, or you can link to a CSS file that has media queries as internal elements and corresponding style coding for each element.  At the time of writing this blog, I have recently discovered that one of my team members had uploaded a media-query CSS file that had attributes for several of these approximate browsing widths.

While a media-querying CSS file is sufficient to make small changes to page elements based on detected browser sizes, I believe we still need to implement separate style-sheets for each mobile device approximation.  The reason I feel this way goes back to basic coding practices.  Just as we do not want to have one method that contains hundreds or thousands of lines of "spaghetti code", it is much easier to maintain separate files of shorter length.  That way, when maintaining or adjusting styles for specific devices we can simply go to the corresponding file, rather than having to browse many lines of code to get to a particular media query's style overrides.  Furthermore, we may want to have completely different interface designs based on the size of the browser, and separate style-sheets would facilitate that better.

Overall, the project started out very well, and we are poised to move on to the next portion of the project, which would be to modify the entire site and not just one page.

At this point you may be wondering where my frustrations manifested.  Well, certain elements of the page seemed to disappear, mainly some of the small navigation bar images.  Also, I ran into a few problems with getting subversion mime-types to work from our project site.  My goal was to be able to see the HTML page render itself straight from the repository, but it doesn't.  While you can easily browse the HTML code, the page doesn't render properly when to you try to view it.  There are still some issues to work out, but we've made a lot of great progress.  I'm looking forward to our next step in the project!

No comments:

Post a Comment