Article title: The ICAP (Interactive Course Assignment Pages ...

jockeyropeInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 9 μήνες)

148 εμφανίσεις


Article title:

The ICAP (Interactive Course Assignment Pages) Publishing System




Abstract



OSU Libraries developed a tool to make it easier for librarians to build and maintain course assignment
pages (ICAPs). The ICAP creation tool is built on Ruby on

Rails, a lightweight, yet powerful open
-
source
framework for web development. The ICA creation tool enables librarians with minimal technical
expertise to create dynamic web pages that integrate Web 2.0 features, chat and RSS feeds, etc. with
traditional
library content, such as catalogs and article databases. The tool was developed using user
-
centered design techniqu
es and in an agile environment.

As of December 2007, the code is available as
free, open
-
source software.[1]


Author full names


Margaret Me
llinger

Kim Griggs


Author biographies


Margaret Mellinger is an Engineering Librarian at Oregon State University Libraries, and the lead of the
ICAP team.

Kim Griggs is a Programmer/Analyst at Oregon State University Libraries, and the programmer of th
e
ICAP publishing system.


Author e
-
mails

Margaret.Mellinger@oregonstate.edu

Kim.Griggs@oregonstate.edu


ICAP Project Background


This project originated in a 2005 needs assessment conducted by Oregon State University Libraries
(OSUL) to determine the best

approach for connecting students with the wealth of information available
to them through the library. We were particularly interested in lowering the barriers to library use for
undergraduates searching for topical information. Initially, we considered b
uilding undergraduate
portals based on colleges or subjects, but as we gathered data, read about undergraduate research
activities and habits, and listened to students, we changed the direction of our subsequent project.[2]
Undergraduates, especially lower

division students, identify more with courses they are currently taking
than with a specific college or subject. They prefer clear starting points for library research, need to
save time, and are very interested in resources that have been recommended by
their instructors.
Rather than developing generic subject or college portals, we focused on library help pages that are
tightly aligned with courses and assignments, include some interactive, or Web 2.0 features, and are
also simple for subject librarians
to create and maintain. The internal name we have been using for the
project is "Interactive Course Assignment Pages," or ICAPs.


We investigated a variety of ways to deliver the course
-
centric, interactive web pages: library portal
software, campus porta
l software, course management software, content management systems, and
web page templates. Because we wanted to lower barriers to participation, we were wary of
implementing library portal software that would require students to log on and create profiles
, so we did
not choose that approach. We were interested in the possibility of developing a tool that integrated with
campus portal software, but it was not an option as our institution evaluated and declined to purchase a
campus portal system. Because we
wanted to integrate library resources with particular courses, we
carefully considered campus course management system, Blackboard. There were several challenges
with a potential Blackboard integration. First, it is not used universally across our institut
ion; two of our
largest colleges, Engineering and Business, use internally developed course management systems.
Second, Blackboard itself was not as flexible and customizable as we envisioned our pages. Finally, it
was not apparent that the Blackboard team

had the resources to work with us on developing a new
service. We knew that a content management system would work for this project. OSUL had a long
-
term plan to move the library web pages into a content management system, but it was not in place at
the t
ime. We tested static HTML templates as an early prototype of the course assignment pages, but
they did not give librarians the ease of publishing or content re
-
use that we desired. When we reached
this stage of the project, we realized we needed to hire a

programmer, and before we did so, we
wrote

use case scenarios and distilled from those the baseline project requirements.

Project Requirements

The project requirements fell into two large categories:

End User Requirements



Library course pages that are e
asily found on the OSU Libraries home page



Pages discoverable by course number



Pages that had content recommended by instructors as well as librarians



A quick search box (federated search tool)



Modules that help students find books, articles, the best
web sites, style guides, course reserves,
news feeds



Link to chat service for live librarian help.



Modules t
o provide greater interactivity


Functional Requirements



Generate course assignment pages with a consistent look and feel



Enable librarians to cr
eate pages with no HTML or other technical knowledge



Use a web interface for content input



Choose which modules appear in the web page



Choose which databases are searched in the federated search



Add RSS feeds to the page



Add Learning Objects (small mov
ies that instruct students on research concepts or library tools )



Ability for librarians to change the content and headers of the modules manually



Manage the publishing of the web pages to the libraries’ web server



Provide permissions and authorization

control



Support content re
-
use between course assignment pages



Framework to allow further interactive features and content re
-
use


