Application Outline

Application
Outline

Our
clients run a Citizen Science service which collects data from the
general public to feed in to large scale science projects. Our job is
to build a web application to support collecting data about trees.
The scientists have given us a set of attributes they want to collect
for each tree observation. Our job is to build the website to support
this and incorporate some features to motivate users to take part –
leaderboards and personal profiles.
The
back-end team is hard at work putting the server side code together.
This code, they tell us, will provide an API that delivers JSON data
and accepts form submissions to update the data collection. Our job
in the front-end team is to make use of this API to build the web
application.
There
will be six views in the application, these are outlined here. Each
page has a specific URL hash as shown here:

• Main
  Page (/): contains some summary information, list of recent
  observations, current top 10 leaderboard of users and a link to the
  form to add an observation. The user and observation entries link to
  their individual views (user profile view and observation detail
  view).

  

• Observation
  Form (/#!/submit): a view containing the form to submit an
  observation. The user will fill out the form and submit it. Once
  they have done that they will see the new observation at the top of
  their list on their profile view.

• User
  Profile View (/#!/users/): shows the brief details of the user
  (name, avatar) and a complete list of the observations they have
  made, most recent first, each observation links to the Observation
  Detail view

• Observation
  Detail View (/#!/observations/): shows the full details of one
  observation including all fields

• Observation
  List View (/#!/observations): shows the complete list of
  observations, each observation includes at least the location and
  weather fields and links to the Observation Detail view

• Leaderboard
  View (/#!/users): lists the full list of users in order of the
  number of observations that they have made. Each entry links to the
  profile view for that user.

This
will be a single page HTML application which means that only one HTML
page will be loaded from the server. It will contain Javascript code
that will construct the different views as required based on user
interaction. The URL hash is appended to the URL to indicate the
requested view, e.g. http://localhost:8010/#!/observations.
At
this point in the project, the back-end team has not dealt with
authentication yet, so we just assume that one user (Bob Bobalooba)
is logged in.

The
JSON API

The
JSON API is provided by a Python web application. You can run the
application from the starter kit with the command:
python
main.pyIt will serve pages on the URL http://localhost:8010/.
The
server provides endpoints for users and for observations. A user
record looks like this:

“id”: 0, “first_name”: “Bob”,
“last_name”: “Bobalooba”, “email”:
“bob@here.com”, “avatar”:
“http://robohash.org/Bob_Bobalooba” An observation record
looks like this: “id”: 0, “participant”: 6,
“timestamp”: “2020-04-05T01:11:52.659941”,
“temperature”: 13, “weather”: “sunny”,
“wind”: “strong”, “location”:
“Marsfield”, “height”: 24, “girth”:
2.85, “leaf_size”: “large”, “leaf_shape”:
“divided”, “bark_colour”: “red”,
“bark_texture”: “crinkles”

Adding
Observations

An
important part of the application is the form to add a new
observation. When submitting an observation to the URL
/api/observations via a POST request, all of the fields in the
observation record are required except for the id and timestamp
fields. These are added by the server and returned in the added
record.
The
other fields in the form are as follows:

• participant
  – participant id, should be a hidden field with the value 0 (since
  Bob is logged in)

• temperature
  – a numerical field

  

• weather
  – a select field with options for “fine”, “raining”,
  “sunny”, “stormy”

• wind
  – a select field with options for “none”, “light”,
  “medium”, “strong”

• location
  – a text input

• height
  – a floating point number

• girth
  – a floating point number

• leaf_size
  – a select field with options for “small”, “medium”,
  “large”

• leaf_shape
  – a select field with options for “rounded”, “pointy”,
  “divided”

• bark_colour
  – a select field with options for “grey”, “red”,
  “silver”, “brown”

• bark_texture
  – a select field with options for “smooth”, “peeling”,
  “crinkles”, “furry”, “spotty”

The
response from the server to a POST request is either a success or
failure. On success you will get a response like:

“status”:
“success”,
“observation”:
…complete observation record…

The
complete observation will include the timestamp and id of the
observation.
In
this case you should update the page to show the detail of this new
observation (the Observation Detail view).
If
the request failed (due to missing fields for example) the response
looks like:

“status”:
“failed”,
“errors”:
[“Missing required field: participant”, “Missing
required field: temperature”]

In
this case you should update the page to show the list of error
messages on the same page as the form so that the user can correct
these errors.

Testing

There
will be automated tests for the application. These will be in two
parts: unit tests and functional tests. All tests will be run with
the Cypress testing system (this runs tests on your application in a
browser and will be introduced over the next week).
Unit
tests check that your Javascript code does what it should. We will
provide unit tests for the functions that access the API and supply
the interface for the data to the rest of the application
(the Model).
Functional
tests check the actual web pages that your code generates. These
tests simulate clicks on links in the page and submission of forms,
then check for the correct response in the updated page.
Marks
will be given for passing the tests that are sup

The post Application Outline appeared first on My Assignment Online.