Learning Objectives, Challenges and Insights

The co-op provided me with ample opportunity to work on professional and personal learning goals. While I have progressed in several different areas, I will describe my experiences with three particular learning objectives, with the challenges I encountered and the insights I gained.

1. Instructional writing for the web
2. Expanding interpersonal communication
3. Overcoming Contribute

1. Instructional writing for the web

Although a seasoned writer online and otherwise, I wished to gain experience with instructional writing for the web. From structuring items intuitively to using understandable and level-appropriate language and terms, text on the web can either discourage or invite readers, then either frustrate or enlighten and engage. Techniques for presenting material clearly can be easier to recognize than replicate, however, especially with other compromising factors involved.

Identifying AND (mollifying OR challenging) the audience

The main issue with creating the Research Help web pages was imagining the intended audience and determining the top priority: do I aim for non-intimidation with small amounts of text and catchy graphics (to increase the likelihood the pages are actually read), or do I aim for providing comprehensive information? Though the page topics were fairly straightforward, I also had to decide what constitutes necessary and desirable content. Was I giving students the information they need, or the information I think they need?

While the pages target primarily undergraduate students, undergrads are far from a homogenous group, from age and cultural background to their familiarity and actual proficiency or lack thereof with technology, research and information literacy.

The complexity compounded from there: Do I describe research in the simplest terms for the most basic comprehension and readably, risking condescension and boring more adept users? Or do I raise the level and potentially alienate the learners for whom this is all new and potentially confusing or outright foreign, such as the concept of plagiarism for some non-Western students? If I provide too much information, will it seem overwhelming and not worth delving into at all? At what point does this happen for a reader, and how can I structure text to aid its consumption? What about the eager keeners, dying for an in-depth discussion of how peer review works? And wait a minute... didn't people learn this stuff in high school?

In preparation for content creation, I looked at how other academic libraries handle information literacy topics, paying close attention to the tone, length and depth of content, as well as the use of images, layout and overall structure, such as breaking up text over several pages or keeping everything on one page. The latter risks the dreaded "wall of text," though clicking through page after page of only a paragraph or two can be just as bothersome, especially for printing or visually scanning or keyword searching the material.

While struggling with simplicity versus complexity, I ultimately used relevance as my guiding principle. For example, Library of Congress Classification (LC) has a long history and contextual intricacies that I as a future librarian find fascinating (and several academic libraries I looked at devote some space to exploring it). While basic understanding of LC facilitates its use, a detailed description about its development and features is useless for the undergraduate student looking for biology books. She just wants the general call number range and the location of where to find them in the library. Writing and revising several times over the content for the Research Help pages, I've come to the conclusion that if the information is not relevant to the task and learning at hand, it should not be included.

Relevant Content

A telling example is how I arrived at the definition of a database, the basis for the "What's a database?" page. Many terms and tools in library studies originate in computer science. This can make standard definitions confusing, daunting and useless for library users—in this case, students looking for research articles.

The Online Dictionary for Library and Information Science describes a database as:

A large, regularly updated file of digitized information (bibliographic records, abstracts, full-text documents, directory entries, images, statistics, etc.) related to a specific subject or field, consisting of records of uniform format organized for ease and speed of search and retrieval and managed with the aid of database management system (DBMS) software. [1]

Many academic libraries, in their glossaries and instructional pages, mimic this sort of definition, such as Albertsons Library at Boise State who begins, "Database: A collection of computer records that have a standard format, usually containing Fields that are searchable and allow some electronic manipulation such as sorting or grouping" [2].

Library professionals understand what this means—and most students could, but they shouldn't need to, not for completing their Greek and Roman Studies assignments. Even the concise definition offered by the Shapiro Undergraduate Library at the University of Michigan—"A computerized file, often of periodical indexes" [3]—is laden with jargon.

See an image of the database page.

Though disparaging such brutally technical definitions, I still faced a conundrum. I believe that the more people understand about a system, the better they will be able to exploit it: to make it do what they want, to troubleshoot when things go wrong and to apply this knowledge to similar systems and situations. But I also realize that most students don't care what a database is, they just want articles.

As such, I distilled the complexity of database structure and functionality into "A database is a searchable collection of information. In library research, a database is where you find articles" [4]. If for any reason students need more information than that, they can research it on their own. The text continues from there, providing more basics about the types of databases they will encounter, what they contain and tips on using them effectively.

Though aiming for maximum relevancy, some sections of the research pages include more depth than others. I used an admittedly arbitrary "that seems about right" gauge for page length and complexity. Rather than spread content over multiple pages, I included bookmark links at the top of longer sections so users can see what topics a page discusses then jump right to them. This is also consistent with other sections of the site, authored by other librarians and staff. Hoping to push the content further and compensate for potential oversimplification, I also included applicable tips and links to more information when I thought it appropriate and useful, especially when addressing a common misconception.

For instance, on the database page, I remind students that clicking "full text only" in online databases precludes them from accessing the near-instant full text from other databases through SFX, our database linking software. While an unfortunate trend in itself, students' impulse to limit to full text presents a painful irony: their demand for immediate gratification combined with misunderstandings about databases cause them to insist upon and receive less of what they want.

