Building An Adaptive Grid and Scheduler for Kendo UI

As a part of our Q3 2013 roadmap, which was announced last month, I mentioned that one of the key themes for the release was to make all Kendo UI widgets “responsive,” by default. Today, I’d like to talk about some approaches we’re considering for our more complex widgets, the Kendo UI Grid and Scheduler.

By now, you’ve no doubt heard the phrase “Responsive Web Design” (RWD) many times. Countless articles have been written on the subject, what it means, and how to adopt its principles as a developer, and I’m not going to spill any more (digital) ink here explaining what it means (though, if you’re curious, Burke did a nice job explaining the phrase and its origins in a post from earlier this year). Instead, let’s talk about RWD in terms of what it means for Kendo UI; namely, when building responsive sites, developers expect that the UI widgets and libraries they depend on will behave in a responsive manner, as well.

We agree, which is why bringing the “responsive love” to Kendo UI Web and DataViz widgets is a big part of our next release. For many of these widgets, the retrofit is straightforward. Where possible, our widgets will support percentage- and/or em-sizing and add the ability to automatically or manually resize based on container resize events or method calls. For widgets like the ColorPicker, ComboBox, DatePicker and others, these enhancements will cover all breakpoints, and quite well.

But the story is a tricky for a few of our more complex widgets, namely the Grid and Scheduler. For these widgets, it doesn’t make sense to simply “squish” the UI for smaller viewports. Instead, we think that these widgets should adapt their behavior on smaller viewports, and in some cases change their look and feel to deliver a better end-user experience in mobile-friendly apps.

For the rest of this post, I’m going to share a couple of ideas we’re considering for adding adaptive capabilities to the Kendo UI Grid and Scheduler. Please note, however, that these are all in process designs that that these screens and examples are not guarantees that a given feature or capability will be delivered in the Q3 release, or in exactly the manner described. Instead, we wanted to give you a “sneak peek” of some of out ideas as we hash out which direction to take our RWD enhancements for Q3.

Data Consumption First, Creation Second

When considering mobile versions of our Grid and Scheduler widgets, it helps to think about how these would be used by most end-users, on devices. In general, consumers tend to use smaller screens, like tablets and smartphones for consumption first, and creation second. And while this may not be the reality for all apps an in all scenarios, it’s a reasonable guideline to follow. As such, we believe that our focus for building adaptive complex widgets should favor using these widgets to communicate information over providing complex interactions, out of the box. This is not to suggest that complex interactions are not important at all, of course, and you’ll see cases below where we think these interactions should be delivered with our widgets.

Let’s take a look at a few examples, starting with the grid and filtering. For those of you who use the Kendo UI Grid with large data sets, you know that the built-in filtering capabilities are often essential to accessing the right data. In a mobile setting, we think a filtering UX could potentially look like the screenshot below, where a new screen would be introduced for filtering on mobile devices. In a tablet scenario, this filtering screen could be surfaced via an ActionSheet to deliver a mobile-friendly UX while keeping with common patterns in use on Tablet-sized devices.

Similarly, let’s consider creating or editing new events in the Kendo UI Scheduler. In a desktop setting, the Scheduler uses a Kendo UI Window as a pop-up for creating and editing events. In the case of mobile, we think a separate screen also makes sense for this scenario, as illustrated below.

 

When targeting mobile viewports, it’s also important to consider the main views of our information, and to focus on communicating only essential data, as opposed to cramming as much data as possible on the screen. Because mobile users, especially those on smartphones, tend to prefer targeted and read-first views of data, it’s important to prioritize what your users see when in these settings. Nowhere is this more true than in the Grid, where the default views on mobile may only be able to comfortably fit 2–3 columns on the screen, depending on the device size. Here’s an example of how we think that might look on a device, as compared to the full-sized Grid.

 

Having a high-level view of essential information is also true for the Scheduler, where data like the number of appointments across several days in a Month view is far easier to consume–and take action on–in a mobile setting than a replication of the blown-out view common to desktops. The example below allows the consumer to quickly view each day of the month by the number of appointments, and then drill into an individual day, as needed.

 

Default Views and Complex Interactions

Each of the examples above boils down to one of two common use cases for our Grid and Scheduler widgets, and a possible approach we’re considering for each. They are:

1. Complex Widget interactions (filtering, editing, etc) - Often, our complex widgets provide features that don’t map naturally to mobile. In these cases, new screens, or ActionSheets in a Tablet view, provide a nice UX that’s comfortable on Mobile without feeling forced or out of place.
2. Default Widget views (grid columns, calendar appointments, etc) - Widgets like the Grid and Scheduler are used to communicate a lot of data on desktop apps. In order to adapt these effectively to Mobile, we think it’s important to pivot the focus to either: a) the most essential data (as is the case for the mobile Grid); or, b) an adapted view that provides a slight pivot on the data, but which can still be drilled into, when needed (for example, the mobile Month view for the Scheduler).

Though the examples above aren’t final, they provide a sneak peak into how we’re thinking about making our more complex widgets useful for Mobile screens. We know you depend on Kendo UI to deliver apps across every device, and we want to make certain that you can rely on each and every widget to do this. We hope you like the direction we’re thinking of going, and feel free to leave any additional comments or questions for us below. We look forward to showing you the final result in our Q3 release!