#tds14

Sometimes the multi-select question items are better displayed as a series of checkboxes rather than a multi-select listbox where you need to option-click each option after the first one and hope you didn't mess up the other options you've selected. This script will make that transformation.

Here is a screencast of me demonstrating how to implement the script and what it will look like:

There are two steps involved in implementing the script. The first is to copy/paste this script into text interface field#259:

<script> /* Tested in TDS 14.0 */ /* Add to text interface field # 259 */ /* Add <input type="hidden" name="custom-UI" value="checkboxes" /> to question item instructions to activate */ $(document).ready(function () { // check for any multi-select questions tagged to be checkboxes $('input[name="custom-UI"]').each(function () { if ($(this).val() == "checkboxes") { // grab the checkbox options that will be necessary var qstName = $(this).parent().next().find('select').attr('name'); var qstOptions = new Array(); var selOptions = new Array(); $(this).parent().next().find('option').each( function() { qstOptions.push($(this).val() + "|" + $(this).text().trim()); if ($(this).attr('selected') == "selected") { selOptions.push($(this).val() + "|" + $(this).text().trim()); } }); // hide the existing listbox $(this).parent().next().find('select').css('display','none'); // build the new checkbox interface $(this).parent().next().prepend('<div name="custom-UI-' + qstName + '"></div>'); for (var i=0; i < qstOptions.length; i++) { if (i > 0) { $('div[name="custom-UI-' + qstName + '"]').append('<br />'); } var inpOptions = qstOptions[i].split('|'); $('div[name="custom-UI-' + qstName + '"]').append('<label><input type="checkbox" name="' + inpOptions[1] + '" value="' + inpOptions[0] + '">' + inpOptions[1] + '</label>'); if (selOptions.indexOf(qstOptions[i]) != -1) { $('div[name="custom-UI-' + qstName + '"]').find('input[name="' + inpOptions[1] + '"]').prop('checked', true); } } // assign the event handlers to the checkboxes to keep the existing listbox updated $('div[name="custom-UI-' + qstName + '"]').find('input').change(function () { checkboxChange($(this).parent().parent().attr('name'), $(this).val()); }); } }); }); function checkboxChange (questionitem, valuechanged) { // this will be the event handler for the changed checkboxes var isselected = false; if ($('div[name="' + questionitem + '"]').find('input[value="' + valuechanged + '"]').prop('checked') == true) { isselected = true; } $('div[name="' + questionitem + '"]').next().find('option[value="' + valuechanged + '"]').prop('selected',isselected); } </script>

This script will now be embedded in the applicant's questionnaire view. You are now ready to add the following tag to any multi-select question items that you want to change from a multi-select listbox to a series of checkboxes:

<input type="hidden" name="custom-UI" value="checkboxes" />

That's it. Now, whenever an applicant opens up a questionnaire with that question item, the interface will be transformed by the script you embedded in text interface field#259.

Here's what the script is doing...

When the page finishes loading, it is looking for any 'input' tags that have the name of 'Custom-UI' and a value of 'checkboxes' and running a function on each one. This will find of question items on the page that need to be changed.

First, the function will create a couple of arrays. One with all the option values for the multi-select question item, and another with all the options values for that question item that have been selected by the user because this might be a questionnaire the user has 'saved' and is returning to finish.

Next, it hides the existing listbox for the question item. We'll still need it though. It is going to function as the element that is getting passed in to the server.

Then, the script builds the checkboxes based on the first array and then marks the selected checkboxes based on the second array.

Finally, the script assigns an event-handler to fire off a function whenever one of those checkboxes change. That function will synchronize the checkbox's state with the hidden listbox.

As I mention in the screencast video, there are a few potential updates to this in the future. The obvious one is to put the checkboxes in multiple columns instead of a single column. This would preserve vertical space and also look nicer. Another potential way to update this script would be to enforce a maximum # of selections in a multi-select question item. Yet another potential update to this would be to display the options in a different manner. Maybe instead of having them appear as checkboxes, they could be displayed as a row of round buttons that you can click on and off. When it comes to ways to improve the UX on the questionnaire page, there are a lot of ideas that could be tossed around and implemented with just a bit of javascript.

Here's a script that connects a learning content page with an assessment so that you can automatically quiz an applicant on her/his comprehension of the material read as soon as it has been marked as such.

I know it's been a long time since I've posted something here. Things have just been crazy busy lately, but don't think I'm abandoning this blog quite yet. I've got a few projects in the pipeline right now, and I really just need the time to fully test and document them out.

So here's a screencast I recorded showing what this script does and how it works:

The code is a bunch of nested loops and 'if' blocks. Just copy and paste this into a plain text editor:

<script> /* Tested in TDS 14.0 */ /* Append to text interface field# 56 (for pre-decision) */ var linkedLCPAsmnts = [ ['NAME OF LCP','NAME OF ASSESSMENT'] ]; $(document).ready(function () { $('a[href*="FuseAction=Students.ContentView"]').each(function () { for (var i=0; i < linkedLCPAsmnts.length; i++) { if ($(this).text() == linkedLCPAsmnts[i][0]) { if ($(this).parent().next().find('div').attr('title') == 'Not Read') { $('a[href*="FuseAction=Assessments.Preface"]').each(function () { if ($(this).text() == linkedLCPAsmnts[i][1]) { $(this).parent().parent().css('display','none'); } }); } else { $('a[href*="FuseAction=Assessments.Preface"]').each(function () { if ($(this).text() == linkedLCPAsmnts[i][1]) { if ($(this).parent().next().find('div').attr('title') == 'Not Taken') { alert('You have completed the learning content page "' + linkedLCPAsmnts[i][0] + '". Please complete the assessment "' + linkedLCPAsmnts[i][1] + '".'); window.location.href = $(this).attr('href'); } } }); } } } }); }); </script>

Then you need to build your array of learning content pages and assessments by editing these three lines of code:

var linkedLCPAsmnts = [ ['NAME OF LCP','NAME OF ASSESSMENT'] ];

You'll be putting the name of the LCPs and assessments in it as an array of arrays (which is the interesting way that javascript implements multi-dimensional arrays). As an example, I want to pair the 'How to get a passport' learning content page with the assessment called 'Getting a passport', and I also want to pair the LCP called 'Safety abroad' with the assessment called 'Safety quiz'. My array would look like this:

var linkedLCPAsmnts = [ ['How to get a passport','Getting a passport'], ['Safety abroad','Safety quiz'] ];

A couple important details:

First, the code is case-sensitive - the name needs to match EXACTLY. One day, I'll get around to writing code that accounts for it, but don't hold your breath. The second thing to notice is the comma after the closing brackets after the first pair. That's an easy character to miss (Yes... voice of experience).

Now I'm ready to append that script to text interface field# 56 (pre-decision tips text). I'm assuming you want to do this in pre-decision, but it will work in any other phase as well. Once implemented, the script builds the array with the LCP and assessment name pairs and fires off a jQuery command when the document is completely loaded. This command is going to find every hyperlink on the page with a destination URL that includes, 'FuseAction=Students.ContentView' and run a block of code on each one of them:

Each anchor link with that URL destination is a learning content page link, and the block of code is going to loop through all learning content page names included in that array we built to see if the page is linked to an assessment.

If it turns out that there is a match between the LCPs on that application page and one that is configured to be linked to an assessment, we do a second check to see if that LCP is marked as read or not.

If it hasn't been marked as read, we then hide the assessment that it is linked to because the applicant shouldn't take that assessment until reading the LCP. If it has been marked as read, we check to see if the assessment it is linked to has been completed. If it hasn't, we generate the alert letting the applicant know that s/he needs to take the assessment on the LCP that has been marked as read.

This script demonstrates how you can create process elements that can be considered dependencies of each other. There are other ways to take this same concept and apply it in other ways. For example, if you wanted to have a questionnaire that should only be filled out after a signature document has been signed, you could have a similar script check the sig doc and then hide the questionnaire if it hasn't been marked as completed.

An important thing to remember though... this is a pure interface adjustment. It doesn't impact what the software considers when generating reminder emails. If you are hiding process elements, they will still appear as incomplete application requirements in the reminder emails. So you might get some confused applicants wondering how they are supposed to finish process elements that aren't appearing on the application page. However, if your linkages are pretty intuitive, it shouldn't be something that can't be figured out by the user.

The 'My Reviews' panel has an odd quirk to it. It displays the applications that aren't ready to be reviewed yet. If your reviewers have immediate access to review applications, that's not a problem, but if you want them to wait until you've marked the application as 'ready for review', there's no reason to have them displayed on the page. This script will hide the 'not ready for review' applications in that panel.

This is a very simple script to implement, just append it to text interface field# 3551:

<script> /* Tested in TDS 14.0 */ /* Add to text interface field # 3551 */ $(document).ready(function() { $('a[href="javascript:alert(\'This application is not ready for review..\')"]').each(function() { $(this).parent().parent().css('display','none'); }); /* uncomment these lines to also hide the submitted reviews $('b:contains("Review submitted:")').each(function() { $(this).parent().parent().parent().css('display','none'); }); */ }); </script>

Now, the reviewers will only see the applications that have been marked as ready for review or have had a review submitted. All the others will be hidden.

The script is selecting every anchor link on the page that generates the javascript alerts letting the reviewer know that the application hasn't been marked as ready for review. For each one, it is traversing up the DOM to get the the row element for that application and changing the css to hide the row.

However, let's not stop there. There's another way this listing gets cluttered up. After a reviewer has submitted the review, the application still appears in the reviewer's list showing what their recommendation was. If this really isn't necessary information, you can hide those rows as well by 'uncommenting' the lines:

/* uncomment these lines to also hide the submitted reviews $('b:contains("Review submitted:")').each(function() { $(this).parent().parent().parent().css('display','none'); }); */

This means that the final script you implement in the text interface will look like this:

<script> /* Tested in TDS 14.0 */ /* Add to text interface field # 3551 */ $(document).ready(function() { $('a[href="javascript:alert(\'This application is not ready for review..\')"]').each(function() { $(this).parent().parent().css('display','none'); }); $('b:contains("Review submitted:")').each(function() { $(this).parent().parent().parent().css('display','none'); }); }); </script>

A common method for coders to use to make something in their code optional is to use the commenting characters to deactivate lines of code instead of creating a bunch of configuration variables at the beginning of it. When you remove the commenting characters, you are adding an additional command to the script. This looks for any bold tags with the text 'Review submitted:' in them. These are the tags in rows where the review was marked as completed by the reviewer. It will then iterate over each of them to traverse up the DOM and hide the row by manipulating the 'display' attribute.

Join us on October 1st for The Digital Shift: Libraries @ The Center, a dynamic day-long online conversation about our shared digital future. 

It's not too late to register for this great lineup of speakers and topics, including:

Who’s Afraid of the Internet? Digital Literacy, Corporate Data-Mining, and Government Surveillance

This session will discuss the challenges of promoting digital adoption and digital literacy in the post-Snowden era of widespread reports of government and corporate surveillance of internet traffic. It will discuss teaching techniques to distinguish well-founded skepticism from unfounded skepticism and helping digital learners do a cost benefit analysis in a learning environment based on respect and consent. The session hopes to touch on interpreting concepts like “free”, “open”, “private”, “commercial”, and “non-commercial” in their digital context, and conclude with some practical resources for increasing online privacy (DuckDuckGo, Disconnect.me, and others)

Presenter: Scott Pinkelman, Digital Literacy Innovation Specialist at the Free Library of Philadelphia (PA)

Implementing New Digital Strategies in Response to a Community Emergency: The Queens Library Post Super-storm Sandy

In October of 2012, Super-storm Sandy devastated the Rockaways. Queens Library stepped up to provide critical crisis information services in the weeks that followed. Among the most requested service was access to online information as thousands of Queens residents lost both connectivity as well as their digital technology in the storm’s aftermath.  When Gov. Andrew Cuomo and Google combined to donate 5,000 Google Tablets to Queens Library for use in those affected areas, the library stepped up. But how to respond when broadband access was scarce or not available? QPL used this lack of Wi-Fi access as a design inspiration and a springboard for innovation. QPL built a tablet platform loaded with Queens Library content– useful with or without Wi-Fi. Today library customers in and beyond Queens’s storm affected areas have access to curated, practical resources with a special focus on resources that aid their economic viability.  Lessons learned from this work should spark new thinking about the central role of public libraries in community informatics and disaster assistance and recovery. This presentation will outline how Queens Library developed a proprietary interface platform preloaded with specific community resources and customized content to assist  the community in finding information about disaster relief, housing, jobs, education, community health, and immigration information. Queens Library received the 2014 ALA Library of the Future

The display of program parameters on the public brochure page can sometimes be a bit difficult to massage into an aesthetically-pleasing format. There aren't a lot of settings to mess with, and trying to fix it up with CSS is not easy because of the way that the data is rendered on the page. This script says, "To heck with it all - let's parse the data on the page - nuke and pave!"

So, this was my first screencast, and I know the sound quality and organization could be little bit better, but rather than spend weeks polishing up a more rehearsed script and re-re-re-recording something till I get bored and quit, I decided to just take a quick whack at it and see how it turns out.

The code I've posted to the repository just needs to be downloaded and appended to text interface #3, and that will take your existing 'Fact Sheet' on the brochure page and re-render it using semantically classed 'div' tags rather than a cumbersome table:

It will also not display any program parameters that have option values that turn out to be more than 200 characters. However, if you don't like that aspect of the script, you can modify that behavior by adjusting this line in the script:

if (paramvalue.length < 200) {

By adjusting the logic in this line, you can determine whether or not a parameter should be displayed. The 'if' statement is just looking for a condition that makes the parameter acceptable to render.

Most likely, the part of the script you'll want to modify is the 'style' block at the end. By adjusting these CSS statements, you can change the way your program parameters appear on the page. By default, it's rather boring, but here are some alternative ways to display your program parameters.

First, this configuration will make them appear in three columns instead of two:

<style> #custom-fact-sheet { padding: 10px; } #custom-fact-sheet .cfs-parameter { float: left; width: 33%; padding-bottom: 15px; } #custom-fact-sheet .cfs-param-name { text-decoration: underline; } #custom-fact-sheet .cfs-param-value { padding-left: 5px; } #custom-fact-sheet .cfs-glosslink { color: blue; } </style>

All you have to do is adjust the 'width' of the parameter class so that three parameters can fit in a single row (33% instead of 50%):

Next, this configuration will put each parameter in a rounded square with a drop shadow and pack them in as tight a space as possible.

<style> #custom-fact-sheet { padding: 10px; } #custom-fact-sheet .cfs-parameter { background-color: lightblue; border-radius: 10px; box-shadow: 0px 0px 5px black; float: left; margin: 10px; padding: 10px; } #custom-fact-sheet .cfs-param-name { text-decoration: underline; } #custom-fact-sheet .cfs-param-value { padding-left: 5px; } #custom-fact-sheet .cfs-glosslink { color: blue; } </style>

This involves adding a bunch of decorative CSS statements and removing the 'width' statement from the parameter class:

Finally, this configuration will adjust the font size and create a 'hover' state for the parameter 'div's:

<style> #custom-fact-sheet { padding: 10px; font-size: 15pt; } #custom-fact-sheet .cfs-parameter { float: left; width: 50%; padding-bottom: 15px; } #custom-fact-sheet .cfs-parameter:hover { text-shadow: 0px 0px 5px lightcoral; } #custom-fact-sheet .cfs-param-name { font-weight: bold; text-decoration: underline; } #custom-fact-sheet .cfs-param-value { padding-left: 5px; } #custom-fact-sheet .cfs-glosslink { color: blue; } </style>

In this one, after adding some statements to the parameter class, I've added a new style block for the 'hover' pseudo-selector that adds the colored shadow under the text when the mouse is over it:

Definitely feel free to experiment even more with this and combine the various techniques. Let me know if there are other variants of this that you'd like to see. I think the next step in this script would be to update the 'pop-up' for the glossary entries so that they use a modal window rather than a separate window/tab (those are sooooo 2004). Obviously, another potential mod for this would be truncating long parameter value options with a toggle to display the full value.

I finally got around to updating the API-driven program search that uses the public interface API to build a dynamic Google map of results from a series of checkbox panels. It will now support program parameters as search criteria with just a couple adjustments.

It's been a long time coming, but the update has been posted to the github.com repository and is ready for use. Now, along with the region and terms, you can have program parameters appear as search filters in this dynamic program search.

Just like before, implementing this search is really easy. You just need to download the HTML file from the repository and then open it in a plain text editor. There are three primary configuration options:

var sitedomain = "//#SITE DOMAIN HERE#/"; var searchparameters = ""; var mapsapikey = "#GOOGLE API KEY HERE";

These are the ones you have to fill out. Although, you can leave the 'searchparameters' one empty if you don't want to implement any as search filters. When you're done, it should resemble something like this:

var sitedomain = "//studyabroad.terradotta.com/"; var searchparameters = "10000,10002"; var mapsapikey = "AIazSyB05xlejW9d0JVE0hTLIaRys0Do5MzbVJU";

If you don't know what your program parameter ID#s are, you can quickly find out what they are by just going to the Maintenance > Data Import/Export Utility and exporting the program template. The header of that template will have each program parameter with the ID# after it. Put them in there as a comma-delimited list and you're ready.

Don't forget about the other configuration option though. There is a variable later in the script where you can identify specific terms that you want to filter out of the search:

var excludeTheseParamsArray = []

You can remove your extra terms that might not make sense for an outgoing program search. So if I didn't want 'summer2' or 'winter-spring' to appear in my list even though they are terms on my site, it would look like this:

var excludeTheseParamsArray = ["summer2", "winter-spring"];

This can sometimes happen when you've got other program types that add terms that don't make sense, and while we're on the topic, this search is for the 'Outgoing' program type. If you've implemented the outgoing with side trips and OneStep program type as a separate program type, it won't find programs assigned to that type.

This is actually an issue I've reported to the Terra Dotta developers already. You can't search multiple program types with a single API request. Technically, if I wanted to, I could make multiple API requests and combine them into a single set of results, but I'd rather just wait for the API to support multi-program type requests and then add that capacity to the code. It keeps the code cleaner and faster.

Once your configuration is done, you just copy/paste that HTML into the WYSIWYG Editor of a page on your site, and you're good to go.

This update took a bit of work and some refactoring of existing code, but the last round of refactoring it went a long way towards making this update a lot easier. Program parameters are a bit more complicated to work with because you need to identify the type of program parameter it is and also the construction of the parameter in the URL is bit more complicated.

I'm thinking the next major update to this could be one of two things. Either I can get rid of the dependencies on the Terra Dotta CSS classes and structures so that the code is truly portable and able to be implemented anywhere, or I can turn the filters into 'buttons' that open a modal interface where you make the changes to the checkboxes and then updates the search results when you close that modal. This would save on the vertical space and allow the map to just appear without the user having to scroll down.

Till then, feel free to let me know if you see other areas where this could be improved upon.

If you've got process elements in your application process that have due dates that don't fit the natural four-phase schedule of Terra Dotta software, this is a bit scripting magic that can create due dates for process elements on the application pages.

This system will allow you to designate specific process elements to have specific due dates for each application cycle on a program by program basis. Now, before you start getting REAL excited about this, let me point out that all this script does is put these colored due date elements on the application pages. It isn't an actual data point in the software that you can query and report on, and while I tried to figure out a method to put a notification like this on the applicant home page, I wasn't able to come up with a feasible solution for that. If you want to have notifications and such go out to your users, you'll still need to manage that through query watches and such. This script is simply a way to have a due date appear on the application pages without you having to put that information in the content of the process element itself or, heaven forbid, actually put it in the name of the process element. It is also more effective than having the due dates all stuffed in the application instructions panel. Even though, coincidentally, that is actually where the information is stored.

So here are the steps to implementing due dates for a program:

1.) Download the application page script from the github.com repository and save it to your local drive.

2.) Put that script in text interface field 56 and/or 12318 depending on whether you need these due dates for the pre-decision or post-decision process elements.

3.) Download the due date template file from the github.com repository and save it to your local drive.

