#studioabroad

[gsdstudioabroad]

We’ve moved to Instagram

Follow @gsdstudioabroad​ on Instagram for an inside look at our spring 2019 studio abroad in Tokyo under the tutelage of Sou Fujimoto, as well as for updates on upcoming studios abroad. Previous posts will remain archived on Tumblr. Learn more about the program at gsd.harvard.edu/studio-abroad.

[gsdstudioabroad]

Amsterdam, A visit from the GSD, Midterms and a Third Birthday

The past two weeks have been rather eventful. We’ve had a spontaneous afternoon trip to the Amsterdam office to present our work to Rem, a visit from a GSD studio, our midterm presentations and a third birthday.

Two weeks ago, some of our studio went to Amsterdam with AMO to present some updates to our presentations. We stayed for dinner and then ventured out to explore Amsterdam for a bit before heading back to Rotterdam.

Earlier last week, we had a visit from a studio from the GSD. It was really lovely to see familiar faces again and hear about life back across the pond.

On Friday we then had our mid-term presentations. We each presented our topics and the research we had carried out up until then to a (rather large) group of critics. Our internal critics that day were Rem Koolhaas, Samir Bantal, Janna Bystrykh, and the rest of the AMO Team. Externally we had critics coming in from all over Europe: Niklas Maak, Federico Martelli, Stephan Petermann and Clemens Driessen. Initially Mark Lee, our chair, was also meant to visit from the GSD to facilitate an exchange with our peers at Gund, but last minutely, he was unfortunately not able to make it.

Being able to hear all the presentations in such detail and in close succession was really fascinating. It made apparent to us many of the links that exist across our topics, though they might appear rather separate at first. We wrapped up the presentations with our semiotics investigations from our workshop earlier this month. The same night we then celebrated our third birthday (Happy Birthday, Charlie!) with some celebratory post-mid-term drinks and food before beginning our weekend of some well-deserved rest.

[sweitzephreniac]

Reasonable Withdrawing Reasons

Instead of a big text area where the students can just type in 'Just cuz' and then withdraw their applications, make them choose from a drop-down menu and give your site more consistent data about these withdrawn applications.

This is an interface modification that will have a default option provided to the applicant when they click on the 'withdraw' button, but they can then select other options. This includes an 'other' option which reveals the free-form text area that allows them to type in whatever reason they want.

To implement this script, copy/paste this script to a plain text editor:

<script> $(document).ready(function() { var reasonarray = ["financial","course credit","just cuz"]; $('#taComments').parent().css('display','none').before('<div class="padding left-bdr rightbdr"><select id="reasondd"></select></div>'); for (var i=0; i < reasonarray.length; i++) { $('#reasondd').append('<option value="' + reasonarray[i] + '">' + reasonarray[i] + '</option>'); } $('#reasondd').append('<option value="other">other</option>').change(function() { var reason = $('#reasondd').val() if (reason != 'other') { $('#taComments').val(reason).parent().css('display','none'); } else { $('#taComments').val('').parent().css('display','block'); } }); }); </script>

Adjust this line in the script so that it has an array that is the list of reasons that you want to have offered in the drop-down menu. The first one will be selected by default:

var reasonarray = ["financial","course credit","just cuz"];

Append the script to text interface field#351, and it's ready to go.

The script isn't too complicated. First, it is hiding the existing interface and adding in a drop-down menu (the 'select' tags). Then, it iterates through all the options you provided in the array and creates each one as an 'option' tag in the drop-down menu. When it's done with that, it adds the 'other' option to the drop-down menu. Finally, it assigns an event handler to the drop-down menu.

The event handler is fired off whenever the drop-down menu is changed. It grabs the current value of the drop-down menu, and if it isn't the 'other' option, it assigns that value to be the value submitted as the reason. It also makes sure that the native interface's textarea tag remains hidden (in case you selected 'other' and switched back to another reason). If it IS the 'other' option, it reveals the native interface's text area tag after clearing out its contents (in case you had previously selected another option in the drop-down menu).

This has been tested in Version 12.

[sweitzephreniac]

Tag-Teaming an Awesome Program Search

If you thought this blog might be never updating again, never fear - I am still planning on posting updates in the future. Unfortunately, the last couple of months have been crazy busy with getting all the aspects of this summer's TDS release in order so I haven't been able to dedicate quite as much time as I would like to brushing up on my own coding skills.

