melissahoulroyd.info

I’ve been working at my new job as Reference & Instruction Librarian at a small liberal arts college for a little over 3 months so far. It’s hard to believe. So far I’ve been busy designing and presenting instructional sessions, writing a white paper, meeting with students for reference interviews, meeting with faculty to discuss their needs, creating LibGuides and tutorials, and prototyping a new website.

On top of the diversity of projects and responsibilities I have, I feel so lucky to be working with such awesome people. The library is very small and staffed with a handful of delightful federal work study students, another part-time librarian, and a radically militant (and just plain rad) library director.

Thus far, my biggest challenge has been designing instructional sessions for nontraditional students. When I took a workshop on instructional design through Simmons Continuing Education last summer, I learned that one of the first things an instructor should do is consider their students and how their students learn best. It sounds so obvious, but it’s easy to ignore. At the small liberal arts college where I work, our average student is 38 years old. Depending on the class, I could have students that use computers all the time mixed with students who are unfamiliar with the use of a mouse. I’m struggling to understand how to reach the lowest common denominator without losing the attention of the more advanced students.

Got any tips or tricks for library instructional design? What’s your biggest challenge?

The Arthur Curley Memorial Lecture at this year’s ALA Midwinter Conference was presented by Al Gore. What would such a famous speaker and activist say? How would he connect the crisis of global warming to libraries? I had high hopes.

“If you want a book to be signed, you have to buy them over there before the lecture!” This was my greeting outside the convention center ballroom as staffers gesticulated towards a bookstand. The tone was set, and the room filled quickly.

Gore started his lecture by acknowledging the suffering and destruction in Haiti. Empathy, he explained, is one of the most powerful emotions tying humans together. He asked us to empathize with future generations and consider the kinds of destruction they will inevitably face if we don’t act decisively to save the environment.

“Save libraries!” I was thinking. “Prevent global warming and the destruction of libraries!” What kind of world would this be without libraries?

Gore outlined our options for prevention, covering each chapter of his new book, Our Choice: A Plan to Solve the Climate Crisis, except the one chapter that was relevant to libraries and librarians.

Surely, the majority of the people in that room had already seen An Inconvenient Truth. The lecture did not stray very far from the same information. What if he had paid the most attention to the one chapter he skipped? Wouldn’t that have been inspiring and energizing?

I left the lecture feeling frustrated and dismayed. This presentation was another symptom of what I feel is a larger problem with ALA conferences. Bonnie Swoger wrote in the Undergraduate Science Librarian that “there is a disconnect between the library world and the research world.” I feel that a similar gap exists between libraryland and the technology, design, and marketing worlds.

Getting such big names as Al Gore to speak at our conferences is awesome, but let’s make it even better by inviting them to talk about their ideas relating to our profession. Let’s take the opportunity to hear something new.

We need to hear from our users, as Bonnie suggests, but we also need to hear from experts outside the library world to help us move forward and keep up with the ever-changing landscape our libraries are part of. We need futurists, philosophers, economists, designers, and technologists to speak at our conferences. We need to hear it from the horse’s mouth — what will effect us.

I still think librarians are a great source for programming at ALA, but I want diversity of thought. I don’t want canned presentations or recycled discussions. I think the change would help us keep up and maybe even change our general image from “behind the times” to “in the know.”

Yesterday, I was complaining to Joe about how I wish Google Docs had a batch export feature. A few hours later, he sent me a link to Google’s Data Liberation Front, a project to help get data out of Google. (The Data Liberation Front claims to want us to want to use Google products, not to corner us into it.)

Today, I found out that Read Write Web published a post yesterday entitled All Your Docs Belong to You: Google Docs Now Exportable. My wish came true!

As of today, several bloggers have reported seeing this new feature, which allows users to grab all their Google Docs and batch export them as a zip file. Files can be exported in a number of formats, including Microsoft Office and Open Office formats.

I tried it and it worked. Hooray for backups!

See also: Data Liberation Front Blog‘s Liberating Google Docs.

The LITA Program Planning Committee (PPC) is the committee that collects, reviews, and schedules LITA-sponsored programs for the ALA Annual Conference. The illustrious Jason Griffey is the chair of the committee for the 2008-2010 term. I was lucky to be appointed to the committee this year, at a time of significant transition for the program planning process.