Every time I mention this to a student at the reference Library Help Desk, I receive a look of horror. It's not intuitive, and not something the average user would ever notice, thus my decision to include it on the database page. As an added bonus, not clicking full text utilizes our SFX popup, which in addition to potential links to full text also includes links to the catalogue to find items in print, as well as links to interlibrary loan. These remind students that they have other options besides full text.

Relevant Design

See an image of the style guides page.

As originally envisioned by LIG, the style guide page contained a text-only two column list of links for the "Most often used style guides" and "Subject-specific style guides." Looking at other style guide web pages, I found the most effective ones include images of the manuals, which I decided to add to UVic's page. This makes the page more appealing, and users recognize and are instantly drawn to the guide they need.

Upon adding the cover shots, I reexamined the page layout; in a single screen length, half of the most often used guides were visible, along with half of the subject-specific guides. Why not all of the most often used guides? Swapping out the two vertical columns for top and bottom sections puts APA, MLA, Chicago and Turabian all visible on one typical desktop or laptop screen.

return to top

2. Expanding interpersonal communication

In this co-op I wanted to move beyond my historic reliance on chain-of-command–style interaction and communication. In the past I have sought advice from and requested or transmitted information through a direct supervisor, whether or not that supervisor had a role in the project. As I assume roles with increased and increasingly diverse responsibilities, I see more value in and opportunities to eliminate intermediaries and go directly to the source.

This was particularly fitting for this position, given Pia's hands-off supervisory style, busy schedule and detachment from the website redesign. If I had any technical or logistical questions about the website, Pia would most likely not know and need to ask someone else—so why don't I ask that person myself?

My initial reluctance to do so was the concern that I might be bothering someone or that I was overstepping my bounds (for instance, critiquing parts of the site for which I wasn't responsible). It was also difficult because I did not actually belong to the WRAP group and was not in the loop with many of their activities, timelines and so forth. I did not need to be part of the group, but the more involved I became, the more I wanted to be (though by this time, the website was nearing completion, rendering it moot).

Though coming in at the end of the redesign, I found it interesting to see a massive project involving multiple talents come together—from the librarians and IT staff to the outsourced design team. The more I saw my comments and questions favorably received, the more comfortable I became with drawing attention to potential problems and inquiring about the process as a whole. While it wasn't my "job" to do and know these things, I did have a responsibility to my own curiosity and initiative to learn beyond my stated duties with the content development. As a result, I learned from—and added to—the project significantly more than had I stuck solely with Pia.

return to top

3. Overcoming Contribute

However much of a "learning experience," the final objective I hoped to explore turned out disappointing—learning Adobe Contribute, or rather, learning how to overcome its constraints. Aimed at novices, this web page creation and updating software attempts to eliminate the esoteric bits of web work that intimidate lesser-skilled users.

After the site launch, UVic Libraries implemented Contribute because several librarians and staff, all with varying skill levels, work on pages, and Contribute keeps it simple and relatively fail-safe. The editor is allegedly WYSIWYG—What You See Is What You Get—but I and others often found this not the case. In other web software, more adept users can view and fix the code so pages display properly, but this option is not available in Contribute, leaving people who otherwise know what they are doing trial-and-error troubleshooting a limited—and limiting—system.

While I am not an expert in web design, I found it exasperating. The situation reminded me of my paradox with writing content: who is it better to serve? Those who already understand and can most effectively manipulate a system to achieve stunning results, or those who don't know what they're doing but are now more easily able to muddle through, consequently lowering everyone's performance? Ironically, web novices were just as frustrated by the software's hit-and-miss usability.

Contribute also locks out much of the striking CSS developed by the design firm. The software thus cheats UVic Libraries out of the aesthetics and functionality it commissioned and paid for. It also cheats us out of our own talent, forcing us to figure out workarounds instead, or give up and be content with the less than satisfactory.

Granted, Contribute does have different levels of permissions and lockdowns, which UVic Libraries is still figuring out. Whether it will improve or stay in place at all remains to be seen. In the meantime I share troubleshooting tips and commiserate with my colleagues, becoming the de facto go-to person for Contribute troubles in the department. If nothing else, I am glad to have been exposed to it if only to know now to stay away from it, should I ever be in the position to help make a purchasing decision for a library in the future.







[1] Reitz, J. (2007). Database. In ODLIS—Online dictionary for library and information science [online]. Retrieved August 31, 2008 from http://lu.com/odlis

[2] Albertsons Library, Boise State University. (2006). Database. In Library jargon defined. Retrieved August 31, 2008 from http://library.boisestate.edu/Reference/BBRIN/jargon.htm

[3] Shapiro Undergraduate Library. (2004). Online database. In Library glossary. Retrieved August 31, 2008 from http://www.lib.umich.edu/ugl/guides/glossary.html

[4] Holle, M. (2008). What's a database? Retrieved August 31, 2008 from http://library.uvic.ca/site/lib/instruction/research/database.html