King’s Collaborator Locator


The King’s Collaborator Locator (KoLo) project is aimed at developing a web application to connect researchers, academics and staff with similar research interests. KoLo is led by Dr K. Faith Lawrence (Department of Digital Humanities/Department of Liberal Arts), Dr Arna van Engelen (Department of Biomedical Engineering and Dr Alan Brailsford (Department of Pharmacy and Forensic Science).

As a large and multidisciplinary institution, King’s College hosts a wealth of knowledge, expertise, tools and equipment. While making it an ideal environment for research, especially interdisciplinary research, the large scale of the university and the vast array of disparate expertise makes it very challenging to find like-minded people and establish collaboration across faculties and campuses. The goal of KoLo is to help establish such connections.

Users will have the opportunity to create a lightweight profile, linking back to PURE, in which they can specify their particular areas of interest or equipment they can be contacted about. As well as suggesting general matches, users will have the opportunity to enter the desired characteristics of potential collaborators or existing research resources that they are looking for and KoLo will try and find matches for their needs.

The KoLo web application, accessible via both desktop and mobile, will be developed by the King’s Digital Lab, in conjunction with student interns and will be tested by a limited multi-faculty group of volunteers with the aim of eventually launching the application university-wide.

The KoLo project is funded by the Centre for Research Staff Development (CRSD), the Faculty of Arts and Humanities and the Department of Digital Humanities.

First ideas

During our last meeting, we discussed the general structure of the resource (navigation and data structure) and some useful functions, sketching the first draft of the project.


Firstly, we tried to imagine the possible scenarios where a user might interact with our web application.
A casual user may enter the site either through a direct link or following a search result.
He/she probably hopes to gain inspiration from fellow colleagues and/or see if there is the potential for a collaboration, but he/she might not have a specific idea about what to look for or what to expect; that’s why at least a sample of the app’s content should be provided, even to non-registered users, while displaying all the researcher profiles and published projects for the registered members.
On the other hand, the user might have a specific need in mind, or a rough idea of what to search for; hence, the application will provide a filter function to narrow down the searching scope.
When the researcher finds a person/project of his/her interest, he/she should be able to browse a detail page where the full information about the relevant item is stored.

The user may wish to gain more exposures in their research field and be informed about potential collaborations, or simply meet new people with similar interests within the scholar system.
He/she will then create his/her own profile on this application by filling in a profile form, and get recommendations for potential collaborations based on the data he/she entered.

The user might have one or several ongoing projects, and want to find an assistant/collaborator with certain skills, or a certain kind of equipment. Therefore, he/she will use the application to create a post about his/her project(s), similar to a recruitment ad. Said ad(s) should be shown in the user’s profile detail page.

The draft of the user stories and the site structure is shown below:

Image 1
Image 1. User stories and site structure

Bios and ads, the fundamentals

Before structuring the data, we studied several similar websites for reference, such as King’s Research Portal, CoFoundersLab (an entrepreneurs networking site) and (a researchers networking site). 

With consideration of the data we will have, we thought about dividing the whole app in two major branches:

  • a space for the users’ bios
  • a space for the ads

This way, it should be easier for the user (whether registered or casual)  to retrieve the data he/she is interested in.
Possibly, it will also be slightly easier to manage the link between each user and his/her ads (a single registered user will be able to upload 0 to n ads, not bounding the single profile to a precise number of ads).

Both these sections have a quite similar design: the items are displayed in blocks, each one containing a little image and some schematic information (the user will be able to read the full item, of course, by clicking on the link to the related page).
We should decide how many blocks should be displayed on the first page of each section, before the user has to browse the next page… probably 10-15 are enough.
Of course, bio-blocks will have different information than ad-blocks, related to their specific function: bio-blocks will store personal data of the researcher (eg. name, position, interests), while ad-blocks will store practical information about the position announced (eg. payment, period, location).
Similarly, both sections will have a filtering tool that reflects the different data stored.
Finally, the user will be able to see the personal page of the author of a particular ad by clicking on his/her name; on the other and, every personal page will display a list of all the ads posted by that particular person.

Adding a contact

We put quite some consideration into making the process of adding a new contact into the user’s contact list as simple and quick as possible. Ultimately, we concluded that each bio-block should have something like an “Add to contact” button that, proven the user is logged in, will automatically add said contact to his/her contact list, without changing the current page.
This will allow the user to keep searching for other contacts, if willing to do so.
Anyway, the general page structure will have a “Go to my contact lists” button, possibly near or inside the user’s profile space (where the user’s profile is showed), hence it will be always possible for the user to stop the research and check the full list of contacts.

Speaking of this: we thought it could be helpful to allow the user to store the contacts in thematic groups, in order to make the retrieval of a specific contact effortless. This mechanism should be handled similarly to a folder system: there should be the option to create a new group, name it as pleased, and then “insert” all the intended contacts (more than one, if needed, in a single operation).

After our discussion, we sketched the first draft of the page layouts Image 2
Image 2: Layout Sketch of Homepage  

Image 3
Image 3: Layout Sketch of Detail Page