I'm pretty sure I'll get at least one more article posted here within the next couple weeks, but then the big project will be going back through everything I've posted here and testing it in the TDS 2014 release for compatibility. I'm not expecting a lot of issues to arise, but you never know what little wrinkles might throw an error here and there. In fact, I found one today that I think might be a bit of a difficult fix (hiding the WYSIWYG Editor interface for essay questions to make it just a file upload button).

If you keep an eye on the Github repository, you'll notice that there were some updates posted to the API-driven program search. I'd like to give a shout-out to Antonio Carella for being the first pull-request on the Sweitzephreniac Github repo. He added a couple very significant changes to the code.

First, he added a way to exclude specified terms from the interface. If your site has some extraneous term names that really aren't used for study abroad programs, you wouldn't want them appearing in the panel as checkbox options. If you want to exclude them, just look for these lines in the code:

// Add names of parameters you wish to not show up to the list below, inside quotation marks, and separated by a comma, e.g. ["Proposal", "Other", "Fall-Winter Terms", "Summer-Fall Terms"] var excludeTheseParamsArray = []

You can put the terms you don't want to appear in there, and your search widget no longer will include them as checkboxes.

Second, he made a major change to the info windows that appear when hovering over pins in the Google map. A significant problem with the way it worked before is that if you had more than one program in the same city, only one program would appear in the info window. My version of the code just overwrote the previously parsed program so that only the last program in the data returned for that city would be displayed.

Antonio's change has code that goes through all the marker data and checks for duplicates. When it finds them, it concatenates the data so that there will just be one marker with the data for multiple programs. It's a pretty nice bit of code that he's commented verbosely to explain what it is doing.

If you've implemented that custom program search I posted and you aren't using this updated version, I would strongly recommend checking it out and updating with these additions.

Now, all that's really left for me to do is add the ability to have program parameters appear as criteria options as well. Hopefully, going through all the articles I've posted here over the next few weeks for the upgrade won't take too much time, and I'll be able to get a 'feature-complete' version of this program search posted.

[sweitzephreniac]

Process Management Management (PMM)

If you have a lot of process elements on your site, going through the listings in Process Admin can be a bit of a pain. Here's a script that will make that interface a little bit easier to work around. It isn't going to create 'folders' for you, but it's going to give you a handy way to get at what you want to find a bit more easily.

The script is easy to implement. You're going to append this to the tips text of each of the four process element types - 8535, 3971, 11788, and 11787:

<script> $(document).ready(function(){ $('table[summary*="table showing existing questionnaires"]').first().prev().remove(); $('a[href*="FuseAction=ProcessAdmin.MaterialsView"]').attr('title','Click to Preview'); $('.data-header').click(function() { $(this).next().toggle(); }); $('a[href*="ViewRetired=1"]').before('Filter: <input id="element-filter" type="text" value="" maxlength="20">  '); $('#element-filter').keyup(function() { var filter = $(this).val().toLowerCase(); $('a[title="Click to Preview"]').each(function (){ var elementname = $(this).text().toLowerCase(); if (elementname.indexOf(filter) != -1) { $(this).parent().parent().css('display', 'table-row'); } else { $(this).parent().parent().css('display', 'none'); } }); }); }); </script>

Once you got this script added, you'll see the 'Filter' field appear at the top of the listing to the right of the link to view the retired process elements. As you type into it, your view will only show the process elements that match it. You'll also have the ability to click on the section headings to collapse and expand them.

The first couple lines of the script are making adjustments on the pages so that all four of the process element pages have the same structure and attributes. This removes a border table that only appears in the data table of the Process Admin -> Questionnaires tool:

$('table[summary*="table showing existing questionnaires"]').first().prev().remove();

This adds the 'Click to Preview' tooltip to all the preview links in the data table of the Process Admin -> Materials tool:

$('a[href*="FuseAction=ProcessAdmin.MaterialsView"]').attr('title','Click to Preview');

If didn't have these two lines, the same script wouldn't work for all four process elements. I'd need separate scripts for the questionnaires and materials. Why have three scripts when you can have just one, right?

Next, I put this event handler on all the section headers:

$('.data-header').click(function() { $(this).next().toggle(); });

It uses the jQuery 'toggle()' method on the data table below the header to hide and reveal each section. This is why we needed that first line for the questionnaires page. If it wasn't there, the first header's event handler wouldn't be toggling the right part of the page.

Next, I create the label and input field with the id 'element-filter' for the filter:

$('a[href*="ViewRetired=1"]').before('Filter: <input id="element-filter" type="text" value="" maxlength="20">  ');

