辅导代写案例- COM3504/COM6504 The Intelligent Web Assignment 2022-2023 欢迎使用51辅导，51作业君孵化低价透明的学长辅导平台，服务保持优质，平均费用压低50%以上！ 51fudao.top 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). a photo (usually) 1 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. 2 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