4.) Modify the due date template file so that it has your necessary due dates for process elements.

This is really the work involved in implementing. You're going to take the template that is provided and looks like this:

<span style="display:none"> <!-- Tested in TDS 14.0 --> <!-- Process element due dates - add to phase instructions--> <input type="hidden" class="process-due-date" value="NAME OF PROCESS ELEMENT|TERM,YEAR|MM/DD/YYYY" /> </span>

... and you will change the 'input' tag so that it has the name of the process element, the app cycle of the due date, and then the due date itself. If you have more than one due date, just copy/paste that input tag as often as you need. So that you end up with something that looks like this:

<span style="display: none"> <!-- Tested in TDS 14.0 --> <!-- Process element due dates - add to phase instructions--> <input type="hidden" class="process-due-date" value="Outgoing Cond. Pre-Dec Sig Doc 1|Fall,2015|08/01/2014" /> <input type="hidden" class="process-due-date" value="Outgoing Pre-Dec Sig Doc 2|Fall,2015|08/08/2014" /> <input type="hidden" class="process-due-date" value="Outgoing Pre-Dec Sig Doc 1|Fall,2015|08/28/2014" /> <input type="hidden" class="process-due-date" value="Mobile Number|Fall,2015|08/01/2014" /> <input type="hidden" class="process-due-date" value="Outgoing Pre-Dec Mat Sub 2|Fall,2015|08/14/2014" /> </span>