Instead of defining what happens with this field in the 'input' tag, I attach this event handler to it:

$('#element-filter').keyup(function() { var filter = $(this).val().toLowerCase(); $('a[title="Click to Preview"]').each(function (){ var elementname = $(this).text().toLowerCase(); if (elementname.indexOf(filter) != -1) { $(this).parent().parent().css('display', 'table-row'); } else { $(this).parent().parent().css('display', 'none'); } }); });

Every time there is a 'keyup' in that field (which means every keystroke), this routine is going to run. It will check every process element on the page by looping over all the preview links. That is why we had to add that second line for the materials page. It is checking each of them to see if the contents of the filter are in the name of that process element. If the name of the process element contains the text in the filter, it has the 'display' attribute set to display the table's row. Otherwise, it gets hidden.

I also remembered to make the filter case-insensitive by making all the strings I'm comparing lowercase letters. I've forgotten that in past 'filters' I've built. It's such a small detail, but it really makes a different in usability.

An interesting thing about this script is that I was able to get the basic script written in about 15 minutes. It was a piece of cake. Figuring out why it didn't work on the questionnaires and materials pages took another thirty minutes. Finally, figuring out the way to manipulate those two pages so that I could use a single script on all four pages took another hour. It's not that those two lines two an hour to type. That time was spent determining that was the way I wanted to do it.

This has been tested in Version 12.

[sweitzephreniac]

My Own Private Brochure Page

Before you start rolling your eyes, I'm completely aware of my lack of design skills, and this is not meant to be something that you implement without adjustment. While this isn't going to look like something you want to have on your site, the underlying code and methods used to render the content can provide the groundwork for a completely re-imagined program brochure page.

Overview

I took on this project as a way to familiarize myself in working with the public interface API's data. Specifically, the data associated with the program brochure page, and while I don't have the design chops to really produce something eye-popping, I can definitely implement a few alternate interface ideas that are not used by the built-in brochure page.

The goal was to put together a template that separates the design/presentation layer of the brochure page from the code that fetches and parses the resulting data. It was not completely successful, but it gets pretty close.

There are a few files involved although only one of them is actually code; the other two are templates that are used in the implementation. The code file is long and complex, but I've put in a lot of comments that try to make it as clear what the code is doing (no matter how strangely).

Implementation instructions

There are a four steps to using this template:

1.) Download the code files and save them to your document center

There are three template files involved:

CustomBrochurePageCode.html CustomBrochurePageBrochureTemplate.html CustomBrochurePageBannerTemplate.jpg

The first is an HTML document with the styles, containers, and script that will generate the brochure page (CustomBrochurePageCode.html). The second is the html that should be used in the program brochures as the template (CustomBrochurePageBrochureTemplate.html). The third is a jpg that can be used as a template for the banner images that you want to create (CustomBrochurePageBannerTemplate.jpg).

All three of these files are in the github.com repository. Unlike other HTML documents that I've posted here that you store in the document center, these need to have their content copy/pasted into the source HTML of the WYSIWYG Editor. They aren't designed to be saved and fetched as files. When you're done, you should have these items appearing in your document center like this:

2.) Create banner images and put those IDs in the program notes of your programs

If you want to have different brochure banner images for different programs, you can use the template in a standard image editor and save different images with different dimensions. However, it would be a good idea to keep the width of the images consistent. I'd recommend creating a folder in your image library where you store these:

You'll be taking the image ID#s of each of the banners and then implementing them in your programs by adding |BannerImage|#| to the program notes with the image's ID# where the '#' is. So, for example, if I had banner image that was image ID#2447 in my image library, I'd have program notes that look like this:

3.) Use the brochure template to create tabbed brochure content

Now you're ready to create the brochure content for the page using the file in the document center (CustomBrochurePageBrochureTemplate.html). You'll need to copy/paste the raw html of that template into the program's WYSIWYG Editor on the brochure tab. Then you can change the lorem ipsum text of each section to what you want it to display on that particular tab.

This would be great time to implement another trick of mine - One Click Brochure Templates.

When viewing this template in the WYSIWYG Editor, it will just appear as one long piece of content, but it has the necessary markup included so that the styles and scripts can do their thing to turn it into tabbed content. Don't worry that it looks like this in the program builder:

4.) Preview the alternate brochure page

At this point, you're ready to view your program brochure in the new template. All you need to do is get the document center file ID# of 'CustomBrochurePageCode.html' and the program ID# of one of the programs that you've configured to go to the new brochure page. Then, navigate to this URL:

