Apophis - Bunker app - UI prototype - admin screens

Challenge overview    

                                    

    

• Briefings about the application

We’re building an Angular web app for desktop screen resolution.

 

• Basic goal of the challenge

Develop UI prototype for Bunker Desk Toolkit Admin screens

 

• Technology and Framework details

• Angular

• CSS/SCSS

Project background    

 

The intent of this project is to create an MVP web application - Bunker Desk Tool Kit - to manage the activities currently done with a combination of excel tools and manual tasks. Using the new web application, users will be able to:

• Schedule bunker deliveries and resupply movements

• Report and communicate effectively with third-party terminals, barges, and agents

• Provide optimal blend opportunities

• Update Marketers and Traders of the status of inventories and deliveries

In this challenge, we will implement admin dashboard. Future challenges will integrate with backend API.

General requirements

 

Validation

Follow the existing code base and lint configuration

 

Layout Specification

• App will support desktop screen resolution only

 

Typography:

Use Arial font instead of Gotham that is used in the designs

 

Server Side & Client Side Functions:

Sorting/filtering is done on the server side

Platform requirements

 

- Desktop: Latest Firefox, Latest Safari & Chrome Browsers (Mac & Windows). 

 

Assets

 

Base code is available in Gitlab. See forums for access to the project repository.

Marvel app link and design assets are available in the forums

 

Application development requirements

Application has 3 types of users - Administrators, Schedulers and marketers. We have a mock login page (there will be an SSO login in the future) where you can select a user type. We will work with admin screens in this challenge.

 

All admin pages are in scope - all of them are crud forms and don’t require complex components. Swagger api definition is provided in the forums - you don’t need to integrate with the api, but you do need to use mock json data in the screens, so use the same data models - it will make integration with the api way easier

1. Regions and areas
   Remove the “Deactivate” toggle - an area can be deleted but not deactivated. Create a new user role “super admin”. Regular “admin” user can’t manage regions/areas

2. Contacts
   Phone number should be a single field with a number formatting pattern. Only a single phone and email can be entered per contact

3. Terminal companies

4. Tanks
   Remove “Tank type” and “unavailable dates” sections. Add a field to select a product that is stored in the tank

5. Products and Product specifications
   There is only one specification for a product, so essentially these two tabs manage the same entity (product)

6. Barges

7. Vessels - this screen is not in scope

8. Conversion factor
   This screen manages a simple mapping of different API values to volume conversion factors. API value can be either loaded from an existing product, or entered manually. Remove the “default value” section in the table and just show the main table with product id, API and conversion factor columns.

9. Access denied screen
   Show this screen in case the current user can’t access the route - this should be implemented across the app, not just the admin interface

10. Users and roles - this screen is not in scope

 

HTML requirements

    - HTML should be valid HTML5 compliant.

- Provide comments on the page elements to give 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 your reason for any validation errors. Use the validators listed in the scorecard.

    

CSS requirements

• Follow the existing code base css styling and avoid adding duplicate style/components - merge and refactor existing components where it makes sense to do so

• 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.

• All CSS naming should not have any conflicts.

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

• Only use table tags for tables of data/information and not for page layout.

 

JS requirements

All JavaScript must not have a 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.

 

Framework specific requirements

• Code should follow the best practices of ECMAScript 5 (ES5) or above.

• Split the code into Reusable components.

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. If a library is not commercial friendly you will 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.

Deliverables

• Submit updated code base and a demo video

 

Final Submission Guidelines

See above