Responsive Web Design has been abuzz for some time now. In case you just now clash with the term, it’s a web design approach aimed at crafting sites to provide an optimal viewing experience across a wide range of devices. Basically, a CSS3 / JavaScript / jQuery powered  site that adjusts itself to better suit the screen it’s on, with the added bonus of keeping a single code base. What’s not to like? Well besides it’s often abbreviated ‘RWD’ which outside of the IT fields stands for Rear-wheel drive, so slightly confusing for people into both.. but that’s a minor issue. Other than that, it’s pretty awesome, but also sometimes hard to implement – some elements of a Web app simply don’t handle well squishing into smaller spaces. Complicated enterprise applications might even require quite a bit of extra work – and as you know with Ignite UI we want to help you get the extra work out of the way! And what do heavy business apps use? Grids, of course!

Now, how do you imagine a big table with a few columns and at least a few hundred rows is to fit in portrait mode on tablets and event more so on phones? The limited space calls for some changes and I’m quite excited to tell you your jQuery Grids will soon (and I mean soon – 13.1 is right around the corner) be equipped with the Responsive feature, ready to fit right into your RWD site! Do I hear clapping? Yeah, that’s not some simple data table we are talking about here – a full-fledged, feature-packed jQuery Data Grid and its Hierarchical version – they can do so much you might as well just make a whole app out of them. A responsive app!

Lastly, if you are in for a quick start with the whole toolset and related concepts you can Get Started Learning Ignite UI Today! The more you know, the more exciting this will be.

What can it do for you and what can you do with Responsive!

The main star of the Responsive feature is allowing you to know in what ‘state’ the app is running and define separate grid and column settings for each to make the best of whatever space you have. For example only do a few major columns for a phone view, some more for a tablet:

And the all the extra stuff when you have the space:

The feature allows you to trigger column visibility based on CSS classes – with a slight nod towards those familiar with or already using popular responsive UI frameworks like Twitter Bootstrap. The RWD Grid comes with 3 modes (mode recognizers if you will, we can work on the naming), that are used to match predefined or custom states ( such as ‘phone’, ‘tablet’ and desktop). Mode Recognizers if you will, but we can work on the naming:

• Responsive mode – the base
• Infragistics mode
• Bootstrap mode

The base implementation looks at the window width, but the Infragistics and Bootstrap profiles rely on CSS3 media classes through a set of classes. Actually here is where Bootstrap comes with their set of media queries and specific classes, that many of you should find familiar. It’s not as simple as putting CSS classes on table cells, though! The igGrid is way too complex for that, but the Responsive feature does the next best thing – hiding columns thought the API methods and detecting when to do that using the class on a test element. I actually love this technique, because that’s how you do a ‘matchMedia’ polyfill (because most mobile browsers support media queries, but not 'matchMedia') and I always thought it was super clever workaround. But anyways, the point is that though CSS you can define when columns will be visible and the grid will do the rest for you. I’ll actually just include a shot of the Twitter Bootstrap description that should be clear enough:

Basically what you do is have you classes in CSS - the ones that come with Bootstrap as above, or the ones from Ignite UI CSS that are pretty much the same, but with out usual “ui-“ prefix, so it’s “ui-visible-phone” and so on. Basically, you need the classes in there – if you are using Bootstrap – great, you can reuse, otherwise we will provide you with them. Those classes are assigned in the column settings on the feature (remember, they are for the test element only) and it really is as simple as adding the Responsive feature to your grid with settings similar to this:

features : [{
        name : 'Responsive',
        columnSettings : [{
            columnKey : 'name',
            classes: "ui-visible-phone"
        }]
        //....

Or you can even configure visibility though simple properties that match the mode’s profiles:

// ...
features : [{
        name : 'Responsive',
        {
            columnKey : 'BusinessEntityID',
            configuration: {
                phone: {
                    hidden: true
                }
            }
        }
// ...

A Template for every occasion

So hiding columns is not enough? Well the Responsive feature kindly offers additional configuration options by providing templates for separate modes. You heard me right – you can swap the entire grid template on every mode and in the same configuration as above, where you define state for modes, you can also add column template specific to each mode! So that’s quite something – with templates you can change the look and feel of the entire grid between modes – shift controls templated into cells back to data or the other way around, merge columns and more! Just keep in mind the row templates are final and will override column ones if mixed.

Customizable, we need it to be customizable!

And so we hear – there’s a whole bunch of settings you can change for way the feature works. The sheer fact that the responsive modes can be quite a few – you can use the classes and have the designer decide thought media queries when exactly should the modes be triggered! That in itself sounds like a good foundation to keep design consideration out of the code.

Then you also have the option to create your own modes… for example have one specially targeted at “phablets” or something like this or any custom width and CSS media query you can think of. You can also extend and define your own mode recognizers (profiles) where you can not only define custom modes, but also use custom logic to say when they are active. That means you responsive grid doesn’t need to depend on CSS or not even on window width..it can be anything you see fit!

Eventful

Well, it’s not just automatic column hiding and template switching.. There’s a whole lot more! The numerous events you can react to are simply a powerhouse of a customization point – you can react to mode changes or even to separate columns going away or coming into view – either way at any point you can perform additional work to improve you app’s experience! You can reduce page sizes, group records, filter, sort or anything you deem helpful. You can even use the Responsive feature events as hooks for script-related modifications of your entire page/app – after all it’s already monitoring the state of the device, you might as well make full use of that! As you can imagine there are great many possibilities of what you can do.

Settings

Besides the elaborate per-column configuration and per-mode settings already mentioned, the Responsive feature doesn’t have that much:

• A general setting that will ensure the grid will stretch the full 100% of its parent, overriding other settings.
• A sensitivity setting defining just how much of a change there should be before the feature would react to changes in window width. Performance implications here obviously.
• And finally the option to disable monitoring container resizes as a whole – again some performance gains and pretty much the difference between a responsive and fluid behavior. If you are interested in that sort of stuff check out the info for our conference below.

Power to the user

Trust me when I say I appreciate every effort a developer has made to improve my experience using a site and I get annoyed when I have to scroll left and right to read a single sentence. But then again, I’m also a user who doesn’t like his capabilities being taken away unconditionally. Yes, responsiveness can bring better experience, but only if you don’t take away from important content and functionality without the option to get them back. Basically, I hate when something gets hidden permanently on some mobile device and I can’t find it. It’s infuriating, even more so with RWD where I can’t just skip to the desktop version and make do.

In the case of the Ignite UI Grid that would mean using the Responsive feature to hide columns that might contain required information. There’s usually a reason for that data to be there and simply removing it from the picture just cuts of functionality from the app! Best part is that the Column Hiding feature will provide the UI when Responsive kicks in for free:

This is something I personally can’t see such a feature without. So, in case you are hiding columns, please consider giving the user the option to control what he’s seeing.

Resources

This has been more a general overview of the Ignite UI jQuery Grids’ Responsive feature aimed at Responsive Web Design (RWD) and a kind of a teaser for the upcoming 13.1 goodness. I’ll be making some more blogs with more code, demos and tricks very soon, so stay tuned!

• Get Started Learning Ignite UI Today! (yes, yes, again!)
• All the awesomeness coming you way:

  Ignite UI: What’s New in 13.1 HTML5, jQuery & ASP.NET MVC Controls

• As always Free Trial is available and it will soon be serving up 13.1 code for you to try!
  

• Just in case you are joining us tomorrow for a day filled with JavaScript related talks at JS Saturday and the topic of Responsive Web Design and Fluid design interest you – make sure to visit the session by our very own Konstantin Dinev!
  

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev.

And as always, you can follow us on Twitter @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!