The programmer came on board in September, 2006 and further explored available proprietary and
open sources solutions that

might meet the project requirements. Several library
-
created open source
options were good possibilities. She looked at the University of Minnesota's
LibData and CourseLib
[3]
but found that the complexity and comprehensiveness of the software was not a m
atch for this project.
The system requires a significant amount of
set up
, and we wanted instead to allow librarians to
contribute and manage the content, without heavy administrative overhead. Also, the interface seemed
complicated and required users to h
ave some HTML knowledge to format text. University of Rochester's
Library Course Builder
[4] met the requirement of focusing on the course, but as the tool is built in
ColdFusion, OSUL would have had to buy the software, set up a special server, and find C
oldFusion
programmers. This did not seem to be a good way to leverage server space and programmer capacity
when the development environment at OSUL favors MySQL, PHP and Ruby on Rails. While Ithaca
College's
Subjects Plus

[5] uses PHP and MySQL and would h
ave fit into OSUL's current development
infrastructure, it would have needed to be extended to meet our project requirements, as it focuses on
the broader subject level and is set up to build lists of recommended resources from their libr
ary
catalog and da
tabase lists.
After getting a clear picture of the computing environment at our institution
and inventorying the available open source and proprietary software, we chose to build a custom
solution.


About the ICAP Publishing System


The ICAP publishing sy
stem is a custom content management system that enables librarians to easily
and quickly create and manage course assignment pages (ICAPs). ICAP is a dynamic system; rather
than forcing users to write code, it takes care of those details and lets librarian
s focus on the actual
content to be displayed. This makes it easy for librarians to quickly add or change content, without
requiring knowledge of HTML or other web technologies. The system's unique features include an
emphasis on collaboration and content
reuse and an easy
-
to
-
use interface that includes in
-
line help,
simple forms and drag and drop functionality. The system generates dynamic, attractive course
assignment pages that blend Web 2.0 features with traditional library resources, and makes the page
s
easier to find by providing a central web page for the course assignment pages.


The publishing system includes a user interface to create, edit, copy, share, and publish course
assignment pages. The tool also automates the task of sending the URL of a p
age to the instructor. In
the current workflo
w, an administrator registers a

user and provides them with a temporary login /
password. A user then logs in and can create new pages or edit their pages, modules, and account.
Once a page is created, librarian
s can add content, in what we call modules, to the page. Currently,
there are modules for a Librarian and Instructor profile, an assignment module, a RSS module, a
federated search module, course reserves, custom content and a widget module. The Librarian
profile
can include an image and a chat box. Both the Librarian and Instructor module provide contact
information and links to related websites. The assignment module includes links to the assignment,
syllabus and custom content. The Librarian, Instructor,

and Assignment modules are designed to
communicate to the student that the pages are recommended by their instructor and also to build
awareness of the subject librarians. The custom content module include a WYSIWYG (What You See Is
What You Get) text edi
tor. The WYSIWYG enables librarians to easily add links, images, lists and
formatted text without using HTML or Wiki mark
-
up. The widget module includes a code editor that can
be used to embed 3rd party widgets, like YouTube, Google Custom Search box, and
LibraryThing. The
module for OSUL's federated search engine, LibraryFind [6], can be customized to search selected
databases. The course reserves module automatically pulls information from our catalog and the RSS
module aggregates and displays data from a

RSS feed. Users can also share their pages with other
system users and publish their pages to the OSUL website through the interface.


The course assignment pages the tool creates are Netvibes
-
inspired, with modules that chunk the
content under helpful he
aders. The pages maintain a consistent look and feel that harmonizes with the
rest of the library web site and ensure web and accessibility standards through the use of CSS and
templates. We wanted the pages to have a consistent look and feel, so the tool
controls the design of
the pages, but lets librarians choose from a one or two column layout. Both content within the page and
the layout of that content can be customized to a certain extent. The interfaces of both the ICAP tool
and course pages were care
fully designed with all of our users in mind.


Designing the ICAP system


The ICAP team was committed to using user
-
centered design techniques while developing the project.
User
-
centered design (UCD) is a philosophy in which the user's needs, wants, and li
mitations are
considered at every stage of the development cycle. It was necessary to involve our three user groups,
Librarians, Students and Faculty, to increase buy
-
in, facilitate using Web 2.0 applications, avoid feature
creep, and most importantly, imp
rove the user interface. Usability testing is an iterative process; it is
important to conduct usability testing throughout the development cycle. By designing for our users and
then testing with our users we had built
-
in early adopters, quality assurance,

