Andornot Newsletter – March 2014

by Kathy Bryce Thursday, March 27, 2014 8:13 PM

Please check out the latest issue of our newsletter.

In this Issue:
  • Archives Upgrades: The Ontario Jewish Archives, the Galt Museum and Archives, and The Elgin County Archives
  • Meet with Andornot in 2014: Our Conference Line-up
  • Inmagic News: DB/TextWorks and WebPublisher 14.5, Free Training Sessions
  • Tips and Tricks: Spring Cleanup for Inmagic Textbases
  • Tweets: Round-up of Library, Archive and Museum News

Please contact us for further information or to be added to our newsletter list.

New website for the Ontario Jewish Archives, Blankenstein Family Heritage Centre

by Kathy Bryce Tuesday, March 25, 2014 11:36 AM

The Ontario Jewish Archives, Blankenstein Family Heritage Centre (OJA) has recently launched a new website which includes two exciting new features.  Andornot has been working with OJA staff for the past seven months to build a sophisticated search interface to their archival records, and to create an interactive mapping of Jewish Landmarks of Ontario.

A wealth of content related to Jewish history in the province of Ontario is federated and now searchable from a single search box. Much of this is publicly available for the first time and includes:image

  • close to 25,000 archival descriptions
  • selected archival accessions
  • oral histories and interviews
  • historical landmarks
  • Toronto Jewish city directories
  • ship passenger manifests
  • website and online exhibits
  • images, audio, video, digitized text

The OJA came into the project with a specific vision for their site as well as a set of requirements for searching, sorting and displaying results. Results from all data sources are intermingled and facets may be selected to narrow the results by data source, the collection and description level for descriptive records, format, decade, subject, name, and place. Results can also be limited to records with images or video or other types of digital content.

Some of the neat features include:image

  • The provenance is indicated with a hierarchical tree to show the context in which descriptive records were created.
  • For website content pages, the search term is highlighted in a snippet on the results page to show context.
  • Add to a List option allows users to print selected records, or create a PDF, or email their search results.
  • Clicking on an image automatically displays an overlay with dynamically generated and watermarked larger version.

A really helpful feature when dealing with proper names and places is the Did you mean or spell checking functionality. clip_image006 So a search for Eglington will bring up a message suggesting Eglinton instead.  Even if users know the right spelling, this is great for catching typos.

The Jewish Landmarks of Ontario currently includes points of interest in the Kensington Market/Spadina area of Toronto, but will be expanding to include neighbourhoods, towns and cities from around the province.  imageThese historical buildings and sites are pinpointed on an interactive map using data in the Landmarks database, and are accompanied by photos, documents, and audiovisual material pulled from the other databases.

The website was designed by Emerson Media and is hosted on the OJA servers.  The search interface is hosted by Andornot and incorporates the same templating and styles for a seamless transition.  Updated records and images are synchronized nightly based on certain criteria, allowing OJA to choose when a record is ready for publication on the website.

OJA has used Inmagic DB/TextWorks software along with the Andornot Archives Starter Kit for many years to manage their accessions and descriptive records.  Their oral histories database was expanded for this project and we worked with the OJA to create a new, linked Landmarks database.

The search interface is built with the Andornot Discovery Interface (AnDI). AnDI is an ASP.NET MVC web application that leverages the open-source Apache Solr search engine. Solr is fast, can handle very large data sets, and has excellent and highly configurable search algorithms and relevancy rankings.  AnDI adheres to the Dublin Core Metadata standard, with imported data mapped to fields in the Dublin Core element set. This permits multiple data sources, each with different schema, to be indexed, searched and presented in a single discovery interface.   Some modifications were made to the existing OJA databases to better utilize the search features in AnDI but apart from this, staff have been able to continue their regular routines without needing to learn any new software.

The landmarks map makes use of LeafletJs, an open-source javascript library for mobile-friendly interactive maps, and the Google Maps API. AnDI's responsive and mobile-friendly UI was built with the Zurb Foundation CSS framework.

As illustrated by this project, AnDI can be applied to search multiple disparate data sources, thus providing a user friendly interface whilst allowing the archives to maintain their archivist-oriented internal systems and workflow.