5.) Copy/paste this to the program application instructions in the phase in which you need the due dates to appear. It'll look like kinda like this:

If you only have a few due dates to set up and they're pretty much consistent across all your programs, you might be able to just embed this in a text interface field on the page rather than in the program application instructions. Basically, as long as it is on the page somewhere, the script you embedded in the tip will find it.

Also, if the app cycle you are creating the due date for is dual-year term, you'll need to include both years. So if the app cycle is 'Academic Year, 2014-2015', your value for it in the input tag would be 'Academic Year,2014-2015'.

... and like most scripts like this, it is case-sensitive so you need the name of the process element to be an EXACT match.

So what is the script actually doing?

First, the script is getting the current data and the app cycle of the application. It does this by grabbing the app cycle out of the information panel and splitting it into a term/year array. This is why the input tag's version of the year needs to include both years for dual-year; so it will match what was scraped off the interface.

Next, it looks for all the hidden input tag and iterates through each of them with this loop:

$('.process-due-date').each(function () { var duedatedata = $(this).val().split('|'); if (duedatedata[1] == apptermyear) { var status = $('a:contains("' + duedatedata[0] + '")').parent().next().find('div').attr('title'); if (status == "Not Received" || status == "This questionnaire is incomplete." || status == "Not Read" || status == "Not Taken") { processcheck(duedatedata); } } });

