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. 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 Piirus.ac.uk (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: Layout Sketch of Homepage
Image 3: Layout Sketch of Detail Page