COM3504/COM6504 The Intelligent Web Assignment 2022-2023
Deadline: Fri, 19 May 2023 3pm
Handin: zip file via Blackboard (see Section 8 - Submissions).
1. Introduction
This assignment will test your ability to create a web application using the methods and techniques taught in the module.
It will test your understanding of the various components of a client-server architecture, as well as your coding skills in Node.JS.
This is a group project and groups are assigned by the module leaders. The work you submit must be your own work and not plagiarised. You must NOT use any libraries that have not been explicitly recommended during the lectures, as we will regard this as use of unfair means.
2. Scenario
You will develop a “Bird Watching” progressive web application that provides users (typically bird watchers) with means to record and view Bird sightings and also to help with identification. You will need to develop this as a web application, with the supporting server infrastructure. Using the website, the users can add new sightings, view sightings and also comment on identification.
The app should allow access to a sorted list of bird sightings. The system will allow:
● Viewing sightings sorted (at least) by date/time seen, and whether identification is finished.
Sorting by distance away is a ‘stretch’ goal (i.e. nice to have). ● The addition of a new sighting
o Note that once added, most of the sighting will not be modifiable o Each sighting contains (at least)
date and time seen
location (i.e. geolocation)
a (short) description of the sighting
an identification (which may be unknown or uncertain) - this can be updated:
● the original user who sighted the bird needs to be happy with a suggestion and can update the sighting to show the identification
● The identification should be linked to information obtained from the DBPedia knowledge graph. The information includes a common name/scientific name of the bird, an english language description and a URI (which should link to the DBPedia page describing the bird).
the user’s ‘nickname’; as a string - there is no need to implement a login system o A chat/comment linked to each sighting which contains:
comments on the sighting, i.e. discussion and suggestions about what the bird is When a new sighting is added, it is accessible to all users (i.e. you do not need to implement a login
system or a set of privacy rules – when the user enters the site they will see all the sightings).
3. Design
In the sketches below you can see some initial ‘back of an envelope’ sketches of a list of sightings (left) and individual sighting detail (right). The design is left to you - please improve on the sketches below. Note that you will need to add/amend the detail on these sketches and also that you will need to add new sketches for (at least) adding a new sighting and updating the identification status. A good approach would be for the sighting detail interface to also work for adding new sightings and updating the identification.
When clicking on a sighting in the list, the individual details will be shown. For the original user who reported the sighting, this will allow them to update the ‘identification’ detail. The other details are fixed after creation, but it must be possible to chat (in real time) about the sighting. This chat is public to everyone who views the sighting. The original user might also use the chat to add more detail/s.
4. Components
The following is a list of components that must be included.
4.1 The Web Application
● The web application must:
○ be progressive
○ support online and offline interaction
○ be implemented using EJS and JavaScript in a node.JS framework.
● The web application can
○ be multimodal (i.e. provide access via multiple devices, such as mobile phone, laptop etc).
FUNCTIONALITIES
● The web application must allow creating new sightings with associated details - description, date/time, user nickname, location (which should come from geolocation or optionally selecting from a map) and an associated image (photo)
● The web application must allow viewing all sightings with associated details - description, date/time, user nickname, location (which should come from geolocation or optionally selecting from a map) and an associated image (photo)
● Sightings can be sorted by most recent and (stretch goal) by distance away (as the ‘crow flies’)
● A sighting can be selected for more detail/chat by clicking on it.
● When online, the details must be sent to the database
○ Images likely need to be transformed to base 64. Images are uploaded to the server and stored in the MongoDB database. The images can be uploaded from the file system or can be referenced using a URL.
● When the user is offline, you must allow changes to be stored locally (for uploading later), including:
○ it must be possible to create (at least) one new sighting in the browser (indexedDB)
○ It is strongly preferred for more than one (new) sighting to be held offline in the browser
○ it must be possible to add chat messages to sightings the user has newly and previously
created
○ N.B. You must not hold all sighting details offline, since only a selection will be relevant to
each user. You should keep a local copy of the list of sightings, but not all the details.
● When the device is online again, you need to:
○ firstly upload local changes to the server - this should be a safe operation and should not need to consider any server changes
Note that after this, you should be able to safely reload from the server
○ retrieve updates (i.e since last synced) to the list of sightings (retrieving everything from scratch is a weaker solution). This should be new sightings and (only) changes to the identification of sightings.
○ you should also reload any chat messages related to the user’s created sightings
○ As a stretch goal, you should notify the user of new messages in their chats (i.e. for
sightings they created).
How might you do this?
3
● The sighting creation can be implemented as a form where you provide text, a photo, etc.. The photo should be (at least) by uploading through an HTML5 form or (better) by taking a photo from the web camera - or phone camera (if you choose this option).
N.B. It is not a requirement to create a mobile web app, but you may wish to, since geolocation, camera and testing offline usage can be better on a mobile device. Note that Chrome allows you to choose to view web pages as if from a mobile device - choose developer tools then the icon
highlighted here:
Also note that Chrome (by default) insists on HTTPS for geolocation except for localhost. You will be shown in the lab how to bypass this restriction for specific hosts, including for mobile Chrome usage.
4.2 The Chat messages
●
●
The chat part of the application must:
○ be progressive
○ support online and offline interaction
○ be implemented using socket.io in a node.JS framework
○ be non blocking
The chat application can
○ be multimodal (i.e. provide access via multiple devices, such as mobile phone, laptop etc).
FUNCTIONALITIES
● When a user selects a sighting, the (live) chat must appear (likely at the bottom)
● Any new message must be visualised in real time, as it becomes available
● The user must be able to add new message/s which will appear in real time on other user’s chats
(when they have it open). As a stretch goal, users should be notified if someone has added a
message to a sighting they created.
● When online, these should update in real time.
● When offline, messages can be added to sightings that the user created, and the chat will ‘sync
up’ when online with new messages being shown and made visible to everyone viewing the
sighting detail
● Since messages are linked to a specific sighting (eventually), you might choose to store the chat
within the sighting document/object in MongoDB
● Note that messages cannot currently be edited or deleted
How might you do this?
4
You will likely ‘broadcast’ (from the server) any new chat messages with a ‘sighting id’, so the web app can choose which messages it needs to update - i.e. where the user has a sighting open - and/or should be notified since they created the sighting.
4.3 The server
● The server must:
○ be implemented using NodeJS+Express
○ must support the chat system
○ must connect to MongoDB.
4.4 Data Storage and retrieval
● Data storage must be implemented using
○ MongoDB as network DB
○ indexedDB as browser storage