Menu

It’s the middle of the semester and most of the Code Rascals are busy with library instruction. As an instructor, I typically rely on slide decks created in PowerPoint to deliver workshops and presentations to courses. Slide decks help me stay on track during a talk, prompt discussion and explain workshop activities, and create a record of how I’ve tailored sessions for different sections of the same class to meet student or instructor needs. I also really like designing slides. It’s a creative, almost soothing activity, that offers a brief distraction from more complex tasks.

Each semester I find myself dusting off slide decks from previous semesters to reuse and repurpose in old and new courses. Locating and editing slide files is a reminder of the ways PowerPoint falls short as a presentation tool for me (storage and access to the files can be cumbersome, custom fonts don’t display on some machines). I’m getting better at keeping my instruction files organized, but I still find myself scrambling to identify the most recent version of the slide deck, to remember which version I used for which instructor, and to ensure the slideshow will display properly on older PCs in campus classrooms I may have never set foot in. And, then I also have to successfully transport the files with me to various campus locations. OwlBox has been great for cloud storage and organization, but navigating within OwlBox to locate the file at the beginning of class can cut into instruction time, and there’s always a worry that wireless access will cut out leaving me unable to access my files. I hear that some folks use USB thumb drives, but I have a talent for losing those.

I do like PowerPoint, and this is not a rant against it. It’s typically my go-to presentation tool, but I’ve experimented with a couple of other tools this semester.

Slides is a web-based tool (with a free version) that allows you to create and store your slides in one place. The slides are HTML-based, built on reveal.js, an open source HTML presentation framework, and are viewable through a browser, so you don’t need to to have access to PowerPoint or other software to access them.

The Slides editing screen has the same basic features as PowerPoint. You can insert and edit text, media, shapes, and choose from a few basic style templates.

Another benefit is that you can use your phone to view speaker notes and advance through slides during your presentation

Benefits

Simple, intuitive editing interface

Version control

Slideshow can be played from your browser

Slide decks can be downloaded in the free version

Displays the same across devices (so, less worrying about whether the fonts you chose, images you selected, etc. will display properly on a different machine)

Haiku Deck is another web-based tool. I’ve only played with Haiku Deck a little, but the interface immediately feels less intuitive than Slides. I couldn’t control-z to undo my edits which could honestly be a deal-breaker. The great thing about Haiku Deck is the access to images, so if you’re one of those folks who loves using stunning photos to add meaning to what you’re saying, this may be the tool the for you.

Editing interface in Haiku Deck

Benefits

Embedded image search within the application

Access to high-quality images that photographers have licensed under Creative Commons

Automatically pulls in the attribution for photos

Drawbacks

Slide decks are public under the free version

Slide deck cannot be downloaded

Lots of pop-ups asking you to upgrade (though, it should be noted they have an education edition for only $5)

So, should you try any of these? Sure, but remember that the message of your presentation should not be overshadowed by your medium. It’s probably best not to use a new tool just for the sake of using a new tool.A good rule of thumb for using a PowerPoint alternative is to use it because it does something PowerPoint cannot do. For me, Slides offers portability, the assurance that my presentation will display the way I want it to, and access to speaker notes regardless of equipment setup which makes it a good tool in presentation environments with a lot of unknowns. Will I stick with it over PowerPoint? I’m not sure, but I enjoyed making these slides for one of my Gen Ed classes.

The Code Rascals are hard at work analyzing and summarizing our first round of usability testing of LibGuides. As we observe participants looking at our guide content, I’m reminded of a webinar I watched last fall called Web Writing with the User in Mind, hosted by Florida Library Webinars. The presenter, Rebecca Blakiston, UX Librarian at Arizona State Libraries, discusses ways that we can create a better user experience by writing better content for our sites. Blakiston begins with premise that people come to websites for content and to perform tasks. At the core of the presentation are 10 writing tips that we can use make it easier on users to complete tasks and find the content they need. The examples she provides refer mostly to content on library websites, but many of the principles can also be applied to our Research Guides. I’ll recap a few highlights here, but if you’re interested you can view her full slide deck.

