Sadly, this was also harder than I expected. Honestly, in this case, the only requirement I had was that it worked.
Custom CSS Plugin
I tested a lot of plugins (pretty much every one I could find), many of which didn’t work and were simply incompatible with the newest version of WordPress. Here are some that worked:
My Custom CSS – I liked that it colour codes and has line numbers, but it broke when I got over 700? lines. New classes that I added would be empty. I’m also not a fan of the fact that it just adds it at the top of the page instead of as an external file.
Custom CSS Manager – Pretty much exactly like My Custom CSS, but I haven’t broken it. Still unhappy that it doesn’t load an external file instead though.
Your Custom CSS – Simple, but seems to work just fine, even puts your code into an external file, which I like. Didn’t test it to 500+ lines though like I did with the previous ones.
Best Custom CSS – Works fine, can edit CSS files through built-in WP editor, only doing it that way isn’t very intuitive. It also presets CSS files instead of allowing you to set your own unfortunately.
Site Specific CSS – Turns out, most CSS plugins only work in a single site since they write to an external file and the plugin always calls the same external file. Since we’re running a Multi-Site install, I ended up with the site specific CSS plugin. It’s simple (all it does is load a CSS file you link to), but it works! Since it’s just a link, you have to edit the files externally or put it into your theme root folder (or plugin folder) to edit it in the built-in editor.
I rejected a couple of CSS plugins that seem to be no longer in development (such as WordPress.com Custom CSS) even if they (mostly) work and I used a combination of how recent there has been an update and whether developers responded to forums posts as a criteria.
Social Media (Twitter, Facebook) Sharing Plugins
On the upside, it was quite easy to find a social media sharing plugin that worked. I did have a couple of requirements for this:
Facebook and Twitter required
Share buttons (not sidebar widgets) at the bottom of each post (but not pages)
Have to be able to turn off the display of shares counters
I didn’t test a lot of them since I found a couple that work, and I was happy with one in particular. Here are the results:
Twitter, Facebook, Google Plus One Social Share – This one works great and has a lot of options including a floating box of the share buttons. The problem I had with this one is that you have more than one row of buttons, it goes beyond the div because of the display setting. I reported it, but didn’t feel like hacking it, so I went with the last one.
Really Simple Facebook Twitter Share Buttons – This one works great, plus it lets you reorder buttons, and set the width spacing. While the more-than-one-row behaviour isn’t ideal, it works. It also has a via username for twitter. It even comes with a shortcode and selective exclude method.
I’m open to suggestions on better plugins of either, especially CSS ones (for single and multi-site). Next might be form management, but if I can’t find a good free one, I might simply suggest paying for GravityForms (since it’s a one time payment).
UPDATE: Of course, then I finally find out about Jetpack almost all of which is free, including Custom CSS and Sharing. The only downside is that you need a wordpress.com account, and I am not connecting my personal account to work sites.
have manual image selection (i.e. not only through featured image on posts)
be able to set an external link for each image
some sort of navigation i.e. arrows or buttons
works with other necessary plugins for our site
2D, not a fancy 3D one (though in the future a 3D one might be nice for special collections & archives)
Preferred options include:
buttons or numbers to skip directly to a specific image
left/right arrow navigation on hover
caption text at the bottom of image
variety of choices for animation
shortcode to easily add into widget
I tested a lot of plugins (at least a dozen), many of which didn’t work. My guess is that many are dependent on its own version of jQuery and other js files that conflicted with the built-in WordPress one or incompatible with the newest WordPress in some other way.
JJ NextGen JQuery Slider looked promising, but because NextGen messes with user permissions, it was conflicting with the user management plugin I had installed. I’m wondering now if I disable that part of the plugin whether it will work.
DOP Slider works but isn’t ideal since there’s no captioning and the arrows weren’t showing up for me.
Nivo Slider for WordPress worked great. It would need a shortcode added (but that’s easy enough) and the buttons aren’t showing, which is obviously a bug, but we could probably fix it if we wanted them.
Many of the plugins are based on the jQuery Nivo Slider, which is free. Why not just use that? Well, we want our users to be able to add images themselves, and not rely on our team. The Nivo Slider developers offer a WordPress version, but it’s paid. It’s a fairly small amount though so I might recommend purchasing it instead of having to customize existing plugins, especially if it’s a one-time payment.
I’ve been meaning to post this for a while now, especially with all the presentations on Koha and Evergreen at Access 2011. This is a copy of the final assignment from the library automation and systems class (from March 2011), which I did with a partner, so about half was written by someone else. Please note that we were not using the newest versions of either ILS and while we had access to the administrative panel, we focused on a user view (patron & staff), which means that some of the options we say ‘do not exist’ may simply be a matter of an admin setting we did not change (as it was a test server for the entire class). Many of these issues may have been fixed by now, and I actually know for a fact that one of the bugs I reported was fixed. Nevertheless, I thought this piece might be useful for those either working on or looking at these ILSs.
Traditionally, libraries have purchased integrated library systems (ILSs) from vendors who make proprietary software. However, open source ILSs have become much more popular in recent years, with a number of major systems and several companies offering support (Breeding, 2009). Our task was to compare two of these systems: Koha (Bywaters version 3.03) and Evergreen (version 126.96.36.199), specifically the circulation module both through the staff client and the Online Public Access Catalogue (OPAC). A number of techniques were used in the evaluation and comparison process. Our main strategy was direct examination; we performed an operation in one system and then the other, which immediately highlighted any differences. We also consulted the systems’ documentation materials, read users’ reviews, and, at times, turned to listservs and bug reports. Our findings are laid out in a combination of narrative, charts, screen captures, and bulleted lists. For each section, we have attempted to select the medium that provides the most clarity for the user.
We considered several possible approaches to the division of work, and ultimately decided that we would each be responsible for roughly half the circulation modules. This meant that each of us had the opportunity to explore both systems in depth. The remainder of the project was divided up fairly informally, but with an eye to maintaining balanced contributions.
2. Which Version of Koha?
The recent division of Koha into two development streams, ByWaterSolutions and LibLime (PTFS), is a complex and controversial piece of recent history. Tensions exist between the major support companies in the United States and Europe (Hellman, 2010), and both lines have their supporters. However, the ByWater release seems to have gained more acceptance within the Koha community (Leonard, 2010). The ByWater website’s links point back to the original Koha community, whereas LibLime’s directs the user to the koha.org site.
In addition, a large-scale survey of libraries in 2010 showed significantly more user satisfaction from libraries using the ByWater release, particularly in the area of customer support (Breeding, 2011). According to recent postings to a library listserv (Krischel, T., February 17, 2011 [Web4Lib list]), LibLime’s release of Koha is not “uptodate” [sic]. Finally, Liblime has recently released a clients-only version of Koha. Though legal, this move raises serious questions about their commitment to the principles of open source software (Hadro, 2009). For these reasons, we chose to use the ByWater version of Koha in this analysis.
3. Observations and Findings
Below is a detailed discussion of our observations and findings for each functional area.
3.1 Patron Maintenance
3.1.1 Searching for Patrons
The patron search function is easy to use in both systems. Both handle partial inputs in searchable fields. However, where Evergreen uses ‘begins with’ searching, Koha uses a ‘contains’ and retrieves partial matches. In Evergreen, it is also easier for the user to see what fields are being searched and allows the user to use a single field or a combination of fields(see Figure 1). In comparison, according to the message on the search interface, Koha searches patron card number and name fields. This is consistent with the 3.2 documentation (as of March 12, 2011, and not mentioned in the 3.0 documentation). However, partial email matches also produce results (see Figure 2). This is not made transparent, and it is unclear to the user what fields are being searched as the search in actuality includes not only email, but also other names and user ID (Cormack, 2011).
Both systems display results with the most basic patron information, and allow sorting of results. Evergreen also allows customization of the results display and easy access to further patron details while still in the search screen (see Figure 3). It provides a button to return to the search form with the existing search still filled in. In comparison, Koha only has basic patron information display, a non-customizable results list, and no option to return to the search results (although the browser’s back button works).
At first glance, the only feature unique to Koha is the option to browse for patrons by last name. However, as Evergreen searches fields using ‘begins with’, to produce a result similar to that provided by Koha’s ‘browse by last name’ feature, the user would enter, for example, ‘A’ in the last name field, whereby Evergreen will list all patrons with a last name starting with ‘A’.
3.1.2 Adding Patrons
Adding patrons is fairly easy and straightforward. Both systems have the function available either directly from the main menu (see Figure 5) or from the main ‘Patron’ screen. The major difference here is that Koha forces the user to choose the user group to which the patron will be added. This might appear beneficial; however, the list of user groups may become unwieldy if it becomes very long, particularly because they are not automatically grouped when necessary.
Evergreen Sections and Fields
Koha Sections and Fields
Names (First, Middle, Last, Suffix, Alias)
Date of Birth
Names (Surname, First, Initials, Other)
Date of Birth; Sex
Additional Attributes and Identifiers
Favourite ColourPrevious Systems ID
Customized by admin
Phone (Day, Evening, Cell)
Phone (home, work, cell)
Email (home, work)
Names, Address, and Phone
add as many as needed
Groups and Permissions
Profile GroupAccount Expiration Date
Internet Access Level
Set as Family Account?
Claims Returned Count
Category; Sort 1, 2
Customized by admin
Patron Account Flags
Gone no Address?
Save User; Clone User
Hold Notification (set elsewhere)
Patron Messaging Preferences
Item Checkout; DUE; Check-in
Hold Filled; Advance Notice
Figure 4 – Patron Record Sections and Fields Comparison
The form itself is structured differently in the two systems. Whereas Koha has one long form, Evergreen has broken fields into sections and requires the user to select a specific section before entering the information (see Figure 5). The forms are organized a little differently as well. Koha separates the patron names, contact information, and address from their library identification (e.g. barcode number). Evergreen combines name and barcode into a single section for user identification, storing contact information and addresses separately. Other parts of the patron record also vary with the system (see Figure 4). While Koha allows more customization for general messaging (Evergreen only allows customization of hold notices only), Evergreen provides more flexibility by allowing more than two addresses. It is difficult to make a categorical statement about which is better, as it greatly depends on the needs of the organization. A nice feature of the Evergreen form is that required fields are not only marked red, but also automatically turn white when valid text is entered into a field (see Figure 5).
One very useful function that both systems have is notification of possible duplicate records based on first and last names. However, when a possible duplicate record is identified in Koha, a bug allows the patron record to be added without a card number (bug reported).
Login and password automatically generated if left blank
Can clone users with automatic grouping and shared address
Login and password automatically generated if left blank
General error handling in the patron form for the two systems is fairly similar. If the user tries to save without filling in all the required fields or entering valid information, a fairly standard error message appears. Both systems’ error messages list all the required or invalid fields (see Figure 6). They serve their purpose, but could use some improvement. One simple improvement would be to provide a definition of a valid entry (which Evergreen does to some extent, see Figure 6); for example, telling the user that a date must be in the format MM/DD/YYYY, or a name field must only use the characters A-Z and a-z.
Field validation also seems minimal. Koha allows alphanumeric and symbol entry in the name field, which seems unusual. It may not have any validation beyond requiring an entry. Evergreen, in contrast, only permits letters in name fields (see Figure 5). Both have format validation for dates, but does not restrict the range of the date, allowing card expiration date to be earlier than registration/current date, and future birth dates. In Evergreen, an error message does pop up when first entered and after saving if the birth date is invalid or a future date, but the user can still re-enter a future date and save it (see Figure 5). No authority lists seem to exist in either system as any text can be entered into ‘Country’ for example. As a consequence, more advanced validation is also not present, such as no postal code format validation based on country. In short, error messages and field validation could be improved in both systems, but particularly in Koha.
3.1.3 Updating Patron Records
Evergreen is more complicated than Koha when the user wants to edit a patron’s information. The patron must first be found through the search, their information retrieved, and ‘Edit’ clicked on. The Koha interface has an edit option directly next to each patron in its search results lists. Nevertheless, both systems provide good consistency by providing the same form used when adding a new patron. There is one difference: when viewing patron details in Koha, the user can choose to edit only one section of the patron record. This is handy for the user, as this prevents the user from having to scroll through a long form. However, since these small sections are only accessible through the patron details, whether it is an increased convenience is debatable.
3.1.4 PIN Resets
PIN resets are slightly unintuitive and problematic in Koha. Although a staff member can manually change a PIN when editing a patron’s records, random password generation is available only by clicking the ‘Change Password’ in the patron details view. Koha also has no function for the patron to reset their own password, and there is no evidence that this function has been implemented even in the latest (3.2) version. In comparison, Evergreen has a ‘Reset’ button next to the password field when editing a patron record, and the OPAC has a “Forgot your password” link with a short pop-up form that will then send an email to the patron.
The check-in/check-out module is highly accessible and supported by ample documentation in both Evergreen and Koha. It is an option on the default home page for both systems, although its position at the top centre of the screen makes it somewhat more visible in Koha.
The systems follow the same basic sequence of steps for circulating items: 1) identify patron; 2) identify item; 3) check item in/out; 4) print receipt (optional). While Koha allows you to search for patrons by name, email or barcode only, Evergreen allows you to enter a phone number or postal code as well. However, in Evergreen, a different keyboard shortcut is used depending on whether you are searching by barcode or by last name. The comparative simplicity of Koha’s interface makes it more user friendly in this area.
Checking an item out requires entering its barcode. At this point, the user also has the option of manually overriding the standard due date. In Evergreen, the date must be entered in YYYY/MM/DD format. Unless it is manually reset after checking out the item, this custom due date is applied to all subsequent items in the patron’s check-out session.
Koha’s custom due date feature appears more user friendly at first – it includes a drop-down calendar, for instance. A check box in the custom date area is labelled ‘Remember for session’, implying that settings will default to standard if it is left unchecked. However, here there is a glaring error: unless changed back manually, the custom due date remains in effect for the duration of the session, even if this box is left unchecked. Koha 3.0 also does not require any validation for setting custom due dates (see Figure 7, which shows a due date well in the past). This is clearly a problem, though it is fixed in Release 3.2.2. (Nighswonger, 2010).
In both systems, warnings and/or error messages pop up when the user attempts to check out an item to a patron who has fines or has exceeded the maximum number of items on loan. The specifics of these settings can be adjusted in the Administration area.
Since libraries accept book returns even when closed, an important feature of circulation modules is the ability to ‘roll back’ the due date of an item as it is checked in. This function is provided by both Evergreen and Koha, but is more straightforward in the latter system. Koha’s ‘dropbox mode’ can be programmed to automatically roll back the date according to a preset pattern – it ‘knows’ when the library was last open. In Evergreen, the user must enter the date manually.
The overall functionality of the two systems is very comparable for the check-in/out module, though Evergreen offers better support for federated libraries. Koha’s ‘Independent Branches’ function allows for basic sharing of material and patrons to be turned on or off, but is less flexible than Evergreen and does not have more nuanced separation features: either every branch set its own policy, or all branches share a single group of settings. In contrast, Evergreen offers finely granulated levels of access. However, Koha’s well-designed interface makes it a better choice here unless users are working at a large, federated library system with multiple branches.
3.3 Renewing Items
Both Koha and Evergreen support consortia in this area, allowing renewal policies to be set on local and on group levels. Also common to both are administrative options to allow staff override of renewals and custom renewal dates. Setting a custom renewal date requires two steps in Evergreen: first renewing the item, then extending the due date. It is possibly to simply extend the due date, but this will not count towards item renewals. Another minor inconvenience is the need to refresh the screen after renewing; the new date doesn’t appear automatically. The number of renewals allowed depends on the item’s Circulation Modifier, which is controlled under in the ‘Local Administration > Circulation Policies’ area. In the test case, the default circulation policy was recently adjusted to allow two renewals for items that do not specify their Circulation Modifier in the ‘Item Details’ area as for many users, it was previously causing problems by not allowing any.
The Koha staff client suffers from slightly more serious usability issues. The renewal function can be found in both the Details and the Check Out sections of the ‘Patron’ screen. In the ‘Check Out’ section, the function appears in multiple places (see Figure 8). The ‘select all | none’ options underneath the ‘Renew’ heading on the ‘Patron’ screen do not appear to do anything –also notice that this column does not contain any check boxes. Furthermore, the dual function of the ‘Renew or Return checked items’ is not ideal from a usability standpoint. During testing, items were appearing as ‘Not Renewable’, but it turns out the culprit was a bug in the circulation modifier rules. This option could be overridden using the check box provided (see Figure 8). However, after renewing, the status of the item reverts to ‘Not Renewable’. The user might therefore easily conclude that the renewal had been unsuccessful. The system would be improved if it provided better user feedback and more informative error messages. Error messages and alerts can be customized in the administration area, and the frustration encountered in this instance shows the importance of doing so. Finally, it would also be useful if Koha offered the option of renewing items from the ‘Item’ screen.
Renewing from the patron account is a more user-friendly option. In Koha, renewal status and renewal options appear beside checked out items in the patron account area (assuming that online renewal is turned on, which is an administrative option). Renewal status is accompanied by any necessary explanation, for example: ‘Not renewable (on-hold)’ (this particular setting, incidentally, can be adjusted in the administration area).
In Evergreen, the patron renewal interface is very similar to that found in the staff client. However, custom due dates are not an option, which simplifies things. The screen displays the number of renewals remaining, which is more helpful information than the number of renewals used, which is what Koha records. User reports do reveal one glitch: if a hold has been placed on an item, renewing that item will then be disallowed even if the hold in question has been cancelled, unless the item has been checked back in. This is an important point to be aware of.
3.4 Bills, Fines & Payment
Both Koha and Evergreen offer an extensive range of options for billing patrons and accepting payments. Please see Figure 9 (next page) for a detailed comparative summary of features.
Overdue fines can be capped at item price
Overdue rates adjustable according to item type, library branch, etc.
Processing fee for lost items remains on patron account even if material is checked in within the hour
Overdue fees can be set to vary by library, item type, and patron type
Can check ‘Forgive item on return’ or ‘Forgive overdue charges’ before items are scanned, eliminating need to write off bills later
Fines cannot be set to accrue by hour rather than by day (a useful feature for course reserves in academic libraries)
Additional programming needed (cronjob) for fines. Mode function (handles calculation and accrual of fines)
Adding, deleting, and editing bills
Bills’ ‘Full details’ button shows reason for charges
Bills’ ‘Full details’ button shows reason for charges
Only staff at owning library can modify patron’s bill
List of bill types is excessively long and vague; combines charges and credits
Can create manual invoices and manual credit
Not possible to edit bills directly, unless reversing payment
If bill for a lost item is voided, the item disappears completely from the patron’s account (no record of check out)
Patron cannot pay in OPAC (payment upon self check-out available in later versions)
Bug #705061: cannot void or pay fines from booking reservation overdue fines
Clean, simple interface (particularly in comparison to Evergreen’s pop-up screens)
Options to accept payment or write off fines
Patron cannot pay fines through OPAC
Partial payment not possible, except by using manual credit feature
Staff client: Method and time of payment not shown
Accessing account history
History of fines, payments, and current balance accessible through OPAC and staff client
As mentioned, if bill for a lost item is voided, the item disappears completely from the patron’s account
Patron can view outstanding charges and payments in OPAC
No payment history available in staff client
Figure 9 – Summary of bills, fines, and payment features in Koha and Evergreen
3.5.1 Placing/Editing Holds
Adding a hold is easy to do in both systems. Evergreen has an option from the main menu, and Koha has the option from the search results page. Koha has a convenient list of existing holds when placing a hold for a patron, whereas in Evergreen, the user must find the option from the ‘Actions’ menu. Nevertheless, Evergreen as greater flexibility than Koha when placing a hold at specific level (i.e. meta-record, title, volume, copy, see Figure 10). Though this function is not immediately obvious in Evergreen, it is well documented and can be learned quickly. Evergreen hasthe problem in that a held item will show as “Available” until the staff changes the status, and in Koha, this happens some of the time (known bug).
One feature both systems lacked was listing the number of total holds on an item, or the hold place of a patron. Without this feature, patrons may become frustrated if they have to wait a long time and may frequently take up staff time by inquiring about their holds. [I’ve been told this is in both, but it’s not obvious.]
Can change options including notification, start/expiration date, acceptable alternate formats
OPAC:generally same steps and options, but patron only allowed to hold at meta or title level
Editing: staff and patrons may change status, notification, pick-up location, activation and expiration dates, and cancel holds
Can change options including start/expiration date, select first available or specific copy
OPAC: same steps, except use “Place a Hold”, same options
Editing: staff can edit priority and pick-up location (from item record), both staff and patron can cancel holds (from patron record)
3.5.2 Holds Pull Lists
Selection from main menu (‘Circulation’)
Sortable and print option
Can also list holds ready for pickup
No function for creating a list of holds waiting for copy
From circulation menu
Refine results by date, sortable (no specific print option, but can do that from browser)
Can also view ‘Holds queue’ for specific branch or all, ‘Holds awaiting pickup’, and ‘Holds ratios’
Both systems are fairly with nice additions such as sortable fields. However, Evergreen seems to have no function to report a list of currently unfulfilled holds (and none of the available documentation suggests this function is in the new version).
3.5.3 Holds Capture
Can be entered by staff when pulls from shelf
If item on hold checked in, staff notified with basic information
Hold slip printed and notification sent out
Can check out an available item that another patron has put on hold with no notification (even if on pull list, notification only if item has hold capture already set)
Cannot manually change status of item to on hold
If item on hold checked in, staff notified with basic hold/patron information
Confirm (and transfer if necessary) with option to print out slips
If trying to check out item on hold, staff is notified
Hold capturing is definitely much better in Koha, and integrates well with its other functions. In Evergreen, when a patron puts a book on hold, it is not automatically marked as such and an item can be checked out by another patron if the patron takes an item off of the shelf before a staff member pulls it. Although the details are not clear, based on the documentation (2010), Evergreen also seems to send a notice to the patron when the item they placed on hold is checked in, and not when the item is ready for pickup. Clearly, Evergreen can use some improvement, particularly inintegrating their holds function with the rest of the circulation module.
3.6 Changing Status of Items
Search for item and choose status from ‘Actions’ menu
Can mark ‘Damaged’ or ‘Missing’
To change back, item is checked in
Can mark ‘Lost by Patron’ or ‘Claim Returned’ through patron record
Fines are calculated automatically, refunds are not even if an item is found
To unmark these statuses, item is checked in and changes to reshelving
Search for item and choose ‘Items’
Can mark ‘Lost’ (‘Long overdue’, ‘Lost’, ‘Lost and paid’, ‘Missing’), ‘Damaged’, and/or‘Withdraw’
Change back on same screen
If marked lost while checked out by patron
Fines are calculated automatically including refunds
When unset or checked in, item becomes ‘Available’ once more (no reshelving)
Although the two systems have similar functions, they handle them differently, presumably according to how the functions are integrated with the rest of the system. In both systems, item status can be changed through item search or through patron records. However, whereas Koha always takes the user to the item screen (and fines are calculated automatically based on its previous status), Evergreen gives the user different options depending the view. While Koha gives the user a more consistent interaction, Evergreen is more dynamic. Whether one is better than the other comes down to personal preference in this case. Nevertheless, Koha’s consistency may allow the novice user to learn the system more quickly. Evergreen, with its need for an item to be checked in before its ‘Lost’ status can be removed, is less intuitive.
Koha gives the user more options when marking an item as ‘Lost’, but Evergreen has the added benefit of having a ‘Claim Returned’ status for the patron. Workarounds are possible in Koha, but would need to be noted manually, which would not allow for automatic reports or statistics of the number of items that are claimed to be returned. However, Koha automatically calculates refunds when lost items are returned, which saves time for user and patron.
3.7 Changing Load Period
Changing the loan period, for example, of DVDs for juvenile/young adult patrons is very easy in Koha. A table in the section ‘Administration > Circulation and Fine Rules’ allows loan periods to be modified according to library, patron type, and item type (see Figure 11). In this case, the user would select the patron category ‘Child’ or ‘Young Adult’ and the item type ‘DVD’. Such a rule might already exist; fortunately, it is also easy to change it. According to the interface instructions, ‘To modify a rule, create a new one with the same patron type and item type’. The new rule will replace the existing one.
Evergreen comes with a set of ‘Circulation Modifiers’. These are categories designed to “control circulation policies on specific groups of items” (Evergreen, 2010). One of the default modifiers is DVD. It is possible to set three different loan durations for a Circulation Modifier: ‘Short’, ‘Normal’, or ‘Long’. This feature is typically used to control the circulation of DVDs on the item level. However, it is also possible to link a loan duration to a particular patron group. The local administration options can be set to allow patrons in the juvenile/YA permission group to take out DVDs for the two-week period and adults for the one-week period for example.
If one had a section of DVDs that were marked specifically for juvenile/YA patrons, another option would be to create a new Circulation Modifier to accommodate this. This too would be done in the administrative section. As in Koha, this can be done on the branch level or across the system. However, Evergreen has more advanced options for consortia; it allows clusters of branches to share settings, whereas Koha either applies one setting to all branches or requires each branch to set a policy independently.
4. Documentation & Help
Documentation for Koha 3.0 is not complete and seems to focus mostly on back-end settings. As the documentation is in a single PDF file, it is not easy to skim through, a little difficult to navigate without a linked table of contents, and has image markings in the wrong places. Novice users may be daunted by the casual use of technical terms and concepts. The Koha 3.2 documentation is much better in comparison. It is more complete, includes screenshots,and appears to be designed more for the end-user. This difference may be attributed to the fact that the 3.0 documentation was a student project, whereas the 3.2 documentation is a continuing community effort. Although Koha 3.2 differs from 3.0 in a few areas, we found its documentation material very helpful in our evaluation and frequently referred to it.
The Evergreen 1.6 documentation has fewer images and screenshots, but provides many step-by-step instructions and explains its terms when appropriate. On the whole, the text is better organized and easier to navigate, making good use of numbered and bulleted lists.
Informal support communities, such as listservs and wikis, are readily available for both systems. However, the schism in the Koha community has the potential to cause some confusion among users. LibLime refers users to a new support site, Koha.org, while the older communities are dominated by ByWater users. There is considerable overlap in their coverage, but they are discussing different systems.
Koha’s interface is friendlier and more streamlined than that of Evergreen. Modules integrate well with each other, as seen with automatic fine refunds and holds capture. It is generally more intuitive for users, even considering its sub-standard documentation for the 3.0 version since the 3.2 documentation can provide some support for users of earlier versions.As the staff client is web-based, there is also less maintenance needed. The OPAC also has the added features of allowing patron tagging, comments, and reviews. Müller (2011) also did an evaluation of several free and open source software ILS based on software licensing, community, and functionalities for large libraries, and found that Koha was the leader in all three categories and was the only to pass the full evaluation. Nevertheless, Müller advises that Evergreen should also be seriously considered, which may be all the more true with the recent release of Evergreen 2.0.
Evergreen provides more flexibility and functionality for consortia (see Figure12). In addition, our analysis above found a number of features that, though available in both systems, were designed better in Evergreen (PIN resets, for example). Furthermore, its documentation is superior to that of Koha.
Settings for Groups
Multiple Branch Managements
Floating Collection Management
Granular User Permissions (per library)
Figure12 -Consortial features in Koha and Evergreen (RSCEL & OS-OL, 2010)
Overall, the systems are very comparable. Libraries that belong to consortia may decide that Evergreen is the better option for them; the advantages that it offers in this area will warrant its steeper learning curve. Special libraries and stand-alone branches, on the other hand, might prefer to opt for Koha as it generally has a more intuitive user interface. Ultimately, as is always the case when selecting software, the better choice depends on the needs and requirements of the organization.
Breeding, M. (2011, January 27). Perceptions 2010: An international survey of library automation. Library Technology Guides. Retrieved February 19, 2011 fromhttp://www.librarytechnology.org/perceptions2010.pl
Hadro, J. (2009, September 22). Liblime’s Enterprise Koha sets off debate. Library Journal.Retrieved February 19, 2011 fromhttp://www.schoollibraryjournal.com/lj/technologyproductsvendors/855795-296/story.csp
Müller, T. (2011). How to choose an free and open source integrated library system. OCLC Systems & Services: International digital library perspectives, 27(1), 57-78. Retrieved March 12, 2011 from http://eprints.rclis.org/bitstream/10760/15387/1/How to choose an open source ILS.pdf
So, some people may ask, why are you trying to convert PDF to Wiki? PDF is usually the last step in the process, so just use the original document. My response would naturally be, what if you don’t have the original document?
A Two-Step Process
Through my searching and reading on the topic, it seems there is no PDF2Wiki Converter. Every site that I have read explains converting the PDF to one of: DOC, RTF, HTML, XML first then to wiki format.
I tried a number of PDF to HTML programs, but none of them worked to my satisfaction. Most of them only converted simple formatting, such as bold and italics. Adobe has an online conversion tool. It’s better than some of the others I’ve tried as it interprets lists and such. The resulting code is rather ugly and a lot of the code would need to be stripped before using a HTML to Wiki converter. See my previous post on HTML2Wiki for a couple of tools on tidying or stripping HTML code.
I found that a much better alternative was converting the PDF to a DOC/RTF file since it’s a lot simpler and some formatting might be lost, but you won’t have a lot of needless code that might mess up your wiki page. There are a lot of online tools that provide a PDF to DOC/RTF service, however, again, they only tend to do basic formatting. Adobe Acrobat does a really good job, because it will change lists into formatted lists (instead of normal text). The major downside of course is that Acrobat is a paid program though there is a 30-day trial.
I had a lot of problems in particular with PDF to HTML, so I thought PDF to DOC/RTF is simply. Honestly though, unless you have a PDF file which is really long and has a lot of simple formatting (bold, italics, etc.), if you cannot get your hands on Acrobat, then I suggest simply copy/paste (or alternatively save as a text file) and manually formatting it in the wiki’s editing box. Of course this depends on the wiki you’re using because ones that don’t have a toolbar to help you quickly format might be a bit of a pain. Someone please let me know if you have found a better method!
So to continue on ways to convert existing documents to wiki code, next is formatted text documents, which is typically word DOC files, but may also be something like RTF files.
Most sites I found actually just instructed people to use a 2 step conversion. From Word to HTML and then to wiki code. While this may work, it’s much less efficient and I can imagine more things are lost in the process. Admittedly, the converters that I have found are all geared towards MediaWiki, so if you’re using a different wiki then these converters may not work so well. Nevertheless, MediaWiki provides a list of Word to Wiki converters the most basic of which does not seem to be specifically geared to MediaWiki.
OpenOffice Sun Wiki Publisher Plugin (MAC and Windows compatible, not sure about other platforms)
(the wiki converter is built-in, the publishing part of it is optional)
The downside of OpenOffice is that it does not always interpret word documents very well. Embedded images tend to turn into hex code (ex. ffd8ffe000104a46494600010201 etc.) and tables aren’t always interpreted correctly either. The one I tried turned into overlapping text. So, in part, the usefulness of the outputted wiki code will depend on how well OpenOffice has read the word DOC itself, but it should handle ODT and RTF just fine.
Word2MediaWikiPlus Macro (Windows Only)
Word is the better choice for documents that OpenOffice can’t seem to handle very well. There is also a Word2MediaWiki Macro which is easier to use, but does not convert tables or deal with images very well.
For the OpenOffice plugin, ‘special characters’ (used loosely here) sometimes turn into weird symbols or random special characters. As with the HTML converters from the last post, something like ’ (not straight apostrophe) gets changed into ‚Äô, or a bullet point (which isn’t recognized to be in a bulleted list) turns into ‚Ä¢.
The Word2MediaWikiPlus (W2MWP) converter is better at dealing with special characters. The macro will simply insert the character as is and at times put a nowiki tag around it, but regardless, it displays just fine.
For some reason, the W2MWP plugin turns text boxes into a single cell table and then repeats the same text again as regular text (not inside a table). The OpenOffice plugin strips the text of formatting and leaves it as regular text in the wiki output.
When tables are interpreted correctly, I think the OpenOffice plugin does a better job overall. The W2MWP macro is better at keeping formatting, such as colours and border style (below right), but OpenOffice one seems to interpret things inside a table better, such as type of lists (below left). (It’s supposed to be a bulleted list, not a numbered list.)
Needs Good Original Document Formatting
In both cases, the usefulness of the wiki code will depend on how well the original document was formatted. For example, in one of the documents I tested, a number of the number and bullet lists were not formatted as such, but instead, numbers and bullets were just manually added. In both plugins, they were considered to be regular text with a ‘special’ character or number at the beginning of it.
Whether the Word2Wiki or the OpenOffice plugin is better depends on your priorities. OpenOffice seems to interpret lists and text boxes better, and doing a replace all for characters that weren’t interpreted properly is a pretty quick step. W2MWP is better at keeping formatting and interpreting all characters. So, if you like the way your document looks and you want to keep it that way, use the W2MWP macro. The big downside of course is that it doesn’t work on MACs (which I’m using right now, yay for VMware). Nevertheless, my conclusion is that the DOC2Wiki Converters are useful, but may not be the optimal solution depending on how much you’re willing to install and play around with. And if the document isn’t formatted like it should be, then manual wiki formatting might be the way to go.
So, for the past little while on and off, I’ve been looking for and playing around with HTML to Wiki Converters to see which one works best. Most of the ones I’ve found are online and most of them seem to be based on a Perl script created by David Iberri, who provides a web interface as well.
David Iberri has provided a running web interface version for his script for a lot of different wiki dialects. However, I’ve only tested the MediaWiki version for the purposes of my project. I really like the “Fetch from URL” feature which is not available on many others.
Interestingly, I found what looks to be the exact same converter on another site, but it gives me slightly different results. (see below)
Seapine’s HTML to Wiki
The one is really good for basic things and even though it does not have a “Fetch from URL” feature, you can easily copy/paste. However, this converter frequently broke for me when dealing with whole pages because it seemed to stop working when it faced something that it didn’t quite recognize.
Batch/Site HTML to MediaWiki converter
I have not actually tried this one, but I thought it might be a useful resource for later and for other people. This uses the same Perl script in combination with MediaWiki’s PHP importing scripts.
Comparison between HTML2Wiki and the berliOS version General Text
Neither deals with ’ (the non-straight apostrophe) very well for some reason, and I’m guessing it will have problems with some other characters as well. Currently, both give a � in place. However, if it’s always the same character in your wiki document, it’s easy enough to do a replace all.
Both seem to handle tables quite well and one as well as the other, though sometimes the Iberri one seems to forget to put the first line of the table code on a new line, which of course, means the table fails to work.
I would say that overall I like the berliOS version better for links because it can recognize anchor links, whereas the Iberri one will display text. For example (berliOS):
[#reserve Finding Articles on Course Reserve].
The Iberri one does a better job at “oh my god i don’t understand this” by simply stripping the HTML and leaving text. The berliOS one will try to interpret it and end up with odd things at times. However, I think it’s pretty understandable that it doesn’t handle mouse over boxes very well especially when the original script to do that is CSS and not a part of the HTML tag. For example (berliOS):
So overall, I like the berliOS one better because it recognizes more elements, but it’s easier to screw things up with it. So I would say the Iberri one is easier to use since it generally just strips what it doesn’t understand.
On a related footnote-sort note, after converting to wiki code, if there is a lot of HTML code left that seems to be messing up the wiki page, you can try stripping or ‘tidying’ the HTML code. HTML Tidy tries to make the HTML conform to current HTML standards, but depending on how the page is done, it might start creating CSS which obviously wiki pages don’t understand, so the strip HTML function may work better. Zubrag’s Strip HTML online tool HTML Tidy