and an invaluable
knowledge base.


The first phase of the project was to develop a design and define the basic functionalities of the
interfaces based on the use
-
case scenarios for each us
er group. The student interface

(the course
assignment pages) was d
esigned with the guiding principles of saving students' time and helping them
discover quality resources for their course work. We developed an HTML template that was used with
students for three terms beginning in Spring 2006. With the help of course inst
ructors in five classes,
we surveyed 130 students about their experience with the course assignment pages [7]. The results of
this survey helped us identify what was working and what changes needed to be made to the pages.
We found that some students were
not using the pages because they did not know about them. We
needed to make the pages more findable from the Library home page and embed links and information
about the pages in the course web pages and syllabuses. We also found that students needed help
n
avigating through the many resources libraries offer and to address that we decided the pages needed
to support both browsing and search strategies. Students wanted to be able to connect to the reference
librarian outside of the library, so we planned to a
dd more communication options to the pages. Most
importantly, the majority of the students responded positively to the pages and indicated that once
they knew about them they were using them. We have continued to solicit feedback from students in
the form
of online surveys, chats, and emails and will soon undertake a more in
-
depth assessment of
the pages and their effectiveness for students.


Next, we developed the ICAP tool. Working with a graphic design student, we first developed a paper
prototype of the

ICAP tool's interface. We started with a paper prototype because we did not want to
commit to any one solution or development framework before we had a good idea of the needs of
librarian users. The vertical prototype demonstrated only the core functional
ities, which allowed for
more interaction with the tool, such as interacting with error pages. A number of steps were taken to
assess the needs of librarians. We first tested the paper prototype with five librarians who had varied
technical skills. We aske
d the librarians to perform five core tasks (create, edit, clone, share, email
URL) with the prototype while thinking aloud [7]. At the end of each task the librarians were asked to
rate levels of satisfaction and ease of use. We also evaluated the tool on

librarians' success rate based
on the time it took to perform tasks and the number of errors made. At the end of the test the
librarians were asked to rate their overall impression of the tool and offer suggestions and feedback.
The results from that init
ial study indicated that since OSUL librarians had been using Dreamweaver
and Contribute, their mental models of the process of creating web pages did not match the tool's
interface. This resulted in confusion over terminology and workflow while editing an
d cloning (copying)
a page
.

We changed the terms and workflow to align more closely with the familiar Microsoft model of
file operations: open, copy and save as. We also noted that librarians could not find what they needed
to complete some of the tasks. W
e decided to rework the interface and make navigation easier. One
main goal of the tool was to alleviate technical gaps among the librarians. We hoped that we could use
wiki
-
style editing to give the librarians control over the format of the custom content

they create for the
pages. But we found that the wiki
-
editing was too difficult for some and that users preferred formatting
text in the manner of Microsoft Word. Using all these results, we built a prototype of the tool in Ruby on
Rails and had three dif
ferent librarians conduct the same test on the interactive interface. This test
uncovered more terminology confusion and additional workflow issues, which we addressed. We
iteratively tested and responded until we were ready for an initial release in Sprin
g 2007. Knowing
when to stop testing and release the project is never easy. We used our use
-
case, goals and deadlines
to define the initial beta release, knowing we were going to continue developing the tool. During the
beta release, we set up a forum for
librarians to provide feedback and to facilitate open communication
between the users and the development team. From the forum feedback and other conversations, we
improved the workflow to make the tool easier to use and added new functionalities based on
the needs
and requests from the librarians. We have rolled out new feature sets at the end of every term since
the first release and periodically offer training.


A word of caution about following the "release early and often" mantra. When releasing beta p
rojects it
is important to manage the expectations and perceptions of the user group through clear
communication. Releasing without the full feature set can turn potential users off and decrease faith in
the project, unless users trust that the beta produc
t will evolve to suit their needs. Even though we
employed user
-
centered design techniques and iteratively conducted user testing, users still doubted
that the tool would meet their expectations. We learned quickly that we needed to increase
communication
and user involvement. Feedback is solicited in a variety of ways, including user testing,
user training, a discussion forum, surveys, email, meetings, and personal communication. Releasing
new feature sets in response to user feedback restored faith in the

project and created a sense of
ownership in the product which built an unanticipated level of adoption.


ICAP System Architecture