For the upcoming ALA Annual Conference 2010, Jason Griffey and the LITA Program Planning Committee decided to switch the program proposal process from a paper form and in-person interview to an electronic exchange: a Google Form and email correspondence this year, and hopefully a conference planning system by next year. (The PPC ProgramProcess TaskForce recommends the Open Conference System, an open source application from the Public Knowledge Project.)

With generous help from Ranti Junus, Systems Librarian at Michigan State University Libraries, a senior member of the committee, and Chair of the PPC ProgramProcess TaskForce, I learned that the process used to be very involved:

1. The chair, co-chair, or vice chair of the Interest Group (IG) sponsoring the program would fill out the paper form and make many copies for each PPC member to read. (The information requested on the paper form was exactly the same as that requested on the Google Form this year.)
2. The IG would arrange an appointment and meet with the PPC for 20-30 minutes.
3. Feedback from the PPC was immediate: clarifications, potential audience, etc. PPC sometimes suggested the IG collaborate with other IGs within LITA or with other divisions. Typical collaboration usually entailed asking the other IG/division to co-sponsor to share information about the program with their own members. Time slots were also discussed. (Usually, the PPC chair had the timetable with her so she could check with the conflicts.)
4. The PPC would then come to a consensus.
5. A PPC liaison who was assigned to the IG would take over communication to the IG proposing the program after ALA Annual. The liaison was the go-to person for the IG for all PPC-related communications and was responsible for making sure that the IG would get the information they needed in a timely manner. Liaisons were also responsible for reminding the IGs about turning in other information such as the names of the speakers, communicating PPC discussions related to the respective IGs, and informing PPC about the IG’s progress preparing the program.

This year, with the use of Google Docs, Griffey was able to set up a Google Form for program proposals. The information from the Google Form was funneled into a Google Spreadsheet shared by all the members of the PPC. This was the process so far this year: Read the rest of this entry »

Through a happy coincidence, I attended a programming workshop presented by Joe Osborn, a software engineer, game designer, and my fiancé. Since our schedules have been wacky lately, we decided that I would go with him to campus to work on my own research today. But his presentation was too interesting to ignore, and I found myself taking notes.

Joe Osborn preparing for his workshop on programming at USC

Joe started with some pointers:

1. Self-directed learning: In order to really learn a programming language, it needs to be self-motivated “otherwise it won’t stick.” Start with a programming language that makes sense to how you understand the world. If you’re good at/interested in math, start with a language that uses mathematical functions.
2. Google it: Google is tremendously important and useful to learning how to program, as is Stack Overflow, a Q&A site for programmers. ”Generally if you have a programming problem, there is someone who has solved it.”
3. When in doubt, try it: ”It’s not worth it to take the time and reason about it, just stick it in and try it.” ”Plug it in, run the numbers, and see what happens.”
4. Ask your friends: ”If none of the above work, ask your friends.”

Environments

As computers got more complicated, we lost the “basic prompt.” What we have now is a bunch of different environments that we have to install to use.

Low Inertia Languages

All of these environments are really self-contained — download it, run it, and start playing — low inertia to get it running

• Gamemaker Lite: draw tiles that say “move an object forward” or “stop an object,” good for prototyping, Windows only
• Scratch: created by MIT, for graphical programming and can be used for games, click and drag, no syntax to worry about, “get used to the idea of thinking in steps”
• Max/MSP: visual, “like programming with a flow chart”
• PLT Scheme: language similar to Lisp, basic principle is “function applications,” “One of the classic learning languages,” great book called How to Design Programs, highly recommended, often used it to teach programming
  • (circle 10) will create a circle 10 pixels wide.
• Squeak: created in 1980, environment for Smalltalk, “Squeak gives you a big interface, like an OS inside an OS,” some really cool features like any text can be treated like code and then run, breaks down barriers between running the program and writing the program, Squeak Wiki, Smalltalk designed to be accessible to everybody

More Involved Languages

• Python: Windows and Mac installers, editing text files
• Ruby: very simple as far as languages go, why’s poignant guide to Ruby (PDF)
• Adobe Flex: not as friendly as other environments, but there is a huge community of users — lots of community support, Flash is applicable to Flex

One of the really nice things about programming, is that as soon as you learn one thing, it’s easy to learn something else.

Every good programmer needs to really hate the language they’re using at some point, and want to make a new one.

Everyone who programs has an opinion; everyone is biased.

If you learn any of these languages, it will be a lot easier to learn other languages.