We are delighted with the new site, and the feedback we have received from OJA staff has been incredibly positive:

“I would like to extend our thanks to all of you for your hard work over the last year in helping make our new site a reality. This has been a monumental undertaking for our tiny staff of three. I think the site accomplishes what we first set out to do – engage users with different interests and skill sets and expose the richness of the records that we have been entrusted to safeguard on behalf of the Jewish community of Ontario.

Your professionalism, skills and problem-solving abilities have been of tremendous value to us and we are grateful for the time that you have spent trouble-shooting to make sure that everything works at its best. It has been a pleasure working with you.“ [Donna Bernardo-Ceriz, Assistant Archivist]

Spring cleanup for your Inmagic databases. Part 4: Renaming fields

by Kathy Bryce Tuesday, March 25, 2014 9:26 AM

In the first post of this series we wrote about cleaning up the files associated with DB/TextWorks and in the second we covered rationalizing your textbase elements.The third post discussed some steps you can take to protect and maintain your textbases in good health.

In this last part of our Spring cleanup series we will discuss renaming fields. This requires the most caution and forethought, but is also advisable to ensure that new users can understand your textbases. All too often we find clients who have maintained the same textbases for years and years and see no problem with fields named AU, TI etc. It’s pretty easy to guess that these stand for Author and Title in a library catalogue, but what about some of the other abbreviations that may date from much earlier versions of Inmagic when there were limits to the field name length.  We came across a client with an LCCN field, i.e. Library of Congress Control Number. A new non library person started data entry and guessed that this field was an abbreviation for their shelf location, thus creating a horrendous mixture of entries. (We always recommend adding Automatic Date type fields for RecordCreated and RecordModified which can make cleanup of this type of mistake a bit easier.)  Field names in the current version of DB/TextWorks have a 20 character limit which is usually ample to describe the contents. We recommend not including any spaces, but visually separating words with caps or underscores as in PublicationDate or Project_Number.  If you have several databases with similar fields, you should consider giving them consistent names.

If you make changes to a field name, all DB/TextWorks query screens and form boxes simply use the new values and continue to function. Any box labels that were taken directly from the field names will however continue to show the old values.

As a precaution we always recommend making a backup or copy of the textbase before making any significant modifications.  Next, determine if there are any textbases linked to the one you wish to change. Linked fields in a Secondary textbase can be identified by viewing the Textbase Information under the Display tab, but the fields that are linked to are not shown in the primary textbase information, so you do need to understand if there are relationships between your textbases before renaming fields.

As mentioned in Part 2 on changing textbase elements, extra care must be taken if you have WebPublisher PRO, as query screens or canned searches will reference field names and will not update automatically if you edit these. Changing field names may also break forms or query screens with embedded scripts. Scripting capabilities were introduced in DB/TextWorks version 4 so pre 2001 textbases are not likely to include any. More recent textbases from Inmagic such as those in the Library Module, and those provided by Andornot will include some scripting.

If your textbases don’t have linked textbases, scripts or web access, then renaming fields can be straightforward and a great way to rationalize your textbase to make it easier for others to understand.

If you don’t feel comfortable doing this renaming cleanup yourself, contact us and we can help you on a consulting basis.

We hope you have enjoyed this four-part series on spring cleaning your databases – please let us know if there are other topics you would like us to cover!

Spring cleanup for your Inmagic databases. Part 3: Protecting and maintaining your textbases

by Kathy Bryce Monday, March 24, 2014 10:32 AM

In the first post of this series we wrote about cleaning up the files associated with DB/TextWorks and in the second we covered rationalizing your textbase elements.  In this post we’ll discuss some steps you can take to protect and maintain your textbases in good health.

Usually Inmagic DB/TextWorks textbases can function for many years without any intervention or problems. However if you do ever see a “Stop: textbase is in an inconsistent state….” message, please do NOT keep working in it! We have had clients tell us that they just ignore that message not realizing that the textbase might be corrupt. Frequently this message is just caused by a temporary loss of network connectivity while a record is being edited and can be fixed very quickly.