Tips for Writing on the Web from Web Writing with the User in Mind

Know how users read on the web. Deep reading is rare and visitors are likely to scan to find content that’s relevant. Users also tend to focus their eyes on the left side of the screen, skimming down, but staying toward the top of the page.

Know your users. Use analytics data and talk to your users to better understand what they need need.

Simplify your text. Use no more than 25 words per sentence, use active voice, and avoid adverbs for stronger sentences. Fragments and shorter paragraphs can help users scan your content quickly.

Be Human. Use a conversational tone as if you were talking to the user at the reference desk. Write like you talk. Test by reading your text aloud to see how it sounds. Cal Poly San Luis Obispo library’s website is a good example of a conversational, but not overly casual, tone.

Thinking back to LibGuides, our guide text, including database and link descriptions, impact how users interact with our guides. One place we may do well to write more succinctly and intentionally is in our database descriptions. In our usability test, we observed that participants do read database descriptions (some more deeply than others) when selecting a database, signaling to us that we need to be thoughtful about what goes into the descriptions. We should customize database and link descriptions to the guide’s purpose and include details that tell the user how to use a specific resource or why it might benefit them. With course guides, for example, we can use language from course assignments to craft custom database descriptions that connect resources to specific course themes or assignments. In my Meaning of Madness:SPSY 0828 guide, I’ve included language from course assignments in my box titles, and I’ve attempted to keep my database descriptions short and related to the assignments. Writing custom descriptions also forces us to be more cognizant of which resources we’re presenting to users.

If you do add a custom database description, remember to set the description to “Display beneath item title” rather than hover, so that the user can see the description!

We’ll have another post later in the semester summarizing our findings alongside discussions of other best practices.

The purpose of our usability study is to understand how undergraduate users execute research and discover resources in our Research Guides, address system-level usability issues, and to generate a list of best practices for guide creators. We chose to do two to three rounds of testing and study only five participants at a time. This decision was based on findings from the Nielsen Norman Group that “the best results come from testing no more than 5 users and running as many small tests as you can afford.” The idea is that the same usability issues pop up again and again with each participant, and you eventually stop discovering new problems. This approach also gives us the flexibility to make small changes to Research Guides along the way and to re-design each test to probe more deeply into usability issues. To design our study, we began by generating a list of research questions to guide the creation of usability test tasks and to determine specifically what we wanted to know about the way users interact with Research Guides.

Recruitment & Testing

In October, we concluded the first round of usability testing. We recruited in early Fall semester using fliers, social media posts, and digital signage. Interested undergrads submitted their names in a Google Form and Jackie coordinated final meeting times through email. Participants were given $50 Barnes and Noble Gift Cards for their time.

Five users participated in usability tests that ran from 35 minutes to 1 hour. Each session took place in a breakout room in the Libraries’ new Digital Scholarship Center. Our set-up included a Mac laptop, mouse, and external monitor for the facilitators to observe as the participant navigated through the usability tasks. The sessions were also broadcast to a library conference room where other library staff gathered to observe the live sessions. We asked observers in the conference room to note usability issues and gave them the opportunity to ask follow-up questions of the participant. Two Code Rascals facilitated the test in the DSC breakout room while at least two others facilitated observation in the conference room. Sessions were also recorded using Quicktime, so that we could conduct a more thorough analysis later. While each test highlighted a number of usability problems right away, we also wanted the ability to re-watch the tests later in co-viewing sessions as this method provides rich insights that may be overlooked during the live session.

Participants included

1 Freshmen Biology major

1 Sophomore Film major

1 Sophomore, Actuarial Science major/Spanish minor

1 Freshmen Secondary Education/English major

1 Sophomore Psychology major/Italian minor

Overview of the test protocol

We began with a few basic questions including

What is your major and department?

Have you used the library website to conduct research before?

