12 November 2010
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
MERI
6. Next meeting 6.1. 12th November 11.00am
Notes from our meeting on 5th November
MERI
NOV 10, 2010 10:24P.M.
Our current procedures - more information
1. Ex Libris user group conference 1.1. Jenny attended the Ex Libris user group conference earlier this week, and attended a discussion on Verde which was interesting. She spoke to Richard Cross from Nottingham Trent, he is happy for us to contact him and a visit may be possible to see how they use Verde
NOV 10, 2010 09:15P.M. As the aim of this project is to produce a list of requirements for an ERM system, we first had to establish our existing processes and all the people involved, hence my interviews with various people across the Library. We discovered that a large number of people/teams are involved in the process of looking after Electronic Resources, or have an interest at least. Obvious people are those responsible for the acquisition of resources and setting up access, as well as Academic Support staff who will nominate resources for trial/purchase in the first place, and who are consulted on renewals etc. We also discovered that there is work going on in our Customer Service team to improve electronic access for external borrowers, and the staff involved need as much information as possible on which resources might be available, what level of access they might have etc. Customer-facing staff on the Enquiry Desk etc need to be able to help and advise our users when they have problems using/accessing our electronic resources. A lot of the information around electronic resources can be difficult to find - we keep information in various locations, like spreadsheets, filing cabinets, and inside people’s heads. Also, we have recently had some staff moves and transferring of certain responsibilities, so it can be difficult to know who to ask and where to look for certain information. Looking at our current processes turned out to be a worthwhile exercise, as it gave us a chance to review and update processes where necessary, and has prompted people to think about how procedures might be improved. After going over our current procedures and updating our flowcharts, we’re now working on one ‘process map’ detailing the entire process in stages, and going into more detail where appropriate. The original flowcharts are very specific to Salford, so the new format may be more useful to other institutions.
2. Meeting with David Kay 2.1. James reported on the meeting last week with David Kay from SERO Consulting (attended by JA, RF, AW, SH). David is working with JISC and SCONUL on their shared services plan, and he discussed their upcoming project in relation to ours. 2.2. The project will include around 12 institutions; they will look at their workflows and consider what elements could work at a national level. A lot of the work they will do will be similar to the work we have already done, so we would be brought in as an ‘extra’ institution 2.3. If we join the project, between November and April, we will visit about 6 of the participating institutions; work on a requirements catalogue and workflow templates for other institutions to use; look at open source systems – install, test and rate them; participate in meetings/events; rate the commercial ERMs we have seen; do a costing exercise for the workflows involved 2.4. We will still produce our list of requirements in December as originally planned 3. Feedback from ERM Demos 3.1. Charlotte has been asked for some feedback by some of the ERM suppliers. Can you please send any feedback/questions to Charlotte, particularly for the Swetswise demo as they are waiting for a response 4. Our current processes 4.1. Charlotte has been working on putting our existing workflows into another format. The ‘process map’ document is in the MERI folder on the V drive. Please have a look and make any changes/additions, or pass suggestions to Charlotte who will update it 5. Requirements document 5.1. We discussed whether any further additions need to be made to the requirements list. Jenny is doing some work on this before sending it to David Kay, so if you have any suggestions for items we have missed, please pass them to Jenny by next Tuesday
1
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
12 November 2010
CAMBRIDGE LIBRARY WIDGETS
Mashed Library event on the 25th January. The 25th will be a very much hands on event and the 26th will be a strategy-level event aimed at drawing senior library and information services staff into the discussion.
Those Advice Documents Now Online NOV 09, 2010 07:23P.M.
CAMBRIDGE LIBRARY WIDGETS
Update
The documents which started out as our final post and kind of grew, are now online.
NOV 08, 2010 02:17P.M.
So tomorrow probably marks the formal end of the project, with our actual final post, followed by the financial report, and so on. But don’t discard this blog: there should be a fair few “going live” announcements over the next couple of weeks. I’m hoping to get the Library Companion, which is a reimagining of LibX, available in alpha within the next few hours.
Sorry for the delay in updating, everyone. We’re in the process of putting together our closing remarks and have decided that there would be enough value in putting what we have into a number of permanent pages on our website, to guide future widget authors. We’re just in the process of tidying and CSS-ing them all, and they should be up in the next couple of days.
LMS MASH
In the meantime, we’d welcome comments. Please forgive the formatting.
Tabbloid #6 5-11-2010
We will create three pages: a top level page for high-level comments, and one each for writing services and widgets.
NOV 09, 2010 12:31A.M. Open publication - Free publishing - More lmsmash
Here’s the Services page, already formatted and complete: http://www.lib.cam.ac.uk/api/web_services.html And below is what we have for the top level page, and widget writing page, awaiting that formatting goodness. Comments greatfully received: though these are static pages, they’re intended to be living documents.
Last weeks Tabbloid is on the lean side with just three entries but as always it proves that quality, not quantity, wins the day - If you are interested in the techie side of VuFind then the #vufindkeven ‘Developer’s View of VuFind’ will be an illuminating read and certainly shows that even a good piece of software leaves plenty of room for improvement when being implemented. The #blathull team hit an important final milestone in their project last week and had a big aha/doh moment of enlightenment when they implemented a single, unified search index and their experience provides the programme with a useful cautionary tale for anyone else hoping to do the same - happily it sounds like they solved the mystery without too much head scratching :)
We’re building a little app store for all our widgets, which we can reveal in the next couple of days (well, we can reveal it now, but you’ll find it confusing until we fix a couple of things). I’ll announce that ASAP, along with the locations of these pages when they’re up (ETA Tuesday). We’re also finalising the project accounts. INTRODUCTION ============
Last Thursday David Kay and I had a catch up meeting with Ben Showers and over a cup of hot ginger cordial we discussed the following: - Now that a good number of the projects have submitted their final report blogposts we’ll start drawing together and reporting back on any emerging themes. Those emerging themes will be posted on this blog and comments and input from the projects will be very welcome particularly suggestions for any additional themes that you feel are key for us to include in our final report. - In the next couple of weeks Ben will be inviting you all to complete a survey to tease out further questions that we can explore in our synthesis report and also give you the opportunity to give feedback on the JISC LMS project process (i.e. using blogs to report on your progress, and the Google code site etc). - All projects are welcome to attend the strand events. The closest to confirmation is the OSS strand event which will take place on the 25 - 26 January in Edinburgh. The event is piggybacking on the Haggis & Mash
This document describes why you might want to write widgets and services to solve some of the problems in your library. The other documents in this collection are aimed at software developers. However, this introduction is for a more general audience of technically literate people, and describes motivation and general shape. Whilst the remainder of these pages require software development skills, they do not require expensive engineers: a new graduate or a librarian with a sideline in software development should easily be able to get going with them to produce something useful. Why bother with widgets?
2
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
12 November 2010
========================
lists), and so on.
Often, the biggest obstacle to overcome when explaining widgets is to overcome the frivolity associated with the concept: the silly name; their ubiquitous use on social networking sites for producing pointless distractions, and so on. We encourage you to set such preconceptions aside, at least temporarily.
Many of these containers (for example, in a VLE) have rich knowledge of the current user, too. That means that you can present “zero-click” search results, for example for exam papers: there is no need for a student even to search for the papers they are taking because the results displayed by default are usually what the user is after. (However the opportunity is presented to change this, if the user wishes).
Reason 1: Widgets reduce the risk associated with experimentation –––––––––––––––––––––—
Both of these mean that the user spends more time interacting with the real content, and less time navigating.
Widgets are small (we’re talking person-hours or -days) and easily rewritten. This allows you to take risks in creating them. If some users have indicated that a widget might be useful, you can spend half a day creating one: much less time than it would take to perform a formal survey.
Reason 3: Moving development towards specialists –––––––––––––––– Writing widgets, and particularly services, does require some development expertise, but it doesn’t require much, and certainly less than most other approaches. This makes it much easier to keep control of the development. You might have a librarian who is handy with software development. Your library might have a website maintainer who can do it. You might be able to hire someone directly into your library on a short term basis. There’s certainly no need to engage a big external organisation.
Think of how many projects there have been at your institution concerning integration of various computer systems. And think, nationally, how many projects there have been only to integrate catalogue and circulation information between VLEs with LMSes. Consider, particularly, their budgets. We have such functionality already, in production, against our enterprise sites, in use by academics and students, as a result of a small project, created by Huw Jones, a librarian. And that’s just one widget.
Recommendation ==============
Particularly at larger HE institutions, we are used to interdepartmental collaborations involving endless meetings, vague strategy, and nobody to arbitrate or direct the project below vice-chancellor level. So, what we offer to students simply ends up being disjointed.
We’d particularly recommend widget writing to institutions which have struggled, technically or socially, with integration and development in the past, and where the students are faced with a confusing array of different systems to use. Despite their silly name.
Developing software with such a low overhead allows integrations to occur “below the radar”, and “under the budget” of large, difficult projects.
Widgets document:
Reason 2: No more “you’ll need to login to another system” –––––––––––––––––––-
Introduction ============
Remembering URLs, usernames and passwords is difficult, and we seem to spend so much of our time logging into systems and finding our way from the front page to where we want to be.
Widgets are small packages of code which put information from external sources onto regions of webpages. Typically they comprise small collections of HTML, CSS, Javascript and (sometimes) XML.
As a user, widgets allow you to do things “from where you are”. There’s no “that’s in another system” issues. A user can, effectively, design their own screens to fit the way they work. There is no need to login again (auth permitting), to remember a URL, or to navigate to the page you actually want through a maze of initial pages. A screen of widgets might contain some widgets derived from the LMS, some from the VLE, some from teacher-provided data (such as reading
In their simplest form widgets contain only an “iframe” which is a window onto a website hosted on another machine. More complex widgets contain code which is to be embedded and run actually within the outer page. Widgets can usually be written in a day in a text editor, including the time spent to learn a new widget technology, if
3
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
12 November 2010
you have the appropriate services feeding you data. Widgets use services, detailed here to perform queries on underlying systems. A widget may, or may not, have access to further information from the container such as the current user, their permissions and so on.
As described above, an iframe tag is like a window in one web page onto another, often on another site altogether. One use of iframes is for widgets. By placing only an iframe into the widget code for the container, the content of the widget can come from your own server, and will be put inside the iframe by the browser.
Basic Principles ================
Some widget containers require the use of iframes. Others don’t allow iframes, your widget must hosted on the site of the widget container as HTML fragments. Many containers allow both.
* Widgets sit inside a widget container (aka portal). This can be as simple as a static webpage or as complex as Facebook, iGoogle, or a VLE. For most of the different containers which you will target, you will need to write a separate widget. However, writing a widget should be quick, and you can reuse a lot of your code.
If your container only allows one approach or the other, then you have no choice.
* Widgets execute entirely in the browser of the user. Any interactions which they need to make with your own systems takes place through the use of services.
If both are available, I recommend choosing HTML fragments first, and move to iframes if you find something easier to achieve using them. The exception is Facebook, where iframes are generally easier. This blog post is a good discussion of an alternative perspective on the iframe vs fragments issue.
* Widgets can either use iframes or not (not using them is usually called using HTML fragments). You need to decide how yours are to be implemented (see below). But changing your mind later on isn’t painful.
Typically, access to services will become the deciding factor in whether or not to use iframes.
* If you eschew iframes and use HTML Fragments, you write HTML and CSS to lay the widget out as you intend. Then use AJAX in your javascript to call services and then update the webpage.
An iframe widget is running on your server, and so can be given complete access to whatever is running on your server with little difficulty through your own programming. However, the widget is at some remove from the container, and so you will find it harder to access facilities provided by the container (for example, it may be harder to determine which user is using the widget).
* Using iframes is simpler. You write a small fragment of code to be hosted on the container, containing the iframe “window”, and then write the rest of your code on your own server.
The opposite is true of HTML fragments: they are closely embedded in the container, but further from your own systems.
* If using HTML Fragments, a container will typically help you with the javascript by providing you with libraries to perform common tasks (such as calling a remote URL for services). These may well include the jQuery or trimpath libraries of useful javascript methods. Do check particularly if jQuery is installed as, if so, jQuery can save a lot of bother. If using iframes, we strongly recommend using jQuery in your pages.
Trying, and being prepared to change if you run into trouble, is probably the best approach, until you get an instinct for this decision. Writing Your Own ================
* A container may provide you with a means of storing a user’s preferences, or you could use client-side cookies. This is useful for things like preferred layout and usernames.
If you are interested in widgets in general, but have no specific target in mind, try iGoogle Gadgets. These will help clarify the issues discussed in this document ready for when you write widgets in anger.
* Because widgets run entirely in the user’s browser, you cannot rely on what is returned for security purposes, as a user can intercept and change messages between widgets and services. (see below for help on security).
To write an iGoogle Gadget start here. This describes writing an iGoogle gadget as an HTML fragment. The “Include Gadget” on this page is an example of an iframe-based iGoogle gadget.
To iframe or not to iframe? ===========================
4
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
12 November 2010
A Camtools start page widget is like an iGoogle Gadget, and can be written and tested as such. Extra facilities are available within camtools, however. For details contact the Camtools team.
Security ========
To write a Facebook application start here. See here for a discussion of iframe vs fragment issues in relation to Facebook in particular.
Computer security is very difficult. The difficulty is not only in the coding, but in reasoning correctly. Almost everyone believes their concepts are watertight, only to be surprised by an unanticipated attack. But you will probably need to think about security when writing widgets.
To embed a widget into a static HTML page, all you need to understand is how the iframe tag works. Write your widget as for any other iframe widget and then write the relevant iframe tag and encourage others to embed it on their page. One way to encourage this is to make the code copy-andpastable from your site.
There are three main approaches to say safe. First, don’t use security, unless you have to, and then use it as little as possible. This may sound counterintuitive at first, but the fewer things there are to go wrong, the less vulnerable your system is. Do you really need to protect this data? Also, do you really need to be so fine-grained in your control? Keeping a simple undifferentiated circle of trusted individuals is likely to lead to better security than complex fine-grained restriction in many cases. The chances of one of the trusted team betraying the others is usually less likely, or has less of an impact than, the risk of a faulty complex system revealing details to the whole world.
If you want more info, talks.cam views could be valuable, as they show how such a technique is used in a live site. If at all possible, use a library like jQuery to help you write your javascript. This is always possible with iframe widgets, and often provided with HTML fragments. jQuery helps you write javascript by providing common methods for manipulating a webpage which have been extensively tested and debugged. Whilst the javascript language itself is quite simple (adding two numbers, calling a function, and so on), interacting with browsers (making something green, implementing tabs), whilst superficially simple, is very subtle if you want it to work on most browsers, and best left to the experts.
Secondly, if you do use security, use a known technique. The best are those you copy from APIs at well-regarded, popular sites. Discover the techniques they use and copy them. Thirdly, apply strength in depth. Implement as many techniques as make sense, even if they seem redundant. However, beware of unnecessarily complex systems (see first point).
Integrating With Services =========================
Useful toolkits in your armoury include: shared secrets, salts, hashes, HMACs, OAuth, Raven, Shibboleth, IP-range restriction. Google for these for details.
As described in our document on services, services are presented at a particular URL. To consume a service you need to connect to that service as if a web client. You can do this from javascript running on a user’s web browser. This is known (formally erroneously) as AJAX.
Remember, a user can change anything which is sent from their browser.
However, AJAX can only issue a request to the page’s originating server. In the case of HTML Fragment widgets this will be the widget container’s domain (eg google for an iGoogle widget). This would make HTML Fragment widgets almost worthless were it not for the additional ability to “proxy” your request through the container: a javascript function is provided by the container to allow it to issue any requests on behalf of the widget. For iGoogle these methods are detailed here.
Guidelines ========== * Keep the widget as simple as possible: make it do one thing well. Don’t dump lots of functionality into a single widget, users can install multiple widgets matching functions they choose to use. * Let users customise their widget. Your widget will be a part of their page. Issues as simple as title bars, multiple branding, and different colour schemes can be irritating in a page containing many widgets and, more importantly, needlessly consume a lot of screen space.
For iframe widgets, it will be the server from which the content of the frame was served, which may be more useful. Also, with an iframe widget you can, of course, implement server-side code to issue HTTP requests to any site of your choice.
* Consider Context. Where will your widget go? Make sure
5
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
12 November 2010
you include enough information for the user to understand what the widget does but to reduce the amount that they will already know from surrounding context. If it is to be installed in Facebook don’t say “Library Widget” say which library. On your libraries internet, however, say nothing. This site has excellent general advice about designing widgets.
6