It first checks to see if the application matches the input tag's app cycle, then checks to see if the process element in that input tag is an incomplete process element in that application. If that's the case, it runs the 'processcheck' function for that process element.

The function 'processcheck' is a routine that compares that due date with the current date. First, it just adds the due date to the right of the process element's name. It will appear in the non-threatening blue color scheme.

Then, it checks to see if the due date is less than the current date (It's today or in the past), the due date class is replaced with a due date alert so it will appear to the right of the process element's name on the page in red.

If the due date isn't less than the current date, another check is done where the due date has 604800000 subtracted from it. That's how many milliseconds there are in a week which is really what a javascript date object is ... the number of milliseconds since Jan 1st, 1970. Now, if the ue date is less than the current date, it means this process element will be overdue within the next week. In this case, the due date class is replaced with a due date warning class.

After all the hidden due date input tags are checked, there is the final check to see if there were any due dates warnings or alerts added to the page, if there were, it puts the proper box at the top of the page.

Finally, there's a 'style' block at the end of the code that can be manipulated if you want to adjust how these due dates appear:

.duedate-alert { color: #D8000C; background-color: #FFBABA; font-weight: bold; } .duedate-warning { color: #9F6000; background-color: #FEEFB3; font-weight: bold; } .duedate { color: #00529B; background-color: #BDE5F8; } span[class*="duedate"] { padding: 1px 5px 2px 5px; white-space: nowrap; border-radius: 10px; }

You can adjust the font size, weight, colors, etc. to your liking. Feel free to mess around with them in case you feel like they aren't eye-catching enough for your applicants.

A few things to keep in mind about the way this works though:

If you have a lot of due dates and app cycles to manage, they might not all fit in the instructions box for the program. In these cases, you'll want to seek out other text interface fields on the page to use. However, that will make them less transparent/accessible to your other admins who work in the program builder.

If you use the data import/export utility for program data, be careful about re-importing the content. It won't break it, but it will strip out all the line breaks and turn this template into one long block of text.

An alternative system for this would be to have this script and due dates stored in the document center as objects that are fairly easy to manipulate and then just have the application pages fetch their content to check the dates. However, that involves additional server requests, and part of what is nice about the system I've posted here is that everything needed is on the application page when it's done loading.

As I mentioned before, I tried putting in a routine on the applicant home page that would check all the prior and current year applications so that applicants could know on their home page where there are applications with warning and alerts, but unfortunately, that started getting into bad territory where I felt the potential for bombarding the server with a bunch of background requests and expecting the current page to be able to process them reliably was getting too risky. I might return to this again in the future though should I come up with a less heavy-handed approach than 'loading all your application pages in the background'.

If you've been using the software for a few years, something you might have noticed is that the 'Dates' tab of the program builder can get a bit cluttered. Here is a script you can embed on that page that will help manage the length of that table so that you aren't having to scroll past data that's a few years old.

To implement this change, append this script to text interface field# 4445:

<script> $(document).ready(function () { // get the current year var today = new Date(); var curyear = today.getFullYear(); var cutoffyear = curyear - 2 // set the unchanged flag var changed = 0; // select all the rows in the table $('table[summary="This table shows program dates."]').find('tr').each(function () { // for each cell in each row, check to see if it matches a year more than a year in the past var rowdata = $(this).find('td'); var celldata = $(rowdata[1]).text().trim(); if (celldata.slice(4,5) == "-") {celldata = celldata.slice(0,4)} if (celldata.length == 4) { if (celldata <= cutoffyear) { // if it is, then assign it the 'old year' class $(this).addClass('old-year-row'); // check for a program date record notes row after it if ($(this).next().find('td:contains("NOTE:")').length == 1) { // if there is one, assign it the 'old year' class too $(this).next().addClass('old-year-row'); } // update the unchanged flag changed = 1; } } }); // did we change things? if (changed = 1) { // get rid of the gray background cells $('table[summary="This table shows program dates."]').find('.bg-gray-color').removeClass('bg-gray-color').addClass('bg-white-color'); // yes, hide the old year class elements $('.old-year-row').css('display','none'); // create the button for the toggle $('table[summary="This table shows program dates."]').find('tbody').append('<tr>,<td colspan="8" class="left-bdr "><input type="button" value="toggle older date records" id="date-toggle" /></td></tr>'); $('#date-toggle').click(function () { toggleDates(); }); } }); function toggleDates() { $('.old-year-row').toggle(); } </script>

It's quite a bit of code to parse through all the dates in the table but once it's done, manipulating them is pretty straightforward. It's starting off by getting the current year and setting the 'cutoffyear' to the current year minus two. So, if it is 2014, it will be hiding the program date records from 2012 and earlier.

After setting a flag for determining if anything was manipulated, a jQuery command sets up a loop to go through each row in the table where we display the program dates. It grabs the second cell in each row which should be the year of the date records. Then, it checks it to make sure it isn't a dual-year term (chopping off the extra part of the year if it is).

If the the year is equal to or less than the cutoff year, that row in the table gets assigned a class of 'old-year-row'. Then, there's a check to make sure the next row in the table isn't the notes for that program date record. If it is, that row also gets the class 'old-year-row'. Then, since we've changed something, we set that flag to indicate we've changed a row.

Once we've gone through all the rows and assigned a class to any of the rows that we want to hide by default, the rest is pretty straightforward. First, we get rid of the zebra-striping in the table since it is going to look funny when we hide the old date records. Then, we just hide all the rows with that class 'old-year-row'. We add a new button to the interface that has a click event handler that will toggle any rows with that 'old-year-row' class.

If you've been running a site for more than a few years, this will very likely make things look a LOT nicer when you go to the dates tab, and maybe a future project of mine to improve this script will be not just to hide the older date records... but to actually sort the rows by the application deadline dates properly rather than alphabetically, but for now, I can at least make it a shorter trip to the drop-down menu for creating new program date records.