Categories
coding workflow

Taking Google Forms to the Next Level

This originally appeared on the ACRL TechConnect blog.

Many libraries use Google Forms for collecting information from patrons, particularly for functions like registering for a one-time event or filling out a survey. It’s a popular option because these forms are very easy to set up and start using with no overhead. With a little additional effort and a very small amount of code you can make these forms even more functional.

In this post, we’ll look at the process for adapt a simple library workshop registration form to send a confirmation email and introduce you to the Google Apps Scripts documentation. This is adapted from a tutorial for creating a help desk application, which you can see here. I talked about the overall process of creating simple applications for free with minimal coding skills at this year’s LITA Forum, and you can see the complete presentation here. In this post I will focus on the Google Forms tricks.

A few things to keep in mind before you get started. Use a library account when you actually deploy the applications, since that will remain “owned” by the library even if the person who creates it moved on. These instructions are also intended for regular “consumer” Google accounts–there are additional tools available for Google Apps business customers, which I don’t address here.

Creating Your Form

Create a form as you normally would. Here’s an example of a simple workshop registration form.

There are a few potential problems with the way this form is set up, but here’s an even bigger problem. Once the person signing up clicks submit, the form disappears, and he receives a page saying “Thank you for registering!”

If this person did not record the workshop, he now has no real idea of what he signed up for. What he intended to do and what he actually did may not be the same thing!

What comes next? You, the librarian hosting the workshop, goes into the spreadsheet to see if anyone has signed up. If you want to confirm the sign-up, you can copy the patron’s email address into your email program, and then copy in a message to confirm the sign-up. If you only have a few people signed up, this may not take long, but it adds many unnecessary  steps and requires you to remember to do it.

Luckily, Google has provided all the tools you need to add in an email confirmation function, and it’s not hard to use as long as you know some basic Javascript. Let’s look at an example.

Adding in an email confirmation

To access these functions, visit your spreadsheet, and click on Script Editor in the Tools menu.

You will get many options, which you can use, or you can simply create a script for  a Blank Project (first option) You will get this in your blank project:

function myFunction() {

}

Change the name of the function to be something meaningful. Now you can fill in the details for the function. Basically we use the built-in Google Spreadsheet functions to grab the value of each column we want to include and store these in a variable. You just put in the column number–but remember we are starting from 0 (which is the Timestamp column in our current example).

function emailConfirm(e) {
  var userEmail = e.values[3];
  var firstName = e.values[1];
  var lastName = e.values[2];
  var workshopDate = e.values[4];
  MailApp.sendEmail(userEmail, 
                    "Registration confirmation", 
                    "Thanks for registering for the library workshop on " + workshopDate + " nnYou will " +
                    "recieve a reminder email 24 hours prior. nnLibrary",                    
                    {name:"Library"});
}

The MailApp class is another built-in Google Apps script. The sendEmail method takes the following arguments: recipients, subject, body, optAdvancedArgs. You can see in the above example that the userEmail variable (the patron’s email address in the form) is the recipient, the subject is “Registration confirmation”, the body contains a generic thank you plus the date of the workshop, which we’ve stored in workshopDate variable. Then we’ve put in advanced arguments the name “Library”–this is optional, particularly if it’s coming from a library email account.

Note that if a patron hits “reply” to cancel or ask a question, the email will automatically go to the email account that deployed the application. But you may want reply emails to go somewhere else. You can modify the last “advanced” argument to be some other email address with the replyto argument. (Note that this doesn’t always work–and that people can see that the email comes from elsewhere, so make sure that someone is checking the email from which the application is deployed).

 {name:"Library", replyto:"mheller@dom.edu"});
Running the script

Once you’ve filled in your script and hit save (it will do a quick debug when you save), you have to set up when the script should run. Select “Current script’s triggers…” from the Resources menu.

Now select the trigger “On form submit”. While you’re here, also click on notifications.

The notifications will tell you any time your script fails to run. For your first script, choose “immediately” so you can see what went wrong if it didn’t work. In the future you can select daily or weekly.

Before you can save either your trigger or failure notifications, you need to authorize that Google can run the script for you.

Now your script will work! Next time a patron fills out your form to register for a workshop, he will receive this email:

Doing More

After working with this very basic script you can explore the Google Apps Script documentation. If you are working with Google Forms, you will find the Spreadsheet Services classes very useful. There are also some helpful tutorials you can work through to learn how to use all the features. This one will teach you how to send emails from the spreadsheet–something you can use when it’s time to remind patrons of which workshops they have signed up for!

Categories
coding

Creating quick solutions and having fun: the joy of hackathons

Women Who Code
Photo credit Adria Richards, used CC BY-SA 2.0

