Log in to like this post! Responsive Web Design with jQuery Grids: A closer look Damyan Petev / Thursday, May 23, 2013 I really hope I got you excited about the Responsive Web Design mode for the Ignite UI Grids last time – as it is the kind of an unique feature that truly makes this jQuery control stand out! As previously explained it’s not exactly a simple thing to make a grid responsive, but our team made serious considerations on how to best approach this and I do believe they’ve pretty much nailed it and this will turn out to be very useful addition. There were also plenty of things that can’t fit in a single blog, plus the fact that the actual feature was not yet released so there wasn’t too much of demo material to see. So now, with 13.1 out and even accompanied by a service release, without further due, let’s dig into the technical stuff! I’ll start with some interesting design considerations and even potential pitfalls related with Responsive Web Design and then have some specific Grid tips. A Getting Started, of sorts Now these are more of honorary mentions as the most basic stuff were already covered elsewhere, but hey, it doesn’t hurt to have them on a speed dial. So in case you missed it - here’s a nice summary on Building responsive web design using CSS3 Media Queries! And because creating a Responsive app is all in the name of providing users with a better experience I figured some UX tips and food for thought are in order. Our Services or as of recently D3 (from Discover – Design – Develop) have a solid expertise in the field and they share some of it in their blogs. For example this on UX of Responsive Web Design you should definitely check out! There’s a whole lot more on UX, Design and usability and I highly recommend keeping an eye on those. Once you have technology and design considerations in check, I’d like to turn your attention to the now available Documentation for the igGrid Responsive Web Design (RWD) Mode. There’s an good coverage on the theory behind this and also a good amount of examples! Speaking of which, you can also check out our samples for Responsive Web Design Custom Mode Template Switching and Responsive Web Design Mode of the Grid with Twitter Bootstrap Additional considerations Some “good to know about” extras – like the browser viewport. One of the most important things to consider is that many (if not all) smartphone browsers will 'lie' about their dimensions. It's not a bad thing, mind you – most phones these days have such high dpi that it will be impossible to read and interact normally with pages where everything is shrunk to the native resolution. Instead, as you can read on CSS pixel ratios (or, why all mobile sites are 320 pixels), pixels we would use for web development are now relative. The term ‘CSS pixels’ also pops up here and there, but basically the browser will almost always scale the pixels down (so 1 pixel will actually be multiple physical ones), which in term affects the browser viewport dimensions. Those dimensions, usually wider than the screen, are still small enough to squish a non-responsive page and big enough to force the user to scroll. This is where the all-time favorite meta tag comes in setting the viewport to match the device width (which removes that annoying scrolling) but limits your space further, something in the range of 320 – 460 of them virtual pixels! Remember the utility class table from Bootstrap I showed last time? I hope it does it make sense now why phones end up in their respective visibility class even in landscape. On the other side are tablets where many have a pixel ratio of 1 or 2 in the case of retina displays, but for all intents and purposes tablets usually hit the desktop size mark in landscape and only get to the tablet-specific styles in portrait. There’s a very large and very incomplete List of displays by pixel density on Wikipedia if you wan to have a look. There’s also an interesting issue with setting the IE10 viewport in CSS (as is per recommendation) rather than using the meta tag. The issue came out of nowhere and this blog on Responsive Design in IE10 on Windows Phone 8 helped me a lot. As it turns out, the bug applies actual physical pixels when using “device-width” in CSS. Eventually I tracked down the issue to Bootstrap’s own CSS - they applied to fix Win 8 apps in snapped mode, but it completely broke Bootstrap pages on Windows Phone. Keep that in mind, there’s a fix provided that feels hacky at best, but it does work so consider it if working with Bootstrap. Additionally, good things to remember is that touch devices have their special needs and oddities – make sure touch targets are big enough, remember touch events are separate and in the case of the Grid – consider applying the touch-friendly Windows UI Theme. And once more, have a look around those D3 blogs for mobile and usability related articles that can help you. Merging and Column Hiding As I hope it has become clear the Responsive feature allows for both hiding columns through setting and modifying the structure (markup) via templates. The template swapping is a source of quite a few possible modifications, perhaps one of the most useful ones is merging columns, as you may read in the docs. Now I know this might not be necessary, but better safe than sorry: don’t attempt to hide columns through the template or merge them (e.g. writing one less <td> cell). A main thing about the Ignite UI Grid is that is has columns array you usually define or have auto-generated – either way, row templates are designed to do just that – allow you to format the already existing layout! In other words, templated columns MUST match the layout defined or all data properties if generated! You will not get any results if column definitions and markup clash. So, for hiding columns you are stuck with defining column settings (not too pretty if they are a lot, I know). So how then exactly do you merge columns? Well one option is hiding a column though settings and adding its data to another still visible ones in a template. This is the approach you can see in our samples and it works best when the target column header is something that makes sense after you merge, like in that sample the Address taking in the country and city values as well. Another possible way that I personally like is though an Unbound Column. That way you can have the unbound setup with multiple data properties and only revealed when other are not. For example take this part of a grid definition where you have first and last name separate and an unbound column to take their place when on phone: $("#grid").igGrid({ columns : [{ unbound : true, key : 'name', dataType : 'string', headerText : 'Full Name' }, { key : 'FirstName', dataType : 'string', headerText : 'First name' }, { key : 'LastName', dataType : 'string', headerText : 'Last Name' }], //... features : [{ name : 'Responsive', forceResponsiveGridWidth : false, columnSettings : [{ columnKey : 'name', classes: "ui-visible-phone", configuration: { phone: { template: "<span>${LastName}, ${FirstName}</span>" } } },{ columnKey : 'FirstName', classes: "ui-hidden-phone" },{ columnKey : 'LastName', classes: "ui-hidden-phone" }] }] //.... }); Same thing using the ASP.NET MVC helpers: @(Html.Infragistics().Grid(Model) .Columns(column => { column.Unbound("name").DataType("string").HeaderText("Full Name").Template("${FirstName} ${LastName}"); column.For(x => x.FirstName).HeaderText("First name").DataType("string"); column.For(x => x.LastName).HeaderText("Last Name").DataType("string"); //... }) .Features(feature => { feature.Responsive().ForceResponsiveGridWidth(false).ColumnSettings(setting =>{ setting.ColumnSetting().ColumnKey("name").Classes("ui-visible-phone").Configuration(conf => conf.AddColumnModeConfiguration("phone", c => c.Template("<span>${LastName}, ${FirstName}</span>"))); setting.ColumnSetting().ColumnKey("FirstName").Classes("ui-hidden-phone"); setting.ColumnSetting().ColumnKey("LastName").Classes("ui-hidden-phone"); //... }); }).DataBind().Render() ) Essentially turning merging the two columns going from tablet to phone mode in the images below: As you may remember and notice above, when Responsive is used with Column Hiding you get that hidden indicator that is both a cue for the user something else is there and an interaction target to modify the visible columns. In terms of usability for touch though, it does feel slightly hard to hit. Good thing you can pick its width I guess – it seems that something in the range of 14-15px is much easier to hit, which is about double the default size. Of course, unless you arrange your columns in a way that all the ones you will be hiding are in front or at the end, you will get multiple indicators like I have above. Increasing their size for touch takes up even more of the already precious space. So either ensure arrangement or hide the indicator entirely - well, not really since right now there is no such option, but you can always set the width to 0! How would the user know of hidden columns and interact with the feature then, you may ask? Well, the Column Hiding and its API provide you with the necessary tools to build your own user experience by adding an external button to open the column chooser dialog and events to let you know and potentially display when columns are hidden to the user. The column chooser is easy to open with a single call and hiding and showing events are fired for each column separately (by both Hiding and Responsive!) so you can keep track of their count: <button id="openChooser"> Show/Hide Columns </button> <label id="hiddenColumns" data-count="0"> </label> $.ig.loader("igGrid.Responsive.Hiding", function () { $("#grid").igGrid({ //... features : [{ name : 'Responsive', responsiveColumnHidden: hidden, responsiveColumnShown: shown },{ name : 'Hiding', hiddenColumnIndicatorHeaderWidth: 0, columnChooserWidth: 300, columnHidden: hidden, columnShown: shown }] //... }); //initial state after load updateHiddenLabel($("#grid").data('igGrid')); $("#openChooser").igButton().click(function myfunction() { $('#grid').igGridHiding('showColumnChooser'); }); }); function hidden(evt, ui){ var label = $("#hiddenColumns"); var newHiddenCount = parseInt(label.data('count')) + 1; label.data('count', newHiddenCount).text("(" + newHiddenCount + " hidden)"); } function shown(evt, ui){ var label = $("#hiddenColumns"); var newHiddenCount = parseInt(label.data('count')) - 1; label.data('count', newHiddenCount).text("(" + newHiddenCount + " hidden)"); if(newHiddenCount <= 0){ label.data('count', 0).text(""); } } function updateHiddenLabel(grid){ var hiddenCount = 0; var columns = grid.options.columns; for(index in columns){ hiddenCount += columns[index].hidden ? 1 : 0; } $("#hiddenColumns").data('count', hiddenCount).text( hiddenCount ? "(" + hiddenCount + " hidden)": ""); } Note that you should pick a fitting size for the chooser (300 looks ideal, remember that’s in CSS pixels) as the Draggable and Resizable widgets on the chooser are not likely to work too well, unless you use one of those widgets that add touch support to jQuery UI. Of course, you can have the indicators and extra chooser shortcut as well – all depending on what fits your design needs better. Multi-Column Headers When you are using jQuery Grids with this feature there’s a slight consideration to keep in mind. With Column Hiding you can hide columns in groups directly through their multi-header keys. Event though the Column Hiding feature itself allows for such API calls and we’ve also been using “hiding a column” through the Responsive feature, it’s not the same thing. Responsive, much like Hiding, is hooked to the underlying grid framework that just won’t accept such calls because they don’t exist there. So short version – Responsive can’t hide multi-columns at once through their common header, you will have to provide settings for each separately. Responsive Hierarchical Grid Noticing the title? ‘Grids’? Yes, plural. Decided I should show some love for those with more complicated(hierarchical) data on their hands. Sometimes by looking at what we write and demonstrate someone would think we are forgetting about the Hierarchical Grid. We aren't really, we are merely forgetting how easy it is for readers and users to forget that it is build on top of actual flat grids. You know, there's actually a very normal igGrid widget running alongside the igHierarchicalGrid every time, even for the parent layout. When we talk features and functionality, we almost always have both controls in mind and only mention special cases. Point is this particular Hierarchical Grid is not afraid of some Responsive Web Design! The Responsive feature can be inherited but that, as with other features with column settings, won’t do you any good. In other words, the feature and its settings must be defined for each layout you want it on. Which is not half bad because you can apply separate recognizers and mode profiles for them. Twitter Bootstrap is also supported, which is to say you can use Bootstrap CSS classes for column visibility and mode recognition. And it’s also super easy to set up. Introducing the Responsive Web Design page with Ignite UI jQuery Hierarchical Grid and Twitter Bootstrap… whoa, that’s a mouthful! $('#grid').igHierarchicalGrid({ dataSource: '/Home/Departments', autoGenerateColumns: false, autoGenerateLayouts: false, responseDataKey: null, columns: [ //... ], columnLayouts: [{ columns: [ //... ], features: [{ name: 'Responsive', responsiveModes: { phone: "bootstrap", tablet: "bootstrap", desktop: "bootstrap" }, columnSettings: [{ columnKey: 'BusinessEntityID', classes: "visible-desktop" } //... ], rowTemplate: { desktop: "<tr><td>{{html BusinessEntityID}}</td><td>{{html LoginID}}</td><td>{{html NationalIDNumber}}</td><td>{{html Gender}}</td><td>{{html BirthDate}}</td><td>{{html MaritalStatus}}</td><td>{{html JobTitle}}</td><td>{{html OrganizationLevel}}</td><td>{{html HireDate}}</td><td>{{html SalariedFlag}}</td><td><div class='progressbar'>{{html VacationHours}}</div></td></tr>" } }] }], features: [{ name: 'Responsive', responsiveModes: { phone: "bootstrap", tablet: "bootstrap", desktop: "bootstrap" } }] }); The only difference is that you have to specify the Bootstrap recognizer if you need it, and use unprefixed classes for the column visibility like “hidden-phone” and you should be good to go: And the template you notice above is just for desktop where you can enjoy power and space so why not have a column with Gauges or sliders or progress bars in my case: Thinking about it, you get responsive design mode grid with responsive design grids in it in a responsive web design site/app – this should totally qualify for an Inception meme! Resources I have some interesting tips and tricks coming up next, so stay tuned! The super hacky JSFiddle on Responsive Web Design page with Ignite UI jQuery Hierarchical Grid and Twitter Bootstrap. That’s the full-screen version, the actual fiddle – code and all(preview probably in tablet or phone mode depending on how big your screen is) is here. An ASP.NET MVC demo with everything showed above in full code. The Hierarchical Grid here doesn’t use bootstrap so you can compare how very little difference there is in code. There’s a Webinar on Designing for Responsive Design tomorrow, don’t miss! Documentation - igGrid Responsive Web Design (RWD) Mode Responsive Web Design Custom Mode Template Switching and Responsive Web Design Mode of the Grid with Twitter Bootstrap Other awesome stuff: Ignite UI: What’s New in 13.1 HTML5, jQuery & ASP.NET MVC Controls Go grab Ignite UI 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!