The ICAP system technology stack consists of Ruby on Rails, MySQL, Mongrel and Apache.

/** link to larger image

http://ww
w.gliffy.com/publish/1346496/


/** to embed image

<script src="http://www.gliffy.com/diagramEmbed.js" type="text/javascript"> </script>

<script type="text/javascript"> gliffy_did = "1346496"; embedGliffy(); </script>


The ICAP system is implemented in Ruby

on Rails (Rails), an open source web applica
tion development
framework.[8]

Rails provides all the components necessary to build complete da
tabase
-
backed web
applications.

Rails is an MVC (model, view, controller) framework. The model
-
view
-
controller (MVC)

design pattern separates the data access (model) and business logic (controller) from the data
presentati
on and user interaction (view).

Rails provides 'out of the box' scaffolding which can construct
most of the user interface needed for a basic website.

Rails targets a fast development cycle with zero
turnaround time, which enabled us to iteratively test and immediately refine our prototypes.


The ICAP system is mounted on an Apache web server with Mongrel, uses MySQL as the database and
is locally hoste
d on UNIX servers. The database consists of 20 relational tables and rich complex
relationships. For example, the resource table is a polymorphic table that uses Rails
:through
clause for
the associations of the different modules to the page they belong to
. The use of a polymorphic table
enables us to easily add new module types to the system without having to build multiple near
-
identical
join tables and complex insertion methods to maintain the relationships.


The following code snippet
demonstrates the p
olymorphic relationships and the helper methods that ease the selection and
insertion process of a page's modules.


/**

* Resource Table Migration

* Builds a polymorphic table that associates the different module types

* (librarian, instructor, course res
erves) to the page that they belong to.

* The table uses the page id and the

* module id and the module type to make the associations.

**/


class CreateResources < ActiveRecord::Migration



def self.up



create_table "resources", :force => true do |t|




t.column "page_id", :integer



t.column "module_id", :integer



t.column "module_type", :string



...



end



end


/**

* Resource Model

* Tell the class it has a virtual association by setting polymorphic to true. This

* creates an inter
face that the modules can then associate with. We must also tell the

* resources that they belong to a page.

*

**/

class Resource < ActiveRecord::Base

belongs_to :page

belongs_to :resource, :polymorphic =>true

...


/**

*Page Model

*Tell the pages about its

resources

**/

class Page < ActiveRecord::Base

has_many :resources

...


/**

*


Assignment Module Model

*


Associate the modules to resources
as

a resource so that it uses the Module ID
instead of the Assignment ID

*


in the polymorphic table.

*


Tell the m
odule it belongs to a page

through
resources

**/

class Assignment < ActiveRecord::Base

has_many :resources, :as => :resource, :dependent => :destroy

has_many :pages, :through => :resources

...


/**

* Page Model

* Methods to add and get a page's modules

**/

// get the collection of associated modules. Each module is automatically cast to its
model class

def modules



mods = resources.collect {|a| a.resource }



return mods

end


//Create the resource and build the association of the page to a module throug
h
resources



def link(mod)



resource = Resource.create(:resource => mod)



self.resources << resource



end


/**

* What we can do now...

**/


//Get a page using Rails dynamic finder

page = Page.find_by_title("English Comp") #
-
> <Page:054313... >


//Create and add some modules to a page

page.link(Assignment.create(:name => "Course Assignment"))

page.link(Librarian.create(:name => "Course Librarian"))



//Get the names of the modules on this page

page.modules.each do |module|



module.name

end

#
-
> "Course Assignment", "Course Librarian"


One requirement of the tool was to provide authorization and permission controls. There are currently
two types of users in the system: authors and admins. Authors can create new pages and modules and
edit only t
he pages and modules belonging to them. An admin user can register new users, create new
pages and modules, edit all the pages and modules, and grant ownership of any page to any user
within the system. To secure a user's account, the password runs through

a SHA1 encryption with a
randomly generated salt value. Once a user is authorized in the system, the user ID is stored in a
session variable. This session value is used in a Rails
before_filter

that constrains the dynamic finder
with the criteria that the

owner of the page or module must match the current user. This prevents a
user from editing pag
es and modules they do not own.

Other precautions exist in the code to protect
against security risks. One particular security challenge we faced was how to allo
w the addition of 3rd
party wid
gets to the tool. T
o allow widgets
,