http://{YOUR SITE'S DOMAIN NAME}/index.cfm?FuseAction=Abroad.ViewDocument&File_ID={FILE ID# OF CUSTOMBROCHUREPAGECODE}&Prog_ID={PROGRAM ID# OF THE PROGRAM YOU CONFIGURED}

You should see your brochure's content in the alternate format. If you don't, then you might need to check the browser's console log to investigate the cause of the problem.

Details about the script

This code is like the custom program search that uses the API. I've split the code into three distinct parts. The first section is the 'style' tag which is pretty self-explanatory. I've tried to maintain all formatting through CSS and nowhere in the container code itself. I still resorted to using the 'center' tag in one spot of the markup, but other than that, you should be able to adjust the fonts, lists, and buttons completely within the style section. The second section is the actual markup which has the containers that will be filled and revealed by the script. What makes it more than a bunch of empty 'divs' is that I've included the standard 'tips section' of a StudioAbroad page. It's just a copy of what you would get on any other brochure page except that I modified the tips to explain how the content is being fetched and rendered.

The real meat of the code is the last section; the script itself. This has all functions that are used to build the brochure page using the API.

$(document).ready(function(){

This is the initialization function of the script, and all it does is look in the page's URL for the parameter that tells it which program's data to fetch. Then, it executes the API call using the program ID# that it found in the URL.

That's it ... Everything else happens when this executes ...

function _cb_processBrochure(data) {

This is the callback function that is run when the API call succeeds and gets back a JSON object with all the program's data in it. Like the initialization function, it's pretty simple and fires off a bunch of function calls for each section of the brochure page.

However, there is also a section that I've got commented out which can be reinstated if you want to have the data packet that the API is sending logged into the browser's console. This is a really useful way to directly inspect the data you're getting back from the API, and I used it prodigiously when building this script and running tests in my browser.

function actionPanel(data) {

This function is called to build the 'Apply Now' and 'Request Advising' buttons in the 'Action Panel'. Unlike the standard brochure pages, none of the text of this custom page is driven through the text interface editor. If you've renamed a section of button on the brochure page, you'll need to re-implement that adjustment in the specific section of the script where that element is built.

There are two related functions just after this function that builds the buttons.

function RequestAdv() { function ApplyNow(desturl) {

These are the functions that are called whenever an 'Apply Now' or 'Request Advising' button is clicked. They are copied code from the standard brochure page. If you want to adjust the behavior of the page when someone clicks on these buttons, you can adjust that in these sections of the script.

function bannerBuilder(data) {

This function creates the banner image. It also adds the name of the program and, if there is one, the sponsor as well. I have to admit, that it definitely is a little bit of a hack to embed the image ID into the program notes and parse through them like that, but a more elegant method of doing it (like a program parameter value) would involve configuration in the script itself, and I wanted to make this code 'plug-and-play' since it is really intended as more of a proof of concept rather than production-ready code.

Something to note about the banner is that it uses CSS to position the name of the program and sponsor over the banner image rather than forcing the person building the banner to have the text as a part of the image itself. It also ensures the program name displays when there is no banner image.

function informationPanel(data) {

This function builds the information panel with the program's parameter option values, terms, and locations. It's a very complex bit of code, but here's the outline of what it is doing:

- Look for the existence of data for a section (parameters/terms/locations)

- If there is data, parse through it and dump it all into an array

- If there is data in the array, loop through it and build the html of that data

- After going through all the sections, build the navigation options that are needed

- Dump all that html into the panel and set up event handlers on the navigation tabs

Now, you might notice that I'm actually writing quite a bit more code than I really need to. If I was being clever, I would combine steps two and three and just build the html itself as I parse through the returned data rather than dumping it all into an array first, but by doing it the way I did, it makes it easier to update the code that builds the html without worrying about mucking up the data itself. So, for example, suppose I wanted to have the locations displayed as markers on a Google-rendered map rather than as a boring list. I know exactly where in the code to make that change, and I don't need to work around all the logic that is parsing through the returned data.

function showInfoPanel(whichone) {

This function is the event handler for the tabs in the information panel. I'm sure I could have unified the functions that are used by the information panel and the brochure panel and just had a single function determine what needs to be updated, but this keeps the code for one panel all in one place and the code for the other panel in its own place.

The code itself is pretty straightforward though, and it's a technique I use quite a bit for client-side navigation. I hide everything and then just reveal what was clicked.

function brochureTabs(data) {

This function is a bit of a monster. It is parsing through all the brochure content as well as the dates, budget, and course information in the data returned. It's like the function that builds the information panel but with much more complex data.

It does it the same way though; stuff all the data into an array and then iterate through that array to build the html that you want to add to the page. Finish up by building the navigation tabs and add it all into the page's container.

The most complex of the structures are the program date records because they deal with start and end date data that might or might not be there. What made the dates especially difficult was the javascript object for dates. Firefox is remarkably picky about how you create them. Our API's formatting doesn't make it simple either.

function showBrochurePanel(whichone) {

This is the event handler for clicks on the brochure's tabs. Like I mentioned earlier, it could have been folded into the information panel's function. It's basically doing the exact same thing, and that makes it a real candidate for being refactored should I ever return to this code and update it.

function fetchBudget() {

When someone selects a term from the budget sheet drop-down menu, this is the function that is called to get the budget sheet's information and add it to the page. It's actually a bit of a cheat.

The public interface API doesn't provide you with budget sheet data. All it gives you is a URL to the program's public budget sheet page for each term for which there is a published budget sheet. I'm leveraging jQuery's ability to run an AJAX call to fetch the HTML of a section of a destination URL and dump it into a container on the page. Lucky for us, on the public budget sheet pages, there is just one section with the class 'data-table' assigned to it, and it just happens to be the budget sheet table.

function reformatdate(datestring) {

This is a quick little helper function I built to deal with the way that Firefox interprets date objects. I'm actually a bit suspicious about the code around the dates. I wrote it so that it would sort the dates with the earliest application deadline at the top and the latest at the bottom.

I think that's just naturally how the dates are sent back by the API. It's possible I'm just really overworking the date details and could have gotten away with some way-way-way simpler code, but I'd like to think that my routines are less likely to break.

... unless you change the date mask your site uses...

Yeah... I'm pretty sure that will break it.

... well, poop ...

Customizing the display

Adjusting the CSS of this page's code will definitely allow you to manipulate the fonts, buttons, and colors, but chances are that you are going to want to come up with a completely different and original design.

When I started out on this project, I just scribbled a bunch of panels on a piece of paper and started labeling what I wanted to appear in them. If I had a professional graphic designer at my beck and call, I would have then handed my scribbles over to them along with the URL of the site and told them to come up with cool, concept designs based on my really awful wireframe.

Unfortunately, I don't have such a resource available that would do professional work like that in return for a "I'll be your best friend". So I just leaned on the pre-existing interface elements that are in the Terra Dotta Software CSS (specifically the widget classes). Good enough for a proof of concept, right?

So this example's CSS is pretty straightforward, there aren't too many classes and ids, but for example, if I wanted to change around the look and feel of the tabs that you click on to switch from one section to another, I'd change around this section of the style block:

.section-tab { border-style: solid; border-width: 1px 2px 2px 2px; display: inline; padding: 3px 10px; margin: 5px; border-radius: 0px 0px 10px 10px; font-family: Arial; font-weight: bold; background-color: #1372a8; color: white; border-color: black; } .selected-section-tab { box-shadow: 0px 1px 10px -1px #000000; background-color: #000000; }

I could adjust the color of the tab to match my widget's header color by adjusting the 'background-color' attribute, or I could change the font, color of the text, how big the tabs are, etc.

Changing around the actual position of each widget would involve me changing around both the 'div' tags that are used as their containers in the content section as well as the CSS for those containers. This could get a bit trickier as you might need to learn a few pointers about positioning elements on a page. If you want to get into that level of detail, I'd suggest searching for some pages that explain positioning through CSS; specifically, the difference between block and inline elements and how to work with them to get things to appear exactly where you want them.

One thing I would definitely encourage when customizing the display of a template like this is to always look at the CSS before trying to put tags and attributes in the brochure container that will impact how the content looks. It's considered good practice in general because it will keep all the code that effects the 'presentation' of your content in one place, and the structure of how you are organizing it in another place. If you need to tweak it or make changes at a later time, it is much easier to look at code organized in this manner and update it.

Now, as long as we're talking about 'good practice', a real brochure template would be three separate files. One for the CSS, another for the script, and a third for the HTML which would link to the other two. It would allow the CSS and script to be cached by the browser and only reloaded when necessary. If you have full access to your server, that might be an option, but in cases where this level of access isn't provided (like Terra Dotta hosting), as long as you aren't getting too heavy on the size of the file, putting it all in one place isn't going to be a major performance issue.

Methods to take it live

The big final aspect of this is that once you've got a beautiful template you want to deploy, how do you switch a site over to use that template rather than the software's built-in brochure page?

There are a few methods to direct users to the alternate brochure page URL, and I won't go completely into the technical details because there may be different wrinkles in how you decide you want to do it.

The first would be to use what is referred to as a 'stub-override' for the program brochure page. This involves making a change on the server itself. There is a file in the code called '_stub.cfm' and is used to put in high-level code that runs whenever a page is requested. In this case, you would have code that checks the URL of the page being requested and if it's requesting 'index.cfm?FuseAction=Programs.ViewProgram&Program_ID=', you redirect to the alternate URL with that program ID as the parameter in it. This involves needed to learn a little bit of the ColdFusion Markup Language (CFML), and it also assumes you have direct access to the server and the stub file ... which, if you are hosted by Terra Dotta, you do not.

A second method involves putting a script into the program brochure tips text that would grab the program ID out of the page's URL and then auto-redirect the user to the alternate URL with that program ID. This would be a case where you wouldn't actually want to use the '$(document).ready(function(){' jquery command in the script because you would want to redirect the user immediately, not after the page's content was ready. This method can be done by anyone that can put scripts in the text interface, but it seems a little bit janky to me because you're still 'loading' the old brochure page.

The third method that could be used would be to put a script on the program listing and search result pages that uses a jQuery command to find all links to the program brochure page and change their 'href' attribute to the new URL with the proper program ID# in it. It wouldn't be an overly complex script to write, and it would also make it easy to add conditional checks as well. You could test out the new template on a sub-set of users by making the script only switch the URLs when the user has a specific cookie value and then provide a link to a page where the testing users could set that cookie in their browser.

A final method would just be to completely re-write your program search, listing, and search result pages using the public interface API and use the alternate brochure page URL instead of the standard one. This would be a bit more of a project to embark on, but let's be honest here, you've already decided to completely re-write the program brochure page using javascript. Why not rewrite the whole program discovery interface as well?

This has been tested in Version 12.

[sweitzephreniac]

Fighting With an Awesome Program Search

Time for an update on the dynamic program search that I posted here a while back. I've made a lot of changes to it and added a whole bunch of things that make it more than just a simple proof of concept using the API. It still isn't everything I want it to be yet, but you can definitely deploy this version and help people find programs on a site.

As I mentioned ... my God! ... back in December, I was going to improve upon the code, and I've added the following to this version of the program search:

1.) Better criteria panels

Instead of a single panel with a single column of all the checkboxes, the options are all broken into separate panels now. They also can line up next to each other and protect the vertical real-estate of the page. It's much more space efficient and looks a lot better.

2.) Google map

This is a biggie. If you have one, it uses your Google Maps API key. It will translate the latitude and longitude data of your program locations into markers on a Google Map. When you hover over one of the markers in the Google map, it will pop open an info window with the name of the program as a clickable link.

3.) Hover animation in results table

The trick I posted back in January to make application search results have a hover effect was first built for this update. It adds mouse-over events to the program search results table that appears under the Google Map. When you hover over a row, the background colors change. It also makes the whole row clickable for the program brochure page - not just the hyperlink of the program name itself.

4.) Search memory

Finally, I added code that stores all your checkboxes in your browser's cache as a cookie. Then, if you return to the search page during that same day, it will re-check any of the checkboxes that you had the last time you were on the page. This way, you don't need to run the program search many times if you want to go back and forth between the search and the program brochure.

I also re-factored the code a lot. I took the parts that built the criteria boxes and turned them into a single function. That makes it easier to add new criteria to the search without adding a lot of new code.

Not everything is 100% perfect yet. Here's what isn't done:

1.) Parameters as criteria

While there is code for building the criteria panels for program parameters, I ran into some bugs in the API when I was building this. I wasn't able to put in place the ability to have program parameters as criteria options.

I've since learned that it wasn't so much bugs in the API, but that the API wasn't documenting how to construct the URLs. When you need to search the program catalog with many options for a single parameter, the delimiter was wrong. I'm pretty sure I can do a fix in the final version that allows you to add them.

2.) Many programs per city

The Google Map will only show one program per marker. If you have many programs in the same city, you won't always see the in the Google Map's pop up information window. This is going to take a bit more work to build. Listing all the programs in that city and not just one of them could be trickier.

Now, the fun part for you. Here's how to implement this search. Believe it or not, it isn't that hard to do:

1.) Download the code

I've committed the code to the Github.com repository:

DynamicProgramSearch_2_0.html

You'll want to download the HTML code and save it to your local drive.

2.) Configure the parameter for your site

Open the HTML file in a plain text edit. There are two parameters you'll need to configure so that it will work on your site with your Google API key. Lines 91-93 in the file look like this:

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

The two that you need to configure are 'sitedomain' and 'mapsapikey'.

Configure the site domain to look like this:

var sitedomain = "//studyabroad.terradotta.com/";

NOTE: There should be two forward slashes at the beginning and one forward slash at the end of the string.

You will find the Google Maps API key for your site in System Settings -> System Features on the 'Features' tab. If your site isn't using one, just remove the text of that string so that it looks like this:

var mapsapikey = "";

The script will ignore the Google Map stuff when left empty. If your site doesn't have a Google Maps API key, read Terra Dotta's documentation for configuring geocoding. It will provide the instructions for obtaining one for your account/domain.

After setting up these two parameters, you can save the changes to the local file.

3.) Deploy on a page

The easiest way is to go to Website Admin -> Site Builder and copy/paste the HTML into the source of a new content link page. You can also copy/paste the content into the source of a WYS object in Website Admin -> Document Center.

One thing you might want to do is deploy this search on an external website. Unfortunately, the current code is not designed to work on a non-Terra Dotta Software website. It uses the software's CSS for building the panels. Also, the Google Maps API key is usually connected to a domain name so it might not work if you attempt to make calls from another site. To be completely honest, I don't understand how Google enforces it. I've seen different results in different places.

4.) Customize it

Don't let me design your program search - make it your own. At the least, you'll want to add some copy to the top of the page to tailor it to your applicants. There's a simple 'div' at the top of the page that looks like this:

<div id="progsearch-interface-container"> <h2>Find a program:</h2> </div>

This is the container where the search criteria get added. You can add whatever content/instructions you want into this 'div' and it won't cause any trouble with the script. You can also manipulate the CSS in the style tag and adjust the font, background color, etc.

Finally, you can also adjust the characteristics of the Google Map itself by changing around this code:

function buildMap() { var mapOptions = { center: new google.maps.LatLng(34.033333, -6.85), zoom: 1, disableDefaultUI: true }; var worldmap = new google.maps.Map(document.getElementById("map-canvas"),mapOptions); return worldmap; }

If you want to change this around, get familiar with the developer documentation that Google provides for this API. There's a lot of flexibility, and you can make this look quite different from what I've provided you.

Making sense of the code itself:

So there are three main parts to this code, the interface containers, the style block, and then the script itself.

Now, if I did this in a more traditional design, these would be three completely separate files. The html containers would import the javascript and css as external files. It would separate the 'view' of the page from the 'controller' of the page.

Without direct file system access, the alternative is to put those files in the Document Center. While I'm not opposed that method, there is more network overhead involved fetching files that way. Also, the view and style blocks aren't complex. I figure it is just as easy to make the whole thing one file with separated blocks of code.

Just like the initial version of this program search, there are three sections to the script. The first is the initialization of the page which fetches all the data needed to configure the search. The new part in this version is the routine that loads the javascript library for the Google Map. The second section is the interface builder. It takes the data fetched from the API and builds all the criteria widgets and checkboxes. New in this part is the way it checks for the presence of a saved cookie in the browser. I also re-factored the way that the criteria options get built so that I'm not repeating the process for each type of criteria. The third section processes the program search results whenever there is a change to the interface. It has a bunch of new code because it builds the Google Map as well as creates the browser cookie with the current search criteria.

I realize that a lot of the comments I've put in here might be a bit unnecessary. They betray the amateur nature of this code because professional code should be readable with few comments. While I hope the comments are useful to you, they are also a bit selfish. When I come back to this code later, I'd like to know what I was thinking when I wrote it - even if it is a bit embarrassing.

This is, by no means, my final version of this search. There's room for one more final version of this search. One that will allow adding program parameters as criteria and including country and city as options as well. I also want to make the pop-up windows for the markers display ALL the programs in that city, not just the last one in the array I iterated over.

This was tested with Version 12.

[sweitzephreniac]

Alerts, Warnings, and Other Ways to Attract Attention

Sometimes, you need to have a way of displaying a warning or alert about some event or deadline to all your users. Pulling together a few techniques, you can create a system on your site that will check a document center object on certain pages and display an alert or warning that you need shown to the users looking at that page.

This is a simple system to set up, and it's going to combine the 'boilerplate' trick we used for the brochure pages along with a little bit of additional logic. Then, we're going to leverage the StudioAbroad style sheet for displaying alert and warning panels so that it looks consistent with all the other panels on the site.

1.) Create the document center object

To set up the document center object you're going to use, go to Website Admin -> Document Center and create a new doc center object. The name of the WYS object doesn't matter, but you should give it a name that will make it obvious that it is for alerts and warnings. To set it up, switch to the 'Source' mode and copy/paste this HTML into the source code of the object:

<div id="messages"> <div class="panel-header">ERROR PANEL:</div> <div class="SA_error custom-panel"> <div class="sprites_icons ico_icon_error mar-15 align-top"></div> <div class="inline_display alert-content">no message</div> </div> <div class="panel-header"><br />WARNING PANEL:</div> <div class="SA_warning custom-panel"> <div class="sprites_icons ico_icon_warning mar-15 align-top"></div> <div class="inline_display alert-content">no message</div> </div> <div class="panel-header"><br />INFORMATION PANEL:</div> <div class="SA_information custom-panel"> <div class="sprites_icons ico_icon_information mar-15 align-top"></div> <div class="inline_display alert-content">no message</div> </div> </div>

When you click the 'Source' button again to view the rendered page content, it should look something like this:

The page has three sections; one for each type of alert that can be displayed. All you have to do to make one of them active is change the content from 'no message' to whatever you want the alert message to be. When you don't want it to display anymore, you return to this doc center object and change it back to 'no message'.

The error panel is a red panel. The warning panel is the yellow panel, and the information panel is the blue panel. The reason that there is practically no code to identify the panel, font, or background colors is that it will be using the software's existing style sheet classes (SA_error, SA_warning, and SA_information) to handle that part of the rendering. The content of this document center object is organized so that the user-facing script can easily iterate over it.

After saving the content of the doc center object, hover over the 'view' link and take note of the FILE_ID# parameter in the link's URL. That is the number you will be adding to the script in the next step...

2.) Add the script to the tips text of the pages where you need it

The most likely place you will be putting this is on the applicant home page, but it will work on any page. Copy/paste this script into a plain text editor:

<script> $(document).ready(function(){ var doccenterid = {DOCUMENT CENTER ID#}; $("#sa_content").prepend('<div id="alert-panels" style="display: none;"></div>'); $("#alert-panels").load('index.cfm?FuseAction=PublicDocuments.View&File_ID=' + doccenterid + ' #messages', function() { $(".panel-header").css('display','none'); $(".custom-panel").css('display','none'); var panelflag = 0; $(".custom-panel").each(function () { var panelcontent = $(this).find(".alert-content").text().trim(); if (panelcontent != 'no message') { $(this).css('display','block'); panelflag = 1; } }); if (panelflag > 0) { $('#alert-panels').css('display','block'); } }); }); </script>

Then, change this line ...

var doccenterid = {DOCUMENT CENTER ID#};

... so that it has the file ID# of the document center object you created. It will look like this (but with your object's number):

var doccenterid = 55;

This script is what you'll put into the tips text interface field of any page that you want checking for alerts and displaying them at the top of the page. So, if you want this for the applicant home page, you'd append this script to interface field #39, but you can put this script on multiple pages if you want.

After the page loads, the script is creating a hidden 'div' at the top of the content area. Then, it's filling that 'div' with the contents of the document center object using an AJAX call. Once the content is loaded, it hides everything and iterates through each of the potential sections to reveal. If it finds something other than 'no message' in a section's content, it will change the CSS to display that section (even though it is still hidden by the surrounding 'div). Finally, after checking each section, if there was a section revealed, it changes the surrounding div's CSS to display.

If you are having trouble getting it to show up, it is possible that you have a custom layout with a different identifier for the section of your layout that displays the page's content. You might need to adjust this line:

$("#sa_content").prepend('<div id="alert-panels" style="display: none;"></div>');

... so that the identifier 'sa_content' matches your layout's version of that section.

Finally, you can have different document center objects for different pages. You just need to make sure that the script you put in the tips text has the document center file ID# that you want to display on that page. So if you wanted to, you could have one doc center object displaying warnings on the applicant home page, but have a completely different doc center object displaying warnings to your staff on the admin home page.

This has been tested in Version 12.