Hackathons– aka “hackfests”, “codefests”, or “codeathons”, are time periods dedicated to “hacking” on a problem, or creating a quick and dirty technical solution. (They have nothing to do with “hackers” in the virus or breaking into computers sense of the word). Traditionally, hackathons gave developers a chance to meet in person to work on specific technologies or platforms.  But increasingly, the concept of hackathons are used to work on solving technical problems or developing new ideas using technology in fields such as  law, public data, water supply, and making the world a better place. Academic librarians should be thinking about hackathons for several reasons: first, we help researchers to learn about innovative tools and resources in their areas, and these days a lot of this work is happening in hackathon settings. Second, hackathons are often improve library technology in open source and proprietary products alike. And third, hackathons are sometimes taking place in academic libraries (such as the University of Michigan and the University of Florida). Even non-coders can and should keep an eye on what’s going on with hackathons and start getting involved.

Origins of hackathons

People have, of course, hacked at technical problems and created innovative technical solutions since the beginning of computing. But the first known use of the term “hackathon” to describe a specific event was in June of 1999 when a group of OpenBSD developers met in Calgary to work on cryptography (see more on the record of OpenBSD hackathons). Later that same month, Sun Microsystems used the term on a Palm V project. 1 Just as in a marathon, individuals came together to accomplish a very challenging project in a short and fixed amount of time.

The term and concept became increasingly popular over the course of the first decade of the 2000s. The concept can vary widely, but is usually understood to mean a short time period (often a weekend) during which a specific problem is addressed by a group of developers working together, often by themselves but in close enough proximity to each other to meet and discuss issues. They usually are in person events where everyone meets in one location, but can be distributed virtual events. Often hackathons have prizes for best solution, and are a chance for developers to show off their talent to potential employers–sometimes companies sponsor them specifically to find new employees. But they can also be an opportunity for incubating new and learning developers (Layer 7).

Hackathons can be organized around an existing open source software community, but also frequently take place within a company to give developers a chance to come up with innovative ideas. One notable example is Facebook. In Pedram Keyani’s post, he describes the excitement that regular hackathons provide for Facebook’s engineers by giving them a chance to work on an idea without worrying about whether it scales to 900 million people. After the hackathon, developers present their prototypes to the rest of the team and have two minutes to prove that they should be part of Facebook. Some features that were developed during hackathons include the “Like” button and the ability to tag users in comments–huge pieces of functionality that might not be there without hackathons.

Hackathons in library technology

The first library technology hackathon we know about happened at the Access 2002 conference, and was modeled after PyCon code sprints (Art Rhyno, email message to author, July 18, 2012). The developers at this hackathon worked on projects related to content management systems for cultural content, citation digests, and EZProxy tools. Since then, each Access conference has had a hackathon as part of the conference. The Code4Lib conference has also had elements of hackathons (often as pre-conferences) throughout the years.

Another example of hackathons those sponsored by library vendors to promote the use of their  products’ API’s. Simply put, APIs are ways that data can go between platforms or programs so that you can create new tools with pieces of data from other systems. In 2008, OCLC sponsored a hackathon in New York City where they provided special access to various pieces of WorldCat and other OCLC products. Staff from OCLC were on hand to answer questions and facilitate breakout sessions. Hacks included work with controlled vocabularies, “find more like this” recommendation services, and several other items (Morgan). Eric Morgan, one of the participants, described  the event as a success partly because it was a good example of how librarians can take control of their vendor provided tools by learning how to get the data out and use in other ways.

How to get involved with hackathons

It’s easy to be discouraged or overwhelmed about the idea of participating in a hackathon if you are new to the open source software world. First of all, it’s important to remember that librarians who work with technology on a daily basis have a lot of ideas about how to improve the tools in their libraries. An example of this are the ideas submitted for the Access 2011 Hackfest. Ideas included bookmarklets, augmented reality in the library, and using iPads for self-checkout among many others. Reading that list may start to jog your own memory for tools you would love to see in your library but didn’t have a chance to work on yet or don’t completely understand.

But how to take those ideas and get involved with fellow developers who can help complete those projects? Many resources exist to help with this, but there are a few specifically geared at hackathons. First,  OpenHatch  is an open source project with the mission to make it easier to participate in open source software. One feature helpful to those just starting out are “Training Missions” that walk through basic skills you need such as working on the command line and using version control systems. Another area of OpenHatch shows lists of projects suitable for beginners and information on how non-coders can participate in projects. Keep an eye on the events listed there to find events geared for beginners or people still learning. Another resource for finding out and signing up for hackathons is  Hackathon.io.

Try to participate in a hackathon at the next technical library conference you attend. You can also start small by meeting up with librarians in your area for a very informal library technology hackathon. Make sure that you document what you work on and what the results were. Don’t worry about having judges or prizes–just make it a fun and collaborative event that allows everyone to participate and learn something new. You don’t need to create something new, either. This could be a great opportunity to learn how to work all the bells and whistles of a vendor platform or a social media tool.

Don’t worry–just start hacking

