When some one says Responsive web design, you will think of media queries. In my opinion Responsive web design is not only media queries. In case of large sites like goolge plus or any other heavy sites media queries will be only 10%.
If you are developing a responsive blog or a static portfolio site of yours, the content is very less and they are adjustable(we can say them as read-only sites as we cant perform any action on those other than comments). It will be very easy for the developer to control the content based on his design and can develop a nice cool responsive website which will be compatible for all kind of devices and resolutions on the earth.
However, in case of large site the content is not controlled by the developer or the designer as that is posted by the large user group and user has great control over the system. The user can perform many actions based on his interest.
So, Its very important we concentrate on the following areas when implementing RWD for large sites,
- Modal windows
- Tabs (Horizontal and Vertical)
- Internet Explorer
There are four different layout options.
- Fixed width
- Fluid layouts
- Elastic layouts
- Hybrid layouts
Fixed Layouts :
These are non responsive layouts, before RWD this fixed layouts are famous. In fixed-width layouts the site width is constrained by a specific pixel measurement, 960px being the most commonly chosen width today. In 2006, Cameron Moll wrote a blog post entitled “Optimal width for 1024px resolution?” in which he dissected what the “optimal” width was to target for the increasingly popular 1024 resolution. After considering the Chrome browser that left between 974px and 984px to play with.
The biggest problem with fixed-width layouts is that you must operate under a lot of assumptions. When you determine how wide your site will be, you’re making a guess as to what dimensions will best serve the largest percentage of visitors.
This is the an example of Fixed layout(try resizing the browser) http://tcs.com/
In fluid layouts, dimensions are determined by percentages, not pixel measurements. As a result, they’re much more malleable. So you may have a primary column that’s sized at 60% of the width of the container, a right sidebar column in her categorization; sized at 30%, and a gutter of 10% in between. Using a layout defined in that manner means that it doesn’t matter if the user is using a desktop computer with a browser width of 1024px, or a tablet sized at 768px wide: the widths of the elements in the page will adjust accordingly. A fluid layout can avoid lot of problems that are caused by fixed layouts. It prevents the Horizontal scrollbars in most cases. Implementing responsive design in fluid layouts is very easy, with the css3 media queries.
Elastic layouts are very similar to fluid layouts, except that their constraints are determined by the type sizeâ€”typically using the em measurement. One em is the equivalent of the currently defined font-size. Say, for example, the body text is in a font-size of 12px. In that case, 1em equals 12px and 2em equals 24px. Elastic layouts provide strong typographic control. With an elastic layout, you can define the width of the container to be, say, 55em. This would ensure that the width of the container always maintains an appropriate line length. Another benefit of elastic layouts is that as a visitor increases or decreases the font size, elements defined with elastic widths will scale in proportion to that font size.
This the mix of two are more above layouts. Say, you have a case where you have fixed 300px width widget, and the sidebar is in percentage the you need to mix the fixed and fluid layout.
There are many navigation areas one on the top(main navigation), one on the left side bar, one drop down on click of profile picture.
Thinking of RWD we cant get the large real estate in case of mobile and tablet devices. So we need a way to show this navigation in the smaller screen resolutions. This can be done using the media queries with different CSS for small screens.
The basic solution can be stacking the all the menu items, vertically. However when you have submenus an more number of menus we need to handle them separately. Image description not specified. Let’s run through a few quick options.
Don’t do anything: That’s what the page essentially does right now. It’s intuitive and the solution works on a variety of devices, but it consumes a lot of screen real estate.
Its necessary to use modal windows in case of large sites. So how to make these modal’s responsive. We can use the same fluid layout(with percentages) to make them responsive.
The main problem though is not in how the images look, but in how much they weigh, how much demand they place on performance. Currently, the same images are being loaded regardless of the device in use. That means, for example, the 624px lead-in image is being downloaded even on small screens where a 350px image is all that’s needed. The page performance is suffering, and that’s a big deal to people visiting the site.
Performance is an important consideration for any site. Loading images that are unnecessary or larger than needed can have a serious impact on page load time.
Selective Serving images to the mobile devices:
The CSS solution of
display:none is not viable. It hides images from view, but they’re still requested and downloaded. If you want images to show only above a certain breakpoint, the better bet is to load them conditionally, after the page load has occurred.
The main concept is we will bypass the image loading by not using the img tag. We place a
Background Images: Its ok when you use repeat on your backgound image, if you are using a no repeat background image you need to scale it along with the screen resolution.
High resolution displays: Keeping in mind that we have retina display devices available in the market. SVG are one of the solution for those devices.
Tabs (Horizontal and Vertical):
Image description not specified.
the solution can be converting the tab to a
few other solutions
Responsive table, hmm great to thing. In large display devices we can display the whole table as we have more realestate. If it is a mobile device we cant show a proper table.
Forget responsive for IE8 and below and code it for IE9 and above.