we have to let users embed HTML tags that can expose the
database to cross
-
site scripting. We are in the process of enhancing our widget module with a custom
sanitization method that uses c
omplex regexs to strip out and rebuild the code snippets from popular
widget sources. Adding the sanitization process secures our database from malicious code while still
allowing librarians to add some 3rd party widgets to their pages.


Another requiremen
t of the tool was to be able to provide interoperability with other applications. For
example, we wanted the tool to be able to interact with our OSUL federated search engine, LibraryFind,
and Oasis, the OSUL library catalog. To interact with LibraryFind,
we use its API to target the selected
databases chosen by the librarian and to send an http request to the web service. The search results
are displayed in a new window. Pulling course reserves from Oasis was not as easy. Since we do not
have access to the

Oasis database and it does not provide an API, we could not simply query it for the
data. Instead, we have implemented a screen scraper to accomplish the data transfer from Oasis to the
ICAP database. Because each ICAP page is required to have a subject a
nd course number (the required
attributes of an Oasis course reserve search) this made it easier to process the resulting display output
from the catalog, extract the desired data, and pass it on to the ICAP system for use in a course
assignment page. Anot
her benefit of using Rails, is that it has a web scraping library,
net/http
, which
made implementing the screen scraping program easier.


Since Rails provides so much help with building the back end, we were able to place a high priority on
the user interf
ace for the ICAP system.
AJAX and CSS are well integrated into the Rails framework,

which made adding features like drag and drop, inline help, simple forms, and helpful feedback to the
tool's interface faster and easier. The first release of the ICAP publ
ishing tool did not allow the librarians
to arrange the modules on a page. We quickly found out that this was a flaw in the design and we
needed to implement a way for them to do so. One option was to add a position field in the module
database and have th
e user enter a number in a form to indicate the position on the page. This can be
confusing, especially when working in a grid format, and did not test well. Based on feedback, we
decided to add the ability to drag a module around on a page to arrange it.
The first code snippet below
is the portion of the view that lists a page's modules. The second snippet is what we added to the code
to provide the drag and drop functionality:



/**

* Edit Modules View

* List of a Page's Modules in a two column layout

* W
ith out Drag and Drop

**/


<ul id = "right">



<%@mods_right.each do |mod| %>



<li class = "list
-
item">



<span class="list
-
title" ><%=truncate(h(mod.module_title) ,30) %></span>



<span class = 'handle'> Drag & Drop </span>



<
/li>



<% end %>


</ul>



<ul id = "left">



<%@mods_left.each do |mod| %>



<li class = "list
-
item">



<span class="list
-
title" ><%=truncate(h(mod.module_title) ,30) %></span>




<span class = 'handle'> Drag & Drop </span>



<
/li>



<% end %>


</ul>




/**

* Edit Modules View

* List of a Page's Modules in a two column layout

* With Drag and Drop

**/


<ul id = "right">



<%@mods_right.each do |mod| %>



<li


id = "item_<%=mod.id%>" class = "list
-
item">
//add a unique id
for each module



<span class="list
-
title" ><%=truncate(h(mod.module_title) ,30) %></span>




<span class = 'handle'> Drag & Drop </span>



</li>



<% end %>


</ul>



<ul id = "left">



<%@mods_left.each do |mod| %>



<li


id =

"item_<%=mod.id%>" class = "list
-
item">
//add a unique id for each module



<span class="list
-
title" ><%=truncate(h(mod.module_title) ,30) %></span>




<span class = 'handle'> Drag & Drop </span>



</li>



<% end %>


</ul>


/**Crea
te a sortable element out of each list. This makes each item in the list
(through the unique IDs)

* draggable and each list area droppable. It also highlights an item when it is moved
to provide feedback and calls a method

* that saves the new order of the

module.

**/


<%= sortable_element 'left',



:url => {:action => "save_order" },



:complete => visual_effect(:highlight, 'left'),



:handle => 'handle',



:containment => ['left', 'right'],




:constraint => false %>





<%= sortable_element 'right',



:url => { :action => "save_order" },



:complete => visual_effect(:highlight, 'right'),



:handle => 'handle',



:containment => ['left', 'right'],



:constraint => false %>



In addition to reducing development

time, effort, and lines of code
, Rails also lends itself nicely to an
agile development cycle. As expressed by the Agile Alliance [9], agile
development emphasizes:

"Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan."


