Archive
Time span sliders in jQuery
I’ve been working on prototyping a new application that needed a way for users to schedule things in spans of time on multiple days. It should be quick and easy for people to pick arbitrary time spans on each day of the week. The main use case is to set a day time block, during business hours for example, or a block that excludes business hours. Someone might schedule the time span from 8am to 5pm, or they might schedule it to end at 8am and then start again at 5pm. I looked around but didn’t find any examples of doing anything like this that I liked.
I settled on a slider that you can invert. So you can set the range from 8am to 5pm, then click on a check box that flips the slider to mean everything except for 8am to 5pm. It needs to be visually obvious what this is doing, so the slider and text needs to reflect what is happening. I think the result is fairly easy to use and very workable. The layout looks something like this:
The other thing I wanted was to be able to drop the whole thing in a page easily based on code in one place. I anticipate it will be used in more than one location within the application. So I wanted to construct it as a jQueryUI widget that basically wraps the standard slider widget. I didn’t try to make it portable beyond this app. There are a few things I’ve done here that you wouldn’t want to do if you were making a normal jQueryUI plugin. For example, it carries the HTML for laying out the text and sliders within the widget. I think its illustrative for a prototype, but not elegant.
Posts on doing multiple sliders or time based sliders are not easy to find. The best one I found was from Marc Neuwirth. That post saved me some time in figuring out how to deal with the times on the slider. There is also an improved slider on the Filament Group’s site, but it doesn’t really answer the basic needs I had. The fact that I had a hard time finding examples from other people who’d already done the same thing is what prompted this post.
For a time slider, we need to convert the times to integers so we can use them for slider values. To convert the time to an integer, we split the time into hours and minutes, multiply the hours times 60, and add back the minutes. We do the reverse to turn the integer into a formatted time for display. In the code below these operations are done in two functions, named formatTime and getTime. These are single use functions I don’t have a need for elsewhere, so I’m carrying them inside the narrow scope. If I ended up having a similar need somewhere else I’d refactor that out to make it usable elsewhere.
Since I’m making a jQueryUI widget (sort of), I start with the basic self executing function and the widget factory method.
(function($){
$.widget("ui.timeslider", {
});
})(jQuery);
To that, I need to add the options object, which will allow us to set our options for the widget and also double as the options we’ll pass to the individual sliders. That last bit gets a little sticky, because we’ll have a changing scope as we deal with events within seven different slider (sub)widgets. Usually I wouldn’t put the whole callback function in the options definition, since its harder to read and maintain, but its easier to make it portable to each of the sliders this way.
options: {
animate: false,
days: ["monday","tuesday","wednesday","thursday","friday","saturday","sunday"],
distance: 0,
max: 1440,
min: 0,
orientation: "horizontal",
range: true,
slide: function(event,ui){
function formatTime(time){
var hours = parseInt(time / 60 % 24);
var minutes = parseInt(time % 60);
minutes = minutes + "";
if (minutes.length == 1) {
minutes = "0" + minutes;
}
return hours + ":" + minutes;
}
var startTime = formatTime(ui.values[0]);
var endTime = formatTime(ui.values[1]);
var selector = "#"+this.id;
$(selector + "-time1").val(formatTime(ui.values[0]));
$(selector + "-time2").val(formatTime(ui.values[1]));
},
step: 5,
value: 0,
values: [360, 1080]
},
Most of these options are the standard slider options. The only addition is the days array, which we’ll use to add the individual days to our results. Putting it in the options this way lets us pass in a different set of days if we wanted to (maybe Monday through Friday are more appropriate in some places). The slide callback is basically a typical callback for the slider widget. The id based selector will make more sense in a bit.
The rest of the widget is all in two methods: _create and _sliderhtml. _sliderhtml just holds our html to build the containers for the individual sliders. The underscore at the front of the method names are how we tell the jQueryUI factory that they are private.
_sliderhtml: function(day){
var displayday = day.charAt(0).toUpperCase() + day.substr(1);
var html = ""+
'<div class="fieldrow spacer">' +
'<div>' +
'<label for="'+day+'-time" class="inline">'+displayday+':</label> ' +
'<span id="'+day+'-midnight1" style="display:none">midnight to</span> '+
'<input type="text" name="'+day+'-time1" id="'+day+'-time1" value="6:00" class="blended"> - '+
'<input type="text" name="'+day+'-time2" id="'+day+'-time2" value="18:00" class="blended"> '+
'<span id="'+day+'-midnight2" style="display:none">to midnight</span> '+
'<span>Except <input type="checkbox" name="'+day+'-except" id="'+day+'-except"></span>' +
'</div>' +
'<div id="'+day+'"></div>' +
'</div>';
return html;
}
That’s not pretty, and the wrapping displayed here makes it look even worse. This is special use widget, intended for one application. I wouldn’t build more general use widgets with the HTML like this, because you have to edit the widget code to change the layout, but its fine for my limited purpose here. This is the HTML for one slider. We’ll pass it the day from the days array in the options and use the day name for our field names and element IDs. We change the first letter of the day’s name to upper case to make the label.
_create is the standard method that will be used by the jQueryUI to construct our widget. It looks like this:
_create: function(){
var self = this,
o = this.options,
dayslength = o.days.length;
o.timeslider = this;
function getTime(time){
var times = time.split(':');
time = (times[0] * 60) + parseInt(times[1]);
return time;
}
for(var i=0; i < dayslength; i++){
self.element.append(self._sliderhtml(o.days[i]));
$( "#" + o.days[i] ).slider(o);
$( "#" + o.days[i] + "-time1" ).bind("change",function(){
var slider = "#" + this.id.substr(0,this.id.length - 6);
var newval = getTime($("#"+this.id).val());
if(!isNaN(newval)) $(slider).slider("values" , 0 , newval);
});
$( "#" + o.days[i] + "-time2" ).bind("change",function(){
var slider = "#" + this.id.substr(0,this.id.length - 6);
var newval = getTime($("#"+this.id).val());
if(!isNaN(newval)) $(slider).slider("values" , 1 , newval);
});
$( "#" + o.days[i] + "-except" ).bind("change",function(){
var excl = "#"+this.id;
var sliderlength = excl.length - 7;
var slider = excl.substr(0,sliderlength);
var exclude = $(excl).is(":checked");
if(exclude){
$(slider).addClass("ui-widget-header");
$(slider).removeClass("ui-widget-content");
$(slider + " div").addClass("ui-widget-content");
$(slider + " div").removeClass("ui-widget-header");
$(slider + "-midnight1").css("display","inline");
$(slider + "-midnight2").css("display","inline");
} else {
$(slider).addClass("ui-widget-content");
$(slider).removeClass("ui-widget-header");
$(slider + " div").addClass("ui-widget-header");
$(slider + " div").removeClass("ui-widget-content");
$(slider + "-midnight1").css("display","none");
$(slider + "-midnight2").css("display","none");
}
});
}
},
The interesting part, and basically the whole reason for the widget to exist, is in the for loop in this method. self.element is the element from the selector in our page. So we might create the widget like this:
$("#scheduler").timeslider();
In that case the DOM element with “scheduler” as the ID will be self.element within the _create method. We iterate through our options.days array and append the html from _sliderhtml for each day in the array. Then we put a slider widget in each of those blocks of HTML (line 16 above), passing it the same options array we’re using. It has the extra days array, but the slider widget will ignore that. The rest of the loop is adding event bindings to the three input elements embedded in our HTML.
The first two input elements hold the times. This makes grabbing the values extremely easy, because we have an input element with an ID. We put the values in these fields in the slide callback in the options (line 23 and 24 in the second code block in this post). Here we’re binding an onchange to these elements. That allows a user to click on the times and type in a new value, which will move the slider to what they typed. It might be that nobody will ever do that, but I think it’s a nice feature.
The third event we’re binding is a change event to our checkbox. The string manipulation on lines 29 and 30 is identifying the various elements that make up our layout. On line 31 we see if the checkbox is checked or not, and then depending on that we set styling on the slider.
As a last step, I added another checkbox at the top to disable the whole thing, but that’s not actually in the widget. When you click the checkbox it does this:
function(){
if($("#turnitoff").is(":checked")){
$("#scheduler").timeslider("disable");
} else {
$("#scheduler").timeslider("enable");
}
}
This highlights the benefits of using the jQueryUI widget factory for this exercise, if that wasn’t clear already. By using the widget like this, we get the disable and enable methods, and all the other standard widget methods built in.
This is prototype, and I’m not sure yet if it will make it into the production application. If it does (and I remember) I’ll update this to show it used in context. If it gets into production it will likely need some refinement. For example, the checkbox might be better as a button and “Except” is not the right label, and there are a few other things I’d tweak. In the meantime, I hope this is useful for someone.
Learning and community life cycles
My first round of experience learning a web development environment was in the 90’s, when I needed new ways to deliver financial reports to department managers and built web reporting using ASP pages on Windows NT servers. It was live. It was on demand. You didn’t need to run a special client program to get your reports. It was one of my first experiences of providing people with a tool that they hadn’t realized they needed, but within a few weeks everybody was convinced it was essential to getting their work done.
I jumped into the online communities (basically email back then) and asked and answered questions in various groups. I quickly realized that PHP fit what I was trying to do better, and I moved to the PHP community. I learned a lot from those groups. My personality is to listen more than I talk, both online and off, but in those days I was excited about what I learned and wanted to help others learn it too.
It didn’t take me long to notice that people ask pretty much the same questions over and over. Many groups online are used largely by people who are learning a new technology. That’s a critical function, and its a good way to distribute the learning. Like many people, I got tired of answering the same questions, and started thinking maybe people should at least make an attempt to look at the group’s archives.
Since I first started, we’ve moved through forums, blog posts with arguments in the comments, and then to sites like stackoverflow.com and microblogging. They are all useful, and all of these formats for distributing information and learning still continue to some extent even as they are replaced by newer models.
Its fun to go through the life cycle with each new technology. You learn something new, hit snags, and go looking for where the community is. Its even more fun when the community is new and the best practices are still being fleshed out. The beginnings of the CouchDb and Node.js communities were more recent examples of that for me. I didn’t catch either of those waves right at the beginning, but I was fairly early. True to my personality, I tend to listen more than talk, but I enjoy the discussions of sorting out the best way to do things.
The great thing about the early days is that the questions aren’t old for most anybody. Not that long ago the package manager for Node wasn’t settled, and there were discussions about the best way to handle that need. Now npm is the standard, and the question is fairly well settled. People still raise the question of whether it should work differently, but most of the questions have been answered. At least for the moment, npm’s place in the Node.js world is fairly settled. In this case, it happened fairly quickly.
Each generation of developers, of course, reinvents it all. Before long you start to see the same discussions popping up in every community. I’m amazed by people who continue to patiently answer the same question again and again. I don’t have the patience for it. I am much more tolerant of helping people in one on one, mentoring new developers in my team, especially when the new guy is really learning.
In Node, people get caught by async programming, and look for ways to make it work differently. Maybe at some point people will come up with a new paradigm, but Node is async and uses callbacks. If you don’t like that maybe you’re on the wrong platform. In Couchdb people get caught on how to construct views, and whether you can make views dependent on external conditions like the contents of other documents. Someone explains again why it doesn’t work like that. Some discussions never die, like when people find new ways to do things insecurely or rediscover familiar patterns. I’ve recently seen some discussions about dependency injection in PHP that seem rather worn to me.
The communities as a whole go through the same cycles too. People from the Erlang community might notice that many of the discussions and debates in the Node.js community are struggling with issues Erlang had to solve during its earlier stages. Languages evolve and have to struggle with “new” issues that are familiar to other platforms, like when PHP adds new pieces of the OOP puzzle and new debates about typing and inheritence in Java erupt in new contexts.
The world in general owes a great deal to all of the people who work through these cycles, and especially the role filled by people who seem to tirelessly answer the newbie questions. We’re all starting somewhere, and usually we find ourselves learning new things fairly often as the paradigms change. I’ve been through a few generations of PHP and MySQL, but I’m newer to CouchDb and Redis. The cycles repeat, but not exactly. Every once in a while something truly new emerges and things progress. That’s a side effect of the same challenges being faced again and again. Every once in a while, someone asking the same question the billionth time does come up with a novel answer. Then we wonder how we ever got by with the answers we all accepted before. Other times people give a name to something people have been doing for a while. Things move on. Technologies and people come and go. The tools we have now are worlds beyond what we had before. What’s next? Who knows, but there will be people learning it, and asking questions, and someone will be tirelessly answering the new questions for the billionth time. To the people who ask the same questions until the answers finally do change, and to all those people who answer the same things again and again: Thanks!
David's Tech Blog 