96h Minerva Angular 9 Responsive UI Prototype 1

Challenge Objectives

• Build a UI prototype with 2 unique functional screens along with a few popups using Angular 9

 

Project Background

• The purpose of the project is to build a few screens in Angular 9 and then integrate with some mock API.

• In this 1st challenge of the series, we are building the create application and view application pages backed by data from local json files.

 

Technology Stack

• Angular 9

• Angular Internalization (i18n)

• Angular Flex Framework / Layout

• Bootstrap

• HTML5

• Javascript

• CSS

 

API Integration

Although the API is not ready yet, we have provided an API document in which you can find sample JSON responses from the APIs. You are supposed to create local JSON files in the same structure to support the UI code. Please implement local services to load data from the JSON files. The expectation is we should be able to replace the JSON files with actual API calls to integrate the app with the backend without much effort so hardcoded data is not acceptable. This is evaluated as a major requirement.

 

Common requirements

• Angular 9 must be used, and browser compatibility requirements must be covered.

• This app should be built using ngrx for state management.

• The UI should be fluid and generally responsive to different screen sizes. We have provided static HTML implementation of the pages for your reference, you can use that as a starting point but your final submission must match the design and needs to be responsive.

• Please follow the HTML for flow and functionality, but follow the design for look and feel (feature-wise the design is a bit outdated)

• Localization support should be provided (with English being the default), please provide a separate resources file to simulate the support for Arabic (can still be in English but with different texts).

• Field validation should be properly done on UI.

• CSS: No inline CSS other than (Display: none and block)

• The prototype should be responsive at least to the extent of the provided static HTML pages.

• These are evaluated as major requirements as well.

 

Screen requirements

Below is the list of screens that are supposed to be implemented in the prototype. Please cross-compare this with the design, and if you see any inconsistencies or have any questions, raise them in the forum for clarification.

 

Landing

We’ll have a very simple landing page with two links to the other two pages.

 

Create Application

• This page should call local API / services to get data that’s shown on the page on page load, please check the API documentation for details.

• No need to integrate any maps library for now, just show an empty popup as shown in the HTML page.

• The Site Study table section needs to be functional:

  • Adding record will show up in the table at the bottom

  • Editing a row will populate the details into the section above the table and remove the row from the table, the user can edit and add the updated details back to the table as a new row

  • Deleting a row from the table should show a confirmation first (use the same style as the data submitted popup)

  • When adding or editing validation should be performed, please highlight invalid fields and shown an error message below them in red. All fields are required except for: Contract Lease, Land Lease, School Name and Notes.

• Please show a loading indicator whenever the page is simulating API calls.

 

View Application & Payment

• This page is basically a read-only view of the previous page (except for the deletion feature in the bottom table)

• If the application is in progress, show a Make Payment button, and clicking that will simulate the payment submission (show a loading indicator) and then show the success popup (check the static HTML page implementation).

• Once payment is made, it will change to Accepted status and the page will become read-only (refer to the HTML page but follow design for look & feel)

• The user can click Close to change the status to Closed (should also show the loading indicator and the popup)

 

General Requirements

• Make sure you don’t just copy & paste code to create the UI, it’s very important to maintain code reusability so that integration will be easier later. This will be evaluated in the scorecard as a major requirement.

• Do NOT use global z-indexes.

• No errors with production build.

• Must pass standard lint and npm audit.

• The data to be displayed must come from local JSON files and cannot be hardcoded.

• The delivered UI must closely match the provided design.

• Must follow Angular’s best coding practices.

 

HTML Requirements

• HTML should be valid HTML5 compliant.

• Provide comments on the page elements to give a clear explanation of the code usage. The goal is to help future developers understand the code.

• Please use clean INDENTATION for all HTML code so future developers can follow the code.

• All HTML code naming should not have any conflicts or errors.

• Element and Attribute names should be in lowercase and use a "-" or camel naming to separate multiple-word classes (i.e.. "main-content", or "mainContent)

• Use semantically correct tags- use H tags for headers, etc. Use strong and em tags instead of bold and italic tags.

• No inline CSS styles- all styles must be placed in an external stylesheet.

• Validate your code- reviewers may accept minor validation errors, but please comment on your reason for any validation errors. Use the validators listed in the scorecard.

 

Code Requirements

• Provide comments on the CSS code. We need CSS comments to give a clear explanation of the code usage. The goal is to help future developers understand the code.

• Please use clean INDENTATION for all CSS so developers can follow the code.

• Do not create a single .css/.scss file for the whole app. Each component should have its own stylesheet file.

• Ensure that there are no lint errors.

• All CSS naming should not have any conflicts.

• You’re free to choose between CSS & SCSS but you need to use flex instead of float.

• Follow a clean folder structure.

• Use CSS3 Media Queries to load different styles for each page and don't build different pages for different devices/layout.

• Use CSS to space out objects, not clear/transparent images (GIFs or PNGs), and use proper structural CSS to layout your page.

• Make sure npm run build works without any errors.

 

Javascript Requirements

• All JavaScript must not have copyright by a third party. You are encouraged to use your own scripts, or scripts that are free, publicly available, and do not have copyright statements or author recognition requirements anywhere in the code. 

• Use typescript and linter for code quality

 

Licenses & Attribution

• Third-party assets used to build your item must be properly licensed or free for commercial use. MIT, some modified BSD, Apache 2 licenses are ok, but if a library is not commercial-friendly you need to get our approval first.

• Sufficient information regarding third-party assets must be present in your documentation. This includes the author, license info, and a direct link to the asset online.

 

Browser Requirements

Windows: Edge (chromium based version), Chrome latest / Firefox latest

Mac: Edge (chromium based version), Chrome latest / Firefox latest / Safari latest

 

Documentation

• Design source file (in Figma format)

• API documentation

• Static HTML implementation

Final Submission Guidelines

What To Submit

• Code that covers all the requirements.

• A detailed README file including information on how to set up, run and verify your application.