We recommend every so often running Check Textbase from Manage Textbases on a menu imagescreen (i.e. without a textbase open). This will detect and repair problems in the textbase and your user file. The process generally takes just a few minutes for most textbases, but can take a while for very large ones. We suggest specifying Options to Repair Structural Problems and Rebuild 10 or more Damaged Indexes (depending on textbase size). If any problems are found these will be listed in the .chk file with a recommendation for action. Running Check Textbase in this manner will clear the inconsistent state message if it was just caused by a network glitch.

As part of your regular maintenance we also recommend confirming that you have a backup routine for your textbases. We have have heard some horror stories over the years.  Two clients had fires, and two had floods in their buildings.  One of these had no offsite backup and lost several years work.  Another client had all their textbases deleted by an over zealous IT guy who didn’t know what they were and figured they weren’t important, and another client hit batch delete instead of batch modify!  For many of our smaller clients without any IT support you can always simply make a backup by copying your textbases to a USB stick and taking it home with you.

The above information applies to the non-SQL version of DB/TextWorks. Clients with DB/Text for SQL versions should ensure their IT staff are aware of the recommendations in the Administrators Guide available from the Inmagic extranet.

For more information, check out the Help file built in to DB/TextWorks, or the printable PDFfor version 13.   If you run Check Textbase and need help implementing the recommendations, please contact Inmagic Support if you have a maintenance contract, or we can help you on a consulting basis.

Spring cleanup for your Inmagic databases. Part 2: rationalizing textbase elements

by Kathy Bryce Thursday, March 20, 2014 3:04 PM

In Part 1 of this series of blog posts on spring cleaning your databases,we wrote about the various files created by DB/TextWorks and what was safe to delete.

Now that you have successfully cleaned up the various folders with your textbases, it’s time to turn your attention to the textbase elements, i.e. the query screens, forms and saved sets within your textbases. 

Hopefully you have these!  We hate to find that clients are using the default basic imagequery screen and basic forms when it is possible to create your own very easily. We have watched in horror as clients scroll down long edit screens to add information to a new field they just created which of course appears at the end of their data structure.  We recommend designing query screens and forms with fields placed side by side, grouped under logical headings to allow everything to be viewed at once without any need for scrolling. Additional text boxes can easily be added to all screens to provide helpful search or data entry hints.  So no excuses – try designing some forms – it’s not hard!

On the other end of the spectrum are clients who have created so many forms it’s not obvious which are the ones in common usage.  So they may have Report-Test or Label3 or QBE_Susan etc.  Regular users of the textbase may know which ones are appropriate, but think about our succession planning motive – how can you make it obvious to a new user which they should use?

You can see a listing of all the query screens, report forms and saved sets for a textbase under imageMaintain > Manage Textbase Elements (or Display > Textbase Information to view a printable list).  This list may show more forms than from clicking the Select Form icon, as some may be for printing or web use only.  Most will say (public) after the name – any that do not are visible to you only, and are stored in your personal user file (see Part 1of this spring cleanup series).

Caution:  if you are using WebPublisher PRO you will want to make sure you know which forms are being used in your web interface before any deleting or renaming.   If you are using menu screens or script buttons in your textbase, these too may be set to use specifically named forms. However it’s probably safe to delete ones with names such as test, report1 etc. but if in doubt, before actually deleting forms, we suggest simply renaming them.  They can then be renamed back if it is found they are still in use.   Under Manage Textbase Elements there is a Rename option.  We recommend keeping the same name prefaced with an x.  This means they will drop to the bottom of the list and it is clear that that they are pending deletion at some point.  You can also create a backup of all your forms first by selecting all of them (Shift click) and choosing Export to create an .xpf file.

It is good practice to note additional information in the Description line when you save a form, such as how it is sorted, if it is designed for a specific label size or for a particular function.  This can be invaluable when trying to ascertain years later why a form was created. We also recommend naming your forms consistently starting with an indication of how they are used, i.e. print only forms prefaced with Print as in the screenshot above.

For more information, check out the Help file built in to DB/TextWorks, or the printable PDFfor version 13. If you don’t feel comfortable doing this cleanup yourself or would like assistance designing forms or query screens, contact us and we can help you on a consulting basis.

Our next post in this series will cover maintaining your textbases in good health.

Month List