Whilst discussing the way libraries will want to change, over the lifetime of the product,  the way their particular Prism tenancy looks, feels and behaves, it became clear to me that there are several subtly different processes that could be involved that are often lumped together under the heading of customisation or configuration.

Although only subtly different on the surface these activities attract different skill sets and levels in their implementation. 

This post is an attempt to clarify some of the language that will increasingly be used as Prism tenancies are rolled-out.

• Design – the process of establishing the look of your Prism Tenancy.  Defining the fonts, colours, graphics, layouts, and links to give your Prism interface a stunning look that , dependant on your requirements, either fits in with, complements, or even contrasts with the other online styles of your organisation.  This process will inevitably involve web design people from your organisation and/or ourselves.
• Configure – this is the process we are all used to. Switching on and off capabilities, deciding how many facets to display, which elements can be used to sort results, etc. The normal system manager style tasks that are required from time to time.
• Customise – the process of changing the way the core functionality of your Prism tenancy is delivered to those that use it.  This would entail the use of APIs that underpin the product, heavily customising the html used in the display, or even modifying some of the underlying code.   Obviously anyone involved in this will need significant skills in html, JavaScript, web based APIs and other similar technologies.
• Extend – Integrating links to external functionality to add the user experience.  This could be for instance a window enabling users to buy books from Amazon, or links to videos recorded by authors, or enabling a text to speech service that talks the pages to your users, or links to the full contents of books held at Google – the list is endless.  The way that you would implement these extensions would obviously differ but in general you would copy a few lines of html or JavaScript in to the tenancy’s configuration file for say the header or footer element of the pages.    These examples could then be shared between the community of Prism customers, via forums or a development environment such as a wiki.  All others, wishing to use the same extension, would need to be able to do is to paste the code in to their tenancy to test it.  The skill set required here would probably be simple html and  awareness of how to access the tenancy configuration files.

These are general descriptions of what could be involved, not all of which any customer would need to consider – especially in the early stages of moving to a Prism tenancy.  Some may never progress beyond the design and configuration stages.  Others may find over time that their efforts to extend Prism may become popular and well used by others in the Prism community that they share them with.

We are currently in the early stages of the implementation of Prism, so the ability to extend or customise a tenancy is something that is yet to be readily available.  It may be some time before the ability to fully customise becomes an option. As part of the upcoming Prism Days we will be demonstrating the type of extensions that will be possible and discussing how this will evolve.

Hopefully the explanation of some of this terminology will help as Prism, its architecture and the way it is to develop is discussed in coming months.

I would be greatly interested to hear if these descriptions are indeed helpful.