Agile development can work we
ll in the library setting. Software companies have staff dedicated to
specific software development roles, such as business analyst, designer, programmer, project manager,
etc. But most libraries, OSUL included, have small technology departments, where sta
ff must fill more
than one role in the software development process. Agile development methods, by reducing processes
and documentation, lessen staff overhead needed for software development. The ICAP project team is
small, consisting of two reference libr
arians and a programmer, and has fairly broad decision
-
making
ability, which helped streamline the development cycle. Although the team was small, agile
development also allowed us to involve all stakeholders, and respo
nd quickly to their feedback.

Challen
ges

Early feedback exposed design flaws that could have kept the tool from being adopted by the librarians.
Three refinements were particularly important; the ability to move modules around on the page after it
was created, choosing one or two column layou
ts, and the ability to forgo an added chat box, or to
replace a generic chat box with their own. The design was changed, and consequently, the tool has
gained a wide acceptance with the librarians, evidenced by the large number of pages that were created
i
n the first term following the changes. As librarians used the creation tool more, minor bugs and
workflow issues were found and addressed. Later feedback led to further refinements, such as the
ability to add third
-
party widgets to the pages, and changes
to functionalities of the WYSIWYG editor.



There were some critical junctures in the project. The first was getting the right skills and personnel in
place to get the project off the ground. The second was after the first release of the tool when there
wa
s a lot of push
-
back about how it would work, what features would be included, and how it would
change librarians' workflow and level of control over course assignment web pages. The team learned
firsthand that people need time to adopt new software and th
at a high level of user involvement is
crucial in building acceptance for a new tool. The third was when
LibGuides

[10] became available.
OSUL took a careful look at whether or not to continue developing the ICAP Publishing System. We
decided to go forward

because we had a functioning tool in place, and also because we planned to
share our open source c
ode with the library community.


Conclusion

In the coming months we will add features from our original use case, such as a Feedback/Comments
module, and ext
end the tool's functionality to include creating Subject Research Guides. We will also
build in search
-
engine optimization features and supply a means to access web analytics from within
the ICAP system. Some of these features will then be added to the ope
n source code for this project.
Additionally, we will begin a new round of usability testing with students and integrate the feedback into
the ICAP system.

While we continue to evaluate this project and the tool, the ICAP Publishing System has met our ini
tial
project goals. The ultimate goal of this project is to better serve students, and the assessment data
collected from students via surveys, email and use statistics suggests that we are on the right track. We
will continue to gather evaluative feedback

from student users, learning more about their searching
preferences and research habits as we do. We also met our goal of providing librarians with an easy
-
to
-
use publishing system. Librarians have adopted the tool, enjoy using it,
appreciate

that it help
s them
incorporate Web 2.0 features, and find that it saves them time when creating course assignment pages.
Most importantly, it gives the Libraries an updated way to connect students with relevant, quality
resources at their point of need. An additional
benefit is that the new tool and the course pages it
generates gives librarians something to showcase with faculty, who have responded positively,
collaborating with librarians on pages, using the pages in class, and requesting more pages. The library
as a

whole built new capacities as a result, gaining experience with user
-
centered design, usability
testing, software development cycles, and project management. The cumulative effects of the ICAP
project go beyond the tool; the capacities gained will continu
e to benefit OSUL's future software
development projects.


Notes


[1] ICAP Publishing System: http://ica.library.oregonstate.edu/about/index.html

[2] See: Nichols, Jane and Margaret Mellinger. (2007) Portals for Undergraduate Subjec
t Searching: Are
They Wo
rth It?

portal: Libraries and the Academy
7(4) 481
-
490.

and Reeb, Brenda and Susan Gibbons. (2004). Students, Librarians, and Subject Guides: Improving a
Poor Rate of Return
portal: Libraries and the Academy
4(1):123
-
130


[3] LibData. http://libdata.source
forge.net/


[4] Library Course Builder. LibCB http://sourceforge.net/projects/libcb/


[5] SubjectsPlus. http://www.ithacalibrary.com/subsplus/


[6] LibraryFind: http://libraryfind.org


[7] See: ICAP System Wiki. http://wiki.library.oregonstate.edu/confluen
ce/display/ICATeam/Usability
and http://wiki.library.oregonstate.edu/confluence/display/ICATeam/Assessment


[8] Ruby on Rails http://www.rubyonrails.org/


[9] Agile Alliance. http://www.agilealliance.org/


[
10] LibGuides

http://www.springshare.com/libguide
s/