Have you attended any library workshops since you’ve been at Temple?

We then asked participants to complete a series of tasks using the “think-aloud” method or to “literally talk us through what you’re doing and what you’re thinking.” Each participant explored Research Guides freely for 2-3 minutes and gave us their general impressions, completed 7 research-based tasks in different scenarios, and completed an “XO” test where they circled things they liked and crossed out things they did not like on print outs of a subject guide and course guide in their major or minor. The full usability script is available here.

The Rascals are still in the midst of analyzing each recording. We’ll report some preliminary findings here, though look for a more thorough analysis and report at the end of the academic year. Next steps for us include designing a second round of usability testing for Spring semester and generating best practices for guide creators based on the findings by early Summer.

A cadre of Code Rascals visited Portland, OR this spring to attend the ACRL 2015 National Conference. Caitlin, Jackie, and Jenifer conducted a roundtable discussion, “Upskilling Liaison Librarians: Code, Community, and Change.” We were thrilled to have a table full of colleagues from around the nation who were interested in sharing their thoughts and experiences. Discussion topics ranged from the challenges of evolving liaison roles to practical tips for forming a learning community within the library and reaching out to the wider campus community.

A friend active in making and hack-a-thons recently brought an article from the online journal Model View Culture to my attention.

Titled C is Manly, Python is for “n00bs”: How False Stereotypes Turn Into Technical “Truths”, the article examines the socio-cultural biases attached to various programming languages. For example, older developers may be looked down upon for knowing languages that were popular twenty years ago; alternately, due to the well-documented gender discrimination affecting the computer coding field, other languages become associated with “less manly” forms of programming–such as front-end development rather than server-side scripting.

The authors make an excellent case for going beyond such ageist or sexist biases, pointing out that–given the facility with which skilled programmers can learn new languages–the level of project experience one has on one’s resume is a much better indication of skill level than knowing this-or-that-language. Additionally, the authors discuss how disciplinary differences affect choice of programming language. In such cases, biases against a language serve as a proxy for biases against the particular discipline that has adopted it, giving an appearance of objectivity to an ultimately ideological us-versus-them mentality and serving to separate various social groups.

Given the library’s service orientation, I found this article provides a cautionary tale against the possible use of technical knowledge in support of an ultimately false conception of power. Especially at Temple, where we value the diversity of our student population, and in the library, where we serve constituents from a number of different disciplines, using knowledge of a particular language or tech paradigm to form in-groups and out-groups is unhelpful and contrary to our professional mission.

Earlier today, Proquest hosted a webinar with Godmar Back and Annette Bailey on the work they’ve been doing at Virginia Tech to customize some aspects of the Summon interface. See their Code4Lib paper for the technical details. Much of the webinar consisted of watching Godmar Back think aloud, navigating the code, to show how they “reverse-engineered” Summon code to identify components of the AngularJS framework they could augment. They used a utility for deobfuscating the source code (Code Rascals W0rd of the Day: Grep) so that they could identify Summon developers’ custom directives that they could modify with their own JavaScript. At least, I think that’s what they said they did.

According to a recent interview with Proquest, the original motivation for all of this was to be able to capture user click-throughs in Summon results for Virgina Tech’s libFX project. Check out the “discipline ticker” for an example of what they were trying to do. But, of course, it opened up the possibility for other customizations.

Example of a default expanded facet.

Examples included being able to improve labeling of links, or to have certain facets default to an open state on search results pages, and to retain that choice after page reloads. Another example, demoed at the end of the webinar, was the insertion of local notices, such as simultaneous user limits, into certain result displays.

They acknowledged that considerable technical skills were necessary for sleuthing the Summon code. They also acknowledged what they felt were the “moderate” risks associated with “writing code that directly interfaces with vendor code,” and expressed confidence that the risks were manageable. A big takeaway from the webinar is that much is possible, even when dealing with seemingly inscrutable vendor interfaces. It would seem that what it takes is a culture that supports experimentation, and a willingness to invest the necessary resources into creating the best possible user experience regardless of whether a system was developed in-house or purchased from a vendor.