You can approach hackathons in whatever way works for you. For some, hackathons provide  the excitement of competing for prizes or great jobs by staying up all night coding amongst fellow developers. If the idea of staying up all night looking at a computer screen leaves you cold, don’t worry. In a April blog post, Andromeda Yelton shared her experience attending her first hackathon, and encouraged those new to this type of event to “sit at the table” both physically and by understanding that they have something to contribute even if they are not experts. She suggests that the minimum it should take to be involved in hackathons or similar projects is “interest, aptitude… [and a] drive to contribute.” (Yelton)

There are a lot of problems out there in the library world. Hackathons show us that sometimes all it takes is a weekend to get closer to a solution. But don’t worry about solving all the problems. Just pick the one you are most concerned about, find some friends, and start hacking on it.

Works cited
Layer 7 Technologies. “How to Run a Successful Hackathon for Your Open APIs”. July 12, 2012. http://www.slideshare.net/rnewton/how-to-run-a-successful-hackathon-for-your-open-apis.
Morgan, Eric Lease. “WorldCat Hackathon « Infomotions Mini-Musings.” Infomotions Mini-Musings, November 9, 2008. http://infomotions.com/blog/2008/11/worldcat-hackathon/.
Yelton, Andromeda. “My First Hackathon; or, Gender, Status, Code, and Sitting at the Table.” Across Divided Networks, April 6, 2012. http://andromedayelton.com/blog/2012/04/06/my-first-hackathon-or-gender-status-code-and-sitting-at-the-table/.
  1. This information comes from Wikipedia, but does not have a citation and I am unable to independently verify it. This is presented as common knowledge in a variety of sources, but not cited.
Categories
administration change coding library management technology

Lazy Consensus and Libraries

Happy feet
Photo courtesy of Flickr user enggul

Librarians, as a rule, don’t tolerate anarchy well. They like things to be organized and to follow processes. But when it comes to emerging technologies, too much reliance on planning and committees can stifle creativity and delay adoption. The open source software community can offer librarians models for how to make progress on big projects with minimal oversight.

“Lazy consensus” is one such model from which librarians can learn a lot. At the Code4Lib conference in February 2012, Bethany Nowviskie of the University of Virginia Scholar’s Lab encouraged library development teams to embrace this concept in order to create more innovative libraries. (I encourage you to watch a video or read the text of her keynote.) This goes for all sizes and types of academic libraries, whether they have a development staff or just staff with enthusiasm for learning about emerging technologies.

What is lazy consensus?

According to the Apache software foundation:

Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don’t have to insist people discuss and/or approve your plan, and you certainly don’t need to call a vote to get approval. You just assume you have the community’s support unless someone says otherwise.
(quote from http://incubator.apache.org/odftoolkit/docs/governance/lazyConsensus.html)

Nowviskie suggests lazy consensus as a way to cope with an institutional culture where “no” is too often the default answer, since in lazy consensus the default answer is “yes.” If someone doesn’t agree with a proposal, he or she must present and defend an alternative within a reasonable amount of time (usually 72 hours). This ensures that the people who really care about a project have a chance to speak up and make sure the project is going in the right direction. By changing the default answer to YES, we make it easier to move forward on the things we really care about.

When you care about delivering the best possible experience and set of services for your library patrons, you should advocate for ways to make that happen and spend your time thinking about how to make that happen. Nowviskie points out the kinds of environments in which this is likely to thrive. Developers and technologists need time for research and development, “20% time” projects, and freedom to explore new possibilities. Even at small libraries without any development staff, librarians need time to research and understand issues of technology in libraries to make better decisions about the adoption of emerging technologies.

Implementing lazy consensus

Implementing lazy consensus in your library must be done with care. First and foremost, you must be aware of the culture you are in and be respectful of it even as you see room for change and improvement. Coming in the first day at a new job is not the moment to implement this process across the board, but in your own work or your department’s work you can set an example and a precedent. Nowviskie provides a few guidelines for healthy lazy consensus. Emphasize working hard and with integrity while being open and friendly. Keep everyone informed about what you are working on, and keep your mission in mind as the centerpiece of your work. In libraries, this means you must keep public services involved in any project from the earliest possible stages, and always maintain a commitment to maintaining the best possible user experience. When you or your team reliably deliver good results you will show the value in the process.

While default negativity can certainly stifle creativity, default positivity for all ideas can be equally stifling. Jonah Lehrer wrote in a recent New Yorker article article that the evidence shows that traditional brainstorming, where all ideas are presented to a group without criticism, doesn’t work. Creating better ideas requires critiquing wrong assumptions, which in turn helps us examine our own assumptions. In adopting lazy consensus, make sure there is authentic room for debate. Responding to a disagreement about a course of action with reasoned critique and alternate paths is more likely to result in creative ideas, and brings the discussion forward rather than ending it with a “no.”

Librarians know a lot about information and people. The open source software community knows a lot about how to run flexible and transparent organizations. Combining the two can create wonderful experiences for our users.