I recently stumbled upon a post in ACRL’s TechConnect blog from librarians Margaret Heller and Will Kent at Loyola University Chicago describing their migration to LibGuides 2.0. Their implementation of ‘sticky tabs‘ intrigued me. They implemented the Affix plugin for Bootstrap (the framework on which LibGuides is built) which fixes LibGuides’ tabbed navigation to the top of the page as the user scrolls through the guide content. The tabs are more visible, and the user doesn’t have to scroll back to the top to navigate to another section of the guide.

After some preliminary investigations, the Code Rascals decided that sticky tabs looked simple enough to implement. Jenifer located some helpful tutorials on the affix plugin, and we spent one of our meetings tinkering with incorporating the code into LibGuides’ customizable settings. After some trial and error (and frustration), I finally had some success a few days later!

Sticky tabs in action

I’ve noticed on many of my own guides that the homepage has the greatest number of hits, while other pages and subpages have far less traffic perhaps suggesting users are finding what they need on the homepage, or perhaps that they don’t notice the navigation to other sections of the guide. Without presuming too much about user behavior, here’s hoping that the sticky tabs increase user awareness of content beyond what’s visible on the homepage. The sticky tabs should at least ease navigation through the rest of the guide.

Try the sticky tabs out yourself here and let me know if you have any feedback. We plan to introduce a template that you can select for your guide if you’d like to start using sticky tabs!

Though we have each chosen our desktop text editor of choice, we are currently exploring online environments in which we can collaborate in our code editing practices. Below are a few of the online editing spaces that we have explored thus far:

Collabedit offers free online editing in a variety of languages, along with a chat bar on the side so that editing partners can communicate. It is very minimal and does not feature color coding or autofill.

Stypi (formerly https://code.stypi.com Stypi became defunct in 2015)

Stypi is another free online collaboration space. Like Collabedit, it is very minimal, with one common coding area and a side bar for collaborator chat. However, Stypi also features auto complete and color coding for the various languages that it supports.

While it does not support the same variety of languages as other editing spaces, JSFiddle does offer three simultaneous windows for editing the HTML, CSS, and JavaScript of a page, plus a fourth window to view the result in realtime. And, like the other editors, it is free and has a chat bar on the side.

Since our current focus is on front-end web design, we will be experimenting further with JSFiddle in the coming weeks and months. Keep your eyes peeled for more in depth exploration of this and other online collaboration tools.

One thing we Rascals knew at the outset was that we needed a place to play. Information sharing is great, but we all know from experience that, for work of this nature, the learning is in the doing. While Treehouse.com gave us prepackaged exercises we could follow, that didn’t challenge us to retain, adapt, and apply what we were learning beyond the moment the tutorial ended.

In a learning environment, space to play is essential. We wanted to identify a low stakes project that would allow us to build, test, and rework all the front-end development tools and strategies we were learning about. The end product would simply serve as a portfolio that we could share. However, as public services librarians, we were operating outside of our formal organizational roles. As a grass-roots group working on self-development, with perhaps a blessing but not a mandate from the administrative hierarchy, we had little access to the sanctioned resources. Without access to a library-run development server or sandbox, we would have to find another way.

We worked our way through growing pains and sidestepped many roadblocks; an idea was too large-scale, an idea crossed over too much into the responsibilities of another area in the organization, the experimental nature of our aims (education and staff development) meant our needs had far lower priority than projects already in line for production. So on. So we reset our direction. For the time being, our sandbox will be our free Mexican server access and our astro sites, and the back-end access we still have to systems like Libguides will be where we’ll tackle small “fixes” that can improve user experience.

Reflecting on a summer of jumping hurdles calls to mind a quote (attributed to various folks over time, but Grace Hopper might be most fitting to cite here): it is easier